Main takeaways from "Coding like your life depends on it"

Jules Mays full-day workshop called "Coding like your life depends on it" covered a lot of ground. The main subject is how we, as developers, should tackle everyday work. It does not matter if it is a new feature or a bug fix, we have to "code like our lives depends on it".

 

There were a lot of very complex topics - too complex to cover in a summary-style blog post like this (and there is definitely some things that I will have to investigate further, before fully understanding it). However, there were a few points that really struck home for me. The points that Jules May made about software are absolutely spot on. We cannot take quality for granted!

 

Software quality

It is in the nature of the beast that we as humans are flawed. This also applies to programmers. All programmers introduce bugs in their code, no matter how skilled they are. The question is how we handle those bugs and the measures we take to discover bugs as soon as possible. We must realize that the earlier in the development process we find and fix bugs, the cheaper and faster it is. 

 

As a developer, we face many challenges. Our main responsibility is to implement features described by the business. This is something that we are comfortable doing. But we also have the responsibility to demand of the business that bug fixing and technical debt must be prioritized. All too often the business only have focus on which features should be implemented next, so that the sales department has a new shiny gadget they can sell. However if the business does not embrace the fact that all software systems have technical debt - and that the technical debt is exponential over time - the software will suffer a slow and painful death. Each new change will be more and more time-consuming to implement, eventually making it impossible to keep working on.

 

To prevent the total collapse of a codebase, it is empirical that the developers take responsibility for the code base and clearly communicate that the quality of the code base must be prioritized on equal terms with new features. The developers must do this since the business does not have the skill set required to recognize the importance of eliminating technical debt and improving the quality of the codebase.

 

"Software quality is not a luxury that we can take for granted - Jules May"

 

Keep asking 'why'?

In criminology, the broken window theory, states that visible signs of decay eg. a broken window that is not replaced in a building, will create an environment that encourages additional disorder. The same concept applies to a codebase. If there's no structure and/or the quality of the existing code is not up to par, chances are that the next time someone makes changes to the codebase, the new code will be of equal or worse quality. This will make the overall quality of the code deteriorate more and more over time.

 

To mitigate this, developers should be encouraged to take responsibility for the changes they make. One of the ground pillars of this is understanding the general architecture and adhering to it when adding new features. It is also important to find the root cause of a bug when trying to fix it.

 

"Find the defect that is causing the malfunction, instead of just patching up the malfunction - Jules May"

 

A good way to try to get to the button of a malfunction and thereby find the defect that is the culprit, is to open the debugger and keep asking 'Why did this happen?'. Keep asking 'why' until it is not possible to ask the question anymore; then you have found the defect that should be fixed. Doing this will improve the quality of the codebase immensely.