Software Quality During Implementation, How Can It Be Achieved?
Software quality is not something you can introduce to a system during the final moments before a release, nor should it be something to sacrifice simply to increase the speed of development. Rather it should be given consideration at each and every point of the development lifecycle, from inception to implementation, and treated with a certain degree of priority.
Achieving high quality software doesn’t have to be complicated, and it certainly doesn’t have to be time consuming. During the implementation stage alone, you can find plenty of simple development processes and practices that will have a significant impact on software quality.
Keep Consistency With Coding Standards
It is important to remember that software applications do have a life following on from the final release. In some cases, software is expected to last for at least 20 years before it is replaced. As you can imagine, over such a period of time development teams will change, some people will leave and others will come to fill the space. If you were to allow each developer to code in their own preferred format, it wouldn’t take long for code to become unreadable and conflicts to appear.
By taking the time to define the standard to which developers must write their code, you can ensure that all of your code will be both understandable and consistent across every aspect of a project. Furthermore, having this consistency will ensure that any developer will have the capacity to read your code and know what to expect, effectively improving the efficiency of other quality processes such as code reviews.
Allow The Comments To Explain
It may seem counterproductive to spend time writing clean and understandable code only to go and add in comments all over the place, yet they do have their uses. For example, a potential strategy to mitigate the risks of documentation becoming outdated or inaccurate over time is to embed it within code comments and utilise tools to extract it. The major downside to these comments is that they tend to make your code rather cluttered, noisy and generally hard to read for anyone actively maintaining it.
Alternatively, comments can be used as a means to provide clarifications on the intent and reasoning behind certain sections of code. Whilst these things can seem obvious during the present they tend to be forgotten with time, by adding in clarifications you allow developers to know that piece of code exists and avoid wasted man-hours trying to improve or ‘optimise’ code that does not need to be (or in some cases cannot be) optimised.
However, it is important to avoid adding comments in situations where they aren’t needed. If the code is simple and obvious, don’t add in a comment, as the example below shows.
/* Set the value of the age integer to 32 */ int age = 32;
Know Where You Stand With Version Control
As you develop and maintain software systems you will constantly be making changes. When you work alone it is a relatively simple task to keep on top of these changes, however as you add more people things become a little more complicated.
By implementing a version or change control system, such as git or subversion, you are given the means to manage changes with ease, with each change and the different versions that are created as a result all being logged in one place.
For example, should you have a team of three or four engineers working on the same piece of code all at once, having a version control system in place allows each individual to make changes as they see fit without the worry of overwriting another team members work. Organisations that utilise version control are also provided with an additional layer of security should major issues arise within your system, allowing you to roll back to a version where the code was known to be in working order.
Remember To Review The Code Too
Regardless of the type of development, the industry or how much you trust and respect your development team, there is always a value in performing reviews on your code. In every team you will have developers from all sorts of backgrounds and with a variety of strong suits. By having several people peer review code you not only spread understanding of the project at hand, you effectively offer the opportunity for someone to suggest an alternative solution or a way to reduce complexity and improve performance.
Of course, you also get the added benefit of reducing the risk of mistakes going unchecked and open bugs making it into the final release, however there are some things one should be cautious of. As with all things, by doing too much you begin to lose the benefits. Reviews take time and effort to do properly. If you spend too long reviewing and re-reviewing code repeatedly, you will quickly find yourself hindering your own progress.
Defend Against The Unexpected
The easiest way to distinguish an experienced programmer from a novice is the degree to which they write defensive code. It is unreasonable to expect end users, who have not been a part of the development process, to be aware of the exact ins and outs of how to interact with each feature and function. Therefore, unless you want users to experience unexpected errors, crashes and failures, you must attempt to defend against this possibility.
Defensive programming is a method of designing software in order to avoid failure due to unexpected circumstances, and as such aims to build software of better quality and provide a better user experience.
For example if you were to write software to control the temperature of a home or office building, you wouldn’t want users to be able to enter unreasonable values such as 200°C whether it be on purpose or by accident. In order to defend against such as possibility you could include a few lines of code to cap the maximum and minimum values that can be entered.
Have You Covered All The Code?
You should always test your code. If you don’t test you cannot be sure if your software actually solves the problem it is trying to solve, or if it does it reliably. But how can you be certain that you are managing to test everything? After all the larger and more complex software becomes the harder it becomes to test. One potential solution is to look into your code coverage.
By looking into how much of your code is covered during testing, you highlight areas that are continuously skipped over. Having access to this information offers up the opportunity to investigate the reasons why these areas go untested, such as redundant code, missing test cases or undocumented functionality. As a beneficial outcome of this process, hidden bugs can be brought to the surface, where they can be removed prior to the final release.
Don’t Leave It All To The QM
Whilst it is undoubtedly the role of the Quality Manager (QM) to encourage and enforce the adoption, improvement and following of a quality plan or process, they are not solely responsible. In order to reduce rework, improve user satisfaction and reduce the risk of untested non-functional requirements, quality has to be considered by the rest of the team and become integrated as part of the development life-cycle.
Furthermore, it should be remembered that the purpose of quality auditing is to check that quality has been achieved. Not used as a checklist to make sure that it will happen.