• Anonymously Yours (unregistered)

    That's so messed up it's impressive. Is bureaucratastic a word, because if it isn't this example proves it should be.

  • (cs)

    Be careful what you ask for . . . .

  • Ru (unregistered)

    I think you'll find the word you're probably looking for is 'bureaucraptastic'.

  • Maxim (unregistered)

    Haven't they heard of Agile Development?

    CAPTCHA: slashbot :)

  • (cs)

    Sadly a lot of places are like this. A lot of bullshit and nothing gets done because "We have to follow procedures" when those procedures are A) for enterprise organizations (which it seems every mom-and-pop shop thinks they are, and tries to act like) and B) usually nonsense.

    I'm surprised he gave it four months. I would have quit the second week. In fact, I recently quit a job in the first week because it had similar bullshit "procedures" for making any changes (not as stupid as this one, though) and an ungawdly codebase of horribly-written Classic ASP/VBScript.

  • (cs)

    We have a process like this where I work, but it's really nice when people actually do their own jobs. It takes awhile, but you can get to a point where the programmer gets to stop constantly being frazzled about everything and other people pick up some of the load.

    Unfortunately, we're moving backwards away from the process towards chaos - the managers have started silently dropping the "verification" part of the process and sending ANY problem straight to me, the programmer. Eugh. It doesn't help that many of the problems are caused by random people screwing around in the production database without telling anyone.

  • Dana (unregistered)

    This is a prime example of why you should ask lots of questions before you accept a new job offer. Even if you accept the position based on wrong or misleading info, you will already have a good reason to resign as soon as you're ready.

  • Flim McBoobie (unregistered)

    In a company with 30 people, one might expect there to still be cowboy coding antics. It's too bad there weren't, really, because things would have gotten done quicker at least. Rational people usually acknowledge processes in spirit, but know when process creates inefficiency. I'd say that "Eric's" bi-polar manager should have at least received one beat down for not recognizing that the process was a cumbersome, and stifling thing, and not helpful at all. So the realWTF(tm) was Eric's boss.

  • (cs)

    Apparently they know about Sarbanes Oxley (SOx) and SDLC!!!!!

  • (cs)

    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.

  • Joe (unregistered) in reply to Robz
    Robz:
    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.

  • (cs)
    RDN is a free magazine for influential readers

    WTF? Influential readers? What a sad, sad statement.

  • (cs) in reply to pitchingchris
    pitchingchris:
    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.

  • iMalc (unregistered)

    We use a Lotus Notes database for defect tracking points finger down throat. We're in the process of moving to team foundation server at the moment, but it has been taking several months...

    Structure is good, but disallowing two people from talking to each other like that is just stupid!

  • derby (unregistered) in reply to Joe

    Sarbanes was (he retired) a democrat ... not that there's anything wrong with that.

  • GrandmasterB (unregistered)

    Cowboy Coders and Anarchic Hackers?

    Sign me up!

  • (cs)

    But it's Enterprise-y, so it must be good!q

  • CynicalTyler (unregistered)

    The REAL WTF is that Eric's boss' boss didn't say "WhyTF is it taking four months to close a bug?" That kind of time schedule might work for Microsoft, but I can't see how it would work at a business of 30-some people. If you're a client paying for four month turn-around time on a simple bug, I think it's time you realized you should take your money elsewhere!

  • Steve (unregistered)

    I'm not a professional programmer, just by training, but I AM in the military, and everywhere I've ever worked has been just like this. Too much process, not enough actual work.

  • Fregas (unregistered)

    An advertisement for a more agile process if i ever saw one.

  • Chris Lively (unregistered)

    This looks like one of those processes that grew out of necessity. I've seen plenty of small shops where the programmer(s) get overloaded with "it doesn't work!" messages when, in reality, the problem was user training.

    The whole point is to insulate the programmer so that he spends his time writing code instead of being a nanny, which in this case was his bosses job. Of course, things can be taken a bit too far.

  • whicker (unregistered)

    Or,

    In my job the way this works is, the user gives a feature request his his/her boss (It would be nice if...), who escalates the feature request to the president of his/her company (it used to do this...), who in turn contacts the president of my company as a "problem with the program, it should...", which results in the president here coming in and demanding I drop everything and fix this "serious bug" and keep him informed of the issue.

    Which then takes about 2-3 weeks to actually deploy because they're "too busy" to allow the update (got a meeting right now; in use right now; sorry, I'm on my way out; oops, have to (not) call you back), probably because it's so mundane and everything is functioning that there's no reason for them to.

  • Anonymouse (unregistered)
    Prisoner of Process was originally published in Alex's DevDisasters column in the August 01, 2007 issue of Redmond Developer News. RDN is a free magazine for influential readers that provides insight into Microsoft's plans, and news on the latest happenings and products in the Windows development marketplace.
    The Real WTF
  • nonymo (unregistered)
    Prisoner of Process was originally published in Alex's DevDisasters column in the August 01, 2007 issue of Redmond Developer News. RDN is a free magazine for influential readers that provides insight into Microsoft's plans, and news on the latest happenings and products in the Windows development marketplace.

    The final irony: the Daily WTF turns into a WTF.

  • (cs)

    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

  • Ambulance Driver (unregistered)

    Anybody can make asinine rules, but that doesn't make rules themselves bad. Likewise, anybody can make asinine processes, but that doesn't make process itself bad.

    Circumventing processes may allow you to get something done faster. Running a red light will also let you get to your destination faster. Is it a good idea to do this?

    In some cases, no; if you're in a small car approaching an intersection with a blocked view, probably not a wise move to save 20 seconds.

    If you're in an ambulance and those extra 20 seconds can mean somebody's life and death, the sirens have been blaring for a block and traffic is stopped in all directions; sure, blowing off the red light is a good idea.

    You have a brain for a reason; use it.

  • PleaseReleaseMe... (unregistered)

    This is almost exactly what our managers are doing to our techies. They call it "Six Sigma" too...

  • Gareth (unregistered)

    I think the correct word would be 'Bureaucratastrophe'

  • Eric (unregistered)
    Send us your 300-600 word tale-if we print it, you'll win $100 and an RDN T-shirt![1]
    So *THAT'S* how the DailyWTF is funded in an adblock-aware 'net ;) I'm fairly certain this is a word-smithed version of a story I submitted about my old job -- I'm glad it worked out :)

    [1]http://reddevnews.com/devscope/article.aspx?editorialsid=327

  • Pirate Programmer (unregistered) in reply to iMalc

    Worked at a place like this. Programmers forbidden to discuss project with the target users, all of whom sat within 25 feet of us. Instead we had to go through the biz analysts, which interposed at least a one day delay and usually a garbled response.

    I left but friends who stayed told me the project never moved forward.

  • (cs)

    My Employer is not as bad as this, and We're a 3 billion a year HR software company.

  • Anonymous (unregistered)

    Root cause of problem: Insufficient staff.

    1. users call developers directly, several times a day, to talk about problems with the software, problems with their love live, problems with their pets' digestion - etc.

    2. No software gets developed because developers can't get any development time in, because they are busy responding to customer issues, fighting fires, resizing columns on reports, changing the color of the text on the cancel button, - while some of the real, painful issues are ignored.

    3. Manager realizes schedule is in danger - tells developers to focus on the big-picture items, developers stop answering their phones and start coding. Customer whines that problems aren't getting fixed, they're lonely, have nobody to talk to, etc.

    4. Manager creates "process" so there is an official channel through which customer feedback can flow - so customers can't say that there's no way they can feed back info. Customers feel a little better for a little while.

    5. Manager (who was incompetent to begin with - otherwise we would not be here, telling this story) realizes that they're 10 issues into their 500 issue list, and 10 days from shipping, from their original 300 day schedule. Everybody works weekends and evenings to pick up the slack - any process that may have been used to help with tracking development, now goes out the window (when it's most needed).

    6. Schedule is blown, developers are all burnt out, product ends up shipping filled with bugs. GOTO 1.

    (occasionally toss in a: #7 "We need to port this whole thing to .Net, because that will fix all our problems!"

  • (cs) in reply to Joe
    Joe:
    Robz:
    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...

  • Joe (unregistered) in reply to nwbrown
    nwbrown:
    Joe:
    Robz:
    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.

  • Tom (unregistered)

    "Republicans are known traditionally to be "business friendly" and yet they, along with a Republican president, passed this abomination of a law."

    World Com and Enron melted down. Congress was going to do something.

    I like SOX because I made money writing software for it. Yeah SOX!

  • (cs) in reply to Joe
    Joe:
    nwbrown:
    Joe:
    Robz:
    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.

  • Bill Lumbergh (unregistered)

    We need to talk about your TPS reports...

    CAPTCHA: onomatopoeia

  • (cs) in reply to nonymo
    nonymo:
    Prisoner of Process was originally published in Alex's DevDisasters column in the August 01, 2007 issue of Redmond Developer News. RDN is a free magazine for influential readers that provides insight into Microsoft's plans, and news on the latest happenings and products in the Windows development marketplace.

    The final irony: the Daily WTF turns into a WTF.

    I'm fairly sure the annals (and the old forums) will show this was in fact the First Irony.

    If a manager like this is incompetent enough, you can just code in peoples' pet features and add it as part of a completely unrelated ticket. In fact some folks I've worked with are doing that right now, though it's their manager's manager they're sliding things by.

    If not, just get the scoop from the user, show him a few prereleases to get the good word, and tell him not to say a damn word that might get it sent back to testing when it's ready for review.

  • Synonymous Awkward (unregistered) in reply to nonymo
    nonymo:
    Prisoner of Process was originally published in Alex's DevDisasters column in the August 01, 2007 issue of Redmond Developer News. RDN is a free magazine for influential readers that provides insight into Microsoft's plans, and news on the latest happenings and products in the Windows development marketplace.

    The final irony: the Daily WTF turns into a WTF.

    So you don't think it's a good idea to teach Microsoft developers about wackily stupid programming (or, in some cases, "wackily clever") and how to avoid it? Although, with the quality of comments these days, I suppose it might just make them worse.

    Also, you Americans need to vote in somebody from the other party, if only so that we can hear you whining about the evil Democrats (or whoever) for a change.

  • MikeC (unregistered)

    "RDN is a free magazine for influential readers that provides insight into Microsoft's plans, and news on the latest happenings and products in the Windows development marketplace."

    Now the Real WTF is that RDN is free if you live in the US, but $40pa if you live outside.

    For a DIGITAL version.

    Since when does it cost more to e-mail something internationally???*

    *ah yes. Since MS figured out that people would pay it.

  • (cs) in reply to Anonymous
    Anonymous:
    occasionally toss in a: #7 "We need to port this whole thing to .Net, because that will fix all our problems!"

    Ah, yes my favorite. As you're sinking into the quicksand your boss gives you a boulder to hold on to.

  • AnonymousTart (unregistered) in reply to MikeC
    MikeC:
    "RDN is a free magazine for influential readers that provides insight into Microsoft's plans, and news on the latest happenings and products in the Windows development marketplace."

    Now the Real WTF is that RDN is free if you live in the US, but $40pa if you live outside.

    For a DIGITAL version.

    Since when does it cost more to e-mail something internationally???*

    *ah yes. Since MS figured out that people would pay it.

    There are no influential readers outside the US, clearly.

  • Disgruntled Postal Worker (unregistered)

    I'm guessing the company needs to follow this complex process because (one of) their customers demand a certain project management certification.

  • Cloak (unregistered) in reply to Chris Lively
    Chris Lively:
    This looks like one of those processes that grew out of necessity. I've seen plenty of small shops where the programmer(s) get overloaded with "it doesn't work!" messages when, in reality, the problem was user training.

    The whole point is to insulate the programmer so that he spends his time writing code instead of being a nanny, which in this case was his bosses job. Of course, things can be taken a bit too far.

    I'm allright with insulating the programmer from "It doesn't work!"-error reports. But on the other hand, I find it sometimes important to be there when a bug is reported by a user. As a programmer I often know directly what this error relates to (whereas a user advocate might not even have programming practice) and can solve it in some seconds. But when this advocate comes who doesn't have a clue of how the program works or which questions should have been asked it usually takes me several days of question/response to only understand what the problem is, let alone the famous "user error" where users simply use the program the wrong way or where they don't know how the program should react. Anyway, it's the boss (well, in the end it's the customer) who pays my salary and if he thinks that with such a miserable service level he will still be there next year, well, I don't care. I cannot make this a totally better world.

  • (cs)

    This isn't a process designed to increase productivity or prevent having the developers bogged down by complaining customers.

    This is a process designed to grant job security to the Boss.

    After all, if the customers can more or less directly go to the programmers, why do they need a boss for only three of them? Maybe you can promote one to spend a little time supervising the other two. Or have somebody from higher up do that work.

  • (cs)

    This is amazingly like what just happened to me at my job.

    I support around 10 users and a dozen applications written for internal use. The old bug fix/new feature process was:

    1. The user would walk the 20 or 30 feet from their desk to my office and tell me about the bug or new feature. If a new feature, tell me how it will make their jobs easier or better. I might have to walk to their desk to have them show me how to reproduce the problem.

    2. I fix the bug or add the new feature, it's tested (first by me, then a typical user), and then put into production.

    The new process:

    1. The user has a problem or feature request. They talk to their immediate supervisor.

    2. The immediate supervisor fills out a System Work Request and submits it to their department head.

    3. The department head prioritizes the work request and forwards it to me, with copies to my supervisor and his supervisor.

    4. I go to the department head to get sufficient information to figure out what the problem or feature actually is; if the department head doesn't have the information, the department head goes to the user's immediate supervisor for more info. The user's immediate supervisor typically has to go to the user (with me tagging along the entire way) for the info.

    5. I fix the bug or add the feature, test, and put into production.

    The new process usually takes about three days to initially get the original problem/feature request from the user to me so I can start working, instead of the 10 minutes or so previously.

    In this case, it's my boss's boss who's to blame. She's a really bad micro-manager (we've had confrontations before because I didn't ask her about a field change to support a new feature request, even though she's not a developer - she's an accountant).

  • notimportant (unregistered)

    The procedure isn't too bad (similar to what we have), but the tools are, like, so medieval. Something like http://bugzilla.org or http://redmine.org would help.

  • Erik (unregistered)

    A lot of people laugh at how silly this is, but the opposite end is worse. I guarantee that poor change management is the major reasons for lots of the WTFs on this site.

    The reality is that once you grow beyond mom-and-pop stage, you have to have some sort of way to control the request avalanche. 9 times out of 10, the feature you need fixed can only be fixed by a person who has 25 other things going on simultaneously.

    I work somewhere that is transitioning out of cowboy coder world. The problem is they're putting in too much regulation, just like in this story. Our users are not used to software evaluation requests taking 3 weeks to even start. It's bad, but so is waking up at 3 AM to fix problems caused by putting untested code into production.

    I'm on the admin side, so the big buzzword for us these days is ITIL. I think that's fine as long as you pick and choose what works for your company. Too often, big companies go out and pay millions for Tivoli/Unicenter/OpenView/ITIL_compaatible_package_of_the_month and wonder why everyone's spending time filling out project reports and forms.

  • titie (unregistered) in reply to Maxim
    Maxim:
    Haven't they heard of Agile Development?

    CAPTCHA: slashbot :)

    no one has heard of agile development! Even the new guy here who just came out of 4 years of university never heard of it.

    Rather then find the right person for the job many companies would rather hire a bunch of idiots and make them follow the cluster F method.

  • Jay (unregistered) in reply to titie
    titie:
    Maxim:
    Haven't they heard of Agile Development?

    CAPTCHA: slashbot :)

    no one has heard of agile development! Even the new guy here who just came out of 4 years of university never heard of it.

    Rather then find the right person for the job many companies would rather hire a bunch of idiots and make them follow the cluster F method.

    The real test is whether your new hires are willing and able to learn the new paradigm. On graduation, I had no idea what agile development was because we had only been taught waterfall and the like. Didn't take me long to figure agile out, though, given the opportunity to work.

Leave a comment on “Prisoner of Process”

Log In or post as a guest

Replying to comment #155426:

« Return to Article