Hacker News Reader

Comment by ctrager | Hacker News Reader

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.

View on HN

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"

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.

And it sounds like the users didn't understand that in some manner.

Hmmm, what am I trying to say... I guess... as I think about it now, the lines of communication were very hierarchical - up and down the chain. But when it was time for me, a tech guy at the bottom, to talk to a user on the front lines, the disconnect was hilarious to me - but maybe you had to be there... I feel like I'm a boring old man telling this story.

Ahh I see. I can understand why it would bring you back that memory. I was just confused at first, cheers!

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.

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

I was just sharing the story.

Now 2 weeks for a simple change in a if. Some changes can take months and the software is not just a few line of code so if you do the math you may start to have rust on your hardware even before the v1.0 is out. Also nobody is going to read this type of “doc” but another schema spec coder if that’s the name.

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

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

Perfect opportunity for a new corpspeak term.

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

Waterfall is so last week. Properly scheduled climbing projects meet MVP more often!

Yeah, Sooo over Waterfall. We do Wagile here!

(Hey, what are the worst bits of waterfall and agile? Let's combine them into our methodology!)

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

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?

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.

nice.. it's just "low code" :-)

Cutting and pasting with scissors and actual paste sounds pretty awful. But what I was hoping to get more insight about, if the task was to draw tens of thousands of pages of flowcharts (not text), would a 1980's PC (maybe 16mb RAM, 5.25" floppies, no GUI) be more efficient than a pen and paper? Even on a modern PC, I can often draw a flowchart quite a bit faster than I can create it in Lucidcharts or similar software.

I dunno. I myself was pretty clueless about PCs at that time. I owned a Kaypro from the early 1980s that ran CP/M, but I never touched a PC running Windows (or even just DOS) until 1994. They weren't part of the centralized IT departments I worked in. They WERE part of a sorta grass roots revolt by the user departments, setting up their own Lotus spreadsheets, whatever, as a way of bypassing the slow bureaucratic centralized IT departments.

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

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.

Reply on news.ycombinator.com