I was able to hire a few seasoned engineers to begin working on the next pass over the monolithic …

"put the donkey, where the owner of the donkey wants you to put the donkey" - egyptian proverb i dont know how much money this company was making, and why it couldnt invest in both backend and client facing communications but, on the other hand, being client focused and continuously delivering client facing feature, might be the thing that keeps the revenu streams coming in other words, i used to always take the dev side in stories like this, but overtime i learn to be more sympathetic to the clients, i have been in situations where the devs overestimated the value of cleaner architecture, its a financial service, not a software company, i think the real solution would have been to completely outsource the software development

CatB is a fine book. That feels like such add choice for the situation, aside from just seeing if the person was willing to engage with ideas within software. I'm curious what texts people would suggest for a non-developer to get some insight. The ones that come to my mind are the Mythical Man Month, Peopleware, Facts and Fallacies of Software Engineering by Glass, or maybe even the 1968 NATO report on software engineering.

I find Microsoft's 5 Pillars in their Well-Formed Architecture to be a useful way to explain this to non-technical people. At the start of a project, fully focusing on your features makes sense. But as a project grows, non-functional concerns can sabotage the business model if not addressed. - Reliability - Security - Cost optimization - Performance Efficiency - Operational Excellence The first four have a direct impact on the customer. Buggy or insecure software, or excess costs, will all affect the customer directly. The fifth point is about devops, and making sure that we can continuously (as a process) meet the customer's needs in all of these areas. I've found that if I can fit refactoring into one of these pillars, it is much easier to explain to non-technical people. Of course, some people just can't be helped, and aren't open to alternate ways to think about software projects.

I think that was a good move by the senior engineer. In part because I've done something similar and want to believe it's the right thing to do. Did it change anything? Did the founder manage to keep things going?

It works in everyone’s favour. Founder got what his culture sets out to build. Customer got their features faster. Senior engineer clearly knows it is not the place for him and moved on. Everyone wins.

Shouldn't the free market drive companies with these type of leaders down ? They should become swamped by the faster more agile competitors? But sadly, it seems the inertia keeps some pretty ignorant organizations functioning for decades.

Would it be ethical in a situation like this to hide all the technical improvements and just show the increased speed of client facing delivery? Seems like everyone would be happier.

This puts me in mind of a home owner on one of those renovations shows where the workers discover a structural flaw mid way through the job, and explain this means they don't have as much in the budget now for added features. The equivalent of the boss in this story would demand to leave the structural issues unaddressed to keep the marble counter tops in the budget, and then the house would cave in a year later.