The company I'm at now has been building the "most simple", "low-code" solutions they can find for 15 years. We're constantly talking about the Pareto principl

The company I'm at now has been building the "most simple", "low-code" solutions they can find for 15 years. We're constantly talking about the Pareto principle: "80% of software can be written in 20% of the time." And we optimize for building that 20% of the code in the simplest, fastest way possible. The problem is the other 80% of the code, the part that accounts for 20% of the features, ends up being necessary before full adoption of the software takes place. 80% working simply isn't good enough. But since we've optimized for that easy 20% using low-code solutions, the other 80% of our code ends up being twice as painful. We end up deciding it's too expensive to continue and attempt to force use of the 80%-finished software as-is. Historically, this hasn't turned out well for us, and users end up compensating via spreadsheets or even paper. It takes a couple years for this whole process to play out. The project is often declared a success since 80% of it got done and deployed so quickly. But there's always those last nagging bits that, upon further inspection, have led to the app/feature/whatever being abandoned later on. > It is that kind of thought process and default overhead that is leading companies to conclude that software development is just too expensive. It is too expensive for them. If you're building a house and get sticker-shock at the cost of building the foundation, maybe you're in too deep. Please don't skimp on the foundation.