[ctrager]

LOL and true to my experience. In the 80's was a United Airlines employee on a project where Arthur Anderson (aka Accenture) was the consultant. The project included approximately 75 entry level AA programmers that were brought to the office on two big buses. My job was to write specs for them. The specs had to be 100% detailed, every "if", every "loop", except that I had to follow the AA methodology and write the entire program basically in flowchart form. Pencil and paper. The spec was a looseleaf notebook of diagrams. The spec would then be stored in a box, like, the kind you would use for moving, and the boxes put into a storage room. If I needed to change a spec, an AA employee would have to climb the piles of boxes to find my box, and then I would use actual scissors, actual glue, to make the change.

It. Was. Insane.

[ctrager]

Another golden memory of that project was when I was given the assignment to meet with users - accounting people - on screens for approving tax payments. It was kinda a big deal for me at that stage in my career, to even talk to users. So, I meet with these guys and I introduce the topic, and they go, "What are you talking about? What do you mean 'approving'? They are taxes. We HAVE to pay them"

[b0afc375b5]

I'm not sure I get what you're trying to say here. Yes, the company has to pay them but someone has to look at the numbers so that the company doesn't overpay or underpay.

[nazka]

I’m not even sure insane match what you just described at that point.

Now I know someone that do that for the software for subparts of nuclear reactors and it’s exactly all the same. The specs, the time to review, the politics of hierarchy, the time to fix a simple bug (can take 2 weeks for a simple if)… But at least the specs are in a software.

[listenallyall]

If you were building a nuclear reactor, would you err on the side of too much documentation, oversight, and code review, or too little?

[mbrodersen]

That makes me think that formally proving the code correct using a proof assistant would actually be faster than the process you describe.

[BurningFrog]

Say what you will about the Jira process, there is no climbing involved...

[bckr]

Perfect opportunity for a new corpspeak term.

"Let's sync this week for the pre-sprint Jira climbing"

[nickjj]

If you use Basecamp you can climb with hill charts: https://basecamp.com/features/hill-charts

[listenallyall]

Just curious, but in the 1980's, what viable alternatives did you have to pen and paper? Did Visio exist? Did any flowchart tools exist, for DOS? For Apple ][? If they did, could you navigate, or print, a hundreds-to-thousands page flowchart in one of those OS'es?

[ctrager]

If I had just written the program directly, I could have TYPED, and I could have used the backspace and delete keys to erase instead of an ACTUAL eraser, and I could have used cut and paste instead of ACTUAL scissors and paste.

Plus, I could have used the compile, test, debug cycle to verify that what I was writing actually worked.

My specs were the same complexity as the code: Let's pretend, for example, there were no "sort" statement in the computer language. My spec couldn't just say, "sort the names in alphabetical order". My spec had to have the exact logic of a sort algorithm, but drawn as a flowchart (actually, not a flowchart but an AA proprietary format)

I didn't have to do "sort", but I did have to code algorithms that were more complex than that.

BTW, to make it more fun, there were rules about who was allowed to talk to whom. I was not allowed to talk to the programmer who had to retype my spec into actual code. I didn't even know who he/she was. And the programmer wasn't allowed to talk to me directly, but had to go up a chain.

[ryloric]

How can the people who came up with this and put this system in place not know how insane this sounds?

[ctrager]

I don't know. I speculate: So, like, the consulting company has to sell... something. They develop a... what was it called...a system development life cycle methodology? Maybe partly sincere, maybe partly bullshit, I dunno. I remember it visually as a shelf of several manuals. I imagine top AA partners selling to the top execs. Then everybody down the hierarchy doing what they've been told to do, being, not evil, but just respectful of the hierarchy. Also, many of those AA people only knowing the AA way, not having the experience, the confidence to be sure that the AA way was insane. Also, the way AA worked then "Up or Out", you are always competing with your peers. Not good for your career to rock the boat, to attack the methodology that the top partners had sold UAL.

And I don't think there was much that we as UAL employees could do. The fact that upper UAL management brought in AA to lead the project, to me, that means they were already dismissive of their in-house people and seduced by the outside people. Later in my career I experienced both sides of this a few times.

I only worked on the project 14 months. During that time the top AA partner in charge quit AA. Then the replacement quit AA, and maybe another. Maybe even they knew. I think a lot of people knew it was insane, but not able to change things as individuals.