3 ms·

A Note on Rich Hickey

5 points by wellpast 14y ago

nostrademons 14y ago
Rather flowery language, but addressing the main point... Time to market is also an objective, measurable quantity. Usually more measurable than coupling. Yet the effect of time to market is visible immediately in the bottom line, while the effects of coupling won't be visible for several years. I can almost guarantee you that when you see a senior developer choosing to build a tightly-coupled pile of shit, there was deadline pressure involved. And it's not true that "you couple, you lose; you don't, you win". Much of Google code is a tightly-coupled mess (that's one reason you don't see more open-source software come out of it; the reason MapReduce isn't open-sourced isn't because of policy, it's because it's so tightly coupled to Google infrastructure that nobody wants to spend the time to untangle it). Amazon code, by most reports, is even more of a mess, and Facebook code is the biggest pile of shit there is, except for all the hot startups that you'd wonder how they managed to work if you worked there. So maybe it's not that the rest of the industry is stupid; it's that you're optimizing for the wrong things.
- wellpast 14y ago
  I disagree. With experience, keeping behaviors decoupled doesn't cost more than the alternative. It's not a time to market issue.
  - dustyleary 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. 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.

5 points by wellpast 14y ago

Rather flowery language, but addressing the main point... Time to market is also an objective, measurable quantity. Usually more measurable than coupling. Yet the effect of time to market is visible immediately in the bottom line, while the effects of coupling won't be visible for several years. I can almost guarantee you that when you see a senior developer choosing to build a tightly-coupled pile of shit, there was deadline pressure involved. And it's not true that "you couple, you lose; you don't, you win". Much of Google code is a tightly-coupled mess (that's one reason you don't see more open-source software come out of it; the reason MapReduce isn't open-sourced isn't because of policy, it's because it's so tightly coupled to Google infrastructure that nobody wants to spend the time to untangle it). Amazon code, by most reports, is even more of a mess, and Facebook code is the biggest pile of shit there is, except for all the hot startups that you'd wonder how they managed to work if you worked there. So maybe it's not that the rest of the industry is stupid; it's that you're optimizing for the wrong things.

wellpast 14y ago
I disagree. With experience, keeping behaviors decoupled doesn't cost more than the alternative. It's not a time to market issue.
- dustyleary 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. 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.