Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've always found an enormous amount of good practices (not just engineering ones) in aircraft operations and engineering that would be applicable to software engineering.

I've always day dreamed of an IT organization that combined those with the decision-making procedures and leadership of modern armies, such as the US Army one.

I've re-read multiple times FM22-100 which I find strikingly modern and inspiring:

https://armyoe.com/wp-content/uploads/2018/03/1990-fm-22-100...

While I do understand that business leadership cannot compare to the high standards of those required by way more important stakes, I think there's many lessons to learn there too.





It's all about balance, in the end. If you do too much of one thing your business will fail. If you don't do enough of another, your business will fail too. And they're the same thing...

The trick then is to do just enough of everything to avoid disaster and to move as fast as you can to get to a realm where you can actually afford to do it right. Most start-ups initially cut corners like it is crunch time at the circle factory, which then usually catches up with them at some point either killing them or forcing them to adapt a different pace. Knowing exactly when to put more or less attention on some factor is the recipe for success but nobody has managed to execute that recipe twice in a row without finding things that no longer work, so it remains a dynamic affair rather than one you can ritualize.

And that's where checklists shine: repeated processes that are well defined and where change is slow enough that the checklists become 'mostly static', they still change but the bulk of the knowledge condensed in them stays valid over multiple applications.


I guess you are not the only one. Here is talk by Andrew Godwin about using aviation practices for software engineering:

https://youtu.be/d0eo3FxKQNc


In some areas, I absolutely agree... I think when it comes to vehicles, medical devices and heavy equipment, it would be better to see much more rigorous practices in terms of software craftsmanship. I think it should be very similar in financial operations (it isn't) and most govt work in general (it isn't).

In the end, for most scenarios, break fast, fix fast is likely a more practical and cost effective approach.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: