One thing I like about this is that the author doesn’t talk in terms of absolutes. He assumes (correctly) that advice is not universally applicable and that eac

One thing I like about this is that the author doesn’t talk in terms of absolutes. He assumes (correctly) that advice is not universally applicable and that each process needs to be traced back to fundamental axioms or requirements. As a random example I’m right now trying to explain this to a large government enterprise customer. They write “cold blooded” software, the type where they have a development project with a fixed budget and a fixed scope and then the code goes into hibernation for five years until they can “find the budget” again. So of course, they picked the Angular framework, one of the fastest moving, most “hot blooded” frameworks in the world. Angular might be the right choice for a startup writing highly interactive software. It is definitely the wrong choice for an org that thinks of maintenance as something that occurs twice a decade. It’s these things that most fundamentally kill quality. Picking a framework, language, or even operating system because it’s “hip” or “cool” or the “buzzword of the year”. Not because it’s suitable for the project. The thousands of cuts come later, but they barely rate in comparison to having your legs chopped off at the knees right from the beginning.