> sometimes you're faced with choosing between a quick 20-minute change (that introduces coupling between previously uncoupled code), or a day-long refactoring to do it "right".
I don't relate to this only b/c this choice between 20 minutes vs. a day doesn't (shouldn't) come up as frequently to make it a time-to-market differentiator.
If it is -- if you're repeatedly bombarded by having to 20 minute hacks -- I think your problems are going to surface very very soon, not years from now.
Many teams I've witnessed code fast, fast, fast -- the wind in their hair and all -- but if you look at the puck you'll see that they're doing "suicide sprints" -- back and forth, back and forth. The team that does this right (that makes the "right" wise choices) is more like an elephant -- fast land speed, not quite a rabbit, but wise -- continually pushing the puck forward and at a much higher overall pace than the rabbit.
(Sorry for the potentially stomach turning analogy.)
> If a junior dev makes tightly-coupled code, then at some point down the line, schedules slip.
It's much, much bigger than slipped schedules. Take this interaction with a Product Manager:
PM: How long will it take to build this feature?
Engineer: Three days... I think?
PM: Nevermind, we won't do that.
In an inflexible code base this conversation happens over and over and over again. The "potential" of the codebase starts to become a tacit, subconscious limiter of innovation (the PM eventually stops asking certain questions--i.e., stops imagining ideas.)
It's not people dying but it's innovation, it's a stock price, it's jobs. It's a huge deal. That's why the frustration.
I don't relate to this only b/c this choice between 20 minutes vs. a day doesn't (shouldn't) come up as frequently to make it a time-to-market differentiator.
If it is -- if you're repeatedly bombarded by having to 20 minute hacks -- I think your problems are going to surface very very soon, not years from now.
Many teams I've witnessed code fast, fast, fast -- the wind in their hair and all -- but if you look at the puck you'll see that they're doing "suicide sprints" -- back and forth, back and forth. The team that does this right (that makes the "right" wise choices) is more like an elephant -- fast land speed, not quite a rabbit, but wise -- continually pushing the puck forward and at a much higher overall pace than the rabbit.
(Sorry for the potentially stomach turning analogy.)
> If a junior dev makes tightly-coupled code, then at some point down the line, schedules slip.
It's much, much bigger than slipped schedules. Take this interaction with a Product Manager:
PM: How long will it take to build this feature? Engineer: Three days... I think? PM: Nevermind, we won't do that.
In an inflexible code base this conversation happens over and over and over again. The "potential" of the codebase starts to become a tacit, subconscious limiter of innovation (the PM eventually stops asking certain questions--i.e., stops imagining ideas.)
It's not people dying but it's innovation, it's a stock price, it's jobs. It's a huge deal. That's why the frustration.