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.

A "must read" for XP lovers and haters 1 Comment More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • This particularly caught my attention:
    A willingness on the part of team members to address any and all project issues has proven invaluable on many occasion...
    Both of the times I decided that I didn't like where I was working any more and quit was when I hit resistance to fixing issues that were obviously broken: the implementation was obviously not what the users wanted, but software a manager had been carrying around on tape from an old job, so That Is What We Will Use; the other was simply a project that was sloppily set up and never fixed. (In that particular one, it took literally weeks to properly configure the development environment after a checkout, because no one ever either wrote down how to do it, ot spent a few extra minutes writing a script to automate it. Not standardizing the development platform to either Windows or FreeBSD caused that one, in my opinion.)

    Sometimes it was passive - I just couldn't get anyone else to acknowledge that there was a problem, and it wasn't something I could solve solo. Sometimes it was active - like moving me out of an office into a cubicle, with the implied message of "quit doing what you're doing or we'll really make your life insufferable". In that particular case, a co-worker and I actively resisted the status quo, insisting on fixing things properly rather than in a half-assed fashion, and arguing for actually designing to meet user needs. Didn't work. We both ended up in the cubes. We also quit and got better jobs not long after, so it evened out for us. I'm not sure if that's a management success or not ...

    If you can get mangement on your side in one of these cases, you can generally fix them. If management is not interested, or is actively opposed to the necessary fixes, finding another position is pretty much your only option.

    If you are a manager and one of your good programmers comes to you and says "the solution we're implementing is not what the users want, and I have proof", or "the project has a problem, and this illustrates it", ignoring the problem or shooting the messenger is not going to help you or the project; especially since you're probably going to lose that programmer and possibly other good ones (if not all of them) as well. Making an example of someone who points out problems leads to people eventually not pointing out any problem, and a distinct chance of eventual Big Failure. Career-altering Big Failure.

    Any more, I always ask anyone I'm going to work with how they handle process problems. I'm looking for an understanding that if the process is bad, the quality of the software will suffer until the process is fixed. It doesn't really matter if it's a coding process or a project-management process or the process of understanding the actual user needs: if you leave bad in anywhere, bad eventually comes out.

    A project is not a success if you make all your deadlines, but the good people keep qutting.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.