
All Late Projects Are the Same (2011) [pdf] - musha68k
http://www.systemsguild.com/pdfs/DeMarcoNov2011.pdf
======
ScottBurson
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
At a previous gig "strategic" was a euphemism for "we don't have a paying
customer for this work" :-)

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

~~~
greggman
You can use "we didn't start early enough" in such a way that it loses all
meaning.

If you know your deadline (most game devs do) and your 100% in control of your
scope then it's up to you (the team) to pick a scope that fits your resources
(people and time).

The original article talked about situations where people didn't know the
scope or couldn't change it and often wasted lots of time not starting. I
think those are fundamentally different situations.

~~~
dahart
You're absolutely right that games are in a generally different situation than
a lot of other software projects; having control over scope means, in theory,
you don't ever have to be late. And yet it happens routinely, possibly (I
speculate) more often than not.

The article implied once that people wasted time waiting to start, in reason
#1: "Nobody had the guts to kick off the project until the competition proved
it doable and desirable."

But reason #2 is where games that have a deadline and scope control fit in.
"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."

You picked a scope that fits your resources, and yet you manage to run well
past the deadline. You started it thinking you'd get it done in time, and yet
you managed to run late. _If_ you started earlier with the same deadline,
scope, people, etc., you would finish on time. This might feel like a somewhat
silly observation (which the author points out in advance) but it is
nonetheless true for the situations you are describing. If you didn't finish
on time, then you didn't start early enough. It's a slightly twisted way of
saying your scope was bigger than you thought. It's not saying that actually
starting earlier is the solution.

Reason #3 is entirely metaphorical. "No one knew that the project needed to be
done until the window of opportunity was already closing." This is saying that
you know your scope, and you have a deadline, but you didn't even think of the
idea until it was too late. It is true to say that you didn't start early
enough, but it is also true that you couldn't possibly have started it
earlier, without a crystal ball.

The thrust here is not literal. I disagree that it loses any meaning at all,
it just might not mean what you thought.

------
rubidium
"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
Adding more manpower doesn't mean faster completion.

~~~
loup-vaillant
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.

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

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

~~~
gahahaha
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
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.

------
bboreham
Longer treatment of similar material by same author:

[http://www.goodreads.com/book/show/946076.Why_Does_Software_...](http://www.goodreads.com/book/show/946076.Why_Does_Software_Cost_So_Much_)

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

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

