When a marathon runner realizes he got the first 10km 30% faster than planned, does he get happy? No! He knows he already lost the race. Too much energy was spent and, as humans are not perfect machines, he will burn out before the finish line. Building software is a long distance run. When all you can think about is how fast we can go, your judgment gets clouded. All extra speed will come with a price down the road. Instead, what should we strive for?
The long road
No, you didn’t get it wrong: marathons are still about who runs the 42,195m first (at the least last time I checked). So one cannot ignore the timer and call it a victory for being happiest participant. The point here is: being faster over the first half of the run won’t mean nothing if you get injured and don’t cross the finish line first.
Marathoners train hard for years so they can have control and knowledge about their body. A smart runner knows that he or she has energy as a finite resource and going over the body limits will not pay off. They have planned how fast they should run each mile and they try to stick to it. So they monitor other things during the route: body heat, heartbeat frequency, pain levels and more. If they see room for keeping or increase their speed, they will do it. Otherwise, sometimes the best decision is to cool off and try to regain ground later.
How is this related to software? First, we train hard to strengthen certain skills and gather knowledge, as runners do. Second, software projects are not speed tests. The usual enterprise software lifecycle take several years of effort, money and knowledge. Long shots, as a marathon. So focusing on being fast, specially on early stages, usually is the worst strategy. And, as in a marathon, you can see others taking off way faster than you, and this makes you worried about getting behind. However, the one with the best skills and plan will win, no matter how the run started.
In software we have tons of metrics to keep track on how things are going: technical debt, code smells, tests…each one of them paint a different picture of how things are going. When you are reading this signs, you know how fast you can go safely. You can push some of them, define looser standards and even neglect them for a while watching out for milestones and keep on track. However, if you fight these numbers at some degree, things will go sideways. And you should not stop on internal software metrics. All KPIs should be watched for, as they can complement how to manage plan changes.
No plan is written in stone
Even in marathons, the plan is not always perfect. You can feel a old injury sooner than you expected, or get a adversary particularly fast on that day. This happens on software too. So those are signs to just run off and forget about it all? No! In software, you have metrics about your performance. You can look at them and see if there is any room to increase your delivery power. In fact, those metrics are there for allow not only a better plan, but a more flexible one. Or better plans are those more flexible?
There are no shortcuts
Shortcuts are paradoxical. If you think about a destination, there is a optimal way of getting there. In software we usually can’t be sure of this perfect path and whether we are on it or not, but we sure try to be. If you do find a shortcut, you were actually in the wrong road in the first place. So that’s not a shortcut, just you adjusting back to the optimal path. But bear in mind and make no mistake: There is no magic way that will decrease the optimal way of doing something. You whether got closer to the optimal path or you are letting some technical debt for posterity. This might be exactly what you wanted, but do not think it will disappear. When too much technical debt is stacked, development teams stuck. As on a long run, a fast start can lead to a slower end.
Boosts exist (but use them wisely)
No one will see the finish line from less than 300 meters and keep up the pace when they know they are loosing. They will give it the last effort with all energy left so can win. No one wants to finish a marathon with remaining energy, anyway! These boosts are more than welcomed to win the race. The problem is that in software development this finish line is blurred. We can manage seeing some metrics getting a bit uglier and still deliver a key milestone on time. But what comes after that milestone? An even tighter deadline?
This is the reason we need to keep track of broader metrics, related to the organization and the clients as a whole: sales, profits, customer satisfaction and more, much more. Those metrics can indicate when to boost things up, even if it means internal metrics will be negatively affected. Following this indicators is about managing and setting smart thresholds, not stone cold boundaries. But this works both ways.
What to strive for
Long term delivery speed is the result of constant, healthy performance over the many phases of a project. We need to observe limits and goals in terms of software quality, business KPIs and much more. This scenario allows us to strive for the adequate overall speed, but not as a direct goal. As we keep in mind all the metrics we need to a healthy path, we win the race when we look for:
- Keep it lean: Find the smallest set of features you need to achieve a organization goal.
- Being Surgical: Find the smallest set of changes on your code (or design) to achieve the desired result.
- Business Alignment: Be sure your road map is as tightly with the organization plans as it gets. It is harder to justify any effort when paying people will not understand even why it is happening.
- Correctness: Do the right thing, even when perceivable value and technical effort are somewhat disconnected. If you are aligned with the organization, lean and surgical you can assume this needs to be done, so there is no shortcut.
Conclusion
As long term activities, software and marathons are much alike. Be aware of speeders and promises of magical shortcuts. Know yourself and your team, observe the performance indicators and stick to the plan until you are sure it makes sense to adapt. Marathon runners train for better cardio ratio, running techniques and energy efficiency. How fast they go is an expected outcome. Software Engineers sure have a lot to learn from them.