Architecture and design quality is of utmost importance in any mission critical system. Yet how many times have you seen quality take a back seat to time to market and other factors that are deemed more important to the business. In current development scenarios, how many times have implemented solutions quickly and deployed them production without adequately ensuring scalability, performance, security and other qualities of service (QoS). And all this because it is more important to release on time than to release with quality. The business forces justify going live sooner than later at the cost of overall systemic quality.
Even though over the years, many approaches (Patterns, Idioms, Processes, Methodologies, etc.) have evolved to focus and improve system quality, we seldom find enough time or effort to adopt and implement these best practices. We find little or no time to research, educate and adopt them within our teams. As a result, for most development teams, quality becomes an afterthought in the development process. In some cases we rely on a few key individuals in the team to ensure the quality of implementations. This works well in small and highly skilled teams, but when the teams get large with members of varying skill levels, the technical leadership is burdened beyond their ability to ensure adherence and conformance to best practices. The quality of the system under development takes a spiral dive. Sometimes, we comfort ourselves thinking that we can refactor our system as and when we discover the deficiencies. I think we even kid ourselves that we can do so even after going live. And so, in our quest to meet fast evolving business needs, we wrongly rely on future refactoring to justify such quick and non-ideal implementations. Even if we know we will not have time to refactor, we go ahead any way and implement whatever solution we come up with that works at the moment. Because, that is what the project demands, right?
So what’s the big deal? The big deal is that we pay a price! Sometimes a hefty one. When we find a defect in an implementation, we can find and fix it relatively easily if the defect is truly related to implementation and not architecture/design. But fixing a design problem, like you chose the wrong design or something central to the system, we can’t really fix it that easily without ripping out the guts of the system.
So in theory, identifying and fixing defects early on is the least expensive approach. It might even be possible to contain the impact of such fixes if detected in this early stage. But, despite having known this fact over the years, little has been done in the industry to provide tools and solutions to help identify design and architectural defects early on in the development lifecycle. Thus, in practice, it becomes a difficult task. In any case, even if we successfully identify a design or architecture defect, but do it late in the development cycle, it becomes next to impossible to fix it. So most systems in this stage will go live despite the looming problems ahead, hoping to try to patch it up as they go on. And most likely, the patches are going to be cosmetic and external such as allocating more resources (hardware/personnel) instead of eliminating the core defect in the system.
So, don’t phunk with architecture and design when you can pay a little more attention from the beginning and get it right.
- Software Defect Reduction Top 10 List by Barry Boehm and Victor R Basili
- Return On Investment from Software Process Improvement by Thomas McGibbon