Oct 02, 2011

Why developers should learn the economics of code

Say you are a software developer who doesn’t entirely suck, and are wondering how to take your effectiveness to next level. Should you start learning some cool new language? Functional programming? Order a bunch of books written by bearded mobsters¹?

No. To elevate your craft to the next level you need to step out of it, and start thinking about what fuels your position.

By that, I mean what sustains your position as a software developer, and the team of software developers you work with, the building you work in, your chair, your desk, your workstation, your huge monitor–in short, the entire abstraction layer on top of which you sit pretty and write code².

The fuel is money. You should ask yourself: what are the economics of the software you are producing?

(And yes, this applies to free/open source software. It is driven by economics too, it’s just that its economics are different from that of commercial software. Open-source hackers need to make a living too.)

In my personal experience, less than 1% of new engineers, and maybe about half of longtime engineers who have been working for decades, understand this. Unfortunately, this is not something that is part of the computer science curriculum. One has to infer these things by watching shadows on the walls of a cave. If you pay attention to the way managers and directors and VPs (at least, the really good ones) dig into technical issues, you will catch a whiff of the issues involved.

But why? Why should you try to understand this bean counting? The whole reason you got into programming was so that you would never have to deal with this stuff. The answer is simple–understanding the economics of software will make you a better engineer, and improve the quality and effectiveness of the artifacts you produce. You will see that if you throw in economic considerations into technical debates, the choices will often become much clearer. You might become less attached to your solely technical view, and see the bigger picture. Technical decisions almost always have economic drivers.

Until you make at least an effort to understand this, you are like the kid taken to Disneyland with no idea how much the ticket and food and the hotel and the car and the plane cost.

Here are some of the axes along which economic considerations fall:

• the cost of labor: this is the easiest one to understand as well as quantify. It shows up directly on the books. Obviously, the company is making more money from your labor than it is paying you. If not, then you should be worried, both for yourself as well as the company.
• the cost of acquiring labor: does your enterprise depend on languages, frameworks and technologies whose sole practitioners live as ascetics on Himalayan mountain tops, and even if you could convince them to come down from there, would never work for your filthy moneygrubbing corporation? Not good. Does an army of modern programmers know and love the stuff you use? Is that population added to every year with the graduating class? Good. Though you might sneer at blub languages³, sometimes they are the best solution. Think about this next time you want to introduce your favorite shiny new leaves-Java-in-the-dust language into the company.
• the cost of time: How much time do you have? Are competitors breathing down your neck? Even if they aren’t, remember that developer time is money spent. What is the cost of getting it wrong? What is the cost of getting it mostly right and then refining? What is the cost of not getting it absolutely polished and perfect?
• the cost of maintenance: how long will your product last? How long will you have to support it? Provide patches and bug fixes? Ironically, with modern server-side software, the answer is often “forever, or until the company goes bust.” Server-side software has no EOL, just a continuous stream of tiny revisions. And the more crucial the software is, the longer it will last (e.g. UNIX).
• the cost of machines: this is typically the least understood, and the most misunderstood one. Unfortunately, an entire generation of programmers has been raised on the idea that “programmer time is more expensive than machine time.” This was certainly true in the singular–“machine.” But this assumption begins to break down when writing an application that runs on a warehouse scale computer⁴. If your code runs on a bazillion machines, then it is very likely that even tiny savings in resources (CPU, RAM, disk, packets sent on the network, power) across all those machines will pay your salary.