In-House Developers Share Software Bug Blame

A few months ago, I took software vendors to the woodshed for their lack of quality control and for the excessive number of bugs that their software users must struggle with. I received a tremendous amount of feedback about this topic and shared many reader comments in this forum. (To read the original commentaries, see "Complacency Creates Vicious Cycle of Software Bugs," http://www.sqlmag.com/articles/index.cfm?articleid=26056 , and "Readers Respond to Software Bug Topic," http://www.sqlmag.com/Articles/Index.cfm?ArticleID=26264 .) Granted, vendors deliver notoriously bug-filled software—but who are we to complain? Much of corporate America delivers worse. This excerpt from a reader's email message forced me to think about the quality issue from a broader perspective:

"I've been a developer for 35 years. Five years ago, I came on to a large-scale SQL Server project about 2 years after it began. I just read your latest email with reader responses concerning buggy software. This comes on an afternoon when I am walking through some of our code that has been in production for about 5 years. Talk about buggy!

"I'm looking at a 20-page SQL stored procedure that reformats and moves data from temporary tables into a production database. I haven't finished testing, but I can already see where the procedure potentially throws away data with no trace due to improperly written joins on lookup tables. Error checking and logging are nonexistent.

"I find I rarely have time to malign software vendors about their bugs. I'm too busy handling bugs in our own software. My complaint is with software project managers who are so intent on adding features and releasing new versions that we let our users suffer with the problems we do have some control over, just because we don't insist that our products be less buggy.

"Let's face it. In order to compete in the software industry, you have to have a [powerhouse] product just to survive. I dare say most in-house corporate developers wouldn't make it on the outside if they had to compete in the real world and develop shrink-wrapped software. We'd be better positioned to combat buggy software from vendors if we could deliver higher quality software ourselves."

I don't like to point out problems without suggesting solutions, but I'm at a loss to offer solutions for the types of problems the reader mentioned. I haven't worked in the industry for 35 years, as the reader has, but my 13 years in the consulting world have given me access to dozens of applications. My observations? Many internal development shops lack effective Quality Assurance (QA) processes and deliver applications that contain as many or more bugs as the products that commercial software vendors send to market. This deficiency is as true in the database world as it is in the application world. Everyone in the industry talks about the need for better QA, and most developers believe that their projects incorporate fail-safe QA processes. But when push comes to shove, QA is the first segment of a project that’s cut when the project starts to slip behind schedule.

It seems that solving the QA problem should be easy, but it obviously isn't, or the problem of poor quality control wouldn't be as pervasive as it is. I'm sure that a QA professional could speak eloquently about potential solutions to this persistent problem within corporate IT shops. However, I'm not a QA guru. Still, I'd love your insights. From now on, I'm willing to cut vendors more slack about their QA problems—at least until we start doing a better job of instituting more effective QA policies in our own projects.