A Blast From the Past
Apr. 11th, 2006 02:30 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
davidschrothOne of my co-workers, who is taking a "voluntary" retirement, unearthed the following. It's a little late, but still worth posting.
From: MIT (Milestone Improvement Team) Date: April 1, 1988
To: All System Control Software personnel Loc: Rsvl
RE: Jam-In Process Guide
In order to facilitate the timely integration and field release of marginally functional EXEC code, the MIT proposes the Jam-In Process (JIP) program, effective immediately. To orient all staff to the new procedures necessary to implement JIP, the following memo will outline the new process. As soon as possible, MIT will issue the new 14 volume Process Guide.
All new features and fixes developed in SCS must conform to the following process.
1. Requirements
Have your manager explain what you are expected to implement in this project. Make sure he/she gives you an ironclad Impossible date of Integration (IDI). Argue vehemently for a two week extension.
2. Coding Step
Write your code. Place TCF in a file with an ACR that makes it impossible for your manager to get at it, in case she/he wants to jam-in your code prior to your appointed IDI.
3. Testing
Try to assemble your code and make a boot tape. If your boot tape actually comes up clean, boot to SYS FIN and declare testing complete. Do NOT document your test cases or their actual results. Remember that discovering and fixing bugs takes up valuable time and can only cause your dates to slip. Besides, what's Continuation for?
4. Integration
Fill out your RJI (Request to Jam In) form and have your manager sign it in disappearing ink. Then sit on your TCF until someone decides when and how to shoe-horn your code into the EXEC so that a minimum of other features are broken in the process.
5. Receive SOR and STFR
By now, someone should come by with your Statement of requirements (SOR). If it consists of more than one ambiguously worded paragraph, make sure to disconform (reject) it immediately. Your SOR must be so vaguely worded that your previously written TCF will definitely conform to it; so will a half-dozen other features (so much the better).
The STFR should also appear on your desk (hopefully befre the SOR arrives). File it somewhere deep in the bowels of your broadside, especially if it suggests the project be cancelled or if it proposes a coding strategy that conflicts with your TCF.
6. Write SFD
While killing time waiting for your RJI, quickly jot off your Software Feature Description (SFD). The following headings are mandatory. Make sure to call your SFD "revision Q".
a) Overview
Briefly describe, in the most general terms possible, what your feature is supposed to do. Do not be specific -- if customers figure out your code doesn't really do that function, they're only going a SUR against the feature.
b) Requirements
Make some veiled reference to the SOR or some management memo that vaguely pertains to your feature. Better still, write "TBD".
c) Changed Interfaces
Allude to multitudinous changed interfaces, error messages, console messages, ECL changes, etc. Say the details haven't been decided yet and will be provided in a later revision of the SFD, namely "revision Q".
d) Changed Documents
Of course your feature will require massive updates to user manuals. But hey, we can't keep track of thousands of UP documents -- we're programmers, not tech writers! Mention a few manuals and let LSPI get back to you.
e) Designated Scapegoat
List a primary and back-up scapegoat for your project. The purpose of this is to give managers someone to blame when your milestones start to slip. Remember: when the fingerpointing starts, you don't want anyone yelling at you! Ideal targets are someone working on a project that conflicts with yours, or that you are dependent upon.
When you are done with the SFD, submit it to the Document Review Board (DRB) for review. The DRB chairman, Lewis Cole, will check it for incorrect spelling and the existence of hyphens, then officially conform the document. He will enter the SFD into the PCR data base and lock the entry. He will also archive the document on s6 (in the archive file CIRCULAR*FILE) for later use.
7. Write SFTD
While waiting for official word on your SFD conformance, quickly dash off a Software Feature Technical Description (SFTD). The following headings are mandatory. make sure this document is also "revision Q".
a) Functional Areas Affected
Write "None". We don't have functional areas anymore.
b) Technical Description
Create some documentation header blocks for all your new subroutines and include them in the SFTD. Go back to your TCF and insert the documentation there, too. If you change any data structures, call out in painful detail every bit you are using and add some ambiguous explanation of what this structure now means. It helps if the new data definition insures future random stores.
c) Testing Considerations
Insist you will consider testing your feature. Include every possible hardware configuration in your test plan, especially those your feature can't even run on.
d) IDI
Mention your IDI. This will insure that all problems related to your feature will disappear by management fiat so you can make your integration milestones. If, for some reason, your dates have already slipped, make some surly comments about your primary and back-up scapegoats.
Submit the SFTD to the DRB for the usual treatment.
8. Final RJI
At this point, your manager should come to your desk, wave a piece of paper in your face containing all your milestones, and demand to know what's holding things up. Unlock your TCF, give him/her the file.element-name (or PCR entry number, if S6 has stayed up long enough to get it entered), and let him/her jam it in. If you make your IDI, you will get an attaboy and a pay reduction; if you slipped your dates, you will immediately go into the pool for the next 3 years.
I expect all SCS personnel to assist in making a smooth and timely transition to this new process. Happy New Fiscal Year (old style calendar -- oh why did we ever change ?!).
Martin Bulgerin, MIT chairman
-----------------------------
(the bottom line)
As it turns out, the joke was on us - one or more managers saw the memo, liked it, and implemented it.
From: MIT (Milestone Improvement Team) Date: April 1, 1988
To: All System Control Software personnel Loc: Rsvl
RE: Jam-In Process Guide
In order to facilitate the timely integration and field release of marginally functional EXEC code, the MIT proposes the Jam-In Process (JIP) program, effective immediately. To orient all staff to the new procedures necessary to implement JIP, the following memo will outline the new process. As soon as possible, MIT will issue the new 14 volume Process Guide.
All new features and fixes developed in SCS must conform to the following process.
1. Requirements
Have your manager explain what you are expected to implement in this project. Make sure he/she gives you an ironclad Impossible date of Integration (IDI). Argue vehemently for a two week extension.
2. Coding Step
Write your code. Place TCF in a file with an ACR that makes it impossible for your manager to get at it, in case she/he wants to jam-in your code prior to your appointed IDI.
3. Testing
Try to assemble your code and make a boot tape. If your boot tape actually comes up clean, boot to SYS FIN and declare testing complete. Do NOT document your test cases or their actual results. Remember that discovering and fixing bugs takes up valuable time and can only cause your dates to slip. Besides, what's Continuation for?
4. Integration
Fill out your RJI (Request to Jam In) form and have your manager sign it in disappearing ink. Then sit on your TCF until someone decides when and how to shoe-horn your code into the EXEC so that a minimum of other features are broken in the process.
5. Receive SOR and STFR
By now, someone should come by with your Statement of requirements (SOR). If it consists of more than one ambiguously worded paragraph, make sure to disconform (reject) it immediately. Your SOR must be so vaguely worded that your previously written TCF will definitely conform to it; so will a half-dozen other features (so much the better).
The STFR should also appear on your desk (hopefully befre the SOR arrives). File it somewhere deep in the bowels of your broadside, especially if it suggests the project be cancelled or if it proposes a coding strategy that conflicts with your TCF.
6. Write SFD
While killing time waiting for your RJI, quickly jot off your Software Feature Description (SFD). The following headings are mandatory. Make sure to call your SFD "revision Q".
a) Overview
Briefly describe, in the most general terms possible, what your feature is supposed to do. Do not be specific -- if customers figure out your code doesn't really do that function, they're only going a SUR against the feature.
b) Requirements
Make some veiled reference to the SOR or some management memo that vaguely pertains to your feature. Better still, write "TBD".
c) Changed Interfaces
Allude to multitudinous changed interfaces, error messages, console messages, ECL changes, etc. Say the details haven't been decided yet and will be provided in a later revision of the SFD, namely "revision Q".
d) Changed Documents
Of course your feature will require massive updates to user manuals. But hey, we can't keep track of thousands of UP documents -- we're programmers, not tech writers! Mention a few manuals and let LSPI get back to you.
e) Designated Scapegoat
List a primary and back-up scapegoat for your project. The purpose of this is to give managers someone to blame when your milestones start to slip. Remember: when the fingerpointing starts, you don't want anyone yelling at you! Ideal targets are someone working on a project that conflicts with yours, or that you are dependent upon.
When you are done with the SFD, submit it to the Document Review Board (DRB) for review. The DRB chairman, Lewis Cole, will check it for incorrect spelling and the existence of hyphens, then officially conform the document. He will enter the SFD into the PCR data base and lock the entry. He will also archive the document on s6 (in the archive file CIRCULAR*FILE) for later use.
7. Write SFTD
While waiting for official word on your SFD conformance, quickly dash off a Software Feature Technical Description (SFTD). The following headings are mandatory. make sure this document is also "revision Q".
a) Functional Areas Affected
Write "None". We don't have functional areas anymore.
b) Technical Description
Create some documentation header blocks for all your new subroutines and include them in the SFTD. Go back to your TCF and insert the documentation there, too. If you change any data structures, call out in painful detail every bit you are using and add some ambiguous explanation of what this structure now means. It helps if the new data definition insures future random stores.
c) Testing Considerations
Insist you will consider testing your feature. Include every possible hardware configuration in your test plan, especially those your feature can't even run on.
d) IDI
Mention your IDI. This will insure that all problems related to your feature will disappear by management fiat so you can make your integration milestones. If, for some reason, your dates have already slipped, make some surly comments about your primary and back-up scapegoats.
Submit the SFTD to the DRB for the usual treatment.
8. Final RJI
At this point, your manager should come to your desk, wave a piece of paper in your face containing all your milestones, and demand to know what's holding things up. Unlock your TCF, give him/her the file.element-name (or PCR entry number, if S6 has stayed up long enough to get it entered), and let him/her jam it in. If you make your IDI, you will get an attaboy and a pay reduction; if you slipped your dates, you will immediately go into the pool for the next 3 years.
I expect all SCS personnel to assist in making a smooth and timely transition to this new process. Happy New Fiscal Year (old style calendar -- oh why did we ever change ?!).
Martin Bulgerin, MIT chairman
-----------------------------
(the bottom line)
As it turns out, the joke was on us - one or more managers saw the memo, liked it, and implemented it.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2006-04-11 10:06 pm (UTC)no subject
Date: 2006-04-11 10:17 pm (UTC)no subject
Date: 2006-04-11 10:56 pm (UTC)Whenever I think that our shop has a long way to go, I'll read this and feel better. Thank you. :)
no subject
Date: 2006-04-12 05:23 pm (UTC)If summarily executed == promoted, then yes, said managers were summarily executed.
Strangely enough, we actually got pretty good, process wise, around the time of that joke. But each new manager we've gotten has put their stamp on the organization by gutting more of the pretty good process we developed.
no subject
Date: 2006-04-12 12:32 am (UTC)no subject
Date: 2006-05-10 05:17 am (UTC)