5 ms·

> 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 resea

by tolien 7y ago

> 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_Checklists.pdf https://ti.arc.nasa.gov/m/profile/adegani/Flight-Deck_Checkl... 1: https://ti.arc.nasa.gov/m/profile/adegani/Cockpit%20Checklists.pdf https://ti.arc.nasa.gov/m/profile/adegani/Cockpit%20Checklis... 2: https://web.archive.org/web/20131026210937/http://yarchive.net/air/airliners/dc10_sioux_city.html 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 https://en.wikipedia.org/wiki/British_Airtours_Flight_28M and https://assets.publishing.service.gov.uk/media/5422efe840f0b61342000277/8-1988_G-BGJL.pdf https://assets.publishing.service.gov.uk/media/5422efe840f0b...

davidw 7y ago
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.
- tolien 7y ago
  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!)
- rubyfan 7y ago
  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.
- arvinsim 7y ago
  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.

by tolien 7y ago

davidw 7y ago

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.

tolien 7y ago
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!)
rubyfan 7y ago
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.
arvinsim 7y ago
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.