Software Development

Want to be a great developer? Start reading Schopenhauer

SOLID Principles, TDD, Agile Testing Pyramid, Microservices… I’ve reached the point now where I am incredibly wary of so-called ‘Best Practices’. This is because I keep observing, over and over, that following ‘best practices’ creates lousy software. The code, which is supposed to be clean, is unmaintainable; the architecture, which is supposed to be state-of-the-art, is convoluted; the test suites, which have the right ratio of unit and integration tests, don’t give nearly enough confidence for the effort it takes to create and maintain them; and don’t get me started on Agile Transformations and Microservices Journeys!

I’ve been thinking about best practices and why they don’t work for a long time. For a while, I was of the opinion that the problems I had seen weren’t caused by the best practices themselves, but by developers applying them either in the wrong way or in the wrong situation. But, recently, I read two books that made me completely change how I think about best practices:

The first book is A Philosophy of Software Design by John Ousterhout, which describes how to reduce complexity in software.

It’s an excellent little book, and I highly recommend it if you haven’t yet read it. Some of the advice it gives contradicts best practices from Clean Code, SOLID principles, TDD, etc… For example, if you’re trying to follow the principles from Clean Code, you probably have very small methods (Single Responsibility Principle) and a tiny number of comments (because the code is self-explanatory). The book explains what the problem is with small methods and why having comments is so important, even if the code itself is self-explanatory. I always thought the advice from Clean Code and the SOLID principles were absolute truths, but this book challenges those beliefs.

The second book is The Art of Controversy by Arthur Schopenhauer. Here is one of the parts that caught my attention:

But to speak seriously, the universality of an opinion is no proof, nay, it is not even a probability, that the opinion is right. … When we come to look into the matter, so called universal opinion is the opinion of two or three persons; and we should be persuaded of this if we could see the way in which it really arises. We should find that it is two or three persons who, in the first instance, accepted it, or advanced and maintained it; and of whom people were so good as to believe that they had thoroughly tested it. Then a few other persons, persuaded beforehand that the first were men of the requisite capacity, also accepted the opinion. These, again, were trusted by many others, whose laziness suggested to them that it was better to believe at once, than to go through the troublesome task of testing the matter for themselves. Thus the number of these lazy and credulous adherents grew from day to day; for the opinion had no sooner obtained a fair measure of support than its further supporters attributed this to the fact that the opinion could only have obtained it by the cogency of its arguments. The remainder were then compelled to grant what was universally granted, so as not to pass for unruly persons who resisted opinions which every one accepted, or pert fellows who thought themselves cleverer than any one else.

What Schopenhauer, already in the 19th century, is saying here is that ideas, which we take as absolute truths, germinate as mere personal opinions. Eventually, an idea will become accepted by more and more people, not because it is proven to be true, but because the crowd has trust in the person who has thought of it. Once this occurs, the others won’t dare to question the idea, and it will turn into a widely accepted truth.

You might be wondering what all of this has to do with Software Development!

Schopenhauer might as well be describing how most of our industry best practices and methodologies have come to be. Someone writes a book about a new methodology or technique for writing code or designing architectures, thought-leaders and top companies start talking about these ideas, and before you know it, they become the new standard.

Isn’t that what has happened with Clean Code, Microservices and TDD, to name but a few? Is there any proof that they actually work? Or is it that our community keeps falling for the hype and trusts that all these experts know what they are talking about? We keep justifying bad decisions, and we continue to write bad code and approve bad designs on the basis that they have been built according to current ‘best practices’.

This is why I like articles such as TDD is dead. Long live testing, Why Most Unit Testing is Waste and Write tests. Not too many. Mostly integration. In an era where most articles, books and presentation are regurgitated content, it’s very refreshing to see developers and software architects thinking for themselves and not being afraid to go against the tide of accepted ‘best practices’. I find that inspiring.

If you want to be a good developer, you have to know about current ‘best practices’ and methodologies. You should have an understanding of the SOLID principles, TDD, Clean Code, Agile, and so on. But to become a great developer, you need to go beyond ‘best practices’, use your experience as a guide and start thinking for yourself.

And one last thing, don’t forget that everyone has his or her own agenda. The experts and thought-leaders make their living by selling books, running workshops and consulting. They don’t necessarily have your best interest in mind.

Software Development
5 pitfalls to avoid when building Spring applications in Java
Software Development
Spring Data Couchbase – Pitfalls to Avoid
Software Development
Are You Agile? 6 Signs Your Team May Not Be