3 ms·

I feel like this happens pretty often with rewrites. Up to the very end, you feel like you're doing great. You've written 90% of the original functionality in 1

I feel like this happens pretty often with rewrites. Up to the very end, you feel like you're doing great. You've written 90% of the original functionality in 10% of the code. Then you try to fill in the last 10%, and end up back where you started (with slightly better/more logical code).

guscost 10y ago
Well, if you're rewriting something that is actually worth rewriting, you can end up with way nicer code, but yeah it's still very hard to avoid some awkward crufty bits in that last 10%. The tricky part is that "actually worth rewriting" is a higher bar than you would think. And even when you clear that, finding the sweet spot between "you ain't gonna need it" and "you ain't gonna need it until the rewrite is 95% done" isn't easy.
derefr 10y ago
I feel like the difference between a successful ground-up rewrite and a failed one comes from defining your scope correctly from the outset. You run into the overflowingly crufty "last 90%" work mainly because your new thing still has to plug into an ecosystem of other components that are, themselves, old and crufty. If, however, you've defined your rewrite-project boundary to contain the entire ecosystem of those components, such that you get to redraw all the component boundaries and protocols with fewer redundancies and smaller surfaces, then you really can keep your 10% code—at the cost of having to write that 10% of the code for at least ~9x the number of codebases you were intending to. This is what Plan9 managed to do: draw the correct boundary to simplify Unix, by putting all of Unix in scope for rethinking, eschewing the last 10% of the functionality because the other, redefined components now support the same thing in simpler ways. (See, for example, the way the Acme editor does menu commands.) It's also—whatever you think of it—what systemd is doing, sort of consuming components of the Linux userland and leaving cleaner service boundaries in its wake. The sheer scope of that effort can make the project look bloated—but people forget to compare the codebase with the combined codebases of all the projects it took to have equivalent functionality before.

guscost 10y ago

Well, if you're rewriting something that is actually worth rewriting, you can end up with way nicer code, but yeah it's still very hard to avoid some awkward crufty bits in that last 10%. The tricky part is that "actually worth rewriting" is a higher bar than you would think. And even when you clear that, finding the sweet spot between "you ain't gonna need it" and "you ain't gonna need it until the rewrite is 95% done" isn't easy.

derefr 10y ago

I feel like the difference between a successful ground-up rewrite and a failed one comes from defining your scope correctly from the outset. You run into the overflowingly crufty "last 90%" work mainly because your new thing still has to plug into an ecosystem of other components that are, themselves, old and crufty. If, however, you've defined your rewrite-project boundary to contain the entire ecosystem of those components, such that you get to redraw all the component boundaries and protocols with fewer redundancies and smaller surfaces, then you really can keep your 10% code—at the cost of having to write that 10% of the code for at least ~9x the number of codebases you were intending to. This is what Plan9 managed to do: draw the correct boundary to simplify Unix, by putting all of Unix in scope for rethinking, eschewing the last 10% of the functionality because the other, redefined components now support the same thing in simpler ways. (See, for example, the way the Acme editor does menu commands.) It's also—whatever you think of it—what systemd is doing, sort of consuming components of the Linux userland and leaving cleaner service boundaries in its wake. The sheer scope of that effort can make the project look bloated—but people forget to compare the codebase with the combined codebases of all the projects it took to have equivalent functionality before.