Software development is an optimisation problem

I saw an blog post recently, “The Documentation Fallacy”. Jussi Pakkanen’s position there is that 95% of your code doesn’t need comments, and he said a lot of things that I more-or-less agree with. But, obviously, it triggered some argument when it was posted to Hacker News.

When we talk about software, we have a habit of phrasing things in terms of rules, of absolutes. Comments always rot. If you don’t comment your code, you’re lazy. Code duplication is always bad. Language x is slow.

It’s not surprising that we think and talk this way.

We program computers, and they deal in absolutes. But just like computer programming is not the same as computer science, software development is more than just programming a computer. Software development isn’t a science, and it isn’t an art. It’s an optimisation problem. The principles of software development are in tension with each other. How important is it that your code is documented, for this project? Is it more important to finish a system that’s quick, or to finish writing it quickly? Will people die if you don’t get it right first time, or is shipping the most important feature?

Some of these principles are stronger than others, harder to trade off, but none of them are inviolable. Writing a piece of software involves finding the right balance point for this project, at this point in time. There are no absolutes in software development, and any statement that says that anything about software is definitively, concretely, absolutely true in all situations is guaranteed to be false.