Our project has been 90% complete for a year now...
March 22, 2012 7:23 AM Subscribe
Why are software development estimates regularly off by a factor of 2-3? Scroll down a page to learn why writing software is like a horror hike from San Francisco to Newport Beach.
Irrational optimism. Linked paper has a copyright date of 2003.
Maybe the question should be, "Why do we keep doing software estimates?"
posted by Currer Belfry at 7:48 AM on March 22, 2012 [1 favorite]
Maybe the question should be, "Why do we keep doing software estimates?"
posted by Currer Belfry at 7:48 AM on March 22, 2012 [1 favorite]
I think it's pretty obvious. I, the PM, go off and talk to the dev team. The req's the biz have given me are vague and hand-wavy, but with my knowledge of the biz, I've fleshed them out to a point where I can explain to a dev team the full gist of the requirements and scope. Dev team say 'well, based on what you just told us, we say X days'.
Me, knowing that there wasn't really enough info or time for the dev team to really dig in and ask questions because the biz says 'this project is critical, we dont' have a lot of time for red tape', does the smart thing and tells the biz it will take X times 4 days to do, including an more thorough req's and spec'ing phase, plus I'd like to add another 14 days for QA and bug fixing.
The biz says 'no, this is an urgent project, it has to be done in X minus 5 days'.
I say 'ok then we need to pull out a lot of this scope'.
Biz: no this is critical.
ME: never gonna happen
Biz: why are you always so cynical? Let's get started. Hey marketing team, tell our customers it'll be ready on X minus 5 days.
FAIL
posted by spicynuts at 7:50 AM on March 22, 2012 [42 favorites]
Me, knowing that there wasn't really enough info or time for the dev team to really dig in and ask questions because the biz says 'this project is critical, we dont' have a lot of time for red tape', does the smart thing and tells the biz it will take X times 4 days to do, including an more thorough req's and spec'ing phase, plus I'd like to add another 14 days for QA and bug fixing.
The biz says 'no, this is an urgent project, it has to be done in X minus 5 days'.
I say 'ok then we need to pull out a lot of this scope'.
Biz: no this is critical.
ME: never gonna happen
Biz: why are you always so cynical? Let's get started. Hey marketing team, tell our customers it'll be ready on X minus 5 days.
FAIL
posted by spicynuts at 7:50 AM on March 22, 2012 [42 favorites]
spicynuts, that story is so familiar that I felt my body tense up just reading it. That was the MO for every single project at my previous company, and a big part of why it is previous. Unfortunately, I have to say that my estimates are still off by a factor of about two, and now I have only myself to blame, although it can go either way (i.e. sometimes I finish that project in half the time I specified).
posted by Edgewise at 7:56 AM on March 22, 2012
posted by Edgewise at 7:56 AM on March 22, 2012
I don't know in software, but in biology there's a rule - however long you think the experiment will take to complete, multiply by two. You always forget to account for steps without time limits - things like labeling the tubes and waiting for centrifuges to spin up and down.
BTW, multiplying by two is still often underestimating. Stupid science.
posted by maryr at 7:59 AM on March 22, 2012 [4 favorites]
BTW, multiplying by two is still often underestimating. Stupid science.
posted by maryr at 7:59 AM on March 22, 2012 [4 favorites]
It'd be great if projects were divided into two phases with actual initial project planning (including estimates) happening in the first phases with final estimates happening after real requirements (not just, to use the metaphor, the red line from SF to Newport Beach), but that becoming standard is about as likely as me hiking from SF to Newport Beach (not fucking likely)
(This is probably an obvious point to everyone who cares about such things but it's the type of thing that would make my life so much easier that I can't help to put it out there as often as possible.)
posted by MCMikeNamara at 8:01 AM on March 22, 2012
(This is probably an obvious point to everyone who cares about such things but it's the type of thing that would make my life so much easier that I can't help to put it out there as often as possible.)
posted by MCMikeNamara at 8:01 AM on March 22, 2012
BTW, multiplying by two is still often underestimating. Stupid science.
Remindings me of my father's approach to builders' estimates:
"Take the highest one. Multiply it by two. Then multiply it by two again. Then throw it away and pray."
My father is an architect.
posted by Skeptic at 8:02 AM on March 22, 2012 [11 favorites]
Remindings me of my father's approach to builders' estimates:
"Take the highest one. Multiply it by two. Then multiply it by two again. Then throw it away and pray."
My father is an architect.
posted by Skeptic at 8:02 AM on March 22, 2012 [11 favorites]
Wait, what? So software development estimates are usually off by a factor of 2-3 because developers are stupid and naive? Somehow that doesn't sound right to me. The theory spicynuts gives makes a lot more sense as far as the real world is concerned.
The hiking thing is a nice metaphor, but it's more like a forced march where our "friends" demand from the start that we do something completely impossible.
posted by koeselitz at 8:03 AM on March 22, 2012 [5 favorites]
The hiking thing is a nice metaphor, but it's more like a forced march where our "friends" demand from the start that we do something completely impossible.
posted by koeselitz at 8:03 AM on March 22, 2012 [5 favorites]
Take the developer's estimate, multiply by 5. Then add 50% billing markup cuz that's how we roll, dawg
posted by Doleful Creature at 8:03 AM on March 22, 2012
posted by Doleful Creature at 8:03 AM on March 22, 2012
What I love is when you give an estimate, a manager doesn't like it and digs up some ridiculous optimist to give a "better" estimate, then when it takes as long as you said it would you're still considered "wrong".
posted by Artw at 8:07 AM on March 22, 2012 [6 favorites]
posted by Artw at 8:07 AM on March 22, 2012 [6 favorites]
I think developers are self-selected from a group that is more optimistic than the norm. I mean, development is an activity where you aim to do what noone else has done before, or at least do it better than anyone else. What can be more optimistic than that? So managment goes to this group, which on average is an optimistic lot, and ask for estimates. Of course they are going to get an optimistic estimate.
Pessimist conclude from the get-go that all development is doomed to failure, and choose other paths in life.
posted by Harald74 at 8:08 AM on March 22, 2012 [4 favorites]
Pessimist conclude from the get-go that all development is doomed to failure, and choose other paths in life.
posted by Harald74 at 8:08 AM on March 22, 2012 [4 favorites]
A related problem is when an estimate - as in, a couple of developers throw ideas back and forth for a while and come up with "about two months I guess?" - turns into a deadline. "About two months" is now "We will deliver in two months," with no appreciation that the estimate, even if accurate, could be high or low. But heaven forbid the developers tell you upfront that it could easily take four months, because come on, it can't possibly take that long to just add this little itsy bitsy feature, right?
posted by Tomorrowful at 8:10 AM on March 22, 2012
posted by Tomorrowful at 8:10 AM on March 22, 2012
As someone on the QA end of this let me tell you it sucks. We always pay the price in having our time cut short to accommodate the devs underestimates. So instead we make sure to pad our time as much as we can get away with.
posted by popaopee at 8:11 AM on March 22, 2012
posted by popaopee at 8:11 AM on March 22, 2012
Here's a vague idea in a PowerPoint deck written by people who have never built anything that vaguely resembles software; there's a fixed timeline and budget that's already been set and we were supposed to start building this thing two weeks ago.
This is how I spend every day that ends in "y".
posted by ryoshu at 8:12 AM on March 22, 2012 [1 favorite]
This is how I spend every day that ends in "y".
posted by ryoshu at 8:12 AM on March 22, 2012 [1 favorite]
In the hiking analogy, you'll find out halfway that one of your team was actually hiking to Fresno ("Oh, I was working on some cool tools that will help productivity in the long run!"), two of your team have absolutely no idea how to hike like a professional and the most skilled hiker has just told you he'll be going to Palo Alto instead ("Sorry man, Facebook pays better!").
posted by rh at 8:14 AM on March 22, 2012 [6 favorites]
posted by rh at 8:14 AM on March 22, 2012 [6 favorites]
developers are stupid and naive
I have never met a stupid developer. I've met one or two naive ones but that's cuz they were a week out of college in the big city - who wouldn't be a little naive. I have met developers with varying levels of competency or professionalism. Regardless, none of that matters if:
A) a business fails to commit to the idea of disciplined, up front thinking and planning including 'what is the problem', 'how do i want to solve it', 'how do i want the world to look after i've solved it'
AND
B) respects the feedback coming from the people they've hired to tell them the realistic approaches and methods for meeting the tasked work
"A" usually happens because sales and marketing people don't believe they should have to define their glorious visions beyond 'our customers want it to be pretty and fast' and believe it is the developers job to figure out what 'pretty and fast' means.
"B" never happens because management has already made a commitment to either a customer or to a Fiscal Year goal based on something they pooped out after a night at Taco Bell and god damn if some developer is going to tell them it can't be done I AM THE BUSINESS AND YOUR JOB IS TO SERVE THE BUSINESS
posted by spicynuts at 8:15 AM on March 22, 2012 [14 favorites]
I have never met a stupid developer. I've met one or two naive ones but that's cuz they were a week out of college in the big city - who wouldn't be a little naive. I have met developers with varying levels of competency or professionalism. Regardless, none of that matters if:
A) a business fails to commit to the idea of disciplined, up front thinking and planning including 'what is the problem', 'how do i want to solve it', 'how do i want the world to look after i've solved it'
AND
B) respects the feedback coming from the people they've hired to tell them the realistic approaches and methods for meeting the tasked work
"A" usually happens because sales and marketing people don't believe they should have to define their glorious visions beyond 'our customers want it to be pretty and fast' and believe it is the developers job to figure out what 'pretty and fast' means.
"B" never happens because management has already made a commitment to either a customer or to a Fiscal Year goal based on something they pooped out after a night at Taco Bell and god damn if some developer is going to tell them it can't be done I AM THE BUSINESS AND YOUR JOB IS TO SERVE THE BUSINESS
posted by spicynuts at 8:15 AM on March 22, 2012 [14 favorites]
Woo, welcome to why I quit. You know it might be considered immature, but I just don't want to be asked how long it will take me to do something. I have no damn idea, and I consider the question boring. "I don't know, let's find out together!" is never what people want to hear.
posted by SomeOneElse at 8:17 AM on March 22, 2012 [12 favorites]
posted by SomeOneElse at 8:17 AM on March 22, 2012 [12 favorites]
The traditional time estimation method is to multiply by two and then switch to the next higher units. "2 days" -> "4 weeks"
Poor understanding of the project's complexity.
This is really the #1 killer. You get 80% of the project done in 80% of the time and the other 20% of the project in the other 80% of the time. It's the details (often GUIs, but not always) that take far longer than you thought. "It's not hard" != "it's fast".
The software industry as a whole rapidly changes, and to be on the cutting edge requires the use of tools and concepts with which developers have yet to gain decent experience.
The modern software stack is so massive and complex and constantly changing, that it is almost impossible to predict many of the time consuming issues that inevitably emerge.
And these two are the other main killer. Why do you have to be on the cutting edge? And if you do, why must you use a massive software stack? There's a project here at work that has like two dozen dependencies on fast-moving projects and they only use a tiny fragment of some of them. Like some kind of message queue management thing that's always crashing. What's wrong with making your own? Linked list in about 200 lines and you never touch it again. Bam, 90% of your crashes are gone and a lot of your upgrade treadmill. But no, they have to use that software for Acronym Compliance and PowerPoint Compatibility (i.e. name dropping the popular kids is great PR).
posted by DU at 8:18 AM on March 22, 2012 [9 favorites]
Poor understanding of the project's complexity.
This is really the #1 killer. You get 80% of the project done in 80% of the time and the other 20% of the project in the other 80% of the time. It's the details (often GUIs, but not always) that take far longer than you thought. "It's not hard" != "it's fast".
The software industry as a whole rapidly changes, and to be on the cutting edge requires the use of tools and concepts with which developers have yet to gain decent experience.
The modern software stack is so massive and complex and constantly changing, that it is almost impossible to predict many of the time consuming issues that inevitably emerge.
And these two are the other main killer. Why do you have to be on the cutting edge? And if you do, why must you use a massive software stack? There's a project here at work that has like two dozen dependencies on fast-moving projects and they only use a tiny fragment of some of them. Like some kind of message queue management thing that's always crashing. What's wrong with making your own? Linked list in about 200 lines and you never touch it again. Bam, 90% of your crashes are gone and a lot of your upgrade treadmill. But no, they have to use that software for Acronym Compliance and PowerPoint Compatibility (i.e. name dropping the popular kids is great PR).
posted by DU at 8:18 AM on March 22, 2012 [9 favorites]
For the most recent half of my career, I've often taken to telling people I can't give them an accurate estimate. Some people don't respond well to this, and I've used a comparable metaphor, asking if they'd feel comfortable giving an estimate of time for how long it'd take to cross a mountain range they'd never been over and only had a partial/unreliable map of.
This is great.
posted by weston at 8:21 AM on March 22, 2012 [6 favorites]
This is great.
posted by weston at 8:21 AM on March 22, 2012 [6 favorites]
popaopee: "As someone on the QA end of this let me tell you it sucks. We always pay the price in having our time cut short to accommodate the devs underestimates. So instead we make sure to pad our time as much as we can get away with."
I'm not always happy with my company's scheduling but I'll will say that they're good about giving us in QA enough time to test a new release. The product release date is "date of hand-off to QA + eight weeks". If the developers aren't ready by the hand-off date, then the release slips and QA still gets 8 weeks.
posted by octothorpe at 8:26 AM on March 22, 2012 [1 favorite]
I'm not always happy with my company's scheduling but I'll will say that they're good about giving us in QA enough time to test a new release. The product release date is "date of hand-off to QA + eight weeks". If the developers aren't ready by the hand-off date, then the release slips and QA still gets 8 weeks.
posted by octothorpe at 8:26 AM on March 22, 2012 [1 favorite]
For the most recent half of my career, I've often taken to telling people I can't give them an accurate estimate. Some people don't respond well to this...
I've done this too and haven't had too much blowback. I think it's because I break it down a little: "Your project breaks naturally into three parts. The interface, the basic algorithm and the database. The database part is going to be simple here, so call that 2 or 3 weeks. The interface might take a little longer in the long run because we'll throw at least one away. Call it a 4-6 weeks of time total, but probably only 2 weeks for the first version that works but we'll all hate. The basic algorithm I'm not so sure about since I've never solved this problem. But it sounds similar to one I have solved, so I'm sure it won't take more than a couple of months." Etc.
There's a lot of wiggle room in there and they have a better idea of why I can't be firm and might come back with suggestions on where to throw more people at the project ("you need a subject matter expert!"). It also makes it look like I know what I'm talking about, so they get a warm fuzzy from that.
posted by DU at 8:27 AM on March 22, 2012 [1 favorite]
I've done this too and haven't had too much blowback. I think it's because I break it down a little: "Your project breaks naturally into three parts. The interface, the basic algorithm and the database. The database part is going to be simple here, so call that 2 or 3 weeks. The interface might take a little longer in the long run because we'll throw at least one away. Call it a 4-6 weeks of time total, but probably only 2 weeks for the first version that works but we'll all hate. The basic algorithm I'm not so sure about since I've never solved this problem. But it sounds similar to one I have solved, so I'm sure it won't take more than a couple of months." Etc.
There's a lot of wiggle room in there and they have a better idea of why I can't be firm and might come back with suggestions on where to throw more people at the project ("you need a subject matter expert!"). It also makes it look like I know what I'm talking about, so they get a warm fuzzy from that.
posted by DU at 8:27 AM on March 22, 2012 [1 favorite]
It is actually possible to be a software developer and turn in sensible estimates and then hit them regularly. I know, shocking, but it's true. I did it for years in a number of different sectors using a variety of technologies including financial, web and mobile device development. I say this not to blow my own horn, because it doesn't matter to me, but because saying it is just part of the software development process, or essential to the software developer's mindset, isn't correct. It doesn't have to be that way, and often isn't. You don't hear about all the projects that go well because they were competently planned and executed because they're boring stories. Some folks loves them some disaster porn, especially when it's in their own field.
You get software done on time by demanding detailed functional specifications, by returning well considered line-item estimates appropriate to the assigned team with appropriate error bars factored in for each requirement, include additional line items for unit tests, system tests, system integration and incorporating a full QA process, and by responding to any demands for a shorter cycle by demanding a reduced feature set.
People don't like to follow that process because it's expensive and time consuming for a technical PM (and their clients) to prepare functional specs, and it's expensive and time consuming for technical leads to prepare detailed time estimate responses. You can do it with rockstar developers, and you can do it with journeymen.
That's how you deliver software on time and on budget. You stop being a "bro" or a "cowboy" or a "rockstar" or a "code monkey" or whatever the hell they're calling people these days and you become instead a professional.
posted by seanmpuckett at 8:29 AM on March 22, 2012 [20 favorites]
You get software done on time by demanding detailed functional specifications, by returning well considered line-item estimates appropriate to the assigned team with appropriate error bars factored in for each requirement, include additional line items for unit tests, system tests, system integration and incorporating a full QA process, and by responding to any demands for a shorter cycle by demanding a reduced feature set.
People don't like to follow that process because it's expensive and time consuming for a technical PM (and their clients) to prepare functional specs, and it's expensive and time consuming for technical leads to prepare detailed time estimate responses. You can do it with rockstar developers, and you can do it with journeymen.
That's how you deliver software on time and on budget. You stop being a "bro" or a "cowboy" or a "rockstar" or a "code monkey" or whatever the hell they're calling people these days and you become instead a professional.
posted by seanmpuckett at 8:29 AM on March 22, 2012 [20 favorites]
I have been "Fired" six times by the same company (same manager) for being the cynic... Every time I get hired back to bring "Reality" to a project... and then get told I was wrong... This time though it is going to stick come hell or high water I won't go back.
posted by mrgroweler at 8:30 AM on March 22, 2012 [1 favorite]
posted by mrgroweler at 8:30 AM on March 22, 2012 [1 favorite]
Wait! Now we have unit testing*, everything will be quicker now!
* insert silver bullet of the day here.
posted by Artw at 8:33 AM on March 22, 2012 [1 favorite]
* insert silver bullet of the day here.
posted by Artw at 8:33 AM on March 22, 2012 [1 favorite]
And, oh god, let's talk about the additional pain the recent enthusiasm for all things Agile and Lean have added to this already horrendous situation.
The general impatience of clients (internal or external) is rewarded by the misunderstood definitions and purposes of Agile and Lean methodologies. To far, far too many clients, those words mean only "get the same out of work FASTER!"
Of course, I've yet to meet a company or agency that can manage to implement Agile or Lean in anything resembling the right way. So the insanity and stress increases exponentially. "We're Agile! Why aren't things going faster/easier/better?"
GAH!
posted by gsh at 8:35 AM on March 22, 2012 [2 favorites]
The general impatience of clients (internal or external) is rewarded by the misunderstood definitions and purposes of Agile and Lean methodologies. To far, far too many clients, those words mean only "get the same out of work FASTER!"
Of course, I've yet to meet a company or agency that can manage to implement Agile or Lean in anything resembling the right way. So the insanity and stress increases exponentially. "We're Agile! Why aren't things going faster/easier/better?"
GAH!
posted by gsh at 8:35 AM on March 22, 2012 [2 favorites]
You get software done on time by demanding detailed functional specifications, by returning well considered line-item estimates appropriate to the assigned team with appropriate error bars factored in for each requirement, include additional line items for unit tests, system tests, system integration and incorporating a full QA process, and by responding to any demands for a shorter cycle by demanding a reduced feature set.
This is a really nice idea. I try to do this as much as I can. But you seem to assume that your demands for, eg, a detailed functional spec will actually be met. I'm not sure why you do that.
posted by Tomorrowful at 8:36 AM on March 22, 2012 [3 favorites]
This is a really nice idea. I try to do this as much as I can. But you seem to assume that your demands for, eg, a detailed functional spec will actually be met. I'm not sure why you do that.
posted by Tomorrowful at 8:36 AM on March 22, 2012 [3 favorites]
My favorite line to use when reviewing BS estimates is, "I could agree with you, but then we'd both be wrong." It doesn't make many friends, but it gets the point across.
posted by ryoshu at 8:36 AM on March 22, 2012 [7 favorites]
posted by ryoshu at 8:36 AM on March 22, 2012 [7 favorites]
I think a big part of the problem is a miscommunication that happens between management and developers. Management asks developers "how long to implement this" and what they mean is "how long until we can ship and support this as stable and tested" but what gets answered is "how long to make this work." Somewhere in there a PM is supposed to be translating.
posted by Nothing at 8:38 AM on March 22, 2012 [3 favorites]
posted by Nothing at 8:38 AM on March 22, 2012 [3 favorites]
I've also found that meeting or exceeding estimates tends to make people trust later estimates more, lending your word and demands more authority. Or maybe I just work with more rational people than the norm....
posted by DU at 8:40 AM on March 22, 2012
posted by DU at 8:40 AM on March 22, 2012
Agile is actually a pretty sensible developer-centric response to a lot of these issues. Which is why nobody fucking does it - it's all "where agile now, we don't have to do specs, here's your arbitrary deadline. "
posted by Artw at 8:40 AM on March 22, 2012 [1 favorite]
posted by Artw at 8:40 AM on March 22, 2012 [1 favorite]
You get software done on time by demanding detailed functional specifications ...
And then at the end of the work day, I ride my winged unicorn back home.
posted by octothorpe at 8:44 AM on March 22, 2012 [26 favorites]
And then at the end of the work day, I ride my winged unicorn back home.
posted by octothorpe at 8:44 AM on March 22, 2012 [26 favorites]
I develop embedded software, and feel like I get a fair hearing when I give "pessimistic" estimates or have to explain some slip-up. Part of it is because our whole product is made almost from the bottom up. Other problems in the development process, like wrongly machined castings, miswired cabling, external sensors not behaving to spec and such are very visible, and gives me a hook to explain that SW as well has problems when developing new stuff. And most of the managers are old engineers.
posted by Harald74 at 8:47 AM on March 22, 2012
posted by Harald74 at 8:47 AM on March 22, 2012
@octothorpe
The word you are looking for is alicorn.
posted by Balna Watya at 8:47 AM on March 22, 2012 [4 favorites]
The word you are looking for is alicorn.
posted by Balna Watya at 8:47 AM on March 22, 2012 [4 favorites]
The central problem I encounter is this:
Us coders deal with reality every day. We have an idea of what's possible, and it's based in fact. Sometimes we get a little excited about something and think we're invincible, but usually the group as a whole can see what's really possible and say it. And this is an empirical thing. It is a definite process where an actual thing must be brought into the world and tested and made to function correctly.
Salespeople and people in marketing live in a world of artifice, where it is their job to out-mojo the clients and convince them through sheer ebullience, conviction, or force of will to give us their money. As the rare programmer who has actually worked in sales, I know how this is – it's a world where believing in yourself is central to doing your job, where demands and restrictions are mostly just psychological power games with nothing real behind them. You act as though you're selling a real thing, but in fact you're selling this idea built out of all kinds of emotions and feelings and desires. So you turn to the people who are supposed to build that crazy amorphous ball of intangibles and ask them to do it for you – and they respond with the same kinds of ridiculous objections you've been hearing the whole time from the client before they'd actually buy: stuff about time frames, stuff about technical capabilities, stuff about facts and figures and why there's a limit to what's possible. And you get impatient, because you know all that stuff isn't real, you've long since convinced yourself it isn't real and you've been spending months convincing the client that they're not real either, the reality is that if you just believe in yourself and believe in our incredible capabilities then anything and everything is possible and can be completed five minutes from now.
So there's this endless struggle – the struggle between solid facts and the capabilities of a real system and the shadowy, vague instinctive impulse that is sales. And to the instinctive impulse of sales, the question "when can we deliver?" is flatly identical to "when do we want our money?" and anybody who says otherwise is just trying to put off their payday for no good reason.
posted by koeselitz at 8:50 AM on March 22, 2012 [27 favorites]
Us coders deal with reality every day. We have an idea of what's possible, and it's based in fact. Sometimes we get a little excited about something and think we're invincible, but usually the group as a whole can see what's really possible and say it. And this is an empirical thing. It is a definite process where an actual thing must be brought into the world and tested and made to function correctly.
Salespeople and people in marketing live in a world of artifice, where it is their job to out-mojo the clients and convince them through sheer ebullience, conviction, or force of will to give us their money. As the rare programmer who has actually worked in sales, I know how this is – it's a world where believing in yourself is central to doing your job, where demands and restrictions are mostly just psychological power games with nothing real behind them. You act as though you're selling a real thing, but in fact you're selling this idea built out of all kinds of emotions and feelings and desires. So you turn to the people who are supposed to build that crazy amorphous ball of intangibles and ask them to do it for you – and they respond with the same kinds of ridiculous objections you've been hearing the whole time from the client before they'd actually buy: stuff about time frames, stuff about technical capabilities, stuff about facts and figures and why there's a limit to what's possible. And you get impatient, because you know all that stuff isn't real, you've long since convinced yourself it isn't real and you've been spending months convincing the client that they're not real either, the reality is that if you just believe in yourself and believe in our incredible capabilities then anything and everything is possible and can be completed five minutes from now.
So there's this endless struggle – the struggle between solid facts and the capabilities of a real system and the shadowy, vague instinctive impulse that is sales. And to the instinctive impulse of sales, the question "when can we deliver?" is flatly identical to "when do we want our money?" and anybody who says otherwise is just trying to put off their payday for no good reason.
posted by koeselitz at 8:50 AM on March 22, 2012 [27 favorites]
I'm surprised no one's invoked Scotty in this thread yet:
posted by mysterpigg at 8:51 AM on March 22, 2012 [2 favorites]
James T. Kirk: How much refit time before we can take her out again?
Montgomery Scott: Eight weeks, Sir... but ya don't have eight weeks, so I'll do it for ya in two.
James T. Kirk: Mr.Scott. Have you always multiplied your repair estimates by a factor of four?
Montgomery Scott: Certainly, Sir. How else can I keep my reputation as a miracle worker?
posted by mysterpigg at 8:51 AM on March 22, 2012 [2 favorites]
Software projects are late because developers spend time writing and reading about why software projects are late. The problem is getting exponentially worse as the feedback cycle builds up.
posted by srboisvert at 8:51 AM on March 22, 2012 [2 favorites]
posted by srboisvert at 8:51 AM on March 22, 2012 [2 favorites]
Harald74, I spent a year working in embedded software, and I found the same to be true: nowhere have my realistic, conservative, overtly padded estimates been taken more seriously.
posted by Mars Saxman at 8:52 AM on March 22, 2012
posted by Mars Saxman at 8:52 AM on March 22, 2012
And yet, if you give an estimate of 6 months, if you cannot break the project down into many little parts, each with an estimate in days, such that they all add up to 180, your estimate will not be accepted...
It's not just that developers aren't able to anticipate every bump in the road; it's that unforeseen delays are simply not allowed in the budget.
posted by cotterpin at 8:53 AM on March 22, 2012 [2 favorites]
It's not just that developers aren't able to anticipate every bump in the road; it's that unforeseen delays are simply not allowed in the budget.
posted by cotterpin at 8:53 AM on March 22, 2012 [2 favorites]
I remember seeing that answer going around twitter a while ago and wishing there had been a metafilter thread so that I could see some actual good analogies. It just seemed like it was saying "our estimates are bad because we put literally zero thought into them". Like, well done?
posted by lucidium at 8:55 AM on March 22, 2012
posted by lucidium at 8:55 AM on March 22, 2012
To be charitable, sometimes it's not that zero thought was put into things. Sometimes a very large amount of thought has been put into them, but almost all of the thought-weight is divorced from reality and instead is based on clapping really loudly so Sales Tinkerbell doesn't die.
posted by Drastic at 8:58 AM on March 22, 2012 [11 favorites]
posted by Drastic at 8:58 AM on March 22, 2012 [11 favorites]
Oh sure, I just meant that I thought the analogy was bad because real life estimating emphatically does involve a lot more thought than that. I was surprised to see so many developers (or, the couple of developers I saw talking about it on twitter) agreeing with it when it just seemed to make us look like idiots.
posted by lucidium at 9:04 AM on March 22, 2012
posted by lucidium at 9:04 AM on March 22, 2012
Wait, what? So software development estimates are usually off by a factor of 2-3 because developers are stupid and naive?
"Stupid" and "naive" aren't the words I would use, but the end results can look that way. It's been my experience that amount of experience as a software developer only weakly correlates to ability to accurately estimate development times, and I think this is a result of cognitive bias and poor or non-existent self-monitoring. The first comment in that Quorum thread posits "failure to assess previous project scopes" as one factor in this problem, and I think it's one of the biggest: in the absence of rigorous self-monitoring, we tend to forget about the amount of time spent on dead ends and debugging. When it comes time to estimate the completion date for the next project, that misapprehension leads us to deliver a forecast that under-represents that amount of time we'll spend on bugs or mistakes.
posted by invitapriore at 9:05 AM on March 22, 2012
"Stupid" and "naive" aren't the words I would use, but the end results can look that way. It's been my experience that amount of experience as a software developer only weakly correlates to ability to accurately estimate development times, and I think this is a result of cognitive bias and poor or non-existent self-monitoring. The first comment in that Quorum thread posits "failure to assess previous project scopes" as one factor in this problem, and I think it's one of the biggest: in the absence of rigorous self-monitoring, we tend to forget about the amount of time spent on dead ends and debugging. When it comes time to estimate the completion date for the next project, that misapprehension leads us to deliver a forecast that under-represents that amount of time we'll spend on bugs or mistakes.
posted by invitapriore at 9:05 AM on March 22, 2012
Against my better judgement, I'll mention that for the last five years of my software career, I worked for a consultancy that specialized in fixing the fuckups of other software development teams who didn't think it was possible to follow a process and deliver software on time and on budget.
The consistent pattern amongst our clients was the failure of the previous developers to ask for and receive detailed functional specs, and to deliver in return firm line-item time estimates. We would go into disaster situations and ask for functional specs and there would be none, just a half page of thoughts and a bunch of clients who had never really been talked to, and a bunch of software that was vague and directionless not because of technical incompetence but because there was knowledge of how to successfully manage the process of converting vague handwavey concepts into solid code. I remember with not too much fondness many spec development conference calls with clients who expressed some kind of surprise that they'd never actually been interviewed by a requirements team.
We were really expensive, too. It would have been a lot, a lot cheaper for our customers if they would have just followed process to begin with.
posted by seanmpuckett at 9:08 AM on March 22, 2012 [2 favorites]
The consistent pattern amongst our clients was the failure of the previous developers to ask for and receive detailed functional specs, and to deliver in return firm line-item time estimates. We would go into disaster situations and ask for functional specs and there would be none, just a half page of thoughts and a bunch of clients who had never really been talked to, and a bunch of software that was vague and directionless not because of technical incompetence but because there was knowledge of how to successfully manage the process of converting vague handwavey concepts into solid code. I remember with not too much fondness many spec development conference calls with clients who expressed some kind of surprise that they'd never actually been interviewed by a requirements team.
We were really expensive, too. It would have been a lot, a lot cheaper for our customers if they would have just followed process to begin with.
posted by seanmpuckett at 9:08 AM on March 22, 2012 [2 favorites]
Having done this for several decades and felt the pain constantly from both the developer and the business side, I feel like Kanban really is a way out of the darkness.
The basic idea is that instead of a push system wherein the business guesses how much work can be done (and is often eagerly optimistic about it), the developers operate in a pull system, where the work is cut up into features and put on priority queues and the developers pop the next unit-of-work off the top of the stack when they are finished with the last one.
This puts all the incentives in the right place, because now the system is working as rapidly as actually possible given the speed of the developers. And, inevitably, tickets start piling up. After a few weeks, it becomes acutely obvious what the baseline possible speed of the development team is, and how poorly that synchronizes with the expectations/desires of the business team. Then great conversations start happening.
posted by felix at 9:08 AM on March 22, 2012 [2 favorites]
The basic idea is that instead of a push system wherein the business guesses how much work can be done (and is often eagerly optimistic about it), the developers operate in a pull system, where the work is cut up into features and put on priority queues and the developers pop the next unit-of-work off the top of the stack when they are finished with the last one.
This puts all the incentives in the right place, because now the system is working as rapidly as actually possible given the speed of the developers. And, inevitably, tickets start piling up. After a few weeks, it becomes acutely obvious what the baseline possible speed of the development team is, and how poorly that synchronizes with the expectations/desires of the business team. Then great conversations start happening.
posted by felix at 9:08 AM on March 22, 2012 [2 favorites]
... because there was no knowlege ...
posted by seanmpuckett at 9:09 AM on March 22, 2012
posted by seanmpuckett at 9:09 AM on March 22, 2012
I have a super power in that I can estimate large software tasks with haunting accuracy. If I say it will take "x days/weeks/months +/- y" then it does. Where I work now, I used to estimate for everyone on the team. How do I do that? I estimate it for myself and than multiply that by a factor which is "how much faster/slower am I than that person?"
How am I so accurate?
posted by plinth at 9:10 AM on March 22, 2012 [9 favorites]
How am I so accurate?
- I never estimate anything in units under 1/2 day. Nothing.
- I write/have written literally millions of lines of code. I know how long many common tasks will take and have an idea of how many bugs I will introduce and how many of those bugs will be "bad"
- If code involves any of the following:
- another group's deliverables
- an outside library with/without source
- shifting sands
- hostility
- reactivity (ie, panic from a support case)
- oddball tools
- dependence on a new technology
- unusual personalities
posted by plinth at 9:10 AM on March 22, 2012 [9 favorites]
I never estimate anything in units under 1/2 day. Nothing.
Hour estimates are usually bullshit, so I approve this message.
posted by Artw at 9:23 AM on March 22, 2012 [5 favorites]
Hour estimates are usually bullshit, so I approve this message.
posted by Artw at 9:23 AM on March 22, 2012 [5 favorites]
I think almost every answer in this thread and the Quora thread misses the actual reason.
Software estimation is bad because in most cases getting the length of the project estimated correctly is not the most important thing, or even an important thing. This is easy to see because there are almost never consequences for the estimator if the estimate is wrong (or rewards if it's right), and just as rarely consequences for the company. Sure, sometimes you're making boxed software and you have to get the master copy done by october or it won't be on store shelves for christmas and if that doesn't happen the company folds, but that's the exceptional case. In your standard we-can-update-whenever web shop, it just doesn't matter if the product launches in june or july and even though people get all huffy about a project when it's late, if it really mattered you'd see some consequences.
Now consider product planning: theoretically business folks should come up with a good idea and vet it with user focus groups and have it all validated before going ahead and getting it built, but in practice somebody comes up with an idea and everyone else says it's terrible but it gets pushed through because of political whatever and the development team spends six months building it and it's released and nobody uses it. And, again, there aren't any consequences for the person who pushed the original idea.
The observation here is, most new products fail. They can fail for a variety of reasons: they take too long to build, they cost too much money and get cancelled, or they're just bad ideas. Companies make most of their money off existing products, and you'll note that new features in existing products are both easier to design and easier to estimate -- the "we thought it would take three months but it took three years" kind of projects are almost always the ones you start from scratch, not the ones that are adding a new menu item to an existing application.
However, this doesn't mean starting new products is bad -- obviously every old product was a new product at some point. It just means most new products are going to fail and/or have problems, and people understand this.
posted by inkyz at 9:42 AM on March 22, 2012 [3 favorites]
Software estimation is bad because in most cases getting the length of the project estimated correctly is not the most important thing, or even an important thing. This is easy to see because there are almost never consequences for the estimator if the estimate is wrong (or rewards if it's right), and just as rarely consequences for the company. Sure, sometimes you're making boxed software and you have to get the master copy done by october or it won't be on store shelves for christmas and if that doesn't happen the company folds, but that's the exceptional case. In your standard we-can-update-whenever web shop, it just doesn't matter if the product launches in june or july and even though people get all huffy about a project when it's late, if it really mattered you'd see some consequences.
Now consider product planning: theoretically business folks should come up with a good idea and vet it with user focus groups and have it all validated before going ahead and getting it built, but in practice somebody comes up with an idea and everyone else says it's terrible but it gets pushed through because of political whatever and the development team spends six months building it and it's released and nobody uses it. And, again, there aren't any consequences for the person who pushed the original idea.
The observation here is, most new products fail. They can fail for a variety of reasons: they take too long to build, they cost too much money and get cancelled, or they're just bad ideas. Companies make most of their money off existing products, and you'll note that new features in existing products are both easier to design and easier to estimate -- the "we thought it would take three months but it took three years" kind of projects are almost always the ones you start from scratch, not the ones that are adding a new menu item to an existing application.
However, this doesn't mean starting new products is bad -- obviously every old product was a new product at some point. It just means most new products are going to fail and/or have problems, and people understand this.
posted by inkyz at 9:42 AM on March 22, 2012 [3 favorites]
Another huge multiplier for time is that the initial design is often quite wrong once it's no longer a prototype or a Photoshop document. Once somebody sees their design in action, there are numerous changes that have to happen, and that can take two to three times the initial estimate for "revisions."
I briefly entertained the idea of doing a talk at WebVisions about "Everything I know about web design I learned from Montgomery Scott," but at least he had time to catch up on his technical journals.
posted by fifteen schnitzengruben is my limit at 9:46 AM on March 22, 2012 [1 favorite]
I briefly entertained the idea of doing a talk at WebVisions about "Everything I know about web design I learned from Montgomery Scott," but at least he had time to catch up on his technical journals.
posted by fifteen schnitzengruben is my limit at 9:46 AM on March 22, 2012 [1 favorite]
I actually worked at a company that used Scrum pretty much as specced and hit deadlines, communicated clearly, and turned out product on time and on budget. It was kind of amazing to watch. We even bullied the web team into daily standups and mostly fixed that pile-of-intransigent-shit process.
Pity the product was the most useless piece of crap imaginable.
posted by restless_nomad at 9:47 AM on March 22, 2012 [3 favorites]
Pity the product was the most useless piece of crap imaginable.
posted by restless_nomad at 9:47 AM on March 22, 2012 [3 favorites]
You get software done on time by demanding detailed functional specifications ...
I have yet to meet a single customer who knows what they want to the level they can produce a detailed functional spec without help. The deep-in-the-weeds thinking required to produce a functional spec from a set of vague requirements is the job of the software engineer. Requirements gathering is often times twice the work of actual development, especially if you're doing any sort of firm fixed price project.
The problem lies in the fact that most customers think that software development is not difficult, that the computer does most of the work for the engineer, and are always shocked when the RFP comes back with twice the development time and three times the cost they were expecting. Sales and management, who's existence is tired directly to bringing in money and making the customer happy, will cut those estimates in an effort to ingratiate themselves and keep the money faucet open. But at the end of the day, software development isn't something you can hope & pray away, and if they engineer says it's going to take two months, and management says it will take one, it will end up taking four.
And at that point, everyone hates everyone else. Management is bleeding money, developers are working weekends and updating their resumes, and the sales guys are get reamed by the customer. I've seen it happen on 1/2 a dozen projects, and it's the most demoralizing shit ever.
posted by Fidel Cashflow at 9:48 AM on March 22, 2012
I have yet to meet a single customer who knows what they want to the level they can produce a detailed functional spec without help. The deep-in-the-weeds thinking required to produce a functional spec from a set of vague requirements is the job of the software engineer. Requirements gathering is often times twice the work of actual development, especially if you're doing any sort of firm fixed price project.
The problem lies in the fact that most customers think that software development is not difficult, that the computer does most of the work for the engineer, and are always shocked when the RFP comes back with twice the development time and three times the cost they were expecting. Sales and management, who's existence is tired directly to bringing in money and making the customer happy, will cut those estimates in an effort to ingratiate themselves and keep the money faucet open. But at the end of the day, software development isn't something you can hope & pray away, and if they engineer says it's going to take two months, and management says it will take one, it will end up taking four.
And at that point, everyone hates everyone else. Management is bleeding money, developers are working weekends and updating their resumes, and the sales guys are get reamed by the customer. I've seen it happen on 1/2 a dozen projects, and it's the most demoralizing shit ever.
posted by Fidel Cashflow at 9:48 AM on March 22, 2012
DU: "The traditional time estimation method is to multiply by two and then switch to the next higher units. "2 days" -> "4 weeks""
Precisely.
Even then most people fail to take into account the effects of Hofstadter's Law which states: "It always takes longer than you expect, even when you take into account Hofstadter's Law."
posted by ob1quixote at 9:50 AM on March 22, 2012 [6 favorites]
Precisely.
Even then most people fail to take into account the effects of Hofstadter's Law which states: "It always takes longer than you expect, even when you take into account Hofstadter's Law."
posted by ob1quixote at 9:50 AM on March 22, 2012 [6 favorites]
All the reasons (in the post, and the comments) for why software development makes estimation hard make sense to me, and match my experience. I imagine, without knowing from personal experience, that similar things apply to construction and other physical engineering projects.
What makes no sense to me are folks who seem to be saying that having no planning (and therefore estimation) at all is somehow OK in a business. It's not! Saying that you can't do good estimation without functional specs can make sense, saying that you can't do good estimation too far out and should keep your horizons short makes sense, saying that estimation is estimation and therefore will have errors makes sense, but dudes, outside of your personal projects "it'll be done when it's done" is just not an OK answer.
I have no dogma about which method you use b/c it depends entirely on the kind of project and the team and all that. But you gotta use something.
posted by feckless at 10:06 AM on March 22, 2012
What makes no sense to me are folks who seem to be saying that having no planning (and therefore estimation) at all is somehow OK in a business. It's not! Saying that you can't do good estimation without functional specs can make sense, saying that you can't do good estimation too far out and should keep your horizons short makes sense, saying that estimation is estimation and therefore will have errors makes sense, but dudes, outside of your personal projects "it'll be done when it's done" is just not an OK answer.
I have no dogma about which method you use b/c it depends entirely on the kind of project and the team and all that. But you gotta use something.
posted by feckless at 10:06 AM on March 22, 2012
Closing this tag will take between 2 and 7 weeks.
posted by feckless at 10:06 AM on March 22, 2012 [7 favorites]
posted by feckless at 10:06 AM on March 22, 2012 [7 favorites]
Programming's easy, every customer's call
Brings a whole new revision
Have to pick up the pace, still hold to my vision
posted by mikurski at 10:07 AM on March 22, 2012 [3 favorites]
Brings a whole new revision
Have to pick up the pace, still hold to my vision
posted by mikurski at 10:07 AM on March 22, 2012 [3 favorites]
Requirements are awesome. I love requirements. I have instituted requirements gathering processes at many companies I've worked for.
Yet, the most common response when I ask a PM or AM or other "team lead" for requirements from the client? A look of unbridled fear and "Uh, no, I don't think we can go back to them for that. They'll just say we know/have everything we need" or "Well, they're looking to us for our expertise, so let's just use best practices."
For example, recently, I became an honorary product designer because there were no requirements.
posted by gsh at 10:25 AM on March 22, 2012
Yet, the most common response when I ask a PM or AM or other "team lead" for requirements from the client? A look of unbridled fear and "Uh, no, I don't think we can go back to them for that. They'll just say we know/have everything we need" or "Well, they're looking to us for our expertise, so let's just use best practices."
For example, recently, I became an honorary product designer because there were no requirements.
posted by gsh at 10:25 AM on March 22, 2012
seanmpuckett: " I worked for a consultancy that specialized in fixing the fuckups of other software development teams who didn't think it was possible to follow a process and deliver software on time and on budget. "
So you're the crazy fucks who are telling a friend of mine they'll write a full on CRM package in 6 weeks. I just hope you guys don't all get hit by trucks in the same week.
posted by wierdo at 10:29 AM on March 22, 2012
So you're the crazy fucks who are telling a friend of mine they'll write a full on CRM package in 6 weeks. I just hope you guys don't all get hit by trucks in the same week.
posted by wierdo at 10:29 AM on March 22, 2012
When people ask me about my projects' schedules, I like to say...
"It will take two months..."
(Wait for inevitable request to compress schedule.)
"..and if we rush it, it'll take three."
posted by ZenMasterThis at 10:50 AM on March 22, 2012 [1 favorite]
"It will take two months..."
(Wait for inevitable request to compress schedule.)
"..and if we rush it, it'll take three."
posted by ZenMasterThis at 10:50 AM on March 22, 2012 [1 favorite]
So you're the crazy fucks who are telling a friend of mine they'll write a full on CRM package in 6 weeks.
In my experience, being up "the follow-up guy" is also generally easier because:
"Look at these concrete examples of how you fucked this up before by not having requirements! Lets not do that!"
Is generally an easier sell than:
"Look. Seriously. This is going to fuck up if you don't give us some requirements. Trust me."
posted by garius at 10:53 AM on March 22, 2012 [2 favorites]
In my experience, being up "the follow-up guy" is also generally easier because:
"Look at these concrete examples of how you fucked this up before by not having requirements! Lets not do that!"
Is generally an easier sell than:
"Look. Seriously. This is going to fuck up if you don't give us some requirements. Trust me."
posted by garius at 10:53 AM on March 22, 2012 [2 favorites]
Nobody wants to pay for specs and good estimates? And without them, you're just guessing? And function point analysis kind of feels too much like phrenology?
(This is a great inside-baseball thread, btw.)
posted by saulgoodman at 11:33 AM on March 22, 2012
(This is a great inside-baseball thread, btw.)
posted by saulgoodman at 11:33 AM on March 22, 2012
I'm actually a little grateful for function point analysis as an estimation technique. Recently, I estimated a project for a proposal using both Function Point Analysis (based on the COCOMO II model as implemented in this this handy online calculator) and just developer gut-feel. The Function Point Analysis saved us from making an overly optimistic estimate in this case, because the developer-intuition-based approach led to a project schedule of roughly six months, while the more formal estimation approach led to a project schedule of nearly 2 years. I think the formal estimate came out high but still much closer to reality, given the very broad, idealized nature of the requirements as set out in the original RFI... At any rate, it was nice to have a basis for comparison.
posted by saulgoodman at 11:51 AM on March 22, 2012
posted by saulgoodman at 11:51 AM on March 22, 2012
Day rates! On time, on budget, on scope is not relevant to my interests.
posted by Damienmce at 11:58 AM on March 22, 2012 [2 favorites]
posted by Damienmce at 11:58 AM on March 22, 2012 [2 favorites]
That and the internet. Its like giving everyone a TV at their desk.
posted by Damienmce at 12:09 PM on March 22, 2012 [3 favorites]
posted by Damienmce at 12:09 PM on March 22, 2012 [3 favorites]
So timely. My current team is doing 2 week sprints of development, each of which is supposed to result in a "Potentially Releasable Product Increment". Scrum has been amazing for using thin and incomplete requirements to just DO SOMETHING, even if it's a little bit wrong. The process results in software in production, quickly, and ready to use, even if it's only 1/2 or 1/16 baked.
Now you might say, "what use is a 1/16 baked product"? It turns out that a partially complete product inspires the business owner to realize their latent requirements. Ideas about detailed functionality might never come out of a formal "requirements gathering" process done on paper, but come screaming out of user's emails after they start using the product...
But put aside the differences between waterfall and agile: The OP was about estimating, and you still have to estimate in Scrum. The cool thing is even if your estimates are off, you still release what you DID complete at the end of the sprint, so you can tell your client, "well we didn't finish your email module, but hey look! FLASHING RED BUTTON!"
Now what's interesting about this current project: The primary schedule driver is the User Guide team. The client seems to be more interested in a kickass User Guide than they are in the application itself. I think the User Guide staff outnumbers developers by a factor of 3.
posted by joecacti at 12:24 PM on March 22, 2012 [3 favorites]
Now you might say, "what use is a 1/16 baked product"? It turns out that a partially complete product inspires the business owner to realize their latent requirements. Ideas about detailed functionality might never come out of a formal "requirements gathering" process done on paper, but come screaming out of user's emails after they start using the product...
But put aside the differences between waterfall and agile: The OP was about estimating, and you still have to estimate in Scrum. The cool thing is even if your estimates are off, you still release what you DID complete at the end of the sprint, so you can tell your client, "well we didn't finish your email module, but hey look! FLASHING RED BUTTON!"
Now what's interesting about this current project: The primary schedule driver is the User Guide team. The client seems to be more interested in a kickass User Guide than they are in the application itself. I think the User Guide staff outnumbers developers by a factor of 3.
posted by joecacti at 12:24 PM on March 22, 2012 [3 favorites]
I should add, this is for web application development, a far cry from embedded...
posted by joecacti at 12:25 PM on March 22, 2012
posted by joecacti at 12:25 PM on March 22, 2012
As someone on the QA end of this let me tell you it sucks. We always pay the price in having our time cut short to accommodate the devs underestimates.
Oh yes. And so much more fun if you're the software testing monkey at the end of a long, oft delayed project that needs to be done by January 1st and it's now end of November, it's only barely testable and testing means not wondering if you find any bugs, but which bugs you want to find today -- and the deadline can't be extended again, because January the first is when the new law goes into effect for which you needed to update this software in the first place and if you cannot pay out social security according to the new rules, we're back on the front pages of the national newspapers again.
All the while knowning that if you fuck up, and you managed not to find that special combination of badly thought out requirement, even worse programmed exception to a general rule, crappy database management and undocumented behaviour of the software, middleware and hardware stack the whole mess lives on that will mean a couple of thousand or ten thousand people won't get their pensions this month, you'll have hit the newspapers' front pages again.
Of course, all the times you do manage to thriump over everything that's put in your way to make your project fails nobody will remember even a week later...
posted by MartinWisse at 12:27 PM on March 22, 2012 [1 favorite]
Oh yes. And so much more fun if you're the software testing monkey at the end of a long, oft delayed project that needs to be done by January 1st and it's now end of November, it's only barely testable and testing means not wondering if you find any bugs, but which bugs you want to find today -- and the deadline can't be extended again, because January the first is when the new law goes into effect for which you needed to update this software in the first place and if you cannot pay out social security according to the new rules, we're back on the front pages of the national newspapers again.
All the while knowning that if you fuck up, and you managed not to find that special combination of badly thought out requirement, even worse programmed exception to a general rule, crappy database management and undocumented behaviour of the software, middleware and hardware stack the whole mess lives on that will mean a couple of thousand or ten thousand people won't get their pensions this month, you'll have hit the newspapers' front pages again.
Of course, all the times you do manage to thriump over everything that's put in your way to make your project fails nobody will remember even a week later...
posted by MartinWisse at 12:27 PM on March 22, 2012 [1 favorite]
As someone on the QA end of this let me tell you it sucks.
My favorite QA malfunction is design-by-QA. This happens when the devs, working off vague requirements, implement something that seems like it might be the desired thing. They dump it into QA's laps, and the poor QA people have to figure out how the thing is really supposed to work so that they can file bugs on it.
And, oh god, let's talk about the additional pain the recent enthusiasm for all things Agile and Lean have added to this already horrendous situation.
I've worked (and am now currently working) in good agile / scrum / XP shops. Whenever I'm interviewing with a shop that bills itself as agile, I insist on talking to the product and program managers, and I ask them how the agile methodology impacts their daily work and their planning. Business buy-in and discipline is the single most important factor in successful agile development, IMO.
posted by Sauce Trough at 2:10 PM on March 22, 2012 [2 favorites]
My favorite QA malfunction is design-by-QA. This happens when the devs, working off vague requirements, implement something that seems like it might be the desired thing. They dump it into QA's laps, and the poor QA people have to figure out how the thing is really supposed to work so that they can file bugs on it.
And, oh god, let's talk about the additional pain the recent enthusiasm for all things Agile and Lean have added to this already horrendous situation.
I've worked (and am now currently working) in good agile / scrum / XP shops. Whenever I'm interviewing with a shop that bills itself as agile, I insist on talking to the product and program managers, and I ask them how the agile methodology impacts their daily work and their planning. Business buy-in and discipline is the single most important factor in successful agile development, IMO.
posted by Sauce Trough at 2:10 PM on March 22, 2012 [2 favorites]
I may have missed a comment to this effect upthread, but what's interesting to me about the hiking explanation is that it begins to illustrate the coastline paradox, but abandons that line of thought and moves on to more concrete obstacles: sand, fences, sea lions, sore feet. I expected the author to claim that it's impossible to complete a software project without an infinitely long schedule.
This is certainly the line of reasoning I plan to pursue at my next meeting with a project manager.
posted by cobra libre at 3:24 PM on March 22, 2012 [1 favorite]
This is certainly the line of reasoning I plan to pursue at my next meeting with a project manager.
posted by cobra libre at 3:24 PM on March 22, 2012 [1 favorite]
spicynuts, that story is so familiar that I felt my body tense up just reading it. That was the MO for every single project at my previous company, and a big part of why it is previous.
I work at a large internet company that is considered by many to be FAIL, and yet our problem (in my experience) is too much time allotted to development, so that nobody has to work very fast and people can tie themselves down into endless meetings to discuss the myriad of options that come out of having too much time available, which leads to a lack of focus and scope creep, leading to an extension of development time, leading to...well, projects being cancelled, usually.
Somewhere out there, somebody must be running projects where there's just a little less time than a team really needs, so that there's a sense of urgency, but the work can still get done in the time allotted (usually.)
If you are that person, memail me.
posted by davejay at 7:07 PM on March 22, 2012
I work at a large internet company that is considered by many to be FAIL, and yet our problem (in my experience) is too much time allotted to development, so that nobody has to work very fast and people can tie themselves down into endless meetings to discuss the myriad of options that come out of having too much time available, which leads to a lack of focus and scope creep, leading to an extension of development time, leading to...well, projects being cancelled, usually.
Somewhere out there, somebody must be running projects where there's just a little less time than a team really needs, so that there's a sense of urgency, but the work can still get done in the time allotted (usually.)
If you are that person, memail me.
posted by davejay at 7:07 PM on March 22, 2012
They always prefer the random number. Then they bug you all the time about your estimate. Over time, your estimate gets better. This is the essence of agile development.
Yes, yes, yes. As a "scrummaster" (I hate the term, mind you) that is the best thing about Agile: it gives you a number up-front that makes management happy, and tools to help developers realize that they're managing their time poorly without you having to tell them. Built-in bullshit for unrealistic managers and built-in shame for lazy developers. What's not to like?
posted by davejay at 7:10 PM on March 22, 2012 [1 favorite]
Yes, yes, yes. As a "scrummaster" (I hate the term, mind you) that is the best thing about Agile: it gives you a number up-front that makes management happy, and tools to help developers realize that they're managing their time poorly without you having to tell them. Built-in bullshit for unrealistic managers and built-in shame for lazy developers. What's not to like?
posted by davejay at 7:10 PM on March 22, 2012 [1 favorite]
disclaimer: realistic managers know estimates are just that, and diligent developers have no difficulty meeting their commitments, so Agile doesn't really change anything for them, other than reduce the time they collectively spend dealing with the less-realistic and less-diligent members of the extended team -- the scrummasters get to do that instead. It's quite efficient.
posted by davejay at 7:12 PM on March 22, 2012 [1 favorite]
posted by davejay at 7:12 PM on March 22, 2012 [1 favorite]
Ha. My job right now is to estimate how long it will take people to do stuff - not me - not people I even know - just nameless and faceless developers in India or wherever. My company has decided it's a waste of time for devs to estimate how long it will take them to do these things, so they've put together an entire team to do this.
On principle that's fine: estimates take time away from development, so if you have a large enough dev team, it makes sense to break that part off and have a dedicated person do it. In practice, it doesn't really work at all. Imagine it's like the hiking example, only instead of the guy who is about to embark on the hike calling his friend with his Sunday estimate, it's a mutual friend who calls him and says, "Hey, the Newport Beach guys want to see you so I've pencilled you in for Wednesday, cool? Cool! Bye!"
posted by Xany at 7:32 AM on March 23, 2012
On principle that's fine: estimates take time away from development, so if you have a large enough dev team, it makes sense to break that part off and have a dedicated person do it. In practice, it doesn't really work at all. Imagine it's like the hiking example, only instead of the guy who is about to embark on the hike calling his friend with his Sunday estimate, it's a mutual friend who calls him and says, "Hey, the Newport Beach guys want to see you so I've pencilled you in for Wednesday, cool? Cool! Bye!"
posted by Xany at 7:32 AM on March 23, 2012
My favorite QA malfunction is design-by-QA.
Me (QA Guy): This test is failing because the product is doing [describes weird behavior].
Developer: Yea, that's expected behavior. We implemented it to work that way.
Me: But that's dumb, the customer is going to hate that.
Developer: [shrugs] Well we didn't have a spec on that area so we had to wing it. File an enhancement bug and maybe we'll fix it for next release (which means never).
Me: [fumes]
... [release goes out to customers] ...
Support: Hey the customers are furious about [weird behavior], why didn't QA catch that. You guys suck.
posted by octothorpe at 8:26 AM on March 23, 2012 [1 favorite]
Me (QA Guy): This test is failing because the product is doing [describes weird behavior].
Developer: Yea, that's expected behavior. We implemented it to work that way.
Me: But that's dumb, the customer is going to hate that.
Developer: [shrugs] Well we didn't have a spec on that area so we had to wing it. File an enhancement bug and maybe we'll fix it for next release (which means never).
Me: [fumes]
... [release goes out to customers] ...
Support: Hey the customers are furious about [weird behavior], why didn't QA catch that. You guys suck.
posted by octothorpe at 8:26 AM on March 23, 2012 [1 favorite]
« Older Randall Munroe's Holistic Browsing Website | A Corgi goes for a hike Newer »
This thread has been archived and is closed to new comments
To further expand the hiking analogy, at some point when they've wandered into a box canyon and ran out of water, the hike leader will tell the realistic one to just keep on walking, whereupon a helicopter will swoop down out of the sky and whisk the leader away to lead some other nescient death march, again on the working assumption that nothing will go wrong and in fact let's make the timeline of the hike even more aggressive. Probably at some point they get promoted to VP.
posted by Drastic at 7:42 AM on March 22, 2012 [17 favorites]