Comment by smj-edison

First, failures aren’t always obvious, and second, studying them isn’t either. This would likely need to be a formalized course. Still…

If people want to know why Microsoft hated DOS and wanted to kill it with Xenix, then OS/2, then Windows, and then NT it would be vital to know that it only came about as a result of IBM wanting a 16bit source-compatible CP/M which didn’t yet exist. Then, you would likely want to read Dissecting DOS to see what limits were imposed by DOS.

For other stuff, you would start backwards. Take the finished product and ask what the requirements were, then ask what the pain points are, then start digging through the source and flowcharting/mapping it. This part is a must because programs are often too difficult to really grok without some kind of map/chart.

There is likely an entire discipline to be created in this…

The things people are talking about in this thread are less to do with the practice of programming, and more to do with the difficulties of managing (and being managed, within) an engineering organization.

You'll learn all of this for yourself, on the job, just via experience.

One place to look is https://thedailywtf.com/

To be cynical, what's the point? You'll get employed and forced to be a part of them by circumstances.

Your company's root priorites are probably at odds with writing good software.

One Japanese company, not going to name names, kept trying to treat software as a depreciating asset. I didn't really understand well but the long and short was that fixing things that were supposed to be "done" was bad for the accounting. New things, however were good.

How can you run a software company like that? But they did and got the kind of outcome you'd expect. Japan made the laws this way and gets software to match.