I was running late. I needed to get to work and was on my way out the door when I suddenly remembered that I’d forgotten to make lunch. Not a big deal – I usually just slap a PB&J together – but I was already late, bundled up and mentally on my way. It was going to be a busy day – I knew I’d have trouble getting everything done if I didn’t hurry up, get in, and get started. Problem is, if I don’t make my own lunch, I have to go out and buy one at some point^[1] – a much more time-consuming process.

Three minutes now, or a half hour later – seems like a pretty clear-cut case, right? The thing is, we hit this exact problem all the time, and usually choose wrong. Do any of these sound familiar?

• You don’t automate a common task, because it’s faster to do it manually
• You don’t learn how to use a new tool, because it’s faster to use something well-understood, if sub-optimal (i.e. bicycle skills)
• You start coding right away, instead of spending time thinking through your design
• You work exclusively on user-facing features, instead of budgeting time to build tools that will enable the team to move faster
• You assign tasks based on who can do them most efficiently
• You don’t allocate time for retiring technical debt
• You don’t write automated tests
• You plan on writing automated tests, but treat them as an optional feature that can be cut if when the schedule slips
• You skimp on equipment expenses (cheap but trivially measurable), resulting in reduced productivity (expensive but hard to measure)

Usually, these choices come down to short- vs. long-term thinking, or easy- vs. hard-to-measure costs / benefits. And as long as this is a conscious decision, that’s fine – sometimes you need to put in a hack to get something out the door, don’t have the cash to buy better equipment, or have an emergent situation that demands efficiency over personal development. The problem is that incentives are always set up to reward the short-term, easy-to-measure answer.

Unfortunately, this frequently means that making the “right choice” can only be done in the dark of night, or at personal risk. Developers who “steal” monitors after co-workers leave so they can have a more effective development environment. Managers who temporarily swap critical team members, taking the short-term hit on team productivity in return for the long-term benefit in morale, skill development, and retention. Engineers who insist on writing automated unit tests in order to reduce the long-term maintenance costs of their code, even though it makes their projects take longer to complete.

These aren’t always the right choices… But they usually are, and are almost always discouraged either through policy, culture, or schedule expectations. You might find individuals who swim against the tide, but they’re unusual, as it’s always easier to align yourself with incentives.

Furthermore, it’s easy to understand why things are this way – an individual contributor may see unused equipment and not understand why she can’t put it to use. Meanwhile, the CEO knows that it isn’t about that one engineer – you don’t want to create an environment in which poaching is rewarded and inequities persist, and if there are 100 engineers and the equipment costs $1000, well, that’s $100k in capital expenses. A manager might decide to take the long view, demand that her team use TDD, write maintainable code, swap engineers with other teams, rotate tasks to make sure she doesn’t have any single points of failure… But if the benefits are hard to quantify and the costs clear, if she’s the only one in the organization taking the long view, then it’s going to come down to upper management’s trust in her judgment, which gets harder to earn as the organization grows.

Where does this leave us? As long as you can’t quantify the benefits of an approach, all you have is an opinion. It’s all very well to say that you read it on the web and Dan’s a real swell guy and we should all do what he says, but it’s going to be a bit more convincing if you can actually develop a set of metrics to demonstrate your results. For instance, one common anti-pattern is to “finish” a project on time, then spend a huge amount of time fixing bugs after the fact. So, track the number of P1 bugs that come out of your team’s projects, the amount of time spent fixing bugs in general, bugs per line of code, and so on. Some of these will turn out to be bogus, or easily gamed, but tracking them over time – and including the meaningful ones as graphs in your status report – will demonstrate trends, educate your audience, and give them confidence that decisions are based on data, not utopian thinking.

Follow me on Twitter

[1] Although TripAdvisor caters delicious lunches three days a week, I’ve given up on them as part of my diet / exercise regime.