Learning and doing


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?

3 thoughts on “Learning and doing

  1. EdvardM says:

    Simply awesome

  2. valk says:

    Good blog post and that picture is great, maybe call it the coder’s cogwheel.

    When I was developing an ideal base for web development (aka re-inventing the wheel) I was spending enormous time rewriting the code as I saw something imperfect. I wanted everything modular. This is like a recursive function and it gets very deep very quickly. In the end there was not much of code but atleast 10-20 times more rewritten or discarded code.

    The dilemma of programming is finding the ideal base between perfecting existing code API and producing features. As unideal solution will affect all later code, its very easy to be hurled back to the vortex.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s