5 ms·

All Late Projects Are the Same (2011) [pdf]

50 points by musha68k 11y ago

based2 11y ago
"All projects that finish late have this one thing in common: they started late"
- deleted 11y ago
  [deleted]
- gahahaha 11y ago
  Yea - I'm not really sure what the take away message here should be (although I found the article interesting). I'm currently working at a late project right now that started early enough, but took too long to hire enough people to finish the project in time, and didn't use the time at the beginning of the project well enough to gather information about the current and future processes. Maybe that's an example of what the author means, but it certainly gets more complicated than "started too late" quite quickly...
  - luckydata 11y ago
    The message is "late software" is really a failure of decision making at the highest level that waffle on necessary things until they become necessary but move too late on it. I've personally seen plenty of that, so works for me.
- pmoriarty 11y ago
  Or they had enough time, but focus was shifted elsewhere during the project, or resources were taken away, or the stakeholders kept changing their mind about what they wanted, or the projects were mismanaged, or the people working on them were incompetent/lazy to an extent that no amount of time would have been enough. Ect, etc, etc..
- dahart 11y ago
  He prefaced this saying it might sound too obvious. My reaction was that it's a non-obvious but brilliant way to think about it. That was only reinforced as I continued to read his reasoning. Thinking this way acknowledges in advance that software is complex, it's more complex than you think it is, and any software project you start is likely to take longer than you think it will. Both sides of a software project or contract ought to know this and say it out loud before starting. More importantly, it underscores that a large software project nearly always starts under pressure. Rarely is something big and expensive undertaken without at least mildly unrealistic goals. Having been there many times, I know the management thinking is often that if we don't have pressure and forces squeezing every bit of developer performance toward unrealistic goals, then we won't even achieve the realistic goals, and we'll be even later than we are. Contractors are probably most affected by and in need of this way of thinking, though I'm well aware of how hard it is to admit you might be late on something when you're trying to win a contract, especially when the competition makes impossible promises.
- jacques_chester 11y ago
  > "All projects that finish late have this one thing in common: they started late" McConnell has a really good discussion of this in Rapid Development, calling it "The Fuzzy Front-end" of a project. "Everyone knows" that certain projects "have" to be undertaken, but they will often just be talked about and talked about and talked about until it's too late to do anything but talk about not talking about things in future.
rubidium 11y ago
"1. Nobody had the guts to kick off the project until the competition proved it doable and desirable; by then, the project was in catch-up mode and had to be finished lickety-split. 2.If the project were started long enough before its due date to finish on time, all involved would have had to face up to the fact from the beginning that it was going to cost a lot more than anyone was willing to pay." In other words, projects are late because business justification is usually weak for software projects. When faced with "in order to ship this by 12monthsfromnow we need to hire 5 more software engineers today" management stalls.
- Etheryte 11y ago
  Adding more manpower doesn't mean faster completion.
  - loup-vaillant 11y ago
    At the beginning of a long project, it probably does. This is not like adding people to a late project. Now if your project isn't easily separable in several relatively independent parts, you are screwed.
- dahart 11y ago
  > In other words, projects are late because business justification is usually weak for software projects. While that's sometimes true, I read exactly the opposite. I read what he said as: 1- Software projects don't start until justification is strong, and 2- justification doesn't become strong until it's already too late. So, the problem isn't (necessarily) that justification is weak, it's that strong justification is itself a red flag, because it's already too late to start if you have a really good business case for it, you should have started before you had all the data to prove you needed to start. But, I don't think he's necessarily saying we should be able to somehow predict the future and start software projects before we know for sure we need them, he's just reflecting on patterns observed and providing more of a thought framework for dealing with these patterns.
jamiek88 11y ago
I think almost by definition anything that is late didn't start early enough.
sarreph 11y ago
> "What’s really wrong with us software folks is that we’re continually beating ourselves up for something that’s somebody else’s fault." Amen to that.
greggman 11y ago
The first thing that comes to mind is Joel's Five Worlds http://www.joelonsoftware.com/articles/FiveWorlds.html http://www.joelonsoftware.com/articles/FiveWorlds.html not all software dev is the same. Coming from games, every project I've been on was an original title. That meant it was 100% up to the team to decide the scope of the game. Most teams (not all) guess how much they can get done and don't plan for cutting features. "We're going to have 12 characters, 30 levels, 10 power ups, 45 enemies, 600 puzzles, online multiplayer, and IAP for 500 items". And then they just start making it. They run into 2 big problems. 1) They don't know if the game will be fun until they're 50-60% in. If they guessed wrong they're off schedule 2) They're attached to the vision and unwilling to cut stuff. My point though is this doesn't fit "we didn't start early enough" IMO. They knew how much time they had. No one was/is dicating too much work. They can cut the scope at any time. But they rarely do. There are solutions. 1 is to prototype with a small team. Unfortunately most teams can't do that as they'd have 90% of their staff doing nothing. Larger companies can do this or maybe if they switched to the Hollywood model, no employees only contractors, they could do it. 2 is to design so things can be cut and to check the schedule and start cutting. This one is hard for most teams because they see the game they imagined in their minds and it's not the game with stuff cut. Players though don't know what that vision is and so won't missed the cut features because they aren't aware of them.
- dahart 11y ago
  > My point though is this doesn't fit "we didn't start early enough" IMO. They knew how much time they had. No one was/is dicating too much work. They can cut the scope at any time. But they rarely do. Doesn't knowing how much time you have, and then not cutting scope when you see your plans don't fit into that time, count as not starting early enough? I also came from games, and I agree that scope is rarely cut, and often self-inflicted. I was also under Mr. Very Large Publisher, and it was more complicated than that- we had control over scope, but not over schedule. We had control over how much work to do and the quality, but not the budget. The major problem in my experience was that the team was excited, motivated and willing to work hard, so optimistic about their ability to do great things inside the limited budget and schedule. Therefore, they tried to do too much. All other things being equal, more time would have helped, every single time. Which can be summarized as "we didn't start early enough." That doesn't mean that actually starting earlier would have solved the problem. Actually starting earlier might have led to even larger plans. So, IMO "we didn't start early enough." is not meant to be taken literally, it's a way of understanding the problem, not a way to solve the problem.
deleted 11y ago
[deleted]
ScottBurson 11y ago
This is my favorite part: If a project offered a value of 10 times its estimated cost, no one would care if the actual cost to get it done were double the estimate. On the other hand, if expected value were only 10 percent greater than expected cost, lateness would be a disaster. Yes it would be a disaster, but instead of obsessing over “What’s the matter with those software folks who didn’t deliver on the schedule we gave them?” we need to ask instead “Why did we ever kick off a project with such marginal expected value?” The message for us software developers is: try to work only on what I call strategic projects: projects whose expected value is much greater than their cost could possibly be. That means they need to continue to pay benefits well into the future.
- pm215 11y ago
  At a previous gig "strategic" was a euphemism for "we don't have a paying customer for this work" :-)
bboreham 11y ago
Longer treatment of similar material by same author: http://www.goodreads.com/book/show/946076.Why_Does_Software_Cost_So_Much_ http://www.goodreads.com/book/show/946076.Why_Does_Software_...
pkaye 11y ago
Having worked in firmware, I have seen the issue with how things are partitioned between software and hardware. The hardware tends to get concrete requirements and everything else abstract or complex in dumped on the software. So you have to figure out algorithms which have not been thought through yet or deal with edge cases the hardware cannot deal with properly. These all add complexities to the software which we can't quantify early on. I believe if we specced out the software design to a level we are confident with the algorithms and data structures involved, you could get as predictable a schedule as hardware design.

50 points by musha68k 11y ago

based2 11y ago

"All projects that finish late have this one thing in common: they started late"

deleted 11y ago
[deleted]
gahahaha 11y ago
Yea - I'm not really sure what the take away message here should be (although I found the article interesting). I'm currently working at a late project right now that started early enough, but took too long to hire enough people to finish the project in time, and didn't use the time at the beginning of the project well enough to gather information about the current and future processes. Maybe that's an example of what the author means, but it certainly gets more complicated than "started too late" quite quickly...
- luckydata 11y ago
  The message is "late software" is really a failure of decision making at the highest level that waffle on necessary things until they become necessary but move too late on it. I've personally seen plenty of that, so works for me.
pmoriarty 11y ago
Or they had enough time, but focus was shifted elsewhere during the project, or resources were taken away, or the stakeholders kept changing their mind about what they wanted, or the projects were mismanaged, or the people working on them were incompetent/lazy to an extent that no amount of time would have been enough. Ect, etc, etc..
dahart 11y ago
He prefaced this saying it might sound too obvious. My reaction was that it's a non-obvious but brilliant way to think about it. That was only reinforced as I continued to read his reasoning. Thinking this way acknowledges in advance that software is complex, it's more complex than you think it is, and any software project you start is likely to take longer than you think it will. Both sides of a software project or contract ought to know this and say it out loud before starting. More importantly, it underscores that a large software project nearly always starts under pressure. Rarely is something big and expensive undertaken without at least mildly unrealistic goals. Having been there many times, I know the management thinking is often that if we don't have pressure and forces squeezing every bit of developer performance toward unrealistic goals, then we won't even achieve the realistic goals, and we'll be even later than we are. Contractors are probably most affected by and in need of this way of thinking, though I'm well aware of how hard it is to admit you might be late on something when you're trying to win a contract, especially when the competition makes impossible promises.
jacques_chester 11y ago
> "All projects that finish late have this one thing in common: they started late" McConnell has a really good discussion of this in Rapid Development, calling it "The Fuzzy Front-end" of a project. "Everyone knows" that certain projects "have" to be undertaken, but they will often just be talked about and talked about and talked about until it's too late to do anything but talk about not talking about things in future.

rubidium 11y ago

"1. Nobody had the guts to kick off the project until the competition proved it doable and desirable; by then, the project was in catch-up mode and had to be finished lickety-split. 2.If the project were started long enough before its due date to finish on time, all involved would have had to face up to the fact from the beginning that it was going to cost a lot more than anyone was willing to pay." In other words, projects are late because business justification is usually weak for software projects. When faced with "in order to ship this by 12monthsfromnow we need to hire 5 more software engineers today" management stalls.

Etheryte 11y ago
Adding more manpower doesn't mean faster completion.
- loup-vaillant 11y ago
  At the beginning of a long project, it probably does. This is not like adding people to a late project. Now if your project isn't easily separable in several relatively independent parts, you are screwed.
dahart 11y ago
> In other words, projects are late because business justification is usually weak for software projects. While that's sometimes true, I read exactly the opposite. I read what he said as: 1- Software projects don't start until justification is strong, and 2- justification doesn't become strong until it's already too late. So, the problem isn't (necessarily) that justification is weak, it's that strong justification is itself a red flag, because it's already too late to start if you have a really good business case for it, you should have started before you had all the data to prove you needed to start. But, I don't think he's necessarily saying we should be able to somehow predict the future and start software projects before we know for sure we need them, he's just reflecting on patterns observed and providing more of a thought framework for dealing with these patterns.

jamiek88 11y ago

I think almost by definition anything that is late didn't start early enough.

sarreph 11y ago

> "What’s really wrong with us software folks is that we’re continually beating ourselves up for something that’s somebody else’s fault." Amen to that.

greggman 11y ago

The first thing that comes to mind is Joel's Five Worlds http://www.joelonsoftware.com/articles/FiveWorlds.html http://www.joelonsoftware.com/articles/FiveWorlds.html not all software dev is the same. Coming from games, every project I've been on was an original title. That meant it was 100% up to the team to decide the scope of the game. Most teams (not all) guess how much they can get done and don't plan for cutting features. "We're going to have 12 characters, 30 levels, 10 power ups, 45 enemies, 600 puzzles, online multiplayer, and IAP for 500 items". And then they just start making it. They run into 2 big problems. 1) They don't know if the game will be fun until they're 50-60% in. If they guessed wrong they're off schedule 2) They're attached to the vision and unwilling to cut stuff. My point though is this doesn't fit "we didn't start early enough" IMO. They knew how much time they had. No one was/is dicating too much work. They can cut the scope at any time. But they rarely do. There are solutions. 1 is to prototype with a small team. Unfortunately most teams can't do that as they'd have 90% of their staff doing nothing. Larger companies can do this or maybe if they switched to the Hollywood model, no employees only contractors, they could do it. 2 is to design so things can be cut and to check the schedule and start cutting. This one is hard for most teams because they see the game they imagined in their minds and it's not the game with stuff cut. Players though don't know what that vision is and so won't missed the cut features because they aren't aware of them.

dahart 11y ago
> My point though is this doesn't fit "we didn't start early enough" IMO. They knew how much time they had. No one was/is dicating too much work. They can cut the scope at any time. But they rarely do. Doesn't knowing how much time you have, and then not cutting scope when you see your plans don't fit into that time, count as not starting early enough? I also came from games, and I agree that scope is rarely cut, and often self-inflicted. I was also under Mr. Very Large Publisher, and it was more complicated than that- we had control over scope, but not over schedule. We had control over how much work to do and the quality, but not the budget. The major problem in my experience was that the team was excited, motivated and willing to work hard, so optimistic about their ability to do great things inside the limited budget and schedule. Therefore, they tried to do too much. All other things being equal, more time would have helped, every single time. Which can be summarized as "we didn't start early enough." That doesn't mean that actually starting earlier would have solved the problem. Actually starting earlier might have led to even larger plans. So, IMO "we didn't start early enough." is not meant to be taken literally, it's a way of understanding the problem, not a way to solve the problem.

deleted 11y ago

[deleted]

ScottBurson 11y ago

This is my favorite part: If a project offered a value of 10 times its estimated cost, no one would care if the actual cost to get it done were double the estimate. On the other hand, if expected value were only 10 percent greater than expected cost, lateness would be a disaster. Yes it would be a disaster, but instead of obsessing over “What’s the matter with those software folks who didn’t deliver on the schedule we gave them?” we need to ask instead “Why did we ever kick off a project with such marginal expected value?” The message for us software developers is: try to work only on what I call strategic projects: projects whose expected value is much greater than their cost could possibly be. That means they need to continue to pay benefits well into the future.

pm215 11y ago
At a previous gig "strategic" was a euphemism for "we don't have a paying customer for this work" :-)

bboreham 11y ago

Longer treatment of similar material by same author: http://www.goodreads.com/book/show/946076.Why_Does_Software_Cost_So_Much_ http://www.goodreads.com/book/show/946076.Why_Does_Software_...

pkaye 11y ago

Having worked in firmware, I have seen the issue with how things are partitioned between software and hardware. The hardware tends to get concrete requirements and everything else abstract or complex in dumped on the software. So you have to figure out algorithms which have not been thought through yet or deal with edge cases the hardware cannot deal with properly. These all add complexities to the software which we can't quantify early on. I believe if we specced out the software design to a level we are confident with the algorithms and data structures involved, you could get as predictable a schedule as hardware design.