Most companies have group with the title "Quality Assurance", but is their role really to assure that the product(s) has quality? I feel that their true role is more "Functional Insurance", as the work they do is used more as a functional safety net for the products and organization than for ensuring that our product has quality. Do not mistake, this is extremely valuable but it doesn't ensure that we have built quality. Quality on the other hand, must be built into the product itself. Unfortunately, quality is difficult to quantify and doubly so in the software industry. Software is often seen as part art form and as such quality can seem a subjective topic. But quality is identifiable and it doesn't come from testing (not unit, not functional, not end-to-end, not automated, not regression). Quality is built into the code itself and I believe there are three main technical concepts that make up quality software: consistency, simplicity, applicability. These three concepts lead to achieving the business needs that software be supportable, maintainable, and extensible.
Consistency:
Consistency is arguably the most important concept of building quality software. Consistency is important because it allows for familiarity and patterns to form. You can have complex systems, but if you have consistency in how those systems are written and applied you gain support-ability and maintainability withing your product you can also usually meet some level of your business needs with solely a consistent code base. Consistency forms patterns and patterns are a developers best friend. Patterns allow for a deeper understanding of the code and that understanding can be achieved more quickly. Often a developer that is coming onto a project is looking for the patterns in order to understand how the software works. Patterns and consistency are so important to software design that there have been numerous books written on well defined patterns (design patterns), that can be used to solve specific problems that are commonly encountered in software.
Simplicity:
Simplicity is the second most important aspect of building quality software. Simple code doesn't mean that you can't solve complex problems but rather to use a pragmatic approach to the problem solving when you are doing it with software. It is not uncommon to see engineers over complicate a problem and attempt to solve it in a way that ultimately makes things worse (or at least less supportable, maintainable, extensible). There are a lot of names for keeping code simple: the KISS Principle (Keep It Simple, Stupid), avoid over-engineering, MVP (Minimum Viable Product), YAGNI (You aren't going to need it), etc. I am a proponent of breaking problems down and solving it using simple building blocks and leveraging those building block in a consistent manner. When we do this we gain ground with all three business needs.
Applicability:
The last area of writing quality is Applicability. Writing software is a process that is completed through the application of a series of tools and methodologies. Using these tools, from language constructs to 3rd party libraries, correctly and efficiently is "Applicability". Unfortunately the depth and breadth of tools and methodologies can be extremely daunting and having the knowledge and experience required to know when and how to use any of the tools available is significant. This is one of the reasons why there is a big difference between the best engineers and mediocre ones. Applicability is an important aspect of quality software because using the right tool for the job and using it correctly greatly reduces complexity (increases Simplicity) and helps enforce consistency. One interesting aspect of applicability is it is not static. It is variable and can change over time. The software development environment is changing with a frequency that can be difficult to keep up with. New tools, new languages, new frameworks, new methodologies, etc. are being introduced to solve new and existing problems better every day. This means that overtime, the code that was written and the tools that you used may no longer be the best way of solving the issue and it may make sense to leverage these new tools and techniques.
What happens when we have a quality deficiency?
Being deficient in one or more of these areas can lead to an inability to execute. What is worse is that we often think that to increase quality we need to test and test and test some more. But what we are really doing is trying to protect ourselves with functional insurance because of the lack of quality in our products. When products suffer from a lack of consistency and simplicity all aspects of writing code and tests becomes more difficult which further degrades our productiveness. This often makes keeping the codebase current difficult which leads to applicability issues and further decreases quality. This downward spiral becomes a self fulfilling prophecy.
So how do we move forward?
Well, the first step is understanding that we must address our deficiencies. In order to do this, we need to identify "WHAT" problems we want our applications to solve. Once this is identified, we need to identify "HOW" we are going to do it at the macro level. We must understand that how we solve the problems can (and in many places should) be different than the solutions we have today. Once we have the macro picture of how we are going to solve the problems, we need to focus on the micro picture and executing on the plan. To do this, we need the time and resources to build quality back into our software. Migrating products, functionality, and software is not an easy endeavor, but it also not an impossible one. As we move toward the future our products need to evolve to the new challenges. Lastly, we need technical oversight both at the Macro and Micro levels. Oversight is used to ensure that we continually build quality into our products. Without oversight is is easy for a single developer or even a team of developers to lose sight of the bigger picture.
No comments:
Post a Comment