5 development techniques to improve software quality

Most of these things you should really already be doing and if you’re not then I’d suggest starting to do so right away.

1. Step back and plan
It’s often hard not to just jump straight in to coding, especially with a project you are excited about. Try to resist that urge by stepping back and taking a bit of time to think about things before you start typing. Think about the problem are you trying to solve, any difficulties that may arise and come up with a potential solution. Even better than thinking about the problem and solution, write it down somewhere. If you start coding before you’ve completely got your head around the problem there’s a very good chance you will end up with little more than a mess.

After all if you start coding a solution before you know what that solution is how are you going to know when you arrive at that solution?

2. Document before coding
Documentation is another aspect of coding that is too often overlooked. Some developers believe it is not their job to document, others just don’t get around to it because of time constraints. Documentation of functions/methods and how particular sections of code are supposed to work can help with debugging and avoid the old “What was I/he/she thinking with this code?” situation.

I suggest that whenever you create a new class/function/method (or any other relevant piece of code) create the skeleton of it ONLY, then write the documentation. Only once the documentation is done should you think about implementing the guts of the function. This will ensure documentation doesn’t get forgotten and you will have a much clearer picture of what you are trying to achieve before you set out.

3. Adopt a coding standard and stick to it.
Use consistent indentation, layout, naming conventions etc across all of your code. It not only makes it easier for you and other to read and modify but it will also make it much easier to debug when you come back to look at the code in a few months time. This is easily one of the most important things you can do to improve the quality of your code but is also one of the most forgotten about or ignored.

4. Write test plans and make sure they are used
A lot of the time testing is performed very minimally or in a haphazard way. This is bad because leaves you open to miss areas while testing or not discovering obvious problems because the tester does know understand how the software will be used. This is unfortunately always a risk but it can be greatly minimised by writing various test plans and ensuring they are actually used. Test plans can be quite complex and extensive or simple use cases that are followed by the tester. Either way they are an excellent way of showing what has been tested and over time they can be expanded to cover more of your software.

Similarly to the writing of documentation for each class/function/method when they are created you should additionally create a set of tests for every function as or before it is coded. Again the tests can be expanded over time and are a great way of performing quick regression checks.

5. Reviews
This is by no means a new concept but it is definitely one that is under-utilised. Developers are often afraid of peer reviews because they don’t like their code being criticised and other developers can often be quite harsh. Don’t take it personally, it can be very useful to  have someone else’s eyes spot things you missed and after a few reviews your code will more than likely start to improve in general.

In addition to peer reviews, review your own code. Go back and have a quick read of what you’ve done in 1 week, 1 month, 4 months and 12 months later if you can. You’re almost guaranteed to come up with a better solution than you did before. Although you may not be able to implement your new ideas in that old project you may be able to use them in future.

Conclusion
I am a big believer in continually trying to improve my skills, knowledge and most of all coding standards. By using the techniques above (as well as others) the quality of software can be improved and over time so will your skills. Let us know your thoughts on the techniques listed above. Do you use them already? Do you think they will work for you or do you hate the idea altogether?

Also, I would love to hear of any other techniques people use relating to improving software quality. Leave a comment and let us know.

May 21st, 2009 | Other posts by Michael Little
  • I'm a bit late on this but I'd like to comment still.

    The first point is the most important. And unfortunately it's almost never done. Always write functional specs before you start writing code. Define your project clearly and also define what you would expect to see in upcoming releases of your project, even if they don't make it for the first version. Then always update that document everytime your project changes. Keep it up to date.

    This has multiple advantages. For one, it allows you to plan correctly your project. If you have to work with other people, that document IS the reference for the project. Not the code. Not everyone is necessarily a coder in your team (if you write it for a client, he certainly isn't able to understand code). It also allows you to easily write a presentation of your project, since it's basically what the functional specs are. You can take chunks of it to insert into the user documentation directly, or to make slides for a conference.

    It may not be obvious at first, but writing a functional spec before anything else actually makes the process of writing an application both faster and easier. I would recommend reading Joel Spolsky's take on the subject, it is quite interesting.
  • Bradley Unterrheiner
    Document before coding - that's a pretty interesting one.

    I've been doing a fair bit Test Driven Development recently which works out to be quite similar. Except rather than documenting code via comments you document it via assertions in the unit tests. As a bonus testing becomes simple very simple; just run the unit tests. Also a great way to force yourself to thing about what you're about to program before starting on the actual production code.

    It's no silver bullet, but certainly worth experimenting with for a few projects. I know it's changed how I approach development work for the better (even if I don't follow it all the time ; - ).
  • Who mentioned user documentation? - I'm yet to meet a user that would want documentation relating to specific functions, classes and methods...

    I was talking about technical documentation of function, classes and methods etc which is quite clearly noted. Furthermore I was actually quite careful to avoid mentioning any specific processes/procedures as the style of technical documentation will vary depending on the type of project and requirements.
  • David
    Um. I've never heard of a developer who wrote user documentation before coding. Plans, yes, but documentation? Reading this, I *think* you mean the pseudocode programming process as documented in CC/2e. If so, you should have said that.
  • The first one is a biggie for me. I used to (and sometimes still do) get super excited about jobs and jump into them only to find that I need to keep re-writing code for functionality I didn't ever consider because I didn't plan. I think writing an app's database schema is a great first step because it is such a pivotal step but also the easiest way to see how the data will all integrate.

    A lot of devs can be quite arrogant and not accept the feedback from others. The problem with this is that if you want to be a great dev (and not just good) you need to continue learning and you cannot learn how to better yourself unless you listen to what others have to say about you.

    Great post Mike.
blog comments powered by Disqus