When you write a program, whom are you writing it for?
Stupid question? Your boss. Or maybe the customer.
WRONG, BUCKO. You’re writing it for other programmers.
“Who are these other programmers?” you ask, eyes full of wonder, young hopper as you are. They’re your team mates. They’re your future hires. They’re you six months from now, when you can’t remember what the hell you were thinking when you wrote this code right here.
This idea is from Fred Books, one of my heroes and whom, were it somehow possible, I would take as my lovely brogrammer bride, in his timeless classic The Mythical Man Month. (OK, maybe it’s not “timeless;” you could probably use email today rather than his recommended “telephone log.” But every other chapter is pure, modern-day-relevant gold.)
You Don’t Want Just a Program
A program, by ol’ Fredder’s definition, just does the job it’s supposed to do today. It’s something you cranked out as quickly as possible to get working ASAP before moving on to something else. You will never, ever understand it tomorrow. Neither will the guy who inherits it; he’ll make an impassioned plea to your boss to throw it out and start over. Where the Still Drinking guy wrote in his famous Programming Sucks essay:
“…everybody spends half their time coping with the fact that nothing matches anything or makes any sense and might break at any time and we just try to cover it up and hope no one notices.”
…he’s talking about your humble “program.”
You Want a Programming Product
A programming product, on the other hand, is well-thought-out. One can look at the code and… understand it. Not because you’ve dumbed it down and avoided cleverness, but because you’ve written it clearly. You don’t have variables named “x” or “count”. You don’t drag the reader into callback hell.
It doesn’t rely on memory, yours or your team mates’. It doesn’t require one to go digging through the codebase to find out WTF is going on before they can even make use of existing functionality. Stuff like this can not be going on. It can be used and extended by anyone who knows the underlying philosophies of this project. (OOP? MVC? ABC, BBD, yeeeeeaaaaaaaaaaAAAAaahhhhh?)
Ol’ Freddie, he estimates that ensuring your codebase is also a product for other developers takes three times the effort as just phoning in an aforementioned “program.”
Probably You Have a Programming System
When your program actually consists of multiple pieces that have to function together, you’ve actually got a programming system. Does your website or mobile app rely on a back-end API? Do you have to coordinate with the unfortunately-titled “back end developer(s)” to hammer out a contract of what that JSON is going to look like? Of course you do; it’s 2016. You’ve got a programming system.
You already know what this entails. The API guys can’t just go changing things willy-nilly, no matter how much of an improvement it might be, because there are apps out there in the wild relying on it. You can (and should) do API versioning, but that brings a whole ‘nother level of complexity with it.
If you’re on the client side, does it mean you model your data to match what the server gives you? That’s easy, you can map the JSON response from the API to your own objects automatically! But those objects might not fit your app exactly, and introduce awkwardness. On the other hand, you can translate the data from the server to your own data model. It’s more efficient, but also more work.
Oh, the quandaries for a programming system!
This is so common today that I don’t even have to tell you. It brings complexity. (Brookie BTW estimates a 3X increase in effort for this one too.)
A Programming Systems Product is What You Need
You can probably guess what this one is already, you rocket scientist you! The programming system you need, but with every part of it done up as a product you’d be proud to pass off to the guy sitting next to you. A collection of projects and codebases so well done that nobody would ever dream of suggesting it be thrown out and started again from scratch. (Or at least, nobody would ever be able to justify it.)
This is the “intended product,” but if you’ve done the math, it takes 9X more resources than cranking out some unintelligible mess this afternoon. (Actually, given the astronomical cost of programmers these days relative to the 1970s, when they were probably seen more like accountants, the price tag is probably a lot more than 9X. Which is why you’ve never worked somewhere that actually allowed you to do this.)
Here’s an illustrative chart I drew on the bank of a bank statement, for the sake of having graphics in this blog post:
I like to think I drew that from my own brain, but in fact, I think I mentally swiped it straight from The Mythical Man Month. (Other than the smileys, I mean. Fred Brooks, if you’re reading, I’m sorry. Call me, K??)