2 ms·
That's not what I took away from the article. On the contrary, to me, the article listed several trade-offs that come with choosing what might be the "right" to
by pflenker 4y ago
That's not what I took away from the article. On the contrary, to me, the article listed several trade-offs that come with choosing what might be the "right" tool at any given time.
The carpenter metaphor does not really fit here, because at some point, a carpenter is clearly "done" and moves on to other projects, whereas developers continuously maintain and extend the work - their own and their colleague's.
- bruce343434 4y agoWhen what you have built is effectively a bike, and the customer requests 2 additional wheels, you don't duct tape them on. You rewrite from scratch, building the customer a car this time. Sometimes, you can salvage parts. Maybe the frame is still good when the customer reveals they actually want a minivan instead of a car. Maybe you can reuse the engine and wheels and transmission and seats. But the other stuff has got to be replaced. Why is our industry so against rewriting? There seems to be a massive focus on building stuff so generic such that it is magically extendable into anything. Hint: it never is. It never will be. Write specialized code, which is always smaller, clearer, easier to understand code against the heavily abstracted bullshit you'd otherwise get. And yes, sometimes that means the "bicycle wheel" library/framework/language needs to be replaced in your shop.
- yladiz 4y agoThis ignores the cost of replacing code. I agree with your point that you should focus on the problem at hand, and not make code too generic, but if you only make specialized code with the idea of “we can rewrite or replace it later” you will end up with a lot of specialized code that is never rewritten.