4 ms·

Spolsky wrote the (for me as a young developer) eye-opening article about why you should never rewrite from scratch. But even then, it was clear that Wasabi was

by olavk 9y ago

Spolsky wrote the (for me as a young developer) eye-opening article about why you should never rewrite from scratch. But even then, it was clear that Wasabi was taking this to an extreme. VBScript is one of the worst and most limited scripting languages ever. Using this as source and then transpiling into more powerful and expressive languages seems totally backwards. Then they brag that they are able to add new features like closures (which already exist in the compilation target languages). So they are creating a new, horrible, proprietary language, just to avoid rewriting the original source. It seemed like a fun challenge to work on, but just like "lets rewrite everything from scratch", the kind of ideas developers come up with when they don't have to consider the big picture and overall cost.

InclinedPlane 9y ago
Spolsky's wrong about rewriting from scratch, he took it way farther than was sensible. The main problem most people make about rewriting from scratch or switching architectures or what-have-you is not doing it at all but thinking that it'll be a cheaper and easier transition that it will actually be and also committing too early to the new product. A lot of this comes down to the arrogance of engineers and the devaluation of testing. The reality is that testing and real-world use have tremendous value in shaping products. Actual usage is one of the best ways to discover bugs, of course, and over time those bugs get fixed, leading to a more mature product. Similarly, actual usage is the best way to discover the gaps between the developers' design and vision for the software and what people actually want and need. More so when people trade hard-earned dollars for software. Developed software thus represents not just X number of hours of dev. work it also represents a tremendous number of hours of refinement, validation, and verification through "beta testing" (product use), in short: product maturity. Trying to replace a mature product with an immature product is a disaster waiting to happen, even if the immature product is technically built on a superior foundation. The right way to do this sort of thing is to spend time running parallel development efforts, giving time for the new thing to mature and compete against the established product and allowing the market/customer base to make the transition as the new product gains maturity and becomes superior in practice not just in theory. Or, as people avoid the new product due to it failing to achieve its promises.
- lmm 9y ago
  I'd take the view that a rewrite in place is always better than a rewrite from scratch. With a little effort it's always possible to implement the new thing piecemeal as part of the existing thing.

by olavk 9y ago

InclinedPlane 9y ago

Spolsky's wrong about rewriting from scratch, he took it way farther than was sensible. The main problem most people make about rewriting from scratch or switching architectures or what-have-you is not doing it at all but thinking that it'll be a cheaper and easier transition that it will actually be and also committing too early to the new product. A lot of this comes down to the arrogance of engineers and the devaluation of testing. The reality is that testing and real-world use have tremendous value in shaping products. Actual usage is one of the best ways to discover bugs, of course, and over time those bugs get fixed, leading to a more mature product. Similarly, actual usage is the best way to discover the gaps between the developers' design and vision for the software and what people actually want and need. More so when people trade hard-earned dollars for software. Developed software thus represents not just X number of hours of dev. work it also represents a tremendous number of hours of refinement, validation, and verification through "beta testing" (product use), in short: product maturity. Trying to replace a mature product with an immature product is a disaster waiting to happen, even if the immature product is technically built on a superior foundation. The right way to do this sort of thing is to spend time running parallel development efforts, giving time for the new thing to mature and compete against the established product and allowing the market/customer base to make the transition as the new product gains maturity and becomes superior in practice not just in theory. Or, as people avoid the new product due to it failing to achieve its promises.

lmm 9y ago
I'd take the view that a rewrite in place is always better than a rewrite from scratch. With a little effort it's always possible to implement the new thing piecemeal as part of the existing thing.