Code means communication has become a bit of a mantra for me. Source code isn't just the means by which you translate requirements into commands and structures a machine can understand. Source code also communicates your intent as a designer and engineer as to what a particular piece of software is supposed to do. If written in a clear and comprehensible manner code can serve as an authoritative design specification with no or little extra documentation needed. I would go as far as ...Read more
When working on a larger codebase knowing about the dependencies between components is crucial, particularly so when you're trying to understand how an existing application works. NGD - Angular Dependencies Graph (part of the Compodoc documentation suite for Angular) is a tool that - as the name suggests - generates dependency graphs (i.e. boxes and arrows) for Angular applications. Dependency graphs give you a high-level overview of an application's architecture and hence are a great first step in understanding how an application ...Read more
Software developer Tom Hombergs recently wrote an article about making log statements more useful by providing context in order to make it easier for a developer who uses your libraries or builds upon your code to find out what the actual cause of an error is. The blog post contains many pertinent examples of both good and bad log output. Seemingly trivial improvements such as making your log output more helpful and explicit can make a huge difference and save a lot of ...Read more
Software developer Andrew Yurisich maintains an - ironically - maintainable version of the authoritative guide to unmaintainable code by Roedy Green of Canadian Mind Products. This expansive, tongue-in-cheek how-to teaches developers to make themselves indispensable through writing code only they can understand. Aside from the comical value learning by what not to do can be an extremely useful method. By making sure your code follows none of the guidelines put forward in this how-to you'll already have covered many aspects of writing readable, ...Read more
Software developer Tom Hombergs - a former fellow student of mine - published this useful checklist for setting up Java applications on Reflectoring: A Checklist for setting up a Java-based Software Architecture It covers a wide array of both high and low level aspects of server-side and client-side development as well as architectural concerns. Furthermore, the checklist also has sections on operations, the development process and testing in particular. While some of the details may vary depending on the type of applications you create, ...Read more
Analysing an existing application if you join a project.
Assessing the quality and maintainability of an application.
Identifying soft spots in an application which could benefit the most from refactoring. There are numerous reasons for wanting to size up the complexity of an application. In addition to general and language-specific tools provided by IDEs and applications such as SonarLint / SonarQube it can be useful to not only take framework specifics into account but to actually make use of them to get a better ...Read more
This article by Marcus Blankenship tries to answer the question why programmers become disaffected with a company and its goals and ultimately turn to just wanting to code. As I wrote in an earlier article about paying for developer tools with developers, particularly in larger organisations, I frequently encounter a feeling of powerlessness and not having significant say in that organisation’s direction. Marcus is spot on in that he attributes this far too common attitude to an often dysfunctional work culture that doesn't ...Read more
IT consultant Erik Dietrich wrote this interesting article about his approach for evaluating software quality from a business perspective. He suggests these 2 questions as the main business considerations when it comes to software quality: Does the software do what it’s supposed to do? Can I easily change what the software does? In other words: Software quality is determined by both outcome and continuity (the extent to which software allows for changing circumstances, see Jeff Sussna's book Designing Delivery for more information on this matter) The ...Read more
When considering the different aspects that potentially contribute to (or detract from, mark you ...) quality, reliability and maintainability of a web application I always like to come back to the Twelve-Factor App. Originally created by Adam Wiggins in 2011 the Twelve-Factor App is a highly useful design framework for both creating new web apps and measuring and improving the quality of existing applications. This framework allows you to create and maintain long-term viable applications that make use of declarative formats, clearly ...Read more