Athens—Greece year 460 BC; a young man contemplating wedlock, asks Socrates for his advice. The wise one replies: “By all means, marry, if you get a good wife, you'll become happy; if you get a bad one, you'll become a philosopher”.
NY—NY year 2011; a young man asks “Socrates” the same question. The wise one replies: “Based on income compatibility, age, employment status, marriage penalty tax liability and cohabitating couple economy; you have a low chance of a successful marriage. Well“Socrates” is not communicating via a paranormal medium—it is an “Expert System”.
From my experience, and also doing work closely with some excellent people in the software field, I have come up with the conclusion that if you can break down the tasks and requirements of the projects to the bare minimum you can come up with a good estimation of project deadlines.
That's not to say that we can't plan software engineering. But it's isn't the same as civil engineering.
The fact that client requirements change all the time simply has to be built into the planning process, and the client needs to understand the consequences of changing requirements.
But this is all for the good - often no-one knows what is actually required until you start work on it, and there's no point in stressing about preparing the perfect spec in advance because that doesn't work.
Instead, start with prototypes/PoCs and progressively refine them until you have what the client wants. Likewise, the estimate should progressively refine itself during the development cycle. I describe this as having a fuzzy view of the project schedule at the beginning (e.g. 10 weeks +/- 4 weeks), but progressively coming into focus during the process (until you can say, "we'll release tomorrow!").
The more you try to do up-front planning in software development, the more precise your estimate will be, and the less accurate.
Precise, because you'll keep breaking down the original assumptions until you have a set of fixed tasks to implement with an exact time allocated to each, but less accurate because you're constantly refining all of the original mistakes, assumptions and redundant tasks from the original assumptions.
The perfect illustration of this is your suggestion of multiplying the developer's estimate by some arbitrary fixed ratio. What this actually tells you is that the developer's estimate is wrong and unhelpful. Probably because:
a) it omits all of the tasks that you haven't told the developer about; because you forgot, the customer forgot, or because they'll be discovered only during actual development
b) it omits the boring integration/testing/release process that developers don't think about because it's boring
c) the spec will change, and the workload will change accordingly.
d) developers do over-estimate how long it takes them to do the work
Use of proper agile processes will give you a far more realistic view of your project.
There is no reason actually to design a peer to peer voice communication software when you have Skype. But why let Skype go unchallenged for years and years? Maybe some of you can come up with better algorithms to top skype and provide better alternatives to the user. Maybe you can present a better GUI than what skype has to offer at the moment. So let's give it a thought.
This blog touches upon the point of talent preceded by wierdness and before it got plunged into a sea of other posts in linked-in, I tried to capture the essense of it:
Comments
guest
Sun, 05/26/2013 - 23:33
Permalink
amazing article
Thanks for posting it. Was really an eye opener!
sakib