15 ms·

> 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

> 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 seen: 1) Management gives an unreasonable deadline to developers before defining the deliverables. Clock starts ticking. 2) Management then fails to settle on the requirements for months and/or continuously moves the goalposts while people are trying to work, turning an unreasonable deadline into an impossible deadline 3) Developers start realizing that they're going to receive the blame when impossible deadline isn't achieved, despite not having any control in the matter. They start leaving for new jobs, and the death spiral begins. It's the universal pattern of a management team that doesn't know how to do anything other than make demands and then apply pressure. Unless you can get someone in charge who has real leadership and planning skills, it's not recoverable.

wdb 4y ago
Sounds like a typical consultant project lol
hinkley 4y ago
> 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 things, and if money doesn’t magically appear in their accounts, which why would it? Then they don’t give you money for some of the things you usually do and while they technically didn’t tell you not to do them, if there’s no money you don’t get to do them. 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 but that’s some gaslighting BS that I hope nobody experiences, but I know people have. Best I can do is tell them to watch out for it. Some places you’re safe until FY+1, and things don’t go fully absurd until FY+2.
- MonkeyMalarky 4y ago
  This but with a cycle of on again off again hiring freezes and the inability to fill open positions from employees that became disgruntled and left.
  - nerdponx 4y ago
    "Inability"
    - MonkeyMalarky 4y ago
      Basically the crux of it. As the poster above said "gaslighing BS". If you want to cut make cuts, make cuts, don't waste our time with making postings and doing interviews just to renege on it after.
- lovich 4y ago
  > 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 college was as a VP, who explain to you how they are forcing the newly hired manager to fire someone at random to “make sure they have a backbone” 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, but we are being systematically stripped of the value we bring. If this wasn’t true then we wouldn’t be able to point towards recent events like jobs setting up a hiring cartel to depress our wages
  - cr__ 4y ago
    > 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.
kwatsonafter 4y ago
Is this the, "rolling robot turtle" Sphero?
- gedy 4y ago
  Yes correct.
gedy 4y ago
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?".
- illuminati1911 4y ago
  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!"
  - TameAntelope 4y ago
    Projects tend to need substantially less planning than people think.
    - justin_oaks 4y ago
      The joke at my previous job was "Months of development can save days of planning." The management in the company didn't plan anything and the meandering development process showed it. Please don't underplan. It's awful for morale to throw away work because of bad planning.
      - TameAntelope 4y ago
        Being willing to throw away work is the single most effective way I've seen at running an engineering org, both in terms of promoting innovation and in being able to quickly adapt to evolving customer needs as they get revealed. If your morale is harmed by throwing away work, that's something you should work on.
        danielmarkbruce 4y ago
        At google it was repeated that Sergey Brin used to say "all work is throwaway work, it's only the time horizon which is in question".
cjonas 4y ago
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 swamped dealing with the fallout. To make things worse, they keep scheduling multi-day, 8hr "planning" sessions that all key devs must attend so they can better "understand the remaining work"
- illuminati1911 4y ago
  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.
  - ratww 4y ago
    This is so common it hurts. I wonder where this comes from. Is it just hubris mixed with incompetence?
    - WalterSear 4y ago
      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.
    - numpad0 4y ago
      This happens when managers think of themselves as the engineering division and the sole isolated source of value while viewing engineers as cost associated with delivery. The proposal PowerPoint is the product and the actual product is a Proof-of-Work that could retroactively nullify pre-realized values.
      - epicureanideal 4y ago
        Wow! This is truly the best explanation of this I’ve ever heard. It explains a lot that I’ve seen.
midnightclubbed 4y ago
The story fills in all the reasons why ‘management’ start at #1. Company A buys company B for a product it believes in. Company A knows that company B was incapable of getting product to finish line, which is why they sold out. No problem though, company A has done this before… The managers at company A are assigned to ship product, just like they have before. Managers can’t say “its all good, we’ll give them a couple more devs and leave them to it.” they were told to manage, changes will be expected, planning must happen. The C level of company A just spent a bunch of money on company B. The product needs to hit positive revenue in 9 months, without positive revenue in 12 months the company will be out of cash. So management are told in no uncertain terms that they have to ship in 6 months. The contracted developers sign on to a 6 month fixed timeframe and know there will be design tweaks by the new management. At every stage everyone is doing their job. Everyone is trying to do the right thing for success and to not get fired. Everyone has a problem that can only be fixed by someone at a different level compromising on their quality of work or their personal happiness. I’m not excusing bad management or execs who looking for a rapid cash-out. Trying to illustrate how a good company can hit the same pattern.
- prox 4y ago
  So basically from the inside everything looks reasonably well, especially at the beginning?
- Kinrany 4y ago
  So company A gambled that they can turn around company B in 12 months or go bankrupt? Sounds like whoever decided to buy didn't do their due diligence.
  - midnightclubbed 4y ago
    Not necessarily bankrupt but at a point where they’d have to cut their losses by losing staff. But company B was going to be fully bankrupt before 6 months without company A stepping in. Companies make these decisions all the time, particularly in industries whose products are hit driven and then tail off.
- 4y ago
quickthrower2 4y ago
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.
- sverhagen 4y ago
  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.
  - cube00 4y ago
    It's something that comes with experience. If you've had projects like this in the past you'll recognise the early warning signs (eg. hard deadline before (even rough draft) requirements are available). You'll know it's time to start the job hunt early because there's no way it can work unless you work yourself 24/7 into the ground. It's not about accepting defeat, it's about accepting you are worthy of something better.
    - krautsourced 4y ago
      That right there. Failing impossible tasks is not a personal failure and nobody should waste their personal life on these tasks out of some sense of 'pride' or 'loyalty'. The failure lies purely with the person who made those plans. They are the ones who failed _you_, not the other way around.
    - MikePlacid 4y ago
      > You'll know it's time to start the job hunt early because there's no way it can work unless you work yourself 24/7 into the ground. Note that in this case there’s no way it can work period. The product is useless and worthless. The ring that beeps differently depending on the color of objects it hits? How much would you pay for it?
WalterBright 4y ago
Start your own company and do it right!
- beefield 4y ago
  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.
  - WalterBright 4y ago
    It's a rare employee who doesn't think he can do a better job than the manager. If he does start his own company, he'll discover his employees are sure they can do better than him. It's an immutable fact of life.
    - greenhorn123 4y ago
      And it is very rare when they actually can, most times they try or are given the chance to it fails. Almost nothing is as easy as it seems from the outside, and giving a critique is a lot easier than executing.
    - taneq 4y ago
      It’s an eye opening experience making the jump from one to the other; you realise that often the technical nitty-gritty is a small fraction of the overall business, and that the obviously technically correct decision can simultaneously be a terrible business decision.
alliao 4y ago
perhaps they are setting themselves for failure to predictably crash the stock so the supposedly acquiree can buy into bigger stacks of the supposedly acquirer's share. what seems like a acquisition may in fact be a pre agreed takeover by the smaller firm...
lkrubner 4y ago
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-project-failure-ever http://www.smashcompany.com/business/the-worst-software-proj...
irrational 4y ago
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).
speeder 4y ago
I worked in a place that died this way, and know of another place that also died this way. The place where I worked: the owner of the company was Bipolar (in the literal sense), and depending on what phase he was, he wanted different features, so every time he "switched", he changed all features, often going back and forth between two feature sets, after a while he got mad the apps were all late and not finished and fired everything and focused on his other business that was more successful. Place I had a friend that worked there: Experienced (but small) movie studio decided to make games... My friend after a while started to complain of features changing non-stop, I made aquantance to a lot of other employees for various reasons and gathering up all their stories one thing was very clear: the owner new wife often hanged around in the office, and went around demanding new features, whenever employees resisted, she called her husband (the real owner), that then proceeded to agree to whatever she asked... Until they married the project was going well, as soon they married it tanked.
blntechie 4y ago
I’m in mid of one of those exact death spirals. Finalizing a launch date before even knowing full well what the scope is. Yeah there is a general fuzzy idea of what the end goal is but that’s not what requirements are. A well defined requirement takes too much time to arrive on especially if multiple stakeholders involved, that people trivializing it really get to me.
jacksnipe 4y ago
In general it blows my mind that people don’t understand that: 1) losing a critical mass of developers is the beginning of a death spiral 2) the critical mass is smaller than you think 3) you lose the developer months before you know you’ve lost the developer
- hef19898 4y ago
  Regarding three, one dead accurate indicator is, IMHO, when people that voiced their opinions and were higjly engaged start to become quiet. This absence of "distracting noise" is sometimes even seen as a sign of improvement, in reality it is the beginning of the end. And so hard to catch, since us humans are bad at realizing things aren't there anymore.

wdb 4y ago

Sounds like a typical consultant project lol

hinkley 4y ago

> 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 things, and if money doesn’t magically appear in their accounts, which why would it? Then they don’t give you money for some of the things you usually do and while they technically didn’t tell you not to do them, if there’s no money you don’t get to do them. 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 but that’s some gaslighting BS that I hope nobody experiences, but I know people have. Best I can do is tell them to watch out for it. Some places you’re safe until FY+1, and things don’t go fully absurd until FY+2.

MonkeyMalarky 4y ago
This but with a cycle of on again off again hiring freezes and the inability to fill open positions from employees that became disgruntled and left.
- nerdponx 4y ago
  "Inability"
  - MonkeyMalarky 4y ago
    Basically the crux of it. As the poster above said "gaslighing BS". If you want to cut make cuts, make cuts, don't waste our time with making postings and doing interviews just to renege on it after.
lovich 4y ago
> 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 college was as a VP, who explain to you how they are forcing the newly hired manager to fire someone at random to “make sure they have a backbone” 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, but we are being systematically stripped of the value we bring. If this wasn’t true then we wouldn’t be able to point towards recent events like jobs setting up a hiring cartel to depress our wages
- cr__ 4y ago
  > 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.

kwatsonafter 4y ago

Is this the, "rolling robot turtle" Sphero?

gedy 4y ago
Yes correct.

gedy 4y ago

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?".

illuminati1911 4y ago
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!"
- TameAntelope 4y ago
  Projects tend to need substantially less planning than people think.
  - justin_oaks 4y ago
    The joke at my previous job was "Months of development can save days of planning." The management in the company didn't plan anything and the meandering development process showed it. Please don't underplan. It's awful for morale to throw away work because of bad planning.
    - TameAntelope 4y ago
      Being willing to throw away work is the single most effective way I've seen at running an engineering org, both in terms of promoting innovation and in being able to quickly adapt to evolving customer needs as they get revealed. If your morale is harmed by throwing away work, that's something you should work on.
      - danielmarkbruce 4y ago
        At google it was repeated that Sergey Brin used to say "all work is throwaway work, it's only the time horizon which is in question".

cjonas 4y ago

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 swamped dealing with the fallout. To make things worse, they keep scheduling multi-day, 8hr "planning" sessions that all key devs must attend so they can better "understand the remaining work"

illuminati1911 4y ago
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.
- ratww 4y ago
  This is so common it hurts. I wonder where this comes from. Is it just hubris mixed with incompetence?
  - WalterSear 4y ago
    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.
  - numpad0 4y ago
    This happens when managers think of themselves as the engineering division and the sole isolated source of value while viewing engineers as cost associated with delivery. The proposal PowerPoint is the product and the actual product is a Proof-of-Work that could retroactively nullify pre-realized values.
    - epicureanideal 4y ago
      Wow! This is truly the best explanation of this I’ve ever heard. It explains a lot that I’ve seen.

midnightclubbed 4y ago

The story fills in all the reasons why ‘management’ start at #1. Company A buys company B for a product it believes in. Company A knows that company B was incapable of getting product to finish line, which is why they sold out. No problem though, company A has done this before… The managers at company A are assigned to ship product, just like they have before. Managers can’t say “its all good, we’ll give them a couple more devs and leave them to it.” they were told to manage, changes will be expected, planning must happen. The C level of company A just spent a bunch of money on company B. The product needs to hit positive revenue in 9 months, without positive revenue in 12 months the company will be out of cash. So management are told in no uncertain terms that they have to ship in 6 months. The contracted developers sign on to a 6 month fixed timeframe and know there will be design tweaks by the new management. At every stage everyone is doing their job. Everyone is trying to do the right thing for success and to not get fired. Everyone has a problem that can only be fixed by someone at a different level compromising on their quality of work or their personal happiness. I’m not excusing bad management or execs who looking for a rapid cash-out. Trying to illustrate how a good company can hit the same pattern.

prox 4y ago
So basically from the inside everything looks reasonably well, especially at the beginning?
Kinrany 4y ago
So company A gambled that they can turn around company B in 12 months or go bankrupt? Sounds like whoever decided to buy didn't do their due diligence.
- midnightclubbed 4y ago
  Not necessarily bankrupt but at a point where they’d have to cut their losses by losing staff. But company B was going to be fully bankrupt before 6 months without company A stepping in. Companies make these decisions all the time, particularly in industries whose products are hit driven and then tail off.
4y ago

quickthrower2 4y ago

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.

sverhagen 4y ago
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.
- cube00 4y ago
  It's something that comes with experience. If you've had projects like this in the past you'll recognise the early warning signs (eg. hard deadline before (even rough draft) requirements are available). You'll know it's time to start the job hunt early because there's no way it can work unless you work yourself 24/7 into the ground. It's not about accepting defeat, it's about accepting you are worthy of something better.
  - krautsourced 4y ago
    That right there. Failing impossible tasks is not a personal failure and nobody should waste their personal life on these tasks out of some sense of 'pride' or 'loyalty'. The failure lies purely with the person who made those plans. They are the ones who failed _you_, not the other way around.
  - MikePlacid 4y ago
    > You'll know it's time to start the job hunt early because there's no way it can work unless you work yourself 24/7 into the ground. Note that in this case there’s no way it can work period. The product is useless and worthless. The ring that beeps differently depending on the color of objects it hits? How much would you pay for it?

WalterBright 4y ago

Start your own company and do it right!

beefield 4y ago
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.
- WalterBright 4y ago
  It's a rare employee who doesn't think he can do a better job than the manager. If he does start his own company, he'll discover his employees are sure they can do better than him. It's an immutable fact of life.
  - greenhorn123 4y ago
    And it is very rare when they actually can, most times they try or are given the chance to it fails. Almost nothing is as easy as it seems from the outside, and giving a critique is a lot easier than executing.
  - taneq 4y ago
    It’s an eye opening experience making the jump from one to the other; you realise that often the technical nitty-gritty is a small fraction of the overall business, and that the obviously technically correct decision can simultaneously be a terrible business decision.

alliao 4y ago

perhaps they are setting themselves for failure to predictably crash the stock so the supposedly acquiree can buy into bigger stacks of the supposedly acquirer's share. what seems like a acquisition may in fact be a pre agreed takeover by the smaller firm...

lkrubner 4y ago

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-project-failure-ever http://www.smashcompany.com/business/the-worst-software-proj...

irrational 4y ago

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).

speeder 4y ago

I worked in a place that died this way, and know of another place that also died this way. The place where I worked: the owner of the company was Bipolar (in the literal sense), and depending on what phase he was, he wanted different features, so every time he "switched", he changed all features, often going back and forth between two feature sets, after a while he got mad the apps were all late and not finished and fired everything and focused on his other business that was more successful. Place I had a friend that worked there: Experienced (but small) movie studio decided to make games... My friend after a while started to complain of features changing non-stop, I made aquantance to a lot of other employees for various reasons and gathering up all their stories one thing was very clear: the owner new wife often hanged around in the office, and went around demanding new features, whenever employees resisted, she called her husband (the real owner), that then proceeded to agree to whatever she asked... Until they married the project was going well, as soon they married it tanked.

blntechie 4y ago

I’m in mid of one of those exact death spirals. Finalizing a launch date before even knowing full well what the scope is. Yeah there is a general fuzzy idea of what the end goal is but that’s not what requirements are. A well defined requirement takes too much time to arrive on especially if multiple stakeholders involved, that people trivializing it really get to me.

jacksnipe 4y ago

In general it blows my mind that people don’t understand that: 1) losing a critical mass of developers is the beginning of a death spiral 2) the critical mass is smaller than you think 3) you lose the developer months before you know you’ve lost the developer

hef19898 4y ago
Regarding three, one dead accurate indicator is, IMHO, when people that voiced their opinions and were higjly engaged start to become quiet. This absence of "distracting noise" is sometimes even seen as a sign of improvement, in reality it is the beginning of the end. And so hard to catch, since us humans are bad at realizing things aren't there anymore.