There are all kinds of software development checklists and principles out there. Some are better than others. My personal favorites are the SOLID principles and The Atwood System of Real Ultimate Programming Power. Here at DevOps On Windows, we’ve tried our hand at such checklists before. However, most software checklists (including our own) tend to focus on specific “how-to” coding or operational guidelines. Don’t repeat yourself, depend on abstractions, deploy frequently, use centralized configuration. These are all great practices to follow, but they are also just a means to an end. The end, of course, is creating software that is easy to operate. At this site, we have always maintained that “doing DevOps” well, and by extension, creating quality software, is not something that you can accomplish by following rote guidelines and checklists. If it were, robots could do our job. As we should know (because it is our job to create them), robots lack the ability to creatively apply best practices and first principles to craft solutions to new problems. In order to defeat the robots, we need to take advantage of our ability to do so. The first step is identifying and understanding the first principles of quality software. Therefore, we present our Robot-Defeating First Principles Of Quality Software:
Quality software must be clear and understandable. Strive to write code that you will be able to understand a year from now after you have forgotten all the details. Alternatively, try to write code that won’t inspire another developer to curse your name years from now when a bug is found or a new feature needs to be added. It is far more important (in most cases) that your code be clear in its intent than it be “clever” or even that it perform optimally. However, software is more than just code. Quality software must also be clear to system operators and end-users. Software should be a “white box” – errors should be clearly displayed, raw data should be accessible to allow double-checking of results, functionality should be easily discoverable, behaviors should be logical and understandable.
Quality software must be consistent. The days of monolithic software solutions are over. Service-oriented architectures and cloud-based services rule the day, because they allow us to create simple, independent, specialized components that work together to form a cohesive whole. In order to support such an architecture, the myriad software components that make up your system must behave in a consistent way. They should all use the same deployment, configuration, and monitoring mechanisms. They should communicate using a standardized messaging layer that is solid, battle-tested, and flexible. User interfaces should use common controls with a consistent look and feel. Your software should be consistent from the perspective of developers (who use consistent APIs to build applications), operators (who use the same set of tools to configure, deploy, and monitor applications), and end-users (who are presented with one common experience when interacting with your system). Consistency is king.
Finally, and perhaps most importantly, quality software needs to be simple. To paraphrase Einstein, software should be as simple as possible, but no simpler. This is a tall order, because the world is a complex place, and it can be very challenging to create a simple system to model such complexity. Yet that is what we must strive for. Don’t write code that is a simple reflection of your requirements. Look for abstractions that allow you to create a simple model from which your required use cases can flow cleanly. Avoid “special cases” and “hard-coded” solutions. When done right, the simple solution is often the most flexible solution, and will allow your software to grow and change with your business. Creating a simple “mental model” for the way the software works is critical to making it understandable for developers, operators, and users alike.
No system of principles can ever capture the full picture of what “quality software” really means. However, striving to create software solutions that are clear, simple, and consistent is a good place to start. Remember also that the clarity, simplicity, and consistency must be evident from all perspectives — developers, operators, and users must all see these properties. Equipped with these principles and our creativity, we have a fighting chance of defeating the robots.