Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Wednesday October 06, 2004
03:52 PM

Software Failures

[ #21218 ]

I write bugs. You write bugs. The customers generate bugs and we all look bad. For the most part, though, it's not the programmer's fault. CNN has an article about software disasters and it makes it pretty clear where the bulk of the problem is: bad management.

Alice the programmer creates a system that implements the spec handed to her by her boss. Because she didn't understand one of the lines of the spec, her software deletes cancelled products rather than marking them as "discontinued." Thus, the system starts to repeatedly fail as queries try to join on non-existent products and someone's failure to add foreign key constraints to the order_items table ensures that the problem is not caught right away. So Alice screwed up big time, right?

Well, possibly. Maybe Alice has been a dedicated employee for 10 years and rarely, if ever, produces buggy software. Sure, maybe a major product has a serious flaw that's not been caught, but the reality is, Bob the manager has a responsibility to ensure that programmers understand his specs. Bob has to make sure that QA has drawn up an acceptable test plan and fully implemented it. Bob has to know that a hard-drive failure on flight-control software doesn't kill everyone on the plane. Bob has to have confidence that customers will know how to use the software and that the software does what is planned.

Customers, of course, don't care, but managers need to understand that they are the ones responsible for the product. The programmers are only responsible for the piece they are working on. And if Alice keeps turning in bad code? It may not be Bob's fault, but it's Bob's responsibility. He has to figure out why Alice is turning in bad code. Is she sloppy? Are the specs clear? Is she not writing tests? Does she need more training? Is QA just missing things? (Side note: QA is Quality Assurance, not Quality Assessment! That's a common misperception which causes all sorts of problems.)

Software is a process. Sometimes the process is all rolled into one individual, but if you have a management team, they are there to manage the process. Sometimes programmers are bad and have to go, but management ultimately has to realize that sometimes programmers are great and the software is still rotten. When that happens, it's time to start figuring out what's wrong with the process.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Alice the programmer creates a system that implements the spec handed to her by her boss. Because she didn't understand one of the lines of the spec, her software deletes cancelled products rather than marking them as "discontinued."

    This is, to me, at least partially Alice's fault. If the spec is even the least bit unclear then the programmer has a duty to seek clarification. A good way of doing this is for the programmers to take the customer's spec and write their own more detailed version, and get t

    • Again, while it may not be the manager's fault, it's certainly the manager's responsibility. If issues like this happen once or twice, no big deal. If they happen repeatedly, the manager has to deal with this. Any manager who just points to others whose work he or she has control of doesn't understand the term "manager." When I first started managing, about 15 years ago, I almost got fired for this. After a while, I realized that I had to assume that responsibility lest their be no accountability. O

  • What I have found is that bugs most often occur where there are gaps in knowledge, whether it be technical, product, or managerial knowledge.

    'Because she didn't understand one of the lines of the spec, her software deletes cancelled products rather than marking them as "discontinued."'

    This is an example of a gap in product knowledge. Alice certainly is technically capable of marking products discontinued. Not enough attention was put into managing the product. This is different than project managemen