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

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