A former colleague of mine from my ThoughtWorks days, Aaron Erickson recently wrote a blog post about Engineering practices and how they impact a project’s velocity. The post is good, and talks about some common engineering practices to help improve velocity. However, the problem I’ve found on numerous projects, regardless of their level of engineering maturity is that they often don’t see that they even have any velocity issues. The closest most projects get to is: ‘We want to release by date x, with feature-set y and at our current velocity that isn’t possible’. Aaron’s post is a an example of positive ways to improve velocity, rather than the unsustainable practices of throwing more people at it or making everyone work 100+ hours a week. But what really is the proverbial anchor slowing the velocity ship down?

Technical Debt?

Martin Fowler wrote a recent blog post related to software craftsmanship where he talked about how much he hates using metaphors to describe software development. Technical debt is an often used metaphor for describing what is essentially causing velocity anchors in the codebase. This is of course completely separate from process issues. (7 design meetings and signoff sessions before even starting to code will kill the velocity of even the cleanest codebase) It’s a tempting metaphor to use. Everyone understands the concept of debt from their own lives. Your income is severely handicapped if every month a large percentage has to go to paying down debt. The same can be applied mentally too, paying down debt every-time you code. However, there’s a number of problems with using this metaphor.

People don’t understand debt

Earlier I said “Everyone understands the concept of debt from their own lives” No, no they don’t. Especially not in America. In many ways our attitude towards debt in our personal lives mirrors the problems in codebases. Can’t afford the new TV? It’s cool, Best Buy has financing. In fact, in many ways the concept of “I’m taking on acceptable debt now to get a feature out, and I’ll totally going pay it off next quarter” is what gets most companies into trouble in the first place.

The code fairies don’t send you a bill

A credit card bill is tangible. They mail you a piece of paper that says: “You have to pay this much right now or bad stuff is going to happen.” And you know exactly what that bad stuff is. Everyone knows what the end of this path is, and speaking as someone who has recently watched family go through it, bankruptcy sucks. There is no such obviously painful end point to accumulating too much debt in your code. The only thing I can tell you is: you’ll know it when you see it. When you’ve spent years working on a codebase, and have a small percentage of the features you want done, and your retention rate is falling rapidly, you’ll know you have too much debt. However, its really hard to make someone understand that when they’re staring at all the screens in best buy.

Software development is subjective

Is that piece of code technical debt or a really clever architecture? I bet you could take any random snippet from your codebase and ask two developers whether its technical debt or not and get two completely different answers. Usually because one of them thinks you’ll “definitely need to let users add their own custom widgets in the future”. (I’ll save the speculative generality rant for another day) My point is that you could spend a lot of time trying to define what is debt vs. ‘good architecture’ and end up being one of those people who hasn’t actually written code in years and has a calendar where every hour is triple booked.

Its not really that hard of a concept really. I’m not sure it even needs a metaphor. Your developers are trying to get stuff done. There’s a bunch of crap in the way making that take longer than it rightfully should. If you care about developer productivity, you try and hunt it down and fix it. If you don’t, then stop reading this and get back to your gant chart. I bet if you put one more developer on that task the earn/burn ratio will look way better. (Another rant for another day though)

So, what are some of the things getting in the way of getting stuff done?

WTF?

That’s the sound your developer makes when they are looking at a piece of code and can’t figure out what it’s doing. it might be a bug fix or a new feature or whatever. The bottom line is that they’re trying to get something done, but instead they spend hours digging through file after file trying to figure out why there are 7 variables named ‘chart’ that all mean completely different things depending upon which part of the application they’re used in. It’s a simple equation. The number of WTFs is inversely proportional to developer productivity. We could probably even make a Sonar widget for it.

Code Jenga

Have you ever touched a piece of code to make what seemed like a simple bug fix only to realize that you just committed an atrocity? One variable changes, and now the login page has no text? It makes developers afraid to do anymore than the bare minimum required. And if anything more is required, it takes forever, because they now have to climb the mountain of WTFs to accomplish the feature/bug fix.

I’m sure I could come up with some more if I kept thinking about it. But then I’ve seen plenty of teams brought to their knees because they spend the entire time arguing about which design pattern to use, or what’s the most productive IDE, or which BBQ restaurant is best.

The only thing I’ve ever seen work is empowering developers* to make the right decision when the time comes. They know the codebase, they know what’s slowing them down, let them make the decision. Yes, stuff still has to get done. Yes, releases still need to get out. But by and large, if you let developers code and focus on solving business problems, most of the time they’ll make the right call.

*Architects aren’t developers. If they aren’t solving business problems, they’re not a developer. I know, a bit hypocritical coming from someone who wrote a framework.

Unless you have a team full of developers who don’t realize all the little things out of their day that’s killing their velocity. 15 minutes to do a build? 7 properties files to update for each change? 10 Different components that all inter-depend upon each other and require a certain build order for no good reason? People get used to the craziest things, and unless someone points it out to them, won’t even notice. And even if you do, they might just shrug and say: ‘I don’t mind’. Then again, telling them they have too much technical debt doesn’t help much either.

And maybe that’s my point really. Regardless of all the engineering practices or programming language, or IDEs, there’s no guarantees. Switching to Ruby won’t make your project ship on time. Using TDD doesn’t mean you won’t have quality issues. Meticulously planning every second of every day of the project from now until completion doesn’t mean you’ll make that date either. The only thing you can do is focus on getting stuff done, hire the best, most passionate people you can, and hope for the best.