Comment On Classic WTF: Prisoner of Process

I think bored employees create these procedures just so they have something to pass the time until retirement.

(frist)

Captcha: abigo (one of the guys in the fiery furnace)

Eric was used to overhearing the data processors' conversations. They all worked in a small room and sat no more than six feet from each other.

TRWTF.

Every single f*cking business... Am I the only one who thinks it's moronic to put everyone in the same room? I feel like I'm taking crazy pills here. Is this in the college curriculum somewhere for business management students? Put everyone in the same room regardless of profession; developers thrive on noise. I wonder if the CEO's house is arranged like that. He probably has the toilet bowl next to the stove and the bed by the front door.

"I'm sorry, I know you're new here, but we all really need to follow procedure : please involve a fucking wooden table."

FTFY

The Nerve:

I think bored employees create these procedures just so they have something to pass the time until retirement.

(frist)

Captcha: abigo (one of the guys in the fiery furnace)

It's actually been my experience that stuff like this is created in order to achieve some degree of ISO / CMMi certification - something that's becoming more necessary, especially if your firm does a lot of business with the government.

With that said, I have yet to see an ISO / CMMi compliant process implemented in a way that isn't a gigantic WTF. The stuff described in this article is pretty tame, comparatively.

Captcha: nobis (dona nobis process)

Couldn't get frist post, as the comment resolution process took too long to complete.

Comment #182749384701 seriously considered posting.

I don't have anything useful to say, but I can share this, which I'm sure you'll be enthralled by...

Captcha: luctus

Yes, and the people that created the compliance process were also government employees trying to drag out their time to retirement.

I would like to thank them right now for getting me involved in their self-inflicted hell.

Captcha: ingenium (Avatar?)

Not a prisoner I'm a free man,
And my code is my own now.
Don't care, where the past was,
I know where I'm going...Out!

"Upon encountering a potential program defect, the user shall immediately cease performing any further actions in the application and shall e-mail his or her user advocate (i.e. Eric's boss)."

Report bugs when you see them. Not a WTF.

"The user advocate shall immediately go to the user's workstation (which always required him to pass by Eric's) and then meet with the user (which always happened within arms-reach of Eric)."

Get someone on the damn bug ASAP. Not a WTF.

"After discussing the potential defect, the user advocate shall send an e-mail to a defect analyst describing the potential defect and requesting that an issue be created."

Make sure the damn bug is worth submitting and isn't user error. Not a WTF.

"The defect analyst shall then create an issue in the defect database (an Excel spreadsheet), assign a defect number (best guess at creating a unique, 12-digit random number) and fill out a defect report (a Word document on a network share)."

Record the damn bug. Not a WTF.

"During their weekly defect-prioritization meeting, the development manager (also Eric's boss) and the defect analyst (the only two attendees) shall meet and assign defects to one of the three programmers."

Assign the damn bug to someone. Not a WTF.

"The defect analyst shall then update the defect database (both the spreadsheet and the document) with the assigned programmer and e-mail the programmer a copy of the issue report."

Record who is assigned to the damn bug. Not a WTF.

"After the programmer notifies the defect analyst of the resolution, the defect analyst shall notify the QA manager (also Eric's boss) during their weekly proposed-defect-resolution meeting (again, with only two attendees)."

Make sure the QA dpt. knows there's a bug fix they need to check. Not a WTF.

"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."

If it don't fix the damn bug, yell at the programmer to fix it. Not a WTF.

"Once the resolution is deployed, the QA manager shall request that the defect analyst close the issue at the next weekly defect-prioritization meeting."

Keep your bug list up to date. Not a WTF.



Sure, their specific (long winded) implementation is dumb but I don't see anything wrong with the process itself. Lots of room for improvement. Yet, at its core, this seems pretty reasonable.

TRWTF: Your company has all these "procedures" ostensibly designed to make your product more robust, but then part of the procedure is to modify a spreadsheet on a shared drive with no versioning and no way to tell who modified it.

the real WTF:
issue #182749384701 ??

Thats a whole lotta bugs! Closing out 1 issue every 4 months... thats... er... 60 BILLION years!

Bob:

the real WTF:
issue #182749384701 ??

Thats a whole lotta bugs! Closing out 1 issue every 4 months... thats... er... 60 BILLION years!

The number is random.
"best guess at creating a unique, 12-digit random number"

Well, I know MY creativity thrives on endless piles of bureaucratic nincompoopery...

I never get tired of hearing about companies that use a shared excel spreadsheet for critical business processes.

I take it, they've never heard of Jira or other similar tools?

Came here to say this!

Developers and Programmers just want to roam free, unfettered by Change Control and process.

The problem with this is you have no audit trail, record of change, issue management, opportunities to review cause and effect.... I've see the effects on the business and stabilty caused by devs operating without controls and audit. It's not pretty and does nothing to promote improved code stabilty, functionality and uptime.

Good process should be followed.

The problem however, as shown in this case, is that poor implementation of good processes & practices can have a detremental effect on the very thing it is there to solve.

I agree with Drew: there's nothing inherently wrong with the process, but it needs serious streamlining. Well, that and something like bugtraq :)

The only wtf is that the process takes a week or so to complete, no doubt due to time sat doing nothing whilst the managers have their meetings.

Apart from that it all sounds pretty sensible.

Apart from the spreadsheet that is.

Can't someone put it in an access database?

Agreed Drew.

Forget the Excel spreadsheet. The only real way to manage software is by writing numbers on a dry-erase board with a "DO NOT ERASE" notation.

Captcha: luctus (hybrid lettuce and cactus).

The thing about process is there's no such thing as "one size fits all". It sounds like the management at Eric's company have taken a process designed for a much bigger company and implemented it as-is, probably whilst patting themselves on the back and congratulating themselves for their rigor. Of course, good management knows that a process has to fit the business; not just in terms of size but in terms of staff, culture, the nature of the product being developed and a whole host of other factors. If you're not prepared to tailor the process to your own environment then there's little point in even having it (and this is something I've encountered at ISO 9001 audits - it's not enough to have a process, you need to justify why that process is relevant and what benefits it brings).

Welcome to Vogon Inc.

Anonymous:

The thing about process is there's no such thing as "one size fits all". It sounds like the management at Eric's company have taken a process designed for a much bigger company and implemented it as-is, probably whilst patting themselves on the back and congratulating themselves for their rigor. Of course, good management knows that a process has to fit the business; not just in terms of size but in terms of staff, culture, the nature of the product being developed and a whole host of other factors. If you're not prepared to tailor the process to your own environment then there's little point in even having it (and this is something I've encountered at ISO 9001 audits - it's not enough to have a process, you need to justify why that process is relevant and what benefits it brings).

Yeah, at my company the software team consists of COBOL and Java programmers. We have the same exact process as the COBOL programmers.

Anonymous:

... implemented it as-is, probably whilst patting themselves on the back and congratulating themselves for their rigor.

and giving themselves sizable bonuses.

Anonymous:

The thing about process is there's no such thing as "one size fits all". It sounds like the management at Eric's company have taken a process designed for a much bigger company and implemented it as-is

We have a winner!

"best guess at creating a unique, 12-digit random number"

Hrm?

DOA:

Put everyone in the same room regardless of profession; developers thrive on noise.

This is the guiding principle behind our cube-farm layout. On one side we have the obnoxious sneezing bitch, and on the other we have the Print Room.

Since the company is still using a 70's-vintage mainframe, all output comes from the Print Room. Soft copies are a radical fantasy; it scares the dinosaurs. Instead, we have entire tables (wooden ones no less) covered in massive stacks of whatever it is that the mainframe spits out. They literally use 20 reams of paper every morning, just for that. The Print Room has a pair of enormous printers which run all day, every day. It sounds like a fucking 747 is idling in the room. The A/C in there is always blasting to fight the heat emitted by said 747, so the lady monitoring the printers gets cold and props the door open. You can see the devs growing more irritated by the minute.

Agreed. Process is not bad. Process that helps to track and prioritize is a good thing. I do believe though that process that intentionally limits direct communication options is wrong.

Drew:

...
Sure, their specific (long winded) implementation is dumb but I don't see anything wrong with the process itself. Lots of room for improvement. Yet, at its core, this seems pretty reasonable.

So what you're saying is that the overall process has some sensible basis. But Anonymous has spelled out exactly why this is inadequate:

Anonymous:

The thing about process is there's no such thing as "one size fits all"... Of course, good management knows that a process has to fit the business; not just in terms of size but in terms of staff, culture, the nature of the product being developed and a whole host of other factors. If you're not prepared to tailor the process to your own environment then there's little point in even having it...

Says it all. It's not that the process is inherently wrong, it's that the process is wrong for this company. That's still a major WTF in my book.

His old workplace had been a haven for cowboy coders and anarchic hackers, where the only semblance of consistency was in everyone's preference to modify code directly in production.

I see that Eric has worked at Yahoo! as well then.

Ken:

Drew:

...
Sure, their specific (long winded) implementation is dumb but I don't see anything wrong with the process itself. Lots of room for improvement. Yet, at its core, this seems pretty reasonable.

So what you're saying is that the overall process has some sensible basis. But Anonymous has spelled out exactly why this is inadequate:

Anonymous:

The thing about process is there's no such thing as "one size fits all"... Of course, good management knows that a process has to fit the business; not just in terms of size but in terms of staff, culture, the nature of the product being developed and a whole host of other factors. If you're not prepared to tailor the process to your own environment then there's little point in even having it...

Says it all. It's not that the process is inherently wrong, it's that the process is wrong for this company. That's still a major WTF in my book.

No, you've got it wrong. This process is stupid. It's one small step away from me keeping a typewriter on my desk and carbon paper in my filing cabinet. Actually, the hard-copy solution would probably be more usable.

A meeting will be scheduled later this week to nominate members for a blue ribbon committee to select a panel to propose a process for choosing a committee to develop a manual to explain how to document a process for process-efficiency analysis.
Said meeting will be scheduled, shortly after blue-ribbon nomination standards have been benchmarked.

Drew:

"Upon encountering a potential program defect, the user shall immediately cease performing any further actions in the application and shall e-mail his or her user advocate (i.e. Eric's boss)."

Report bugs when you see them. Not a WTF.

"The user advocate shall immediately go to the user's workstation (which always required him to pass by Eric's) and then meet with the user (which always happened within arms-reach of Eric)."

Get someone on the damn bug ASAP. Not a WTF.

"After discussing the potential defect, the user advocate shall send an e-mail to a defect analyst describing the potential defect and requesting that an issue be created."

Make sure the damn bug is worth submitting and isn't user error. Not a WTF.

"The defect analyst shall then create an issue in the defect database (an Excel spreadsheet), assign a defect number (best guess at creating a unique, 12-digit random number) and fill out a defect report (a Word document on a network share)."

Record the damn bug. Not a WTF.

"During their weekly defect-prioritization meeting, the development manager (also Eric's boss) and the defect analyst (the only two attendees) shall meet and assign defects to one of the three programmers."

Assign the damn bug to someone. Not a WTF.

"The defect analyst shall then update the defect database (both the spreadsheet and the document) with the assigned programmer and e-mail the programmer a copy of the issue report."

Record who is assigned to the damn bug. Not a WTF.

"After the programmer notifies the defect analyst of the resolution, the defect analyst shall notify the QA manager (also Eric's boss) during their weekly proposed-defect-resolution meeting (again, with only two attendees)."

Make sure the QA dpt. knows there's a bug fix they need to check. Not a WTF.

"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."

If it don't fix the damn bug, yell at the programmer to fix it. Not a WTF.

"Once the resolution is deployed, the QA manager shall request that the defect analyst close the issue at the next weekly defect-prioritization meeting."

Keep your bug list up to date. Not a WTF.



Sure, their specific (long winded) implementation is dumb but I don't see anything wrong with the process itself. Lots of room for improvement. Yet, at its core, this seems pretty reasonable.

I'll see this comment and raise it one more. If this company moved to a more formal issue tracking system than a spreadsheet and streamlined steps 7 and 8 by letting issues flow back and forth between development and QA without separate meetings, I think this would become a fine small company process.

The key mistake many (most?) companies make is that they write processes and then leave them set in stone, instead of regularly revisiting the process to see how it's performing (CMM Level 4) and how it can be improved (CMM Level 5).

<i>
Keep your bug list up to date. Not a WTF.



Sure, their specific (long winded) implementation is dumb but I don't see anything wrong with the process itself. Lots of room for improvement. Yet, at its core, this seems pretty reasonable.</i>

<<snip>>

Umm yeah.. so Drew, what county government do you work for? LOL Seriously, in a small company this creates work that doesn't need to exist

Captcha: valetudo - A guy named Udo who parks cars...

As, yes, TRWTF is using an Excel speadsheet as a "defect database."

Drew:

Report bugs when you see them. Not a WTF.

Get someone on the damn bug ASAP. Not a WTF.

Make sure the damn bug is worth submitting and isn't user error. Not a WTF.

Record the damn bug. Not a WTF.

Assign the damn bug to someone. Not a WTF.

Record who is assigned to the damn bug. Not a WTF.

Make sure the QA dpt. knows there's a bug fix they need to check. Not a WTF.

If it don't fix the damn bug, yell at the programmer to fix it. Not a WTF.

Keep your bug list up to date. Not a WTF.



Sure, their specific (long winded) implementation is dumb but I don't see anything wrong with the process itself. Lots of room for improvement. Yet, at its core, this seems pretty reasonable.

I think the problem is more that they invented a process that takes months to get a bug resolved, when there are countless examples of bug-tracking software which would allow this to happen in a time scale measured in hours or days, depending on how bug-swatting was ranked in the priorities list, and meet all of the requirements you list above.

the defect database (an Excel spreadsheet)

Well, there's your problem!
Write 100 times on the board:
A spreadsheet is not a database.
A spreadsheet is not a database.
A spreadsheet is not a database.

Now if a spreadsheet were a database we'd have an entirely different situation. Since defect == Excel, a defect database == an Excel spreadsheet.

CoderDan:

Drew:

<<snip>>

Keep your bug list up to date. Not a WTF.


Sure, their specific (long winded) implementation is dumb but I don't see anything wrong with the process itself. Lots of room for improvement. Yet, at its core, this seems pretty reasonable.

Umm yeah.. so Drew, what county government do you work for? LOL Seriously, in a small company this creates work that doesn't need to exist

Captcha: valetudo - A guy named Udo who parks cars...

You're missing the point. There is nothing wrong with the process, it's the implementation that sucks. Every decent bug tracking software automatically implements almost all of these steps for you. (except maybe for point 2)

FQFY: Fixed your quote for you.

Ralph:

the defect database (an Excel spreadsheet)

Well, there's your problem!
Write 100 times on the board:
A spreadsheet is not a database.
A spreadsheet is not a database.
A spreadsheet is not a database.

Now if a spreadsheet were a database we'd have an entirely different situation. Since defect == Excel, a defect database == an Excel spreadsheet.

But you can access Excel through ODBC.

bjolling:

Every decent bug tracking software automatically implements almost all of these steps for you. (except maybe for point 2)

When we have bugs that are bothering a user, tech support IMs a tester, the tester immediately tests it, if it's verified the tester immediately files a bug report then IMs a developer and asks them to look into it. The key words being "IM" and "immediately" - regardless of the size of the company, I'd say a process that artificially inflates the time it takes to fix a simple bug by orders of magnitude is a WTF.

Though our company *does* have a rule about tech support not talking directly to developers to ask them to fix anything, presumably for that exact reason (to make sure they wouldn't bother us constantly about things that weren't bugs). Once a bug has been verified and is in the bug-tracking system, *then* of course they're free to talk to us about it all we like.

neminem:

bjolling:

Every decent bug tracking software automatically implements almost all of these steps for you. (except maybe for point 2)

When we have bugs that are bothering a user, tech support IMs a tester, the tester immediately tests it, if it's verified the tester immediately files a bug report then IMs a developer and asks them to look into it. The key words being "IM" and "immediately" - regardless of the size of the company, I'd say a process that artificially inflates the time it takes to fix a simple bug by orders of magnitude is a WTF.

Though our company *does* have a rule about tech support not talking directly to developers to ask them to fix anything, presumably for that exact reason (to make sure they wouldn't bother us constantly about things that weren't bugs). Once a bug has been verified and is in the bug-tracking system, *then* of course they're free to talk to us about it all we like.

I strongly believe the keywords "IM" and "immediately" are precisely what a company has to move *away* from as it matures its software development processes and moves out of a cowboy coder mentality -- that type of urgency has to be reserved for defects that truly are critical. If you've got anything resembling an adequate QA and release process, you're not rolling out new software releases on an hourly or even daily basis, so all "IM" and "immediately" create are not-so-useful distractions.

Now, that being said, I'm thinking in terms of product development with external customers; I'll allow that internal development in a small company *might* legitimately have a faster release cycle.

[quote user="Uncle Al]I strongly believe the keywords "IM" and "immediately" are precisely what a company has to move *away* from as it matures its software development processes and moves out of a cowboy coder mentality -- that type of urgency has to be reserved for defects that truly are critical. If you've got anything resembling an adequate QA and release process, you're not rolling out new software releases on an hourly or even daily basis, so all "IM" and "immediately" create are not-so-useful distractions.
[/quote]

Very true. So you let your customers enter their own bugs, and developers don't look at them until someone in QA has verified that there's actually a bug there. No IM, no "immediately" and things are sped up another notch, meaning more time that developers can spend developing, huzzah.

[quote user="neminem"][quote user="bjolling"]...if it's verified the tester immediately files a bug report then IMs a developer and asks them to look into it...[/quote]

So, the testers are your boss? That's part of what my boss does: prioritize and assign issues.

DOA:

Eric was used to overhearing the data processors' conversations. They all worked in a small room and sat no more than six feet from each other.

TRWTF.

Every single f*cking business... Am I the only one who thinks it's moronic to put everyone in the same room? I feel like I'm taking crazy pills here. Is this in the college curriculum somewhere for business management students? Put everyone in the same room regardless of profession; developers thrive on noise. I wonder if the CEO's house is arranged like that. He probably has the toilet bowl next to the stove and the bed by the front door.

The IT department at my company (both developers and the admins) are in a separate building (which is also our data center). At my former employer, I was the lone IT person (both developer AND admin), and seated next to the customer service department.

Peace is nice for getting work done, but sitting next to everyone was nice for knowing what needed to BE done.

I can run SQL against an excel worksheet thus it is in fact a very slow database! But then again, so is a csv file.

I've noticed that when most people tell you "there's no process," what they really mean is, "I don't want to do any work, and I don't need you making me look bad over here."

Even when a clear and efficient bug submission/assessment process is in place, the company's "Big-shots" always end-up overruling them since they are so special and important. This, of course, renders the overall efficiency of the process from "Ok" to "Chaotic Hell".

I think I feel a poo coming on...

CnC:

I can run SQL against an excel worksheet thus it is in fact a very slow database! But then again, so is a csv file.

Atomic updates? Commit / Rollback? Journals for recovery? Referential integrity? Primary key constraints? Indexes?

Everyone who seriously considers Excel a database, kindly do the world a favor and go play in traffic.

Unless you consider paper in a filing cabinet also a database.

Drew:

Sure, their specific (long winded) implementation is dumb but I don't see anything wrong with the process itself. Lots of room for improvement. Yet, at its core, this seems pretty reasonable.

The implementation is a massive WTF in itself. This needs a complete automation overhaul, preferably using a commercial bug tracking tool. A single tool should take the place of:

-initial user email to advocate
-advocate email to defect analyst
-Excel spreadsheet
-defect report
-defect prioritization meeting
-defect analyst email to programmer
-programmer resolution notification to defect analyst
-defect analyst resolution notification to QA manager
-QA manager problem notification to dev manager
-dev manager problem notification to defect analyst
-defect analyst problem notification to programmer
-QA manager request to close issue
-defect analyst closing issue

Good lord. Having a change control board can actually make sense on a project with just 30 developers, but it really doesn't sound like that's what's going on. I work for a big corporation with mature processes and projects that, by nature, need a fairly strict degree of control -- and we're not anywhere near that anal-retentive about stuff. But then, perhaps it's because we use change control to help us keep track of what we're doing, rather than as obscure rituals performed to appease a mysterious God of Quality.