Speed is a key feature of successful development teams and organizations. As software developers, it is our job to turn abstract visions and ideas into something that users can touch and feel, the faster the better.
The faster we can go from idea to working software, the faster we can earn revenue on those ideas and the faster we can gather feedback from actual users to use as input to feed the next set of ideas (or refinements of existing ideas) to implement. Speed also allows us to react rapidly to opportunities and threats in our organization’s surrounding environment, such as those coming from competition, regulations, customers and market trends. Additionally, speed means that we can address internal issues such as bugs and other problems in our systems in a timely manner.
Ok, so faster is better. Got it. Well, not so, hmm…, fast. When it comes to software development, there is another force coming into play as well. Being fast over a week or two, or maybe even a couple of months, is of relatively little use to our business if we can’t sustain that pace in the long run. Very few companies build their success based on just a few weeks of produced output. Therefore, the speed we are talking about here needs to be of the kind that we as a team can maintain over a long period of time. To use a running analogy, we are participating in an ultra-marathon race, not a 100-meter sprint. And, just as running as fast as you possibly can for the first kilometer of an ultra-marathon will likely exhaust you and have a negative impact on your overall race time, optimizing for short-term speed in software development will actually make you slower in the long run and put your business at risk of being outperformed by competitors using a strategy more suited to the distance.
This means we need to balance short-term speed against long-term, sustainable, speed and in most cases, optimize for speed of the sustainable kind. So, while there certainly are cases when crunching or taking on technical debt in the name of short-term speed is warranted, for example to meet a critical deadline, that should be the exception and not the rule.
Let’s take an example... As a developer, the faster you can crunch out a piece of code, the faster you can get the feature that you are working on into the hands of your users. All good so far. But when optimizing for pure short-term speed, you probably didn’t have time to add those unit tests, maybe ignored a few ugly parts in the implementation and perhaps did some quick copy-paste from other places around the code base since you didn’t feel you had the time to extract that common utility method. And when it comes to naming, well…, “cs” certainly saves a few keystrokes compared to that lengthy “customer_service”. This is short-term speed in its essence.
The missing realization here is that code (usually) is read more often than it is written and that code (usually) needs to be updated, modified and maintained over a long period of time. So, in order to achieve sustainable speed, we need to focus on readability and maintainability as well, which makes the process of writing that piece of code in the first place a bit slower.
So, what are the enablers for sustainable speed? It is pretty much all of those best practices in software development that are all too often ignored for the sake of short-term speed:
- Test automation and testing tools
- Spending time on design and architecture
- Paying off technical debt
- Continuous refactoring and improvement
- Code quality
- Process automation
In closing, it is worth mentioning that the line between short and long-term is not always that clear-cut and that it is all too easy to get stuck in the wrong quadrant of the urgent vs. important matrix in our day-to-day work. When this happens, it helps tremendously to establish a long-term vision for which type of development organization to build and which practices, values and principles to follow based on that. In doing that, we can easily sanity check whether we are on the right track towards our vision, even though we of course sometimes need to make a few 100 meter sprints in the name of pragmatism to meet that critical deadline.
Niklas is ReacMee’s VP Engineering. He’s got extensive experience within development from being a programmer, consultant, CTO and architect. If you have any questions regarding this post or about everyday life in Niklas’ dev-team, don’t hesitate to contact him at firstname.lastname@example.org.
If you want to hear Niklas talk about tech irl you can always follow our Meetup-group TeachMee to know when our next Meetup is held and join us then.