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
--Larry Wall in perl.c from the perl source code
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
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