3 ms·
Except it turns out that: a) The boss has changed his mind and now we're building a pool, so we need to cut off all this f* rebar sticking out. More time to re
by lowbloodsugar 11y ago
Except it turns out that:
a) The boss has changed his mind and now we're building a pool, so we need to cut off all this f* rebar sticking out. More time to remove it, plus the cost of adding it in the first place.
b) Its software, so adding the rebar is as easy as F6-refactor.
You are scaring the children. Stop it with the FUD.
- Silhouette 11y agoYou can always come up with exceptional counter-examples in any argument about probabilities and making cost/benefit judgements. As I noted elsewhere, my experience has apparently been very different to some here, because I'm still waiting to see the project where the entire direction suddenly shifted so fundamentally that it wound up writing off significant amounts of code that was now useless. (Just for the record, I'm also still waiting to see the house where the rebar is in changed to require a pool where the planning consent stated a house was to be built, though I've seen a lot of houses with the rebar in where the walls then went up a short time later without having to rebuild the entire foundation because the rebar was already in.) I've written elsewhere in this HN discussion about a few different types of project where you can't just refactor your way out of trouble if you go too far down the wrong path. The cost of doing so can easily become more expensive than just throwing out the whole thing and starting again. This isn't FUD, it's a few decades of professional programming experience talking. They just happen not to be the same few decades that some of the other posters here have had. And as once again I seem to keep writing now, that is why it is unwise to generalise too far from personal experience or a small anecdotal base to an entire field as vast as programming.