Writing software is hard, particularly when the schedules keep programmers' noses to the grindstone; every so often, it's important to take a breather and look around the world and discover what we can find-ironically, what we find can often help us write better software.

It's a common scene: a group of software (or of any other kind, quite honestly) engineers sitting around a table, arguing over the “best” way to accomplish something. When the conversation is about server-to-server communication, it's a serious topic and yields solemn nods from those around them. When the conversation is about where to go for lunch, it's comical. And yet, no matter how much we know the phenomenon, and how farcical it is, it still happens.

My mother's extended family has the same problem. Whenever we go out to Chicago (actually, about two hours' south of there) to visit, trying to find a place to eat is a nightmare of politeness: “Well, you're the guest, you should choose” And “but you know the area well, you should choose,” And “You must be tired from your trip, you should choose.” Half the time, I want to stand up, scream, “Pizza!” and snatch the keys as I make a break for the door. All of it is well-meaning, and I love them all, but it's enough to drive a man to drink. Heavily.

Alas, it's not just my mother's family.

A group of us-conference speakers and our spouses (hereafter known as “normals”)-were sitting in a Costa Rican hotel restaurant, and the subject of text editors came up, as it always seems to do among programmers, if you sit around long enough and drink enough fruity drinks with rum and umbrellas in them. (Admittedly, in this case, it was tequila shots with cerveza trailers)

One of our number, who shall remain nameless but not too terribly long ago wrote a book on how to be a productive programmer, was extolling the virtues of Emacs. Now, normally, I wouldn't get caught up in this debate-arguing Emacs against vi (or any other text editor of choice) seems to be a religious discussion, and as such, ranks right up there with the Big Three Taboo subjects (sex, politics, and religion). But another of our number decided to throw down the gauntlet, and asserted that Emacs was, admittedly, a powerful editor, but that it simply didn't offer enough out of the box without requiring the user to learn how to program in ELisp in order to know how to customize it. In other words, the learning curve was simply too high to justify the results. My productive friend's response was predictable, and correct: “So you're saying that you don't have the time to make yourself more productive.”

Fast-forward to later that trip, as we sat in the lobby waiting for the shuttles to, alas, take us back to Liberia's airport and the plane back to the US. The “normals” were swapping stories. My wife mentioned an experience with a recent Geek Give, a charity event held in Redmond during the week of the MVP Summit, during which the participants prepare and distribute food to the homeless of Seattle. She was joking how when the event started, the engineers stood around and analyzed and discussed what would be the most efficient way to get everything done, while around them the actual work of getting the food out was already underway.

It was at that moment that the productive programmer's wife uttered a phrase that cemented a half-formed thought in my head: “Sometimes they (the engineers) don't realize that ‘efficient’ isn't always the same thing as effective.”

The Automation Argument

On the surface of things, the argument seems simple: two engineers are debating whether or not to invest more time into a particular facet of the system. It could be part of the build process, it could be the data access layer, it could be the user interface, it could be any part of the system-it doesn't really matter. Two paths present themselves, one of which is quick and dirty, and the other requires far more investment but yields a more elegant solution. Or maybe both are elegant solutions, each in their own way.

Frankly, either scenario usually leads to the same result: they argue. They debate. They each present their well-structured, perfectly logical arguments. They appeal to co-workers for support. They appeal to Stack Overflow and Google for citations and proof of their positions. They appeal to management for a declaration of victory.

In general, they make everybody's life a living hell.

And in the end, regardless of the decision made, and regardless of how well everybody patches the quarrel and agrees to be professional and makes a formal declaration that, yes we all agree that slipping your idea into the build behind everybody's back until it's too deeply ingrained in the system to pull out is not an appropriate thing to do, regardless of all of that, a precious commodity has been lost. Time.

Software projects run on a budget. Several budgets, actually: one is the money budget that we're all familiar with, and one is the credibility and momentum budget that needs to be repaid (the currency involved in discussions around “technical debt”), but one of the most critical ones is the time budget, and it frequently goes overlooked.

Automation experts, and I include myself in this, will argue until we're blue in the face that projects need to automate everything they can. That the five weeks invested in the build process now will pay off in spades later.

But you know what? I'm not sure I believe that anymore.

Budgets

Please don't misunderstand me, and please don't use the previous sentence to justify the quick-and-dirty hack in every case. Because not every case is the same and that's the whole point: for every scenario when the quick-and-dirty is the wrong answer, another scenario presents itself in which elegant proves to be just as wrong. For each case where the decision presents itself, obviously we have to evaluate the cost of the elegant solution in the short-term against the benefit of in the long, and ditto for the quick-and-dirty.

But decisions can't be extended forever. Spending a year to find the most efficient build process system, or the best Web framework, or the best data access approach, or the best domain model, or the “right” user experience, or the best whatever crosses our technical horizon next year-it all costs time. If we take this “technical debt” analogy further, notice that at no point does the technical debt argument suggest that going into debt is at all bad. Like financial debt, too much of it is bad, but ironically, not enough of it is bad, too. Look at businesses: almost every single one started with the assumption of some amount of debt, be it loans from friends or family, a small business loan from a bank or other financial institution, or VC funding. All of these are just fancy ways of masquerading debt.

Because that debt is a necessary component of business, it is the shot of capital that the company needs to make that next giant leap. And as developers, we need to ensure that we aren't so concerned with “efficiency” and avoiding that technical debt, that we lose sight of “effectiveness” and that other critical component of what we do: “getting stuff done.”

Have you ever sat around a table or in a car and tried to decide where the group wants to go to lunch? Yeah, it's like that. You can spend hours trying to find the most efficient place for lunch, and end up burning your entire lunch hour debating. Or you can set a time limit on the discussion (say, five minutes), and then if no decision has been made, just drive to the place that's closest. Or had the most votes the first time around. Or-to heck with it-if you're the one driving, we're going to wherever you want. If the rest of the car doesn't like it, they can either walk or drive next time.

Leadership sometimes means pushing consensus to one side, making a decision, and getting stuff done.