A Note on Rich Hickey
jmolly.com
jmolly.com
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.
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.
> 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?
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.
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.