Do you want to know a trick to increase your team’s velocity?
Now that I have your attention I want to tell you that tricks don’t work. I’ve seen people play tricks and sacrifice quality in order to get something out only to regret it later.
So here’s my non-trick trick: Increase code quality today to increase your velocity tomorrow.
This might not sound very sexy, and it isn’t. It means you’ve got to put in the hard work now to reap the benefits later, but that’s how it really works. You can’t harvest before you plant. And honestly, most of the code I’ve seen requires some degree of restoration before it can be safely extended.
The iron triangle, or the project management triangle, as it’s called, talks about three factors that are in relationship to each other on any project: scope, time, and resources. So if the scope of the project increases it’ll take more time and/or require more resources. But unlike in the construction of physical things, the relationship between these three factors in software development is not at all obvious.
For example, it’s well-known that if you’re running behind on a software project and you add more programmers it’s likely you’ll run even farther behind. We call this Brooks’s Law because it was first pointed out by Frederick Brooks in his book The Mythical Man Month. I’ll take that on at another time. Here I just want to say that there is a fourth dimension in the iron triangle, but it’s one we don’t talk about or recognize very often. If we’re running behind on a project and we can’t add more time and we can’t cut scope, and we already know from Brooks’s Law that when we add more developers to a project it slows things down, what do we do? If each of the three points on the iron triangle are inflexible then what has to give?
When I ask software developers this question, they immediately know the answer because it’s probably something they’ve had to deal with a lot. If we can’t flex scope, time, or resources on a project then we’re left with the only thing we can flex: the quality of our own work. But as soon as we start skimping on quality, as soon as we start forsaking our professional best practices, I propose it doesn’t help us get more done and, in fact, there are enumerable examples of the harm it does. So I will say that forsaking quality in the way I’ve been defining it, in terms of these five key code qualities, is just about the worst thing you can do on a project.
Now, I completely understand the need to make tradeoffs. I know we’re in business and we have to be practical. So do I cut corners at times? Absolutely, yes. And in my thirty-year career as a software developer I’ve faced the issue of having to choose between writing good quality code or getting something out the door to save my company—and I’ve faced that question more than once, and have always picked the latter answer, thank goodness. What good is beautiful code that no one ever gets to use? So please let me assure you that I am a pragmatist and when I talk about code quality, I’m speaking truly pragmatically. I’m speaking purely in terms of dollars and cents.
In software, quality is always cheaper. That’s the bottom line. It may not be true in goods. Poor-quality materials can be cheaper than high-quality materials. In service, one could argue that quality is also essential. I see companies waste a lot of money on poor-quality service. But quality is definitely always more cost-effective in software.
But again, remember that I’m defining quality in very specific ways, so if you haven’t already, please read my last thirty blog posts or so.
One pattern I see time and time again on software teams is that they adopt Scrum, pay little attention to technical practices, and they’re able to consistently increase their velocity for the first few years. But after about three or four years the technical debt they’ve accumulated in their code is so great that their velocity starts to grind to a halt and they find it difficult to even get simple features implemented. This is a place you do not want to get to, though I see it far too often in the software community—teams stuck there without a clue how to get out.
Software is actually quite forgiving, and that’s a bad thing. It lets us form suboptimal habits. There is no swift retribution for poor code quality. If you make a class poorly cohesive it may not be a big deal, but do it over and over again throughout a system, and believe me, it becomes a big deal.
It’s these little practices that make the difference between good code and unmanageable code. So start in the small. It’s easy to understand and it’s something we can implement right now. As we do, as we build code that’s more CLEAN, we’ll find that our team’s velocity, as well as our own, increases in a sustainable way.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
