Software Quality

Topics seems to come in droves. I’ve recently read several articles about software quality. The articles approach the topic from different perspectives but the general points are the same, software quality must improve. Steve Jones over at SQL Server Central recently wrote about software quality. There are several great responses to his posting. Allen Holub, over at SD Times, recently wrote a column titled “Stomping on the Bugs” which is a review of a tool called FindBugs. I’m all in favor of developers and testers using tools to help locate bugs. And as Allen points out, the tools are getting better and better. But as good as the tools are getting, relying solely on them is not acceptable.

Here are my three reasons why high software quality is hard to achieve:

1. Systems continue to trend toward increasing complexity

2. Software development tools open programming to non-programmers

3. Development teams are not disciplined

a. Lack of programming standards

b. Lack of methodical unit testing

c. Lack of design walkthroughs

d. Lack of code walkthroughs

Lack of project management, poor requirements, declining budgets, etc are reasons people often provide when asked why software quality is declining (or perceived to be declining). IMHO these are all symptoms and not causes. I’m not saying they’re not real – I know they are; I’m merely saying that even if you got all those things correct or to a sufficient level you would still end up with quality problems.

To address the problem we need dev and testing tools to reduce system complexity – virtualization technology and tools like FindBugs are super critical to this. We need to put more emphasis on continued training and certification of devs and testers. And finally, we need to treat software development as an engineering discipline. I know I wouldn’t want the designers and builders of bridges or airplanes taking the same shortcuts I’ve seen devs and testers take. Software already impacts our life each and every day and it’s permeating more and more.

I read an article recently in a non-technical magazine (I left it home so I’ll update this once I get home) that talked about using the web as a means for releasing software very quickly. Essentially teams work really fast to implement and then throw the software out on the web for use. We should be very afraid of this practice. I’ll write more on this later.

Finally, doesn’t there seem to a trend toward perpetual betas? Google is master of this, after all, GMail and roughly a dozen other Google properties are still in beta. Does this allow the company to release buggy software without having to accept responsibility for the quality? I’ll need to write more about this another day.