My Octopress Blog

A blogging framework for hackers.

Velocity Anchors

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?


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.


Thank you for sharing the info. I found the details very helpful.

cheap nolvadex
Super-Duper site! I am loving it!! Will come back again – taking your RSS feeds also, Thanks.

cheap clomid
Lucas Ward

That's a nice way of organizing issues. I agree that it's really helpful when deciding how to tackle them to look effort vs. value or in the way you described it, pain reduction. However, I suppose I'm arguing that the technical debt metaphor isn't really helping us. What you really have is a 'wall of stuff slowing us down' I think telling "Management" that it's slowing you down is the key message. It doesn't matter what the metaphor used is, it's slowing you down. I think its too easy for certain types to think of acceptable debt, which I suppose is true, but it beside the point.

Thanks for the congratulations..


I agree and I think it gets to the point of 'why we're being slowed down'. The answer in this case is: "because it takes us hours to figure out what this piece of code is doing for no good reason"
I've heard the technical debt can be measured as a rate of WTF's per minute out of developers mouths.
Fabio Pereira
Very good post Lucas! Congratulations.. I completely agree that people don't understand their debt and it's hard for them to know where to start in terms of "paying". On a previous project we created this Tech Debt Wall as part of a retrospective and it helped us a lot in terms of prioritising and maximising our efforts in fixing tech debt…
Congratulations once again for the post.. very well written.
Lucas Ward
Thanks for the compliment! I'll be sure to add your blog to my RSS feed.

I suppose I really should get on this twitter thing everyone keeps talking about…
Carol Dekkers

Excellent posting and I'm going to reference it in a future one of my own posts (

It's great to find insightful and coherent writing like this one. (I've tweeted it already @caroldekkers).

Thanks for putting your keystrokes to blog (rather than pen to paper). I'm looking forward to future posts.