18 March 2023
One of the most widely used tools in solving the problems of the modern world is software. We find software everywhere - in our phones, our computers, our homes, our vehicles, our banks, and so on. It is not a reach to say that the modern world can only exist with software, not forgetting of course its foundation in science.
At its core, software is the end product of a human enlisting the help of a computer to complete tasks in a way that is faster and less error-prone than it would otherwise be if a human executed the same task. It is important to highlight, however, that software is just a tool that helps humans solve real-world problems. Any practical discussion of what makes software good or bad should ultimately tie up to how well it achieves its purpose as a tool.
One of the most obvious metrics to determine if a software is good or bad is its correctness. Does the software produce the expected output given some inputs? Calculator software, for example, is bad if it answers 5 to the question of what is 1 plus 2.
Another metric that is of high importance is the speed with which humans can alter software’s behavior. If the solution to a real-world problem changes, developers should be able to quickly update the software to align its behavior with the new solution. The less time it takes to make the change, the better the software is.
Speed and quality, then, are the two primary pragmatic metrics that can be used to measure if software is good or bad. Good software is software that reliably exhibits expected behavior while still being malleable enough to quickly adapt to changing needs. To summarize, I offer the following goal as the guiding light for today’s software development teams:
For the rest of the page, I will refer to software in that ideal state as adaptable software.
Ensuring that software becomes and remains adaptable requires implementing relevant practices in two domains: people and code.
People practices deal with questions of how teams are organized, how information gets shared within and between teams, how to ensure that the team is building the right software, how to ensure that teams and individuals are empowered, and so on. One of the most popular, if not the most popular, practices that aim to answer those questions is agile and its many variants.
Code practices deal with questions of how to make code more maintainable, how to prevent introducing unexpected behavior, how to reduce the time it takes to deploy code to production, and so on. This is the area that clean code, devops, design patterns, etc. try to address.
Some practices, such as devops, can be considered as both a people practice and a code practice. Regardless of categorization, any practice that is implemented should ultimately serve to making software more adaptable.
Ensuring that software is adaptable may seem like an obvious goal, one which all software teams surely have and faithfully adhere to. Unfortunately, that is not the case. It is my desire to help remedy this situation.
In succeeding posts, I will share some code practices that, when implemented, can make software more adaptable.
