(A true story.)
Philip (President): Our factory is underutilized by 10%. Either we start building more of our backlog or we lay people off. I'd rather keep everyone busy, build inventory, and get ahead of the curve before the busy season. How can we do that?
Lee (Operations Manager): Company policy restricts us from building more than 3 months of backlog. If you just change that to 4 months, we'll have plenty of work.
Philip: Done. Now how do we implement that?
Lee: I'm not really sure. I think we'd have to change a setting in the legacy software.
David (IT Director): No problem. It's probably one line of code in our core routine. Fill out a ticket and submit it to IT Services.
Judy (IT Admin): I'm assigning this request Ticket# 129281. But it still needs the section on Business Impact completed and Director approval.
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.
David: What's the status of 129281?
Judy: It's the first Enhancement in the Developer Queue, after 14 Bug Reports.
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". I unit tested this successfully and ran 2 batch test runs. The Operations work queue increased 10% as expected. This is good to go. I just submitted it to Code Review and moved in to Homer for User Acceptance Testing.
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: Fuck that shit.
Shirley: That may very well be true. But since you were assigned ORP572, you are responsible for fixing preexisting errors that violate new company policy. I cannot promote this as it is.
2 hours later.
Ed: OK, done. I just resubmitted it to Code Review.
Julie (IT Testing): Homer is not available for User Acceptance Testing because Fred is running a controlled test for month-end accounting close. Use Marge instead.
Ed: I don't have access to Marge.
Julie: Then contact Joe in IT Security. He'll get you permissions.
2 hours later.
Joe (IT Security): I cannot grant you access to Marge without David's signature. He's out of town. Can this wait until Monday?
Ed: I don't think so. Philip wants this right away. Get him to grant access.
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.
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:
Ed: I renamed the Parameters record "MonthsOfDemand" to "SelectedMonthsOfBacklogDemand" and added Module PAR634 to maintain that record and its audit trail. I have submitted it to Code Review.
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:
Philip: David, tell Tony to move Ed's program to production immediately.
David: Yes sir.
Total elapsed time: 6 days.
Lines of mission critical code changed: 1.
Bytes of mission critical code changed: 1.
Excedrin eaten: 24
Pissed off hours spent on Hacker News: 14.