Bytes do not destroy software — people do

Most of the times, people seem to refer to organic growth — much like a garden that grows wild when there’s no-one that’s maintaining it. This is not a valid metaphor — biological growth happens thanks to photosynthesis and is not by the hand of man. Software on the other side is static — it does not change by itself — it changes when someone change it or change the environment it operates in.

In fact, I cannot think of any other discipline that has the level of control that we do in software development. We can control everything in our environment — the running software, the machine it is running on, any connected systems, fake protocols, heck we can even control time!

Still, we produce tons of unmaintainable code — why is that?

Most practices and principles we advocate today are great — they help drive good design, testable code, performant and scalable systems. However, in some sense these practices are only as good as their practitioners — you can still write unmaintainable code with equally unmaintainable tests, or setup code reviews that are reviewed by people that just let it pass through.

I have classified a few behavioral traits based on projects I have been a part of as well as projects I have only observed as an outsider.

Unawareness — some developers just cannot separate good from bad. This is not limited to junior developers it might as well be one of your senior developers.

Stress — tight deadlines, crunch time, personal issues all affects people’s performance. When under stress people tend to make bad decisions, bad decisions often result in bad code.

Ignorance — for many reasons some people just don’t care about the end goal. This can have many faces, some feel angst or disappointment towards their employee. Others mistakenly think their job is to write code, and writing code for the purpose of writing code is a dangerous mindset.

While it is easy to put the blame on your organization — it always comes down to you — the developer, the professional. You are responsible for your actions. Code does not break by itself, code does not break due to organizational changes — code breaks when you break it.

What can we do about it?

Learning to spot these developers will help mitigate the risk they impose to your software. We need to focus less on tools and techniques and more on educating, coaching or even removing developers from their current positions to minimize these problems.

And finally, learn to identify when you are behaving unaware, stressed or ignorant.

Note: This post was originally posted at Medium. I am keeping a copy here for future reference