I find 90% of the complication in large enterprise projects come from the developers trying to write too much architecture and not enough simple, boring, imperative code. At the moment I'm staring at a validation framework and 6 layers of validator inheritance who's job it is to verify that one number is bigger than another one. That's just for one tiny part of the overall system, nearly everything has to be in some inheritance hierarchy or pattern to minimize duplication or even worse, abstracted into an internal library that makes the entire organisation tightly coupled. God forbid you declare more than simple data class per file. We have tens of thousands of lines of code just to extract a few values from a csv file, tens of thousands more to write xml documents all because someone had to prove how clever they were.
Once you take away all these unnecessary complications you quickly find a lot of "large enterprise software" could be a few scripts dropped into a cgi-bin directory, some could even be a shell script + cron. I think we'd be better off with this as the starting point for all enterprise projects and should not become a "real project" until they past a point of complexity where they really deserve to be.
I'll take small stand alone spaghetti scripts over bloated architectures any day. At least they can be refactored without taking the whole system, all it's libraries and half the enterprise into account.
I currently have the opposite problem. Staring a system with zero frameworks where every time the developer wanted to do something they didn't reuse an existing solution, they simply wrote a new one. So there's 10 different ways to create a customer and now there is a requirement to change some validation. It's a major high-risk overhaul of the system to change the validation on a single field of a single entity.
I've seen big enterprise systems that had solid architecture and I quite enjoyed working with them and I've seen the trash-fire variety too.
Abstraction can be wonderful. Abstraction can be ghastly. It's how you wield it. Well designed systems are just that. Well designed. They have solutions that fit their current problems well and make just enough room for the problems of tomorrow, but not for the unanticipatable problems beyond that.
Poorly designed systems don't have solutions that fit their current problems well (or at all), and/or don't have solutions that are amenable to tomorrows problems or have solutions well suited to tomorrows problems, but not todays, or have solutions that fit imaginary problems they will never have.
I think that's what the article fundamentally hints at.
Taking the time to look at the problem and taking the time to derive and refine a well fitting solution. If you can do that, you've won.
The enterprise project I have been on for quite a while now is overengineered, but the overengineering was done by some really smart people with years of overengineering experience. It works and isn't quite an unmaintainable, dangerous monster, but as someone who is very much in the short, simple, readable code camp, it drives me nuts.
Once you take away all these unnecessary complications you quickly find a lot of "large enterprise software" could be a few scripts dropped into a cgi-bin directory, some could even be a shell script + cron. I think we'd be better off with this as the starting point for all enterprise projects and should not become a "real project" until they past a point of complexity where they really deserve to be.
I'll take small stand alone spaghetti scripts over bloated architectures any day. At least they can be refactored without taking the whole system, all it's libraries and half the enterprise into account.