Not exactly “no such thing”, more like quite the opposite, “too many things”. Somewhat like “quality software”, tossed around with mostly no definition, or occasionally too many definitions. (That’s why, in the spirit of XKCD 967, I’m making One Definition To Rule Them All – results so far at Codosaurus: ACRUMEN .)

Quite true.

I personally read “clean code” as “something I can pick up in 5 minutes if I haven’t touched the code base in a year” which is IMO a good pragmatic way of looking at it.

But too many people have been living in poverty, became programmers and skipped five social ladder steps in the upwards direction… and then super quickly became insufferable snobs that started writing bullshit like “clean code aesthete” in their biographies. (Yes, I’ve actually seen that and was flabbergasted)

The older I get the more extreme I become. Our area needs a serious cleanup.

(Sorry for the delayed reply, I’m catching up after a week of vacation!)

Yes, good clean code would be easier to pivot with… but in the time it takes for the business side to decide what to pivot to, the dev side can get started cleaning up the code a bit, plus there’s a fairly large chance that the whole codebase will get chucked and rewritten anyway, or that the biz will just go totally bust and not have a chance to pivot into anything.

As for monoliths, yes, it’s an argument for doing things the easy way. Building a monolith, whether majestic or not, is much easier and faster than deciding where to split things up into microservices, and figuring out how to make them all communicate properly. You can certainly start it as a monolith, and tear off chunks to be microservices later. Again, yes, this will be easier with good clean code… but that’s an investment that you might well not have a chance to cash in. You can also tear off chunks in just a conceptual manner, and reimplement the code differently, perhaps more cleanly this time (since it will probably last longer this time).

But that does bring up an idea… maybe a framework based around microservices in the first place? Say for instance we started with Rails but added microservices for various common things to add on, like various kinds of user management, especially authentication and profiles, maybe authorization, into microservices. Or provided a common foundation for making microservices, so if you needed to split off a service for certain kinds of PII or PHI or credit card data or anything else sensitive, or anything else that might otherwise make sense to split out, you could start that microservice from a common basis, much like how so many apps start from the basis of Rails. Think that might be useful?