|
|
|
|
|
|
by uhtred
1378 days ago
|
|
|
Eh? He's not wrong. for any serious (in production and actually being used by paying customers) software it _would_ be crazy to rewrite a codebase. I can't think of a compelling reason to. For the record, I became a perl user (for fun!) in 2022 because I was attracted to the text processing capabilities, the awesome documentation, the baked in regex handling, the way it's so integrated into unix culture, the fact that it feels like a nice and natural step up from awk or bash when I want to process text files or work with the filesystem, and also the fact that I just find python so boring. Oh, also Perl is a very powerful command line tool that can be easily piped into on linux. I don't think python or ruby are as powerful in that regard but I could be wrong. |
|
|
It's wrong when stated as a blanket statement like that. It depends on the particulars of the case.
I've worked in a company that's taken this dictum as gospel and took it to its absurd extreme where refactoring of any kind was forbidden.
I would explain some dark corner of the codebase and everybody would basically agree that it was in bad shape. I would then explain what I wanted to do about it and people would say "Is that a refactor you're suggesting?" in a tone of voice that would be more appropriate when saying "Is it killing babies that you're suggesting?"
As coincidence would have it, that was a Perl shop. So I speak from experience. And that experience has left me somewhat scarred.
Imagine working on a codebase where any mistake you ever make you're just stuck with. And it's not just your mistakes, but other people's as well. And the mistakes just pile up and pile up and start interacting with each other in nasty ways and there's just no way out. I love being a programmer, but there is little in the world that I hate more than having to be a programmer under such circumstances.
What's more is that the financial benefit of not refactoring is a benefit that usually accrues to those who are in power in a company and who don't have to touch the codebase, whereas the psychological cost of not refactoring accrues to those who have no power who are forced by the others to wallow in the muck. -- That's the thing that Spolsky consistently just doesn't get. He consistently represents the one-sided view of someone "in power".
As a programmer under such circumstances, it really makes no sense to throw away your psychological wellbeing so that your company's owners can make more money, just like it doesn't make sense for a miner to give himself lung cancer so that the owners of the mine can make more money.
Conversely: If you're the owner of a software company (or mine, or whatever) you should partially think of refactoring as an employee benefit that will pay for itself through increased productivity. It's a point that's very convincingly made by Tom DeMarco in his book "Peopleware" [1]. Asking your employees to dial down the quality of their output so you can realize cost savings almost never makes sense when you take into account the human side of the economic equation. You'll demotivate them and the losses in productivity will outweigh the cost savings.
[1] https://www.audible.com/pd/Peopleware-Audiobook/B09WDR3P3V?a...