Everyone seems to be striving for ‘clean’ code at the moment. You can’t read a blog post without the author telling you how clean their approach is. Engineering teams get together and discuss which of the possible solutions is the cleanest. Other developers assure you that they practice ‘clean code’.
I’ve come to a realisation though. There’s no such thing as clean code.
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 .)
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.
The latter, of course. If your investors are scheduled to come by in two weeks you don’t want your programmers fiercely discussing clean code while not having a working prototype.
It’s more important for startups to get their idea out to market quickly, and respond to what the market says. Once that’s settled down, they may have some opportunity to clean up their code, or take more care to write clean code.
But if the startup owners are lucky, they hired people who write clean code in the first place, without taking (much) longer. So, the two questions as literally asked can be answered: “usually not but it is certainly possible”, and “yes, at least the basic functionalities of their MVP”.
This makes sense to me. In the business’ quest for that fabled product-market fit, they’ll need to repeatedly transform their MVP. “Rubber, meet road.” So it seems a useful MVP should be malleable, protean. It’s hard to quickly adjust or repurpose a Rube Goldberg Machine, so it stands to reason that in the context of an effective MVP, “clean” would mean “easy and quick to change.” That in turn seems to imply something like “well structured even when messy.” I’m coming to think this is a major reason why solid, well documented frameworks can be so helpful. It also seems to be an argument for monoliths?
(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?
Somewhat like “quality software”, tossed around with mostly no definition, or occasionally too many definitions. (That’s why, in the spirit of 
(Yes, I’ve actually seen that and was flabbergasted)