3 ms·

> With experience, keeping behaviors decoupled doesn't cost more than the alternative. It's not a time to market issue. This is a strong statement. It should

> With experience, keeping behaviors decoupled doesn't cost more than the alternative. It's not a time to market issue. This is a strong statement. It should be backed up. But, supposing it's true, I think you're not considering: it takes time to develop experience. This is the tautological definition of "experienced developer". And teams where everyone is an experienced developer "basically" don't exist... (I'll concede the fact that of course some teams like this exist, but it's definitely much less than 10% of the teams, so you're not allowed to make general statements that only apply to this minority). The normal organization of teams is that you have many more junior engineers than senior... And junior engineers lack experience. So now we're right back to the beginning: Junior devs will write tightly-coupled code, and if you just accept it, you will deliver a tightly-coupled product in a shorter timeframe. If you push back, spend extra time in code review and educating junior devs, you deliver a "better" product, but take more time. You're still faced with the same decision: code-quality vs time-to-market.

wellpast 14y ago
>> With experience, keeping behaviors decoupled doesn't cost more than the alternative. It's not a time to market issue. > This is a strong statement. It should be backed up. The empirical studies to demonstrate this are extremely difficult to design. However, I think it can be argued for: A central point in countless software engineering and software development books is this exact advice ("avoid coupling") along with attempts at demonstrating patterns, idioms, approaches for how not to couple. Many people that give this message are highly respectable practitioners in our industry, Rich Hickey being one of them. In all of the books and messages that I've read/watched, never once have I seen the messenger say "Here's how not to couple, but note that this takes longer so pick your poison." No -- not one mentions a trade-off. The focus is entirely on teaching you a way to design systems. When I design and code systems, I now instinctively decouple. It would take work for me and more time to couple things together because it goes against my learned instincts. It takes experience and explicit willingness to develop this ability. But it is the most important skill to learn. It has the hugest impact on the agility and potential of your software. (By the way, it doesn't take years for coupling decisions to have impact, the problems of coupling start to cripple you pretty quickly.) To your point about junior engineers... In other industries, we don't hand over the keys to such momentous decisions to entry-level people. Junior architects don't build buildings. Why do we do this in software?
- dustyleary 14y ago
  > 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

>> With experience, keeping behaviors decoupled doesn't cost more than the alternative. It's not a time to market issue. > This is a strong statement. It should be backed up. The empirical studies to demonstrate this are extremely difficult to design. However, I think it can be argued for: A central point in countless software engineering and software development books is this exact advice ("avoid coupling") along with attempts at demonstrating patterns, idioms, approaches for how not to couple. Many people that give this message are highly respectable practitioners in our industry, Rich Hickey being one of them. In all of the books and messages that I've read/watched, never once have I seen the messenger say "Here's how not to couple, but note that this takes longer so pick your poison." No -- not one mentions a trade-off. The focus is entirely on teaching you a way to design systems. When I design and code systems, I now instinctively decouple. It would take work for me and more time to couple things together because it goes against my learned instincts. It takes experience and explicit willingness to develop this ability. But it is the most important skill to learn. It has the hugest impact on the agility and potential of your software. (By the way, it doesn't take years for coupling decisions to have impact, the problems of coupling start to cripple you pretty quickly.) To your point about junior engineers... In other industries, we don't hand over the keys to such momentous decisions to entry-level people. Junior architects don't build buildings. Why do we do this in software?

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