Ways to improve software quality

June 16, 2015

If you are part of a software development team I’m sure you are all too familiar with today’s brutally agile release cycles. With multiple new features wanted for each cycle you get out the door, the high-paced climate can lead to slow, unstable and buggy code that users don’t like and ultimately aren’t interested in using.

Over the years at RSAWEB, I have picked up some valuable ‘tricks of the trade’ that have helped me and others in our team cope with the ever-changing technical landscape.

Here are a few of my key survival tips:

Tip 1: Know the requirements 

The software development team needs to be provided with a definition of what a quality outcome looks like and how it fits into the time, resource and budget constraints. Carefully defining each project will lead to an overall improvement in the ability of the team by not over taxing the various resources with unrealistic expectations.

It is up to the project lead to understand the importance and need of providing clear and concise business requirements, so that the software development team can execute these goals. It is almost impossible to go into too much detail here, and taking the time to write a clear and detailed brief is imperative. Giving a team a vague outline of what’s required and expecting them to fill in the gaps will push the project over the deadline and budget and will again result in unhappy users and stakeholders.

Tip 2: Technical specifications are critical 

A developer needs to be tasked with scrutinizing every possible outcome and use case of each business requirement and, therefore, the creation of detailed scenarios and methods of how code will be used to meet each requirement.

The outcome of this planning will become the developer’s blueprint; a ‘paint by numbers’ plan so to speak, that ensures no major architecture decisions are being made while deep within the coding process. In the end, a developer should have a very clear understanding of how every piece of code will fit together to meet the requirements.

It is also recommended that the developer who does the planning does not write the actual code. This will ensure that the specifications are clear enough to be worked on by anyone else in the team at a later stage, and will also assist in ensuring that the objectives have been considered from more than one perspective.

To read about the importance of technical specifications click here.

Tip 3: Structured task management 

Before a single line of code is written, a developer should have every feature, with the various scenarios and methods, broken up into small, manageable chunks of time, each totalling no more than four hours of work.

Keeping tasks small and manageable will help avoid situations where developers get stuck down a rabbit hole and are too afraid to ask for help when they realize they’ve exceeded the time allowance for that feature. This also keeps team velocity moving forward and makes it easier to communicate progress to stakeholders. Manageable, ‘bite-sized’ tasks are a developer’s best friend.

Here at RSAWEB we are advocates for the task management program; JIRA Service Desk. I have found that JIRA works incredibly well, especially for teams running both SCRUM and KANBAN development cycles. Our team also regularly makes use of the various JIRA plugins available such as Confluence for technical docs and HipChat for instant messaging within the team.

Tip 4: Extensive unit testing 

Unit testing is the closest you can come to having peace of mind after deploying new code into your production environment. Unit tests should be written first and then used to ensure that your code satisfies the build’s requirements, rather than vice versa. This is sometimes difficult for teams that have not worked with unit tests before to grasp, but it is a very important step.

If you would like to read more about unit testing read our blog post here.

Tip 5: Nothing goes live without peer review 

The two-man rule applies each and every time! No code should ever go live without a minimum of one other developer completing a peer review first.

We are all human and no matter how hard we try, mistakes can slip through. Something as innocent as a semi-colon in the wrong place within a string of code has the power to bring a production environment to its knees. Do the right thing and ensure that peer review is a mandatory requirement prior to publishing live.

Tip 6: Monitor the new code 

New code going live does not mean that the job is complete. All of the tests you have in place might pass and the site might appear live and working as it should, but secretly, ominously, behind the scenes something bad could be brewing. We have found that often systems function 100% under a low load but every user you add can double or triple the strain to the system until eventually your database and webservers just can’t cope anymore and everything crashes.

To avoid situations like these, make sure you have a quality application monitoring tool set up to alert you if your code starts to underperform. New Relic, for example, has a great Apdex tool, which lets you know your application response times compared to industry standards and informs you if your users are happy or frustrated with various sections of your application.

In the end, it is vital that you always try to know about issues before your users do as there would be no point in building the system or going through all the steps above if you did not monitor the end result.

Here is another article we wrote about the DevOps environment.

Collaboration is key to creating a succesful DevOps environment