Lately I’ve been wrapping up interviews with the question “What makes software maintainable?” I usually catch a glimpse that says “hmm… I’ve never really thought about maintainability” followed by a response to the question “What makes software good?”, which I didn’t actually ask, but most programmers have thought enough about to give an on the spot answer. The bland responses inevitably involve documentation (fail) and maybe something about consistency (meh).
The underlying question I’m asking is a question you should ask yourself every time you write a line of line of code. That question is “What are you optimizing?” Most programmers have mentally hard-coded the term optimize to mean efficient use of memory and cpu, however it’s a horribly myopic definition. In fact, it’s just plain wrong unless you’re writing an iPhone game or maybe you work at Google and saving a few cpu cycles translates to kilowatts of power and possibly saving a small rain forest.
Let’s see what Wikipedia has to say.
In computer science, program optimization or software optimization is the process of modifying a software system to make some aspect of it work more efficiently or use fewer resources.[1] In general, a computer program may be optimized so that it executes more rapidly, or is capable of operating with less memory storage or other resources, or draw less power. — http://en.wikipedia.org/wiki/Optimization_(computer_science)
It’s not wrong, but it reinforces the notion that less is more and the precious resources are physical resources like memory and cpu. Is it better to have fewer files in your project, fewer dlls in your bin directory, or use fewer semicolons? I recently debugged a chain of jQuery statements that was 430 characters long (un-minified) and used one semicolon. Is that optimized?
Consider this definition:
In mathematics, computer science and economics, optimization, or mathematical programming, refers to choosing the best element from some set of available alternatives. — http://en.wikipedia.org/wiki/Optimization_(mathematics)
This does a better job of capturing the trade-offs we make on a daily basis. I like the idea of choosing the best element rather than consuming the fewest resources. Instead of asking what you’re optimizing, a better question might be what are you maximizing? For a new iPhone game, maybe time to market is your number one concern. I work on enterprise SaaS applications that have a long shelf life so maintainability is a pretty big deal. I strive to maximize readability and testability when I write software. What are you maximizing?
Also, what’s the answer to your question? What makes software maintainable? Would you accept a three word answer of “readability and testability” in an interview? And why is mentioning documentation and maintainability in the same breath result in a fail?
And if you quote the agile manifesto I’m going to murder you.
If a candidate uttered anything about testing as it relates to maintainability, I would be pretty excited. I was expecting it to be common by now and I’m disappointed that in 2010 in a reasonably tech savvy part of the country, unit testing is still considered an esoteric practice.
Mentioning readability demonstrates the candidate has worked on large projects that go on for years and understands what makes areas of an application clunky. Readability builds on top of good abstractions which are also key.
Documentation is for end-user adoption, not programmer maintainability. It can be helpful for a new team member but it ends there. A test suite gives you confidence that you didn’t break anything that was already working. Moreover testing encourages you to write extensible code so when it comes time to add features, you likely have options for elegant solutions or at least it’s easy to pull things apart and assembly them a little differently.
If you haven’t thought deeply about what makes software maintainable then you’re either doing it by accident or your code isn’t maintainable. That’s okay, your code could be awesome in other ways.