Throw Your Money at the Code

In spite of your best intentions, sometimes you have only one viable option: throw money at the problem.

Maybe you find yourself stuck in an enterprise environment where you “know” that

we’re not going to get closer to the customers (any time soon)
we’re not going to get closer to connecting value with cost (any time soon)
we’re not going to change hiring practices (any time soon)

Maybe this sounds familiar:

You have money that you can throw at the problem.
There’s a limit to that budget.
If you don’t use it, then you lose it.

In situations like this, I suggest that you throw your money at the code. Not at the programmers; at the code.

In every enterprise environment where I’ve coached or trained, the code eventually became a bottleneck. We can improve meetings, planning, basic communication, but before long the code gets in the way and jeopardises our entire investment in these bigger, supposedly more important changes. Usually, the culprit is a very old, very valuable legacy code system that everyone has to tip-toe around.

So throw your money at the code. Either at the legacy system or at the code that has to interact with it. (Probably the second one.)

Not at tools, because the same programmers with new tools will likely produce more legacy code.
Not at programmers, because the same programmers with any tools will likely produce more legacy code.
Certainly not at project managers, product owners, and all that… we’ve already assumed that all that happens in another building.

Throw your money at the code with the goal of buying capacity.

If your programmers are unlikely to design themselves out of their mess, then buy time by bringing in a cleanup crew. The cleanup crew probably consists of mercenary-like programmers who will clean up your mess for a fee, but whom you probably can’t hire.

They don’t want a full-time job.
They don’t want to stay in one place too long.
They want to focus on technical problems, not political ones.

A cleanup crew acts as the “rewind” button on your code base.

Now, if you throw your money at the code and manage to buy extra capacity, what will you do with it? Should we reinvest?

If you get to keep your teams intact for the foreseeable future, then you can benefit from investing the extra capacity in developing skills. This could entail training, reading groups, 20% time… anything that encourages learning. The longer they stay, the more you benefit.

If your teams are going to scatter anyway, then you might benefit more from using the extra capacity to crank out more features. It’s true, you’re merely delaying capacity bankruptcy¹, but then, in most enterprise environments, that’s the most you can do, anyway.

References

Tom DeMarco and Tim Lister, Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. Slack equates to “discretionary capacity”. If you think you don’t need that, then please read this book.

Patrick Lencioni, The Three Signs of a Miserable Job. If you’d like to understand more why those mercenaries won’t work for you full time, then please read this book.

I call this project heat death: the point where the cost of starting over becomes lower than the cost of continuing on. You’ve experienced project heat death if you’ve witnessed your company hiring a new CTO who immediately implements a sweeping program change like “We’re going to rebuild it in Python” or “We’re going to rebuild it with SOA” or “We’re going to rebuild it with Scrum”.↩︎