How long does it take to make software? And how long should it take!
Have you ever been asked by someone for your ‘expert’ opinion on how long it would take to go from e.g. the city center to the airport? What was your answer then? Did you give them a generic estimate from off the top of your head? “it’ll take you atleast 50 minutes to get there” or did you ask questions such as when, where and how will they go and then give them an answer? “you have to get to the airport at 7 pm? are you crazy!!!”
An Analog
Lets consider the possibilities for making such a journey. First, there’s the usual route which is 16 km long and would take around 30 minutes, then there’s slightly longer circumventing route but which takes around 25 minutes, and then there’s the shortcut, which is around 9 km but full of potholes and takes longer to travel through. Then you must factor your mode of transport e.g. a mehran would take longer than a corolla, and self driven would be slower than a taxi, and god forbid if you decide to go via rickshaw, which would take twice as long as a car ride. Once you’ve got that down, its time to think about rush hour patterns, which time would be better given the load on the main roads? Next factor, weather! (especially if you are in karachi and it rains!!). Last but not the least, the capability of driver of the vehicle. Some people will travel a clear road at slow speed, while others can breeze through a packed road with ease. In short, there are a variety of possible answers and it depends on the particular requirements, assumptions and constraints of the traveler which will decide which method to choose.
How soon can you make xyz software? The ‘normal’ method!
When you are developing software and leading a team of developers, this is the first question which your boss will ask on the outset of a new project, “How long would it take to make a 5 page website with a CMS engine and rss publishing options?” (e.g. the green and white blog). And usually, you have about five minutes to answer. You do some quick mental calculations, thinking you would use the wordpress engine for cms and publishing, take two days for a design to be completed, three days for the other pages and about 3 additional days to put it all together. Before you’ve had time to think it through, you say 15 days. Your boss will think, okay… if he can do it in 15, he can do it in 10 and goes and commits 6 days to the client. Afterall, its ‘just’ 5 pages.. how much time would that take! The PM doesn’t know what he’s talking about…
Ofcourse, after that it all goes to hell. You are committed to 6 days for a job which would take atleast 8 (that’s around 3 hours overtime a day from the onset), you team becomes overworked, screaming matches sometimes ensue, and as the deadline approaches the stress level goes through the roof. Eventually, if you do make the deadline, the project comes back with bugs, and if you dont, you have a screaming boss and client to contend with.
How soon can you make xyz software? The ‘new and improved (although decades old)’ method!
One of the first things a PM should do to head off this outcome is estimate correctly. Think back to the example I presented on the earlier. The PM did a preliminary analysis and came up with the numbers entirely in his head. There are two problems with this scenario.
First, the PM did not consult the team who would actually be doing the work on how long would it take them. It takes a little longer, but it creates a sense of ownership over the timeline, because the team helped in deciding it. Also, having team input brings to light certain assumptions and constraints which a single person might miss out on or ignore. Another method is to use one of the established parametric techniques available such as line of code, function points, object points or use case points and then generate your estimate based on data on effort/time per point or thousand line of code. For these you need a little more training and hands on experience but these techniques are a must-have in the toolkit of every PM. This is how long it takes to make a software.
Secondly, the PM did not explain ‘how’ he came up with the figure of 15 days to the boss, which is why the boss went and committed 6. When you do not communicate the how but just the what, the meaning ends up getting lost in translation. We are all aware of the amount of miscommunication which can occur in the workplace, a verbal estimate is no different. Something which you said would take 15 days, because of reason a,b and c would be heard by the boss to take 8 days because of reason b,c, and d while they would explain it to the client as taking 6 days because of reason c,d,e,f, and g! There are two ways of effectively handling this. One, never give an estimate verbally or over the phone. Always send along a document which clearly states why you are saying it will take you x number of days, and if you must, make sure to include the disclaimer that these estimates are rough and you will not be accountable for them. Secondly, if you can, make sure you can present your estimates yourself to the boss or client, instead of relying on someone else to do that. The reason is that there are certain constraints and assumptions you would know better and could explain better, which would not be lost in translation. Also, negotiations often happen at this point, and as a PM you are in a better place to know where you can cut down the time, quality or cost (the project management triangle) because of the time and effort you’ve invested instead of the boss or a third party. Allow others control over this process and you’ll be facing the problems stated in the above example even after all your hard work. This is how long it should take you to make the software.
What they say….
Remember, once you give out an estimate, you are locked into the result! you are committed! and you must deliver within the time you said you would. Afterall, you said you could… right? They say that the journey of a thousand kilometers begin with a single step. Take the improved first step and your journey will be less arduous, take the quick and easy one and you will be in for one hell of a ride! And did i mention, you’ll automatically fulfill a very important requirement of the CMMI appraisal process by having the evidences present. Two for one!! it just doesn’t get any better than that!

6:49 pm
You can also make it a rule to always always add phrases like ‘x to y days which may vary with the exact requirements’ even when giving out a rough estimate to your boss verbally. Lets face it, we DO have to make decisions in 5 minutes and commit to over-zelaous deadline at times which might run your company for the next 2-3 years.
Assuming you are a/the PM, if your boss is setting out a unrealistic deadline, add ‘talk to boss’ to your TODO list. You can push him for establishing and following proper processes for at least the major SE phases. If that doesn’t work, add ‘look for a better job’ to your list. Any company with such a boss wont survive for long.
My 1.29 PKR (at the going exchange rate)
9:16 am
haha .. that old method sounds so familiar ….. I once worked for manager that would always cut down my estimates in order to make us work harder … it was just sooo maddening !!!!
2:49 am
Doesn’t seem like a case of bad estimation; sounds like a case of having an asshole for a boss. It doesn’t matter what your estimation methodology is; if your bass is an ass and reduces the given estimate by a 3rd; he’s screwing the company.
Any decent engineer should put his foot down and say “No, I said 15 days. This project is not doable.”
Secondly, you may be committed to a timeline you have given but even the best plans can get broken real quick. General Eisenhower famously said
“In preparing for battle I have always found that plans are useless, but planning is indispensable.”
If something has changed or if you can’t meet with your plans; be honest and forthcoming with the customer. Explain them what can’t be met on time and why. Give them the updated timelines. People like honesty over bullshit any day.
And finally, CMM is a horrible standard that keeps your eye off the real ball. If you want people to respect you; it should be for your work which should speak for itself. Not by some stamp on you saying “Hello, I’m dave, CMM Level 5″