Stakeholders assume the software you write will be reliable, and rightly so. They will not request it as a feature, they assume that the code you produce will work as THEY intended it too – not as you understand that it should.
For software to work as it’s intended, and have it keep working that way, there are some things that developers can do now to improve the overall reliability of the code they write.
Write clean high-quality code that’s easy to read, but more importantly, easy to understand. Don’t just understand the function or the logic; but understand the intent, the reason why the code exists for the systems users. Writing code this way takes practise, practise, practise, and the more you write your code with this concept in mind the better you will get. The more feedback you take on board from your peers the better your code will become too.
Some simple tips for improving code reliability:
Follow the SOLID principles Everyone talks about the SOLID principles for a reason, they are the building blocks of really great code. Take the time to recap them every now and then as new experience can change your understanding of them.
Deal with all exceptions Don’t leave empty catch blocks, and don’t just handle a generic exception by logging it and hoping it goes away. Exceptions are raised by the implementors of code with a reason, understand the types of exceptions the code you are calling can raise, and what are the conditions under which each can happen.
Use meaningful names We name things everywhere in our code. In our functions, variables, classes etc. Naming things well is difficult, you need to portray meaning in a single or few short words.
Use names that reveal intent
Use pronounceable names
Use names that are searchable
Test your code Be responsible for your code doing what it is intended to do, test your code. You don’t have to go full TDD but good unit tests always increase code reliability.
Write good log messages Experience tells us that many developers focus most of their efforts around application logging purely for the phase where software is being actively developed. That logging if it exists at all is focused on the small details needed to debug the functioning of an individual component and rarely contains the “user-centric contextual” information needed to support the system properly in production. Think “how does this message help someone when my code is in prod”.
Great developers are also great advocates for a software’s reliability, to advocate for reliability in your team
Ask lots of questions about the why and the how
Try to understand your users’ goals
Push for change in your team and organisation
Increase your understanding and share that knowledge with your peers
If you want to know more about how developers can improve the reliability of the code they write or how to be a better reliability advocate in your team reach out to us.
