Rapid Development

Of all Steve McConnell’s books, Code Complete gets the attention. People quote it, name websites after it, publish photographs of themselves kissing it and generally froth and foam about it. And quite right too because it’s great. However for my money his book Rapid Development is even better.

Although called Rapid Development, its name is something of a misnomer. It’s not about rapid development techniques per say, rather it’s about excellent project management techniques that as a side effect will enable your project to proceed as quickly as possible. To me it feel’s like its project managers written for developers.

If you don’t want to read it cover to cover (what’s wrong with you – read it all) then software estimation, the sections on motivation and team structure and classic mistakes are worth reading as standalone chapters. I love the estimation tables provided to measure your own schedules against. It’s illuminating to measure your own projects against them. So next time an impossible deadline looms, you’ll have the facts to back you up. Marvellous.

Estimating Lines of Code

I’ve always been a bit puzzled on why people would use lines of code to estimate projects. It seems that estimating (more realistically guessing) lines of code (LOC) to estimate effort and schedule is way harder that splitting the project into jobs and undertaking an estimate for each job. However reading Steve McConnell’s Rapid Development book has changed my mind.

In it he has charts linking lines of code to effort over a range of criteria. So if you know the LOC for your projects you can plug them into the tables and see how you projects measure up. Moreover you could get lines of code for a project to build a historic set of data tailored to your team to take some of the guess work out of that blackest of all arts – software estimation.

Which got me thinking of how you would quickly get non-commented, non-whitespace lines of code for a Web Application written it ASP.Net

---

C#
Count the semicolons C#.

CSS
I would count the number of {

HTML
LOC are more difficult here. Possibility to count open angled brackets (<) and maybe divide by 5 – making the assumption that there is 5 tags per line JavaScript and VB.Net
Semicolons doesn’t work so well here as they are optional in the code. You’d need to be a bit cleverer and count the number of carriage returns without comments and with a length of more then one when been trimmed

OR

Quick and dirty: arbitrarily estimate the number of characters per line then whip through all the files and could the characters and divide by the per line estimate.

SQL stored procedures and functions
Like JavaScript you’d be looking at using carriage returns or using the quick and dirty method

Other elements.
For example SQL reports, Data extract components etc…
Can’t do anything with these so get the back of the envelope out and estimate what fraction of the project was spend on these activities. Multiple the LOC by this ratio.

---

In the best of all worlds we would all use function points or some kind of automated formula based approach but I moved out of the best of all worlds sometime ago and sadly my software development occurs in the dirty old real world. In this world one frequently doesn’t have time to spend half a day calculating historical effort but you’ll always have the opportunity to spend a sneaky 15 minutes seeing how many LOC were wrote and how long it took. It’s always good to marvel at how much work you’ve done and it may even make software estimation a slightly less black art in the future.

Software Estimation for the Courageous

In days of yore a man used to prove his bravery by a mighty quest for a fair maiden, the slaying of a ferocious dragon or by acts of great swordsmanship on the battlefield. Sadly in modern times these opportunities rarely present themselves to the average software developer. But fret not stout of heart – there are still ample opportunities for bravery without moving away from your monitor. Simply give an estimation of how long a software project is going to take using the following methodology.

I truly believe that software estimation is blackest of all the black arts in software development. Entire books are (quite rightly) written on the subject.

The best and simultaneously the worst advice I’ve have ever read about estimation comes from Crash – Learning from the World’s Worst Computer Disasters. Quite simply - sit down in a quiet room with a bit piece of paper and a large mug of coffee and truly and honestly work out how long you believe the project will take. Miss nothing out. Remember the testing, remember the deployment, remember the reworking, remember it all. Then TRIPLE it. No matter how bleak the answer looks – bravely go out and tell your project manager. He/She will not thank you for it. They will request re-evaluations, ask second opinions and doubt your sanity. You may be sidelined, sneered at or send off in exile to the build team. You will be tattered, torn and unloved but you will be correct.

If you are brave then try this. I did once and it caused a career damaging fight between the head of development and the project manager. The project manager left, the head of development sulked but the work was delivered in the (tripled) timescales that I said. I was unloved but correct. I was brave. I never did it again.

As an addendum to this – a far better way of estimating projects would be to actually start to build historic data in your company as base predictions on that. Steve McConnell gives excellent advice on this in Rapid Development. The moral of the above little anecdote is that it’s not enough to be correct; you have to be correct and believable - and that takes evidence.