Very little of this seemed unreasonable, with the exception of:
> Pissed off hours spent on Hacker News: 14.
I hope it was an exaggeration, but also well within the realm of possibility.
This is the only bit that looked like a problem to me:
David: It's for Philip. It we don't do this right away, we'll have to have a layoff.
Judy: OK, then I'll fill out that section myself and put this on the fast track.
2 days later.
If humans understand a change that's in-progress to avoid layoffs, then there's no reason to effect layoffs dogmatically because of a policy which is relying on a laggy process.
There's good stuff in here too:
David: Forget the queue. Mark it urgent and send it to Ed immediately.
1 hour later.
Ed (programmer): On line 1252 of Module ORP572, I changed the hard-coded variable MonthsOfBacklog from "3" to "4"...
Shirley (Code Review): It is now against company policy to have any hard-coded variables. You will have to make this a record in the Parameters file. Also, there are 2 old Debug commands, an unassigned variable warning message, and a hard-coded Employee ID that will all have to be fixed before this module can be moved to production.
Ed: I don't have access to Marge.
Julie: Then contact Joe in IT Security. He'll get you permissions.
2 hours later.
Shirley: Your new Parameters record "MonthsOfDemand" needs a better name. The offshore programmers won't understand what this means. Also, it should have an audit trail of changes.
And more bad stuff
Ed: What policy is that?
Shirley: It's not exactly written down anywhere. The offshore team is 3 months late updating the wiki, but I assure you, all new Parameter records must satisfy new naming requirements and keep audit trails.
1 day later:
Why would a variable rename take 1 day, perhaps that disgruntled time on HN?
This is bad on both the process-side as well as execution. It shouldn't take 2 days to write a test plan as unnecessary as it may seem. Perhaps that's another day spent on HN?
Tony (IT Testing): I see 129281 on Marge, but I have no Test Plan.
Ed: Just run it the old way and the new way and note the increase in the total on the WorkOrdersHours report.
Tony: That's your test plan? No. This affects everything in the factory. I have to have user selected Test Cases, Expected Results, documented Test Runs, and user sign-off.
2 days later:
I've read about bad processes and have even worked in worse environments. This story is nowhere near as bad as it gets. At multiple points problems were solved in <= 2 hours by humans, presumably overriding any silly processes.
> Why would a variable rename take 1 day, perhaps that disgruntled time on HN?
When I work in an environment without bullshit I love my job and get lots done.
When I work in an environment like this I hate my job and have no motivation to finish two ticket in the time I could finish one, because it would means twice as much bullshit.
The thing is, there's very little pure bullshit here: only some unexpected requirements (which do make sense), a bunch of bumps that did have human workarounds/shortcuts, etc. The urgency of the whole thing was synthetic though, which upon recognizing why it's being done could wait until it gets done--waiting some extra days shouldn't necessitate firing people you want to keep.
The other strange part is the "6 days to change 1 line of code" - yes, this one line of code took six days to change. But the actual time investment of each person, even the programmer involved, is much less than those six days. Probably lots of other lines got changed in those days by those same people, including the author, so you're not really offering any useful velocity measurement by pointing to this one line that takes six days to change. (And presumably that's not even true if Ed touched some other lines in ORP572.)
> Pissed off hours spent on Hacker News: 14.
I hope it was an exaggeration, but also well within the realm of possibility.
This is the only bit that looked like a problem to me:
If humans understand a change that's in-progress to avoid layoffs, then there's no reason to effect layoffs dogmatically because of a policy which is relying on a laggy process.There's good stuff in here too:
And more bad stuff Why would a variable rename take 1 day, perhaps that disgruntled time on HN?This is bad on both the process-side as well as execution. It shouldn't take 2 days to write a test plan as unnecessary as it may seem. Perhaps that's another day spent on HN?
I've read about bad processes and have even worked in worse environments. This story is nowhere near as bad as it gets. At multiple points problems were solved in <= 2 hours by humans, presumably overriding any silly processes.