One part of my work on all projects since I left my first employer in Dynamics AX world was to improve quality of software products. That’s not by coincidence – it’s because I want to make high-quality software and to help companies to do it.

High quality is good for everybody – it has obvious advantages for users, but it’s good for us as well – we don’t have to waste so much time with support, debugging, bug fix development, deployment and so on and we can concentrate on development of new features (that’s our real job, isn’t it?). And of course, satisfied customers are more likely to give us more work and recommend us to their business partners.

All those companies I worked for felt that quality of their products is not very high, or at least felt that it is good to talk about quality. Whether quality was really their priority would be another story; now I want to point out the overall expectation about how to improve quality. To quote a certain manager:

“You want to change a process? We thought you would just fix something in code.”

This helped me a lot to understand how some people view software quality improvements – “code is bad, go to code, fix the code”.

Try to think about it a while. Quality of our software is low, because we didn’t get requirements right, because we designed suboptimal solution, because our code is not handling many border situations, because our GUI is not intuitive and so on. Sure, all these things can be fixed, in theory – we can redesign features, we can change technical architecture, we can rewrite code. That can be extremely expensive and actually the activities are the same as what we’d done originally – and we failed. Will it be better this time? And if we want just to review code and change it a little, how will we fix what our software does by design?

What we deliver to customers is a mere output of the whole process of making software. All these analysis of requirements, GUI designs, database designs, object modeling etc. are defining the product and their quality will be reflected in the quality of the product. If our software ignores important requirements, it can’t be good. If our developers don’t know how to work with exceptions, the whole product won’t handle exception correctly. And so on.

Can we just look into code and turn such software into a high-quality one? Obviously, it’s impossible. We don’t know what are the omitted requirements by looking into code. It requires a new and better collection of requirements. We also can’t simply add a better exception handling – we need to make better analysis of possible exceptional situations and how to handle them. We should have done it better at first.

If people say that quality of their software is low, it automatically means that quality of their procedures is low. Their process generates low-quality software. Unless the broken part(s) is fixed, the process will continue to generate similar results.

What development teams really need is not somebody coming and fixing their bad code. They need to think about how they work and whether all procedures are good enough. They need to identify sources of their problems and try to change procedures to avoid repeating the same problem again. They must realize that it’s not just about coding, and think about quality of requirements, designs etc. Without all these things, people can’t expect any real change in quality.

By the way, this is one of things where iterative procedures really excel – you go through all project phases every iteration, so you see whether functional designs are good enough for development, whether it’s easy to add new features to the code base, what people think about GUI… And if something seems to go wrong, you can adjust the process and see whether it’s better in the immediate iteration.