Often I come across software where they has been little or no attention to quality attributes and an out of balance focus on just delivering functionality. Focussing on the desirable quality attributes for your project is important.
Good quality software and code does not happen by accident. It happens as a result of consistent and passionate focus by the software implementation team to meet quality goals. This is something that is very important for your software project. Some developers have a habit of side-stepping quality concerns; especially when they are being pushed for short-term results. Here are four questions any developer should be able to answer.
1. What is meant by code quality?
2. Why do we want quality code?
3. What quality goals should we have for our project?
4. How do we achieve our quality goals?
What do I mean by "software quality" versus"code quality".
Focusing on Code Quality ensures lines of code written by developers follow a good coding standard or style guide. An excellent example of a style guide (for C++) is this :http://google-styleguide.googlecode.com/svn/trunk/cppguide.html. I would personally be happy to see a developer following a concise two page style guide. The reason we want a style guide to be followed is that it makes the code easier and less costly to work on.
Software Quality is about ensuring that the implementation of your software meets quality goals that are important to your project. These quality attributes are the result of an architectural focus on your project and include attributes such as maintainability, availability, testability and usability.
So, why is writing quality software and code important? I think the best way to answer this question is to provide a real world example.
A company has a piece of software that was originally developed a number of years ago. Since then development has continued on the product at a furious rate as new requirements emerged and requirements changed. This software is large and complex and working with the software is challenging. There is a significant backlog of cases to add features, change features and fix bugs and so the developers are busy indeed. Acceptance testing is a real problem as every time the system changes (which is all the time) the expert users have to spend a lot of their time testing the changed software and this results in further bugs and so the cycle continues. Management is worried because their business depends on this software. There is no architectural representation of the system (ie no documentation) and so there is no easy way to talk about the software (to tame the complexity) and understand what needs to happen.
If an Architect had been involved in this project from the outset and focussed on devising an architecture that resulted from the functional requirements, desired quality attributes and system constraints then this business would be in a better position to manage their destiny. If the architect had done his or her job well and an architectural focus had remained for the lifetime of the software then not only would the quality attributes for the software be recognised, but also the software would have implemented solutions for them.
In this real world example it is clear that two quality attributes (at least) were vitally important.
These quality attribute requirements should have been included along with the functional requirements. They were not. As a result this company now has software that is not easily maintained and can only be tested by manual functional testing (the users do it - user acceptance testing). It is a difficult (and costly) problem to solve, especially when the software is so large and complex.
This is a clear example of why the key quality attributes for a software project must be identified and requirements created for them and solutions designed and developed accordingly.
It is a very good idea to include a Software Architect in the team - and it does not matter if your process is Waterfall, Iterative, Agile or Model-driven; you still need an architect and an architectural focus. It is a common misconception that Agile means that you dont need to document and you dont need an Architect. The code alone that you develop does not describe the architecture. And by coding without attending to architectural goals - your code will not miraculously implement an architecture which will meet the business goals of your project.
Software and code quality is important to your software project. Make sure it is a focus for you.