Why software developers should spend time in SQA

Last Monday morning, I spent a few hours helping out on a church service project, where we’re turning an unfinished basement of a single mother’s townhouse into a bedroom+bathroom for her daughter. At this point, the basement has been framed out and sheetrock hung. My first task on Monday was to take a damp sponge and a putty knife and scrape off all the ‘goobers’ of excess ‘mud’ (joint compound) around the screw- and nail-holes in the sheetrock that had been filled in earlier by others working on the project.

My second job was to fill in with ‘mud’ the screw- and nail-holes that had not been filled so far.

I don’t know if Ron (who’s acting as general contractor and foreman on the project) consciously put my tasks in that order, but the order was effective. In filling in the holes, I was very careful not to leave ‘goobers’ of my own for someone else to later scrape off. And even as I did so, I was mentally composing this blog post.

I have long been a strong proponent of software quality assurance (SQA). My experience is that many software projects get themselves into the ‘never-ending story’ pattern because of a lack of proper SQA — that is, the system under development never achieves the stability required to go into production because the organization has not made the investment in SQA to achieve that stability. Management often feels that it can get by ‘on the cheap’ with SQA and ends up spending much more time and money on the project than if it had simply done things correctly in the first place.

But beyond that, software engineers are often guilty of the ‘over-the-transom’ mindset, as in, “write the code and throw it over the transom to the QA team”. They see their job as creating raw functionality, and that it is up to the “testers” to find out where the bugs are. That mindset again contributes to delays in development; as proponents of agile methodologies have pointed out, the best testing is done before or at the time of code writing.

I have spent time working in SQA during my career — most notably at Sun in their Development Tools group — and the experience made me a better software engineer. I think that development organizations should require software engineers to rotate through SQA on a regular basis and in particular to work on their own code. That may help to make them a bit more careful in their own craftsmanship. ..bruce w..

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.