HN guidelines urge us not to cross-examine and I wouldn't want to do that anyway, so let me just say this. If you want to share the details of how you were bit

HN guidelines urge us not to cross-examine and I wouldn't want to do that anyway, so let me just say this. If you want to share the details of how you were bitten by these sorts of things, I'll welcome it as your "lived experience" as they say. My own experience was as a system integrator from 1997 to 1999 for a client-server CRM product called Onyx, which had a VB front-end and a MSSQL back-end with all the logic in sprocs. I didn't write it, so I don't know what that was like, but I customized it, and it worked. I was a Java developer from 2000 to 2002 building first dot-com boom internet applications this way in a small team for admittedly small clients, and it worked. I was a Java developer from 2002 to 2005 building "intranet" applications this way in a small team for a big client (Wells Fargo) with Oracle sprocs, and it worked, though already by then the industry was 5 years into the fashion of "N-tier architectures", "application servers", and "ORMs" so this way was definitely unorthodox. When I came back from grad school this way was history, with Ruby on Rails, Django, and Spring plus Hibernate being the standard. I was again a Java developer at an enterprise back-office software company from 2010 to 2016 and we definitely did not do it this way. We also had 200+ engineers and I'm quite sure it would've been chaos if we'd tried. The way I see it is that there are few technical obstacles that aren't dwarfed by social obstacles. No software architecture or development practice will succeed whatever its merits if people don't want to use them. In my experience, what engineers have wanted is to program in anything but SQL. Building database-backed web services (for example) in the orthodox way is inefficient but it works, and more important it feels like work. It demands large teams, and then rewards large teams with forward progress and a code base that makes sense, but only in the context of a large team. My hunch is that building applications in the database with large teams would fail, but also that large teams are unnecessary when building applications in the database. But hey. Maybe I'm wrong. You tell me. How did the projects you built in this way stuggle?