When we talk about code qualities and code quality practices we may have a tendency to believe that more is better, universally but that’s not always the case. We want software to run fast but we also want it to be easy to understand when we go to change it. Sometimes these characteristics and qualities can be at odds with each other. This is why it’s so vital for professional software developers to understand the trade-offs of their choices.
I tell the professional software developers in my advanced software design and development classes that they may not do anything differently next week then they did the week before taking my class but at least they will know the trade-offs of their decisions. I believe this is vitally important for professional software developers because we can’t make the right decisions unless we understand both our options in the trade-offs between those options.
One way to understand trade-offs more deeply is to understand the root cause of the situation that you are examining. Very often when building software will see many different options for implementing any particular behavior. Generally speaking, in Agile we prefer to take the simplest actions and build the simplest implementations of the features we are creating, knowing that we can go back later and extend them and because we follow good quality practices it is straightforward for us to do so.
I do want to point out here that this is not the norm in the industry. I fully recognize that so if you work on a team that has a lot of legacy code with the stigma around changing it then it probably got that way for good reason because developers went to try to change that code and found that it wasn’t as easy as they might’ve thought.
Poorly written code can be a bear to change because often times making one change can ripple defects any issues across many unrelated areas because of the way software is developed today. When we don’t follow software development practices that support building quality software then very often we find side effects in systems that might not show up until we go to extend those systems. Just getting a feature to work is not good enough because we often need to extend features and if that is very difficult or impossible to do then we have not done our industry is service.
Instead, we want to follow quality practices that support us in making changeable code so that we can build reliability into our software and dropped the cost of ownership. That’s what quality software is all about, dropping the cost of ownership.
In the physical world, we are willing to pay a premium for quality materials or quality service but in the software world, we really do get quality for free. I know this may be difficult for some people to accept but in my experience as a senior software developer doing quality craftsmanship and software development doesn’t slow you down. In fact, it’s just the opposite, paying attention to the quality practices in building quality code actually makes things go faster.
This is true in the physical world and in every other discipline so why would it not be true in software? If you are a chef who is responsible for producing hundreds of meals a day from your kitchen then you know that you must keep your kitchen clean in order to handle that kind of volume. The same is true in software. In order to gain the benefits of Agile software development that is incremental and just-in-time, we have to make the right trade-offs and follow quality practices as nonnegotiable’s.
So in Agile software development, there are a core set of principles and practices that we follow which we never deviate from. We always strive to make our code CLEAN. However, like any good practitioner, we are also aware that there are contraindications and doing the right thing in one situation would be the wrong thing in a different situation. Medicine has the same thing. In order to fight an infection a doctor might give patients penicillin but if a patient is allergic to penicillin then giving it to them will kill them so the doctor must find a different alternative.
In software development, there are many practices that are the right thing to do in one situation but the wrong thing to do in a different situation. By understanding the trade-offs of our actions and the practices that we follow we can make the right choices for any situation that we are in.
At least, that’s what we strive for.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Measuring Software Development.
Previous Post: « Let Go of Perfectionism
Next Post: Hide How with What »