In the five years that I have been developing
commercial software, I have countless times heard the refrain "How long will
that take?" "about two weeks" comes the reply.
It never takes "just two weeks"
I will explain.
In his book "The Mythical Man-Month", Dr.
Frederick Brooks explained that coding, in general, consists of
one-sixth of the time of a software project.
Requirements, Specification, Architecture, Design,
Integration, Testing, and Deployment took the rest - and Brooks wasn't even
counting Technical Writing and Training. Futhermore, he added that developers are
inherently optimistic; the estimates they give are based on hope, not the
reality that there will roadblocks and there will be bugs that
shake out, and these bugs need to be fixed, then the system needs to be
re-tested.
In other words, Brooks points out that yes, it is
possible that coding takes just two weeks - but that's probably not the
question Management is asking. Management is probably really asking "How long
until we can get this into the hands of the customer? (At high quality)."
In my opinion, this difference of meaning is one
of the core problems of software development. In the book Leadership: 2000
and beyond, the main source of communications breakdown is referred to as a
"lack of common core of experience."
Simply put, all too often, Management and Software
Developers lack a core of experience. (Especially upper Management in a company
that is anything but a software company.) As a result, they use the same words
but mean different things.
Two weeks later, coding is done, but there is no
documentation, it's buggy as hell, and the integration doesn't quite work right.
Management now has a problem: Ship it late and offend the customer, or ship it
on time and offend the customer. Either way, it's the coders fault.
In order for Management, Customer, and Coder to
agree, we need to speak the same langauge. That means, when asked the question
"how long is it gonna take?" We have to account for all the variables: Requirements,
(And a change in requirements, 9 business days from now), Specification,
Architecture, Design, Coding, Integration, Testing, Testing/Coding Feedback Loop,
Deployment, Training, Techical Writing ... and a little something extra for risk.
More than one person has attempted to create a
system where we track the differences between estimated and actual time, to create
a "load factor" for our estimates, but developing a rich history of multiple projects
takes time. I strongly recommend looking into Personal Software Process (PSP) or
Extreme Programming, but in the mean time, remember to account for everything.
Just keep in mind, It ain't gonna take "just two weeks"
EPILOGUE: No, it never, ever, ever takes just two weeks
I wrote the article above on August 17th, 2002 during a leave of absence for
the birth of my daughter. Came back to work, and had this problem on the very
next project. I kid you not.
So, we're sitting in a meeting, and the ship date for the product is
September 20th (it's now the 9th.) All of the coders are confident that we can make
that date, when someone points out that that's the day the software has to be MAILED
TO THE CUSTOMER. Which means we have to physically burn 80 CDs prior to ship - and
that will take about two days. (So we're back to the 18th). Except that we have to
get and test a "build candidate" previous to burning - which means the morning of the
17th we'll have to do a build, burn it later in the morning, and test it in the afternoon.
Which means we'll have to be done by the morning of the 17th - three days of development,
which essentially go up in smoke because the coders and management aren't speaking the same
langauge. In other words, No, Virginia, it ain't gonna take "just two weeks"