You're not quite disagreeing with the analogy, you're actually re-enforcing it. What you've really taken exception to, is the OP's perceived standards of 'hygiene'.

And between say 'medicine' and 'refuse collection', standards of hygiene and priorities can and will be wildly different.

> It's not an easy thing to do unlike cleaning your house. It just takes one's will to clean the house but when it comes to keeping your codebase clean, it's much more than just will.

Let me put it this way. I've seen no relationship with code purity and a happy client

Have you ever walked into a restaurant and asked to see how they refrigerate or organize their ingredients?

No? Would you say then that you don't care if your food comes out slowly or gives you food poisoning?

You care about the result, but you trust it to someone else.

It is a Chef's responsibility to maintain the mise-en-place and food safety to a degree which enables him or her to keep delivering meals quickly and without salmonella.

It is an Engineers's responsibility to maintain the code clarity and tests to a degree which enables him or her to keep delivering improvements on business needs quickly and securely.

That analogy would work if I hadn't worked for companies who made $400m+ with code and processes that would be at home in a 14 year olds hobby project. Oh and 0 tests.

I find a lot of a certain kind of sw person who need analogies to make their mental model work. It never did for me

> the number of people with this knowledge is very small in most teams and sometimes there's none.

This is just it. It's expensive to organize things.

Bad architecture is worse than no architecture. It take time to build, then more time to tear down.

How do you organize with no experience? A mess already holds a structure. It can be evolved into the right structure. But if you adopt the wrong structure too early, you're stuck with a bad system that has to be destroyed and rebuilt.

That's true in a way but with the huge caveat that cleanliness of a home is very objective. Everyone recognises and agrees when a home is very clean or very dirty.

Software architecture isn't like that at all. Developers routinely have massive fights and disagreements over whether something is clean or not. One person's clean is another person's over-engineered monstrosity.

This changes the equation quite a bit. In any sufficiently big team either one person has to be top dog and enforce their personal perception of clean on a perhaps unwilling team. Or you have to flex and tolerate multiple competing definitions in a codebase, which if you have "clean freaks" in the team can lead to constant pointless refactoring and rewriting.