Programming Priorities
Software development (or, you know, life in general) is all about juggling priorities.
For this post, I’m thinking specifically about code design priorities. You only have a limited amount of time to implement a feature, so you have to pick and choose which aspects of it to spend time on. Do you spend your hours crafting the perfect architecture? Optimizing the shit out of it? Writing automated tests? Documenting your code?
Once, a junior developer, having trouble figuring out what to focus on, asked me about what my personal priorities were. Here’s what I came up with:
- Functional
- Maintainable
- Everything else (distant third)
Functional is obviously #1: if the software doesn’t work, what’s the point?
What’s not as obvious is that maintainable is #2, and that everything else is below it.
What do I mean by maintainable code? I like this answer from StackExchange (emphasis mine):
“Maintainability isn't a binary property, either being maintainable or not. It's a continuum. Roughly speaking, maintainability is inversely proportional to the amount of time it takes a developer to make a change and the risk that change will break something. Improving readability, coupling, or consistency all contribute to maintainability because it won't take as long to make any given change.”
In short, maintainability makes it easier to change code later.
Focusing on maintainability now means you don’t need to focus as much on anything else because the malleability of the code gives you the option to refactor later. That saves you time now without blocking you from later altering the code to match new needs.
For example, perhaps you didn’t focus on optimization at all, but it turns out that the new feature is bogging down your whole system. You need to make it faster - but lucky for you, there’s automated tests to verify your changes, and the slow part of the code is isolated such that you can optimize it without rewriting the whole feature. In this case, it only takes a day or two to optimize that small portion of the codebase and ship it safely.
How do you write maintainable code? That’s a huge subject, such that there are entire books on the topic (e.g. Code Complete), but my tl;dr would be:
Automated tests - so you can modify the code and know it still behaves the same as before.
Good architecture - proper decoupling, encapsulation, etc. make it possible to refactor without rewriting everything.
Readable - simple code with useful comments, so others (or yourself, years later) can actually understand what the code is doing.
All easier said than done, sure, but those are the ideas.
Is maintainability always my #2 priority? No!
With software development, there are always exceptions. Sometimes you need to crank out code ASAP to put out a fire, tech debt be damned. Other times you know, in advance, that you’re working on a critical path and need to optimize as much as possible. Or you may be working on code that is already unmaintainable (from a previous developer, perhaps even yourself), and you just need to make a small tweak.
But my default priorities are as above - functional, maintainable, then everything else.