Simplicity is the key


Junior developer: I don't understand how does this library work. I'm a stupid asshole.

Senior developer: I don't understand how does this library work. The library's author is a stupid asshole.

The joke above is not really a joke. If you're familiar with Boost C++ libraries, you've probably noticed that despite their powerfulness and internal complexity many Boost libraries documentation pages start with “Five minute tutorial” section. And this is the essence of a good library. No matter how powerful it is and what sort of problems does it solve. No matter how complex it is internally. The basic principles of a good library should be explainable in five minutes within a couple dozen lines of code. And that couple dozen lines of code should be a completed program which you can build and run.

A major part of his working hours a software developer should think. The rest of the working hours he should express his thoughts with a programming language. Whenever a software developer spend his time on something else, it means that something is wrong. If a software developer google too much to understand how does a library work — then it's a bad library. If a software developer spend his time on configuring a build system instead of programming — then it's a bad build system. An overgrown complexity of any library, system or a tool chain should never be excused by its powerfulness. It's OK when something is hard to master. However it's not OK when something is hard to start.

There are a lot of overengineered software products that we're forced to use in our everyday work due to lack of better alternatives. And it's unlikely that a single developer could do something about that. However you've could contribute to the common cause.

Make things simple and make sure they're easy to start dealing with. Use simple third party things. Simple usage means simpler integration. Simple usage means simpler migration from one solution to another in case if a solution hadn't answered to your requirements and you have understood this too late (or if your requirements have changed in some drastical way). On the other hand, simpler code is easier to maintain, which means that simpler code less likely contain bugs. And if it does — it's easier to find them and easier to fix them. That's true for your own code as well as for the third party code which you're using in your projects.

Simplicity is more important than it would look at first glance, and its importance is quite often underestimated even in a long run. However making things simple is not a simple thing. Or else we wouldn't be surrounded by unreasonably complex software. Learning how to make things simple and trying to make them simple costs an effort and takes much time. Time, that many software developers prefer to spend on development of other things instead of simplification those which are already exist.

The problem is that return on investment into simplicity usually don't come to you right away. It could be considered as a healthy food. It takes time to feel the benefits of a healthy diet. In the same way it takes time to feel the benefits from the investment into simplicity of a library or an application code.

Another problem is that a software market is a tough highly competitive ecosystem, which is true, and we're often have been told that if you're going to win the race then you should do things faster than your competitors. Is that really so? The answer is my favorite: yes and no. There are some areas of software where a couple of months of delay could cost you unacceptable losses. However, if you really deal with such an area, it most likely is an applications area, not the libraries. Which means that your users most likely are users, but not software developers.

It's more likely that a situation where every delayed month could potentially cost you an unacceptable price is rather exceptional than common. And if you're that unlucky guy who works on such a specific product, then you may ask: “Will investments into simplicity and quality eventually outrun the haste in a long run?”. Well, the answer is my favorite.

Rate this post:

Challenging problems

Share this page: