Live data from Hacker News

Watching an acquirer ruin your company

startupwin.kelsus.com

101–110 of 347 posts

Re: Watching an acquirer ruin your company

#101
post #87
post #37

Earlier quoted context omitted.

Dealing with exactly 1 & 2 right now. #3 doesn't really apply in my case because 80% of the devs are budget staffing agency hires. But on that note, I'd add a 4th point: Management panics when they realize they won't make the self imposed deadline and start throwing bodies at the problem. In our case, we went from 2 teams to 8 over night. The very few engineers who actually were capable of shipping features became sw…

>8hr "planning" sessions One place I was at had quarterly 3 day planning sessions. That was something else.

Wait that actually sounds awesome. What we’re your issues with this practice? A 3 day code freeze while everyone works to solidify a “meeting of the minds” followed by 87 days of heads down progress sounds like fucking heaven to me compared to the weekly planning meetings on top of daily stands up I live with now.

Re: Watching an acquirer ruin your company

#102
post #60
post #10

I’ve seen this twice. First time the PE firm installed their CEO who came in and immediately started talking about cleaning house. A bunch of developers left fearing a layoff. That was bad enough, but what he really meant was sales. He gutted the sales team and brought in his guys. Sales tanked, company growth stopped, hard. Features dwindled and bugs grew. This clown and his cronies were gone after two years and the…

>He gutted the sales team and brought in his guys. Sales tanked, company growth stopped, hard. Features dwindled and bugs grew. how does a changed sales team cause features to dwindle and bugs? it's more likely that management attitudes changed when acquisitions happen - and that new attitude doesn't foster an environment in which good code gets written. It wouldn't have mattered if the sales team changed or not imho…

> how does a changed sales team cause features to dwindle and bugs?

I can think of at least two ways:

1. In many companies, sales is an important part of the window to the customer. Sales interprets customer desires and forwards them to product management.

2. If revenue drops, the company may need to cut costs too, and one stupid way to do this is to reduce development spending.

Re: Watching an acquirer ruin your company

#103

> As soon as Sphero completed the acquisition, bringing Kelsus in as an app developer, two things happened: 1) Sphero told us they needed fully revamped iOS and Android apps six months later with no schedule wiggle room. 2) Sphero spent the first two of those six months organizing a team on their side and hashing out requirements for the new apps. This exact pattern has preceded every mismanagement disaster I've ever…

The most expensive software failure ever:

----------------

The Advanced Automation System began, in concept, in 1981 and ended in 1994, “terminated for convenience” by the government. Billions of dollars were spent on it. It is hard to describe. You can’t learn anything from the name. You know it’s about air traffic control because I told you, or because you read about it in the papers. Maybe part of the problem was the name. It sounds like the system to end all systems.

...At $3.7 billion, the Advanced Automation System was one of the largest civilian computer contracts ever; maybe the largest. It was the largest single contract in IBM’s history. From the moment it was awarded, until near the project’s demise, IBM patted itself on the back. There was something for everyone, beginning with a great ball in Union Station, featuring Chubby Checker and “The Twist”.

...What I saw on the FAA’s Advanced Automation System would have made Sisyphus weep… Whatever commitment and discipline there was… was worn down by a battery of watchfulness that I can only ascribe to fear of failure. In spite of tens of millions of dollars spent on new computers for AAS, the most important piece of equipment on the project was the overhead projector. There were endless meetings attended by dozens of people – as if we were never quite sure about the whole thing. The people in charge simply lacked the confidence and the finesse of the space team: NASA, contractors, and astronaughts.

It has been noted by everyone from the New York Times to the Vice-President of the United States that the main problem on the Advanced Automation System was “changing requirements”. For those involved in large-scale computer systems, that is nothing new. No one can perfectly surmise the shape and feel of a system years in advance. Even replacing some aspect of a system you know by heart is not immune from thinking twice about it. … [But] the requirements churn (it was called) on the Advanced Automation System was not normal. It was the result of our enchantment with the computer-human interface, the CHI. The new controller workstation, fronted by a 20″ by 20″ color display, because it was capable of seemingly endles variety of presentations, mesmerized the population of AAS like the O.J. Simpson trial mesmerized the nation…

The project was handed over to human factor pundits, who then drove the design. Requirements became synonymous with preferences. Thousands of labor-months were spent designing, discussing, and demonstrating the possibilities: colors, fonts, overlays, reversals, serpentine lists, toggling, zooming, opaque windows, the list is huge. It was something to see. (Virtually all of the marketing brochures – produced prematurely and in large numbers – sparkled with some rendition or other of the new controller console.) It just wasn’t usable…

The cost of what turned out to be a 14-year human factors study did not pay off. Shortly before the project was terminated a controller on the CBS evening news said: “It takes me 12 commands to do what I used to do with one.” I believe he spoke for everyone with common sense.

Rummaging through one of the closets at the far end of the hall on the fifth floor one day, looking for some standards document, I found an envelope left by someone who left the company – as many did after so many years advancing against stone, while the wheels of commerce were accelerating on what everyone referred to as “the outside”. It contained “A Brief History Of The Advanced Automation System”. It was printed by hand and left, perhaps inadvertantly, or perhaps with the hope that some anthropologist might some day discover it and make a pronouncement. In every important way, it is the truth:

“A young man, recently hired, devotes years to a specification written to the bit level for programs that will never be coded. Another, to a specification that will be replaced. Programmers marry one another, then divorce and marry someone in another subsystem. Program designs are written to severe formats, then forgotten. The formats endure. A man decides to become a woman and succeeds before system testing starts. As testing approaches, she begins a second career on local television, hosting a show on witchcraft. An architect chases a new technology, then another, then changes his mind and goes into management. A veteran programmer writes the same program a dozen times, then transfers. The price of money increases eight times. Programmers sleep in the halls. Committees convene for years to discuss keystroking. An ambitious training manager builds an encyclopedia of manuals no one will ever use. Decisions are scheduled weeks in advance. Workers sit in the hallways. Notions of computing begin in the epoch of A, edge toward B, then come down hard on A + B. Human factors experts achieve Olympian status. The Berlin Wall collapses. The map of Europe is redrawn. Everything is counted. Quality becomes mixed with quantity. Morale is reduced to a quotient, then counted. Dozens of men and women argue for thousands of hours: What is a requirement? A generation of workers retire. The very mission changes and only a few notice. Programming theories come and go. Managers cling to expectations, like a child to a blanket. Presentations are polished to create an impression, then curbed to cut costs. Then they are studied. The work spikes and spikes again. Offices are changed a dozen times. Management retires and returns. The contractor is sold. Software is blamed. Executives are promoted. The years rip by with no end in sight. A company president gets an idea: make large small. Turn methods over to each programmer. Dress down. Count on the inscrutability of programming. Promote good news. Turn a leaf away from the sun. Maybe start over.”

http://www.smashcompany.com/business/the-worst-software-proj...

Re: Watching an acquirer ruin your company

#104
post #53

Earlier quoted context omitted.

Classic. And when you tell incompetent management that 9 women can't deliver a baby in a month, they'll proceed to try with 10 women.

This is so common it hurts. I wonder where this comes from. Is it just hubris mixed with incompetence?

Mixed with desperation and ignorance. Managers only have so many levers they can push to course correct a situation.

But, it take hubris and incompetence to get there.

Re: Watching an acquirer ruin your company

#105
post #63

Earlier quoted context omitted.

https://cs.github.com/about

Does it work as good as grep though? I have to resort to grep all too often to search for a snippet of code in a project on Github.

It can't be, because it'd be trivial to DoS if so.

Re: Watching an acquirer ruin your company

#106

> As soon as Sphero completed the acquisition, bringing Kelsus in as an app developer, two things happened: 1) Sphero told us they needed fully revamped iOS and Android apps six months later with no schedule wiggle room. 2) Sphero spent the first two of those six months organizing a team on their side and hashing out requirements for the new apps. This exact pattern has preceded every mismanagement disaster I've ever…

As we all know, the problem is they reverse 1 and 2. They shouldn’t be trying to establish a deadline until the have the requirements locked down. Of course, locking down the requirements is the hard part and business people really are bad at it (in my experience).

Re: Watching an acquirer ruin your company

#107
post #81
post #26

Earlier quoted context omitted.

> and the death spiral begins. The death spiral becomes visible, really. The gun had already been fired, the body just hadn’t hit the ground yet. I must say these failure modes are much worse than the ones I’ve experienced, which maybe I should be grateful for, I’d have to think about this. Generally I’ve seen a slower burn, where the remaining fiscal year plays out with soothing tones and promises of not changing th…

> I don’t know which business school teaches people to say “ah can you smell that fresh mountain air” while they have their hands wrapped tightly around your neck … It’s all of them and the higher you get into management the more apparent it is. They sell a system of meritocracy where those who work the hardest get the rewards. Then you get into management and working side by side with people whose first job out of c…

> Software engineers have been tricked into thinking they are part of the in club because they are paid well enough to have the lifestyle that the middle class had between ww2 and the 80s

This, and additionally we've been tricked into feeling guilty about it as well.

Re: Watching an acquirer ruin your company

#108
post #28

Earlier quoted context omitted.

Agreed, and while it's become fashionable to trash on "agile", this sort of thing is why I still prefer it to alternatives. Basically "what do you want next?".

Problem is not the agile, but useless sinecure managers trying to rebrand "agile" as something in which projects don't need planning, can be completely chaotic and any requirements can be changed at anytime without affecting the deadline. "Hey we don't really need to make any decision ever or even know what we are doing. That's the great thing about agile!"

Exactly ... I call that the frAgile methodology and managers seem to love that.

Re: Watching an acquirer ruin your company

#109

> As soon as Sphero completed the acquisition, bringing Kelsus in as an app developer, two things happened: 1) Sphero told us they needed fully revamped iOS and Android apps six months later with no schedule wiggle room. 2) Sphero spent the first two of those six months organizing a team on their side and hashing out requirements for the new apps. This exact pattern has preceded every mismanagement disaster I've ever…

Start your own company and do it right!

Trouble is that management seems to be a P != NP type problem. Really easy to tell when done wrong but really difficult to get right - for variety of reasons.

Re: Watching an acquirer ruin your company

#110

Earlier quoted context omitted.

Word to the wise: start looking for a new job when that clock starts ticking. You may decide to stay but great to have something else to parachute into as an option. Second thing: you can change jobs as often as you want. I am for loyalty but you can’t know what a job will be like until you work it.

This may be good advise, but I hate it. Personally, I couldn't put my heart into the job hunt, while at the same time giving my best at the current job. In other words: just the step of starting to search for a job is for me synonymous to accepting defeat at the current job.

I would look it more like what freelancers have to do. Keep marketing yourself. The process of job hunting can clue you into trends and keep you current. I worked with someone who modernized our tech stack due to things he learned on a job search where he never left due to that search!
Post reply on HN