Monthly Archives: April 2009

Learning and doing

Question

Think about your last project. How large portion of the effort was spent on writing actually useful features for the customer?

We are talking about actually useful here, from the customer’s point of view. Do not include the time spent on testing, meetings, waiting for the code to compile, duplicate code that could be refactored away, etc.

Do you have an answer? How much is it?

My answer

Let me do a ball-park estimate of a project from my past.

The codebase consisted of 80,000 lines of code. Roughly half of those were unit tests, developer scripts, and other non-production code so that brings the number down to 40,000 lines. At least half of the code could have been refactored away: 20,000 lines left. And about half of those lines were for features with negligible purpose, such as unnecessary user configuration options. So, I would estimate that 10,000 lines of code were actually useful.

Including the entire project team – developers, testers, project managers, customer representatives – the project took about 10 person-years. That is roughly 2,300 person-days, 17,000 person-hours, or 1,000,000 person-minutes.

Now, if we generously assume that each line of code takes 1 minute to type, it took about 10,000 minutes to type in the actually useful code. That is 1% of the 1,000,000 person-minute total.

So my answer is: about 1% of the time was spent on writing actually useful features for the customer.

Now, I know what you must be thinking: what a crappy project. But no, not at all. The project received high praise from the customer and spawned more project orders. Both the customer organization and the development organization started an effort to spread some of this project’s methods to other projects. This project succeeded.

Even in a successful software project only 1% of time is spent on writing actually useful features.

Learning cycle

The other 99% goes to finding out what are we trying to do and how we can do it.

Discovery cycle

We are learning about the product we are building, the interfaces we are using, the customer domain, and so on. We even learn about the code we wrote ourselves. Every bug report is feedback and every bug fix a start of another iteration on that minicycle.

To be more productive, we should focus on the 99%, not on the 1%. How can we learn faster?