Company news

What entropy has to do with software development

18.10.2016

Translation: machine translated

And why quality is so important. And why you can't be grateful enough for things that exist in high quality. Unfortunately, quality is not a gift to anyone. It requires effort and work. Part 4 of our engineering manifesto: Appreciate quality!

Although all previous posts started with a quote or a short story, I'm not going to continue like this ;) Just because something has always been that way doesn't mean it has to stay that way. It's exactly the same in software development. For example, a wise man realised that we could improve the understandability and readability of our code by renaming the function "FillAuto" to "BindModel". The original name of the function said nothing at all about what was happening in the code. Everyone knew it over time, but new employees were regularly confused. The wise man dared to question a tradition in our code and bring about a positive change.

That's exactly what this blog post is about. We write code, the code changes, our knowledge grows. Unfortunately, code has a negative characteristic: if you don't approach it very consciously, it becomes more complex with every modification. The entropy increases. At some point, there comes a point where the existing code no longer fulfils the requirements of a new story. Whether this is because the original code was only intended as a prototype, because the performance is no longer sufficient or because we have introduced new patterns in the meantime: at this point at the latest, you should intervene and demand what you are entitled to: the time for a refactoring. But it's not just refactorings that contribute to quality. Automated tests, well-defined acceptance criteria, properly conducted code reviews and, of course, the mindset also have a major influence.

Schedule time for unit, integration and user interface tests

It may take some time to write the tests, but in return you get a kind of assurance that your code works as desired. The test also helps other developers to understand your code and recognise any bugs at an early stage. And you learn how to decouple classes and keep the code testable. Writing tests makes you a better developer! If you want to learn more about testing, I can recommend this article.

Plan enough resources for the CATs

CAT = Code review, Acheck acceptance criteria & Ttest cases.
Also be aware that a CAT is more than just a code review. The code can be beautifully structured and understandable. If the acceptance criteria are not met, the story is not complete. Don't see CATs as a torture, but as a challenge. As a reviewer, you will get to know other stories better and can incorporate your knowledge. As a review recipient, you will be made aware of problems and opportunities for improvement that will make you a better developer!

And last but not least: Always be motivated to deliver the best quality possible

Get feedback from other developers in the early stages of the story and document your realisation and findings so that others can benefit from your knowledge. This will make you all better developers! (and please compile your code locally first before pushing anything to the repository. This will make you more popular developers ;))

As you can see, you will automatically become better software developers if you stay motivated and always emphasise quality.
But now I want to get rid of one more quote: