Hacker News Reader

> Pilots especially are heavily trained to use checklists for just about everything.

Yeah, but it didn't appear out of nowhere. NASA et al did a tonne of research [0, 1] that led up to the idea of using checklists. Likewise Cockpit/Crew Resource Management [2] and the psychology of getting people quickly out of aircraft that are on fire [3], all of which were prompted by one disaster or another.

Software engineering could use some of that rigour, but I'd anticipate a little resistance to publishing research which shows that the process of building some piece of software was a shitshow because the people running said show were bad at it.

0: https://ti.arc.nasa.gov/m/profile/adegani/Flight-Deck_Checkl...

1: https://ti.arc.nasa.gov/m/profile/adegani/Cockpit%20Checklis...

2: https://web.archive.org/web/20131026210937/http://yarchive.n...

3: Lots of which happened after British Airtours 28M, https://en.wikipedia.org/wiki/British_Airtours_Flight_28M and https://assets.publishing.service.gov.uk/media/5422efe840f0b...

As always: for most software, the consequences aren't that bad, so a company that was really rigorous and disciplined and as a consequence a bit slower might well be out-competed by a company that's run in a bit more 'fast and loose' way.

Yeah, I was going to say that - the difference between the rigorous research in aviation/medicine and most software projects can be measured in dead bodies.

There's plenty of software that really matters though, in the same way that using checklists and things makes sense in environments where you won't kill people. We could all learn something if someone researched using, for example, an Agile methodology for building the F-35's flight control software, for example!

Edit: Thinking about this some more, I suppose my point is how to measure this:

> a company that was really rigorous and disciplined and as a consequence a bit slower might well be out-competed by a company that's run in a bit more 'fast and loose' way

while correcting for other factors like marketing etc. You can measure how quickly a group of people will get off an aircraft and vary things like the dimensions of the exit row to test whether your change has improved things but you can't, e.g., re-run a project with TDD and test whether it was "better" (defining "better" in the first place is hard enough!)

For many financial services companies the consequences for bad software quality tend to be high, either from bad calculations at scale or downtime. It’s not life and death but in many companies the pain is real and one of the many reasons for non-agile highly planned and highly process oriented operations.

Yup, I agree. If there was a heavy penalty on the business/financial level(not just on the software level), businesses would take things like software testing, proper timeline management and rigorous specifications more seriously.

Unfortunately, that's not the case. So most business just bulldoze their way to their primary objective.

> Not because agile is bad, but because the people in charge of agile are usually bad.

That's the crux of it. Currently working at an org which is "Agile" and has Scrum masters, but management still insists on measuring work in man-hours and defining requirements in huge chunks then delivering them at arbitrary deadlines. So... it's waterfall with Scrum masters who make it look nice on Jira charts.

> I am not a doctor, nor am I an expert, I have just read some interesting articles and heard from surgeons that they are trying to improve the process to reduce careless mistakes.

Also not a doctor but I've built some checklist software for them. At good hospitals there's a nurse counting every screw, piece of gauze and scalpel passed around in surgery, counting them again on the way out, counting them when the go into the dishwasher and counting them again when they come out of the dishwasher and get preped for the next surgery. Apart from emergencies doctors will have a list of instruments needed for any given operation and there will be a special package of them ready.

This was heavily influence by the aviation industry.

Pilots especially are heavily trained to use checklists

But I bet there are no methodology merchants who never fly planes or operate aviation businesses selling expensive checklist consulting, wasting the time of busy pilots with actual work to do. Like who is the Thoughtworks of piloting? Or of surgery? They don’t exist. Only software is plagued with them.

Funny enough, the practical test standards are more or less published as the test checklist, which includes verification that the person getting their pilot's license used checklists proficiently. (The checklist checks checklist checks?)

Checklists are fantastic if used in the moment by a team.

Checklists used post hoc and imposed on individuals are (IMHO) worse than useless - they give a sheen of process and quality by forcing someone to randomly ink boxes.

And provide a big stick to whack the unfortunate employee.

"You ticked box AX-two-alpha-seven. Do you know what that means? And you didn't complete the P12a checklist. That's gross misconduct. You're fired."

I don't know much about Big Law, but I would be shocked if they don't have the same sort of thing. Hundreds of entry level folks with high turnover with a simple metric (billable hours) to track their progress; it sounds ripe for some equivalent to Agile.

No such thing. Each partner runs their own show for their own clients.

Firm-wide common resources such as a docketing departments will have checklists but they are mostly software driven/automated these days. For example, creating a new matter in the docketing system will automatically generate most of the critical dates and checkoffs for that matter.

I have heard that big consulting firms generally have a system per firm.