All the Perl that's Practical to Extract and Report
use Perl Log In
Ovid (2709)
(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.
Software Failures
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.
I pour myself a cup of strong coffee. :-)
-- Jarkko Hietaniemi
Management *and* Programmer failures (Score:2)
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
Re:Management *and* Programmer failures (Score:2)
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
Gaps in responsibility is a major factor (Score:1)
'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