1. Engineering is more clever than Business ...I don't get it? This sounds like it should be saying we try to "plan ahead" too much, but then the description s

1. Engineering is more clever than Business ...I don't get it? This sounds like it should be saying we try to "plan ahead" too much, but then the description seems to say we don't do enough. 2. Reusable Business Functionality I think this is arguing against doing too much design work up front? From what I've seen, incrementally growing a system tends towards the opposite problem unless I'm aggressively looking for refactoring opportunities. 3. Everything is Generic This isn't a case of too much vs enough, it's a case of correct vs incorrect. If you can guess how the business requirements are likely to change, making things generic in the right way will make that change much easier to do. 4. Shallow Wrappers Yeah. Unless you have actual advanced knowledge that you'll need to switch out a particular library, this should be done on-demand as a refactoring step before such monkeying around. Except for things where you need a seam to make testing easier. 5. Applying Quality like a Tool and 5.1. Sandwich Layers ...does anyone actually think this way? 6. Overzealous Adopter Syndrome Maybe, but keep in mind these can also be used to clarify intent or to intentionally constrain future changes. 7. <X>–ity The examples look like things where pursuit of whichever <X>-ity didn't actually work, rather than cases where it wasn't needed. 8. In House “Inventions” These tend to be a result of either very old systems that date back to before an appropriate reusable version became available, or organically grown systems that had parts gradually come to resemble some existing reusable thing (that initially would have been overkill and more trouble to use than it was worth). 9. Following the Status Quo Or in other words, "don't fix what ain't broken" isn't actually good? How is this "over-engineering"? 10. Bad Estimation How does this fit the theme? I thought the standard way to improve estimates was to put more thought and detail into them, which means the problem here is actually under-engineering (well, that and general noobishness). . . Edit to add: Important Note: Some points below like “Don’t abuse generics” are being misunderstood as “Don’t use generics at all”, “Don’t create unnecessary wrappers” as “Don’t create wrappers at all”, etc. I’m only discussing over-engineering and not advocating cowboy coding. So... if you disagree you're wrong and misunderstanding the article? If it's that misunderstood, it's the article's fault for failing to communicate effectively.