3 ms·

> never once have I seen the messenger say "Here's how not to couple, but note that this takes longer so pick your poison." I agree, but this perhaps exposes a

> never once have I seen the messenger say "Here's how not to couple, but note that this takes longer so pick your poison." I agree, but this perhaps exposes a problem: All of the tutorials/approaches are green-field development. I'd like to think that I basically don't write coupled code "the first time". Problems can come later, when design decisions need to be revisited, often because requirements change. And when they do, 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". > To your point about junior engineers... In other industries, we don't hand over the keys to such momentous decisions to entry-level people. The "momentous-ness" of these decisions is very different. If an junior architect screws up while building a building, people die. If a junior dev makes tightly-coupled code, then at some point down the line, schedules slip.

wellpast 14y ago
> 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.

wellpast 14y ago

> 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.