The back half of the essay was unrecognizable for me, but that's probably because I'm working in different contexts and on different product types. It would be

The back half of the essay was unrecognizable for me, but that's probably because I'm working in different contexts and on different product types. It would be helpful to know what systems the author has worked on and why these findings applied to that context. That way, if I ever find myself in one of those contexts, I can leverage the author's experience. Generalizing individual experiences to general prognostications sells well as a genre, especially in software. This writing pattern was epitomized by OOP thought leaders in the 90s/00s, but was also present in the process evangelists who followed and the more iconoclastic folks like Dijkstra who preceded. However, actually following such general advice without taking into account the author's context can easily end in tears. Ideally, these sorts of pieces should be written up as case studies rather than as general prognostications. With the context that a case study provides, these pieces can teach us a lot about how to engineer systems. Without that context, the reader is left to blindly follow advice that may not be relevant to their context. Or, best case, reverse engineer the context.