Saturday, June 07, 2008

Software Quality is not optional

The last day of TechEd and I did two panel sessions. The topic of the first panel session was software quality.
The panel had an awesome line up including; Billy Hollis, Jeffrey Palermoand David Platt.
In this panel were people I respect, they are smart, have worked in the industry for a while and know their areas well.
Then I discover some panel members (called Billy and David) are happy to accept that software will be built with defects, they do not believe that the software they write is likely to be defect free.
This makes me wonder what hope the industry has as a whole.
The software you produce is an output of your goals. Aim high to achieve high targets. Aim for zero defect software, do everything in your power to build zero defect software and the chances are you can get there.
If you start with the belief that this software will have defects when you are finished building it, then your chances of delivering zero defect software are already lower.

7 comments:

Ian said...

Hi Neil,

I take your point but the reality is that software is almost always built with defects initially. The important thing for me is the approach you describe (Aim high to achieve high targets) coupled with an acceptance that you will need to manage change (bugs, functionality).

You need tools for this, and this is where TDD and Unit Tests pay dividends (as I know you are aware).

I do get a feeling we are potentially on a cusp in software and that we may be able to start adopting a more scientific approach to developing software (and my bet is TDD is the foundation for this).

I think users and buyers of software would appreciate standards they can understand and recognise, and use to measure quality - plumbers have this, why not software engineers - how could we move towards such a standard do you think?

Dr. Neil said...

I had 2 interesting conversations last night.
The first conversation was with Paul Yao. Paul reminded me that we often come at the quality issue from different points of view.
My background in embedded & real time systems leads me to a position where defects cost a lot and are critical to fix. This has led me to spend energy on building zero defect software.
Coming from a Visual Basic Forms background creates a different point of view.
The other conversation was during dinner. I was told that a podcast I did a while back inspired a software team to aim for zero defect software. Over a period of a year this team fixed all the bugs in their bug database (while working on new features in parallel) and are now working on zero defect software. Sweet!!

Jeffrey Palermo said...

The worldview issue is a big one. I have led teams with a zero-defect policy. When a defect is found, the team stops everything, fixes the defect, discusses how it got through, and then resumes. The above process might take 1 or 2 hours, but it has led to an extremely low defect rate. We save tons of time by not promoting defects on into production.

-Jeffrey Palermo
P.S. Great panel. I'm glad I wasn't alone on the topic.

piers7 said...

Whilst I think endevouring to create quality software is a virtue in of itself, the reality is that we all work in slightly different sectors, for different clients, under different engagement models, and there is no one-size-fits-all approach. What works for a safetly critical system (NASA, Nuclear power plant etc...) is very different to what works for Jo's Book Shop website down the road.

Similarly it's not the case that all defects are created equal. Aiming for zero bug software is all very well, but if the reality is that the defect is less important than the functionality you haven't written yet then it becomes a business decision as to how to proceed. It should be an informed decision, sure, but it is not our role to put our own visions of software purity ahead of the client's business goals.

Ultimately quality is just one of a number of variables that have to be considered and played off against scope, time and cost in order to achieve an appropriate outcome. Compromise is a fact of life in business, to which quality is not immune.

Sergey said...

Software quality matters!
25uuustt

Sonia said...
This comment has been removed by the author.
Sonia said...

Yes Software quality matters

Assignment Help Online