• Mr.Bob (unregistered)

    His boss takes the specs from the customer to the engineers. Don't you get it? He's a people person!

  • Flippit (unregistered) in reply to Rank Amateur
    Rank Amateur:
    ...a coder (myself) who sends the fixed code to the tester (myself) ~. Sometimes it’s good to be an amateur. --Rank

    It has been my experience that if a developer does the QC/QA for his/her own code, it almost invariably means we're shipping buggy code.

    Unfortunately, people insist upon failing to learn from history so they can keep making the same mistakes ("QA people are too expensive! Let's use the programmers!") over and over again.

    I guess because it feels faster to cowboy it (i.e., customers are our QA), "doing it twice" is the de facto coding standard.

  • Big Organisation Pain (unregistered) in reply to Quietust
    we use SeaPine TestTrack for this. Its a great tool, and we have a good process from who issues the ticket, Assigning to a developer, and submitting to QA at build time. Its a timesaver and helps communication out in the whole organization. It seems like Erics system was just a manual issue tracker, and it proves that this process needs to be automated so that people can do their jobs. A developer should be paid to design and code software, not spend too much of his time trying to beat the system.

    Indeed. In fact, it doesn't necessarily matter which system you use (I've used a few over the years, the current being TestTrack), just as long as it automates keeping track of each defect (newly added, assigned to a developer, fixed in codebase, fixed in an actual build, assigned to a tester, tested and verified) and sending status emails.

    I don't think I'd last more than a few weeks having to do all of that crap by hand, but once you have a defect management system in place (even if it's Bugzilla), such a "process" tends to vastly simplify itself.

    BUT there's the rub - you can have a defect/process management system that is so locked down to its own process (ie bad), it takes more time and effort than a sensible manual system. Where I am it is Windchill, with so many stop check points (OK that is not WIndchill's fault, but WC does make it too likely that you use this sort) that it takes 2 weeks to get a change in - once it is already complete. (Disclaimer: yes it is a doc/dwg/code release system, not a code bug tracker, but it sits on top of any actual changes here, no matter what type, once any item is out of first pass concept stage)

  • Nano (unregistered)

    It will never get resolved. Theres an infinite loop bug in step 8 of the process:

    8 - If the resolution has any problems, the QA manager shall notify the development manager (perhaps in a meeting with himself?), who shall notify the defect analyst in the weekly defect-prioritization meeting, who shall then notify the original programmer, who shall then repeat the previous step.

    Thanks to the QA manager being the development manager the if clause is always satisfied, therefore the previous step is always repeated ad infinitum. The only way out is to quit the process entirely, like the unfortunate poster.

  • nobody (unregistered) in reply to Rank Amateur
    Rank Amateur:
    That’s funny. There’s a nearly identical system where I code, but I get resolutions usually within the same day. Upon encountering a bug, the user (myself) notifies his advocate (myself) who pass the bug to the analyst (myself) who sends the proposed solution to the development manager (myself) who assigns a coder (myself) who sends the fixed code to the tester (myself) who notifies the CIO (myself), who calls a meeting of the user, the advocate, the analyst, the development manager, the coder, and the tester to declare the bug fixed. Sometimes it’s good to be an amateur. --Rank

    The amazing thing is that I have the exact same process (minus CEO) in a large corporate environment and am required to fill out multiple documents "correctly" for each of the roles. Fun when a process for large groups is shoved down the throat of one -- a process that is supposed to be "lean".

  • Andrew (unregistered)

    Um... why can't they just use bug-tracking software, like Bugtraq, Trac, or possible even OTRS?

    This way the users can submit their own bug reports with much less overhead. After a while users will submit good, detailed reports. A handbook on how to submit a bug report will help (perhaps stored in a wiki?).

    It's time they change their procedures.

  • ELIZA (unregistered) in reply to nwbrown
    Apparently they know about Sarbanes Oxley (SOx) and SDLC!!!!!

    SOX - brought to you by a business friendly Republican Congress. That's the WTF.

    captcha: dubya - another Republican enemy of free markets.

    Oxley was a Republican, but Sarbanes was a Democrat.

    Though I suppose Ken Lay has to be considered the true father of that act...

    You guys are missing the point. Two Senators don't make a bill a law. It takes a Congress. And in this case it was a Republican controlled Congress. Republicans are known traditionally to be "business friendly" and yet they, along with a Republican president, passed this abomination of a law.

    Wrong again. The Democrats were in charge of the Senate in 2002 after Jeffords left the Republican caucus in 01. The Republicans didn't take control again until 2003.

    But again, Ken Lay and friends were the true parents of this law. It was passed in reaction to their scandals. It didn't matter who was in Congress or the White House, something had to be done to convince the masses that their 401-ks and savings were safe.

    This edition of early 21st century History 101 was brought to you by Snacky Smores, the delicious taste of smores in a delightful cookie crunch.

    According to Krugman, Sarbanes-Oxley was like seeing in 1920s Chicago a Ness-Capone Clean Government Ordinance, which demonstrates just how badly Lay screwed up.

  • (cs)

    Nice to read article.

Leave a comment on “Prisoner of Process”

Log In or post as a guest

Replying to comment #:

« Return to Article