

A Note on Rich Hickey - wellpast
http://www.jmolly.com/2012/09/18/a-note-on-rich-hickey.html

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

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

