October 17, 2007

...Learn TDD with Codemanship

How Much "Almost Perfect" Code Can A Team Deliver In A Day?

How much code could a team of 6 people - I mean a real one, and not some fictional team of NASA rocket scientists who use special science and voodoo and stuff in their development processes - deliver in a day if it had to be:

a. Thoroughly tested? - I mean, serious coverage here. Not just every line of code, but every path through the code and every possible combination of conditions that could conceivably result in different behaviour.

b. Thoroughly inspected? - I mean, not just a bunch of us sitting in a room saying "he hasn't used Pascal case here" or "there should be more comments in that method". No, none of that bulls**t. I mean proper, formal inspections where the team chooses test cases for every even slightly complicated block of code and simulates the execution of the test case, making assertions about what should be true at each step and looking for test scenarios they didn't think of already (and then writing tests for those scenarios and adding them to their already very comprehensive suite of automated tests)

c. Thoroughly designed? - I mean, not just having a UI layer and a process layer and a business layer and a data layer (which is how a child might draw a software application's architecture - in crayon). No, I mean properly designed to be easy to change and extend. Simple, cohesive methods packaged into cohesive and loosely coupled classes, packaged into cohesive and loosely coupled distributable components. Elegant abstractions. Meaningful identifiers. Readable and understandable Devoid of unhelpful comments cluttering up the code so we can see for ourselves what's going on.

I reckon a team could produce 50-100 such lines of almost perfect code in a day. That's 1000-2000 LOC in a month, and about 12,000 - 24,000 LOC in a year. The cost of such a line of code might be about 0.1 person-days.

I've worked on projects where it took a team 100+ developers to deliver 100,000 lines of sort-of-working code in 18 months, which was riddled with defects and very hard to maintain (and that's why it cost so much to deliver).

It makes perfect economic sense to take your time and strive for perfection. And yet the vast majority of teams still prefer to do it the hard way. Why?
Posted 13 years, 1 month ago on October 17, 2007