Software Call For Quality

In a previous blog post I argued that we should have more respect for legacy code. While I didn't mean that we should just accept all legacy code as-is, but we also shouldn't completely ignore it's value. The quality of that software is an important factor that will determine its value. This does however not only apply to the code that others have written before us, it also applies to the code we write ourselves.

I have seen many people talk about a piece of software as being legacy code and argue for an entire rewrite, only to see that the code they themselves is not any better in my opinion. That is an important aspect. Clean code is often influenced by personal flavor, there doesn't seem to be a very general global agreement yet on what is clean and good. Which is a bit weird, since we should all aim for code that is easy to read and understand, and that is exactly why people have different opinions. We get used to seeing our own code, our own style, in such a way that a different way, even if it is better, is hard to read.

I see many developers stuck in their own way of thinking and writing code that they completely ignore other ways and cleaner ways of doing things. This can go for something very simple as the way your organize your code to much more complex mechanisms as trying out domain objects. This also goes beyond the actual code that is being written, it is the way it is written as well. Some developers are not very keen on doing pair programming even though they never tried it, the same goes for test driven development.

I understand that developers want to work in a way that is comfortable for them, and I respect that, although it is not bad to sometimes try to go outside of your comfort zone and try something new for a while. When it however comes to the quality of the code I am not willing to settle for less. A developer who is not willing to write tests, or a very limited set of tests that in no way guarantees the working of the code he writes is in my opinion a bad developer.

It should be everyone's main concern to write code that works properly and see what the best way to achieve this is. This means that we have to learn from the mistakes of the past. If a bug appears in some code we wrote, we have to ask ourselves how come we didn't detect it. If we have some code that we struggle to read, we should ask ourselves how it can be improved to make it better. We should be critical for the code others write, but even more critical of our own code. This is not easy to do while you are writing it (hence the reason we do peer reviews), and it often is only visible after we revisit our code a while later.

I believe a big reason for this lack of good software, is that we don't have enough seniority in the software development industry. Most developers stop writing code after 5 to 10 years. I would hardly call 5 years a long time to get proficient at doing something, let alone be it to try out things and decide what works best. Moreover, there is very little time and focus on passing on knowledge to the next generation, as a result you see that the next generation has to start all over again, learning all the best practices from zero. I would like to see more people stay longer in the field and keep making their hands dirty, this is the only way to improve the overall code quality. But years of experience is not enough, repeating the same mistakes over and over again only makes you very good at making those mistakes. You have to learn from your mistakes and try new things.

In general I feel we too often feel the excitement of writing new shiny code, but we don't think enough about the maintenance factor or the quality of it. We see the code as being disposable, something that we will throw away in a few years. In the end, software is always evolving and changing, so why write something that can last ages if it only needs to last a few years. I believe that this creates a vicious circle, where our believe that software is temporary is enforced since we see so much code that is of poor quality and needs to be thrown away, only for use to create poor quality code.

Even if the code we write only lasts a few years, the cost and extra effort it involves trying to debug it and making sure it works properly those few years make the investment in good software quality worth it. I would much rather spend twice as long on implementing a feature if it means that that feature can be used without any issues by my users. User satisfaction alone is already worth it, but the burden to quickly fix the broken code, which often leads to even poorer code quality is a path I went down myself too often.

As always, there are exceptions. Times were a feature is time critical in such a way that it permits a quick hack. But it needs to be fixed as soon as possible without any excuses. These cases are exceptions and should not happen on a daily or even weekly basis, and whenever they happen you should see how these situations can be avoided in the future.