What I do to Ensure Quality in the Software I Build
How do you ensure quality in the software you create?
Many years ago I was asked to send a response to this question to a recruiter for an interview prescreening. I decided to put a little more thought into my answer than the few bullet points you might typically expect.
This is a great, albeit a very loaded, question. One could easily write a series of books to address just this one topic alone. That said, I’ll attempt to be brief and concise, yet comprehensive in my answer. To begin, I believe it’s worth mentioning that the definition of quality is contextual. For example, an executive manager will view quality differently than a team lead, and a team lead might view quality differently than an end user. I have had a wide breadth of experience in my career, and these are some of the things that I endeavor to do to ensure quality when building a software system.
Achieve a full understanding of the business vision, goals, and requirements of the system
It is important to have a full understanding of why you are building software. Most software is built to increase the net income of a business, either by increasing revenues or by reducing costs. It is vitally important to understand such objectives when designing a new system so that it is not over engineered or under engineered. Over engineering software can make it very robust and sophisticated, but if the costs exceed the financial gain, then the system has failed to meet a fundamental business goal. Alternatively, if a system is under engineered, there are a plethora of issues which can arise such as it being very brittle and buggy, unable to scale and handle user load, or it can be very difficult to extend and add new functionality. To that end, I feel it is very important to understand why you are building a particular piece of software so that it may be designed and implemented with those goals in mind.
Achieve a full understanding of the technical environment
Develop a user experience / design optimized for the end users
I’ve built a lot of systems that were amazing on the back end, yet simply failed to meet the expectations of the users because the UI was built for how the managers thought it should work instead of how the users thought it should work. I feel that is a critical component of successful software design to ensure you are carefully considering the profiles of the end users and how they will be using that system. The users don’t care how cool the back end is; they care that the system helps them meet their needs easily and efficiently. To this end, I always try to ensure that the UX component of systems are a forethought instead of an afterthought.
Design and build the system for scalability and extensibility
With the caveat I mentioned above about not over engineering systems, if they are designed properly with the goals of scalability and extensibility in mind, software can be built to scale to the increasing demands of a growing user base and can also be easily extended to meet evolving business and functional needs. One of the primary goals here is that existing systems shouldn’t need to be rebuilt to do this. To that end, I feel that there are some basic architectural principles which should be followed to achieve this goal. Those principles are listed below.
Design and implement an N-Tier architecture
I normally build at least 3 tiers into the systems I design. These canonical tiers, Data, Business, and Presentation, can almost always be separated to support scalability and extensibility without over engineering the system. The fourth tier, Services (between Business and Presentation), has also become increasingly more important with the proliferation of mobile devices.