Two contradicting goals of Software Development
In the "Crystal Clear" book, Alistair Cockburn describes software development as "a series of economically-constrained cooperative games with restricted resources", where each game has two goals:
- Deliver the working software;
- Prepare for the next game.
The first one is about delivering business value; the second one is technical tasks - maintaining and cleaning up. As the development time and the number of developers are limited, the goals are competing - allocating resources for one means withholding from another.
Following this definition, I've noticed that software projects usually go in one of two "gears". Imagine a burndown chart, which ideally should look like a straight line. In real life, the velocity at first is slower than predicted (first gear), and then it goes up. By the end of the iteration, the speed of delivery is much higher than at the beginning (second gear).
First gear: technical improvements
The dev team on the first gear is typically more focused on technical improvements.
As software developers, we understand that it is impossible to predict in which way a product will evolve. Every alive project will have new features that we didn't plan for. The models that code represents are always slightly outdated - the code was designed for the functionality we had in mind a while ago, not today. Without maintaining, the codebase it gets cluttered and full of cruft, the further development gets slower and slower. We have to clean up to keep up the speed.
When we start a new iteration of the product, we can plan what technical tasks should be done for fast and quality delivery. This work allows us to move faster in the latter phase of the iteration.
Overdoing it
The curse of many pet projects is getting stuck in the first gear. When there are no deadlines - oh, it is so tempting to improve the codebase endlessly! Who doesn't like a nice clean code? The bad side is that business value is never delivered.
Second gear: business feature delivery
When the deadline gets closer, the team switches to the second gear.
It is too late to work on technical debt. It might be even time to create some technical debt. Dirty hacks appear. Cutting corners worsens the codebase, but it helps to deliver features on time. The best you can do is to make notes, create technical tickets to handle in the next iteration.
Overdoing it
There was a project that "started after it should have been delivered". A team of developers was thrown on it in a great rush, and they had to do it as fast as possible. It was not a project for several days or weeks; it was for several months. The first results were delivered quite quickly, but then the project started to slow down. It got slower and slower, as hacks and bugs were piling up without getting proper attention. Unfortunately, due to poor management, the team couldn't dedicate time for cleaning up. In the end, the project took much longer and was much more stressful than it could have been. Luckily, it didn't lead to lay-offs or bankruptcy, but the history knows cases when companies went down because of the terrible unmaintained code.
The right moment to switch
When the team knows their current gear, they can make faster and better decisions - when to research meticulously and when to cut corners.
The question is: how do you find the right moment to switch gears? Could it be that some particular project doesn't need the gear-switching at all? Could it be that the second gear is the right way from the beginning? Could it be that the project needs to focus purely on the technical side for several sprints?
The primary tool here is planning, both short-term and long-term. "Gear-switching" happens on the long-term scale as well: during a long project, the first sprints tend to under-deliver and go slower than planned in general. On the late stages of a project, when the requirements are better defined, and the code matches the business domain models, the team can develop features much faster.
Planning is like a reality check: it shows your real velocity and progress. Making a gear-switching decision without planning is like walking in the dark while blindfolded. Based on the plan and the current state, the development team can define the right moment to speed up.
By practicing planning and retrospectives, the team can learn to predict the gear-switching, making the burndown charts closer to a straight line, and thus building more trust and reliability within the company.
Cover photo by Hidde van Esch on Unsplash
Oldest comments (2)
Two gears is a good analogy but leaves out some cases:
1) Lots of gear 1 deliverables turn out to not deliver business value
2) Lots of gear 2 would not be necessary if there had been more collaboration on implementation to begin with. Things could have been coded better the first pass many times.
People underestimate the amount of collaboration necessary to build a product. Its very easy to end up implementing the wrong thing the wrong way.
Yeah, totally agree. It just takes time to improve that collaboration. When we get better at it, the gear switch should become less drastic.