[erlang-questions] If you are homesick for object.selector

[Evan Miller]

On Thu, Jan 24, 2013 at 3:41 PM, Fred Hebert <mononcqc@REDACTED> wrote:
> I just feel maintainability should be seen as more important than it
> is seen in general -- after all, roughly 30% of the programmer time spent
> in a project is for development, 70% of the time spent is in maintenance.
> Of that 70%, between 50% to 90% of it is spent trying to figure out what
> the hell the code is doing (that's 20% to 60% of the whole project's
> life!)
>
> With these numbers, it seems insane to optimize for fast writing instead
> of fast understanding.

"These numbers" are not physical constants. They depend solely on your
market and on your development strategy. Other people's numbers will
be quite different, and in many contexts, optimizing for fast writing
can be quite sane.

There's an apocryphal story of Andrew Carnegie visiting a British
steel manufacturer. The manufacturer boasted that with proper care and
maintenance, some of his furnaces had been in service for decades.

"And that," Carnegie replied, "is why the United States is making you
a back number. You're using still furnaces that ought to have been
scrapped twenty years ago."

I bring this up to point out that there are two approaches to
maintenance. One can build something that is high-quality and lasts
for a long time with proper ongoing investment (what I'll call the
"British" approach), or one can build on the cheap and when it breaks,
crank out a replacement (what I'll call the "American" approach).

It's tempting to think that the British approach is more "long-term",
and there is a strong tendency among engineers to equate build quality
with moral virtue, but there is significant a long-term economic
advantage to the American approach: if you're constantly building from
scratch, you end up taking advantage of technological advances that
are more difficult for your "British" counterparts to incorporate into
their older designs.

DeTocqueville has a similar analysis of the American versus British
shipping industries in the early 1800s. Americans treated ships as
expendable, the British didn't, and the Americans ended up dominating
the industry. The average ship in an American merchant fleet was worse
in terms of quality, but it was newer in terms of design, so it tended
to reach its destination more quickly. (Of course, it was more likely
to be shipwrecked along the way, and hence American seamen were
better-paid than their British counterparts; but the additional wages
were easily furnished by the market's thirst for fast trans-Atlantic
shipping.)

I think there are lessons here for software. Even if *technology*
itself doesn't change (and it does), *markets* change swiftly, and it
can be necessary to build new versions of products rapidly (call it
"iterating" or "pivoting" or whatever you want). Engineers tend to
care deeply about quality-of-build and maintainability, but in some
sectors it is much more practical to be constantly building and
rebuilding "crap" in short time frames. I think this insight largely
explains the popularity of Ruby on Rails. It might seem insane, but
it's really just economics.

Evan