Microservices is just a buzz word for an overly prescriptive (thankfully waning in popularity) type of distributed system. When you are developing a distributed system, the infrastructure is a primary consideration that is potentially even more important than anything in the app layer.
Microservices in particular is often decided at such an early stage and on such loose ground that in many cases it can barely be called an intentional software design, but rather something more akin to picking a perceived one-size-fits-all template. But it does then certainly leak into everything else - completely unnecessary or not. Which is why I'm asking that question.
I'd usually agree, especially as things get big.
But Kent is also pretty famous for throwing out code if things aren't shaping up. He does this in micro increments however, usually with just-written code.
I've just spent years wrestling with someone else's poorly written, ill-intentioned code, bringing it into line. I've taken the above approach of slowly reworking it. Sometimes I wonder if I just kept the tests and jettisoned large bits of it if I'd be better off?
Very contextual of course, but sometimes you have to explore a little bit to know the right places to make tradeoffs.
That's the main reason we have this discussion in the first place IMO. There is no one right answer to the question.
It takes many years to develop good intuition around this stuff though, so I appreciate that as a first approximation. It can get a little dogmatic amongst senior folks though.
If you are talking about refactoring or changing/replacing parts of a system - that's not the same thing. At least to me
I find it really depends on the level of nuance required of the final behavior. Maybe the test suite doesn't cover certain implicit requirements of the software, often a bug becomes a feature without anybody noticing in sufficiently old projects.
Likewise the tests might not even be structured in a way that's conducive to a rewrite, depending on their level of specificity. Maybe you only care about the final, black box behavior and individual unit tests should be thrown out so you don't need to adhere to existing function I/O requirements.
It just depends. Like you said, very contextual.
Sometimes I just reflect on YEARS mucking with code written from someone that was just learning, and I wonder if I'm a little too in the "sunk cost investment" mindset. Hard to tell I suppose, but certainly worth thinking about.
Depends how much you trust your test coverage.
Then you read his latest book "Tidy First" and it tells you when you move out multiplying width and height into an area function you have now made a beneficial design change in your system and the relationship between caller and box, a "tiny step". And suddenly all the doubts wash away.
Not sure what it is with this industry, but the writing is just useless.
Netscape pre 5 or 6 was a mess. It was a downloadable desktop application that kept getting pushed to deliver new features with a struggling UI framework. Additionally, I would imagine that the group delivering this was rather small in respect to the size of the task. They didn't have CI/CD, git, etc to give feedback. This reeks of an overmainaged project that was intentionally underfunded.
Ultimately.. it was an unmaintable mess that required a rewrite to even continue. To me it sounds like it was tech debt piled deeper and higher.
What came of this? Complete browser rebuilds (mozilla mosaic, chrome, etc), and finally this caught fire through the Chrome project and Javascript acceleration at google.
As for the Netscape anecdote, I wouldn't put too much weight on that part.
We do not know the extent of it, we do not know if it achieved its goals, and we absolutely can not say whether or not the alleged rewrite contributed to or affected the evolution of the product into firefox and eventually chrome etc
My comment above was trying to point out: NS6 rewrite wasn't the only browser to start back from scratch at that time.
What I think Spolksy was advocating for: Don't try to completely rewrite things for fun, there are a lot of dark corners there.