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

[Fred Hebert]

There is a difference between maintaining to a functional level and
maintaining in order to keep it current with demands and needs.

The usefulness of a program through time comes from its ability to
answer customer demands and needs -- these needs evolve and change as
the application is being used and has an impact on its environment. It
doesn't live in a vacuum.

The thing is, as you force a program to evolve, you add to its entropy
and it keeps getting higher until it's no longer managable, unless it's
taken care of. That includes bugfixes, but also all the improvement you
could write a new app for. It is not always economically viable to throw
it all out and start from scratch, the same way itsn't always
economically viable to maintain piles of garbage.

Properly maintainable apps are more like factories where if you haven't
welded your furnaces to the support beams, you'll be able to replace them
without taking the whole damn structure down or even stopping
production at all. Sometimes the models will change so much you'll have
no choice but to build a new complex to host them. Doesn't mean all
furnace upgrades or changes warrant a new building.

The problem with code is that there is often no up-to-date
documentation, no owner for the code, it's full of hidden features,
or bugs accepted as features, work-arounds that are implicit but not
documented or specified anywhere, and so on.

To be able to replace any of this code with anything else and have
something at least functionally equivalent, you have to be able to
reverse engineer it. The decision to throw shit out is economical by
nature, but a large part of the price is how much of a brainfuck it will
be to do the desired updates.

When the code is impossible to understand, or that understanding it takes
too long, then it makes sense to throw it all away. It's often more
economical to figure things out as you go without needing to care for
old interfaces that have non-obvious uses slowing you down. It's also
more fun too!

If you can understand the app easily, see the patterns in it, how to
refactor it, and get a good understanding of its structure, it should be
possible to throw away all the old legacy code, and get to write
100% new code in an otherwise old application. And it would be obtained at
a good cost, because answering that user's need was doable efficiently
without them needing to pay for the full reimplementation as part of the
deal.

What I want to aim for, generally speaking, is the case where code is
understandable enough that it never makes sense to throw all of it away.
Just the outdated parts of it, one at a time, as needs grow.

I've discussed of points related to that before, on former discussions
we had with parametrized modules, models, and the structure of web
frameworks. I don't think we need to end up agreeing in any case. I get
your point and you hopefully get mine -- we just choose a different
angle of attack in how we'd do things, I think. I can't have the
audacity to assert my way is the best way; at most, it's the one I
prefer.

Regards,
Fred.

On 01/24, Evan Miller wrote:
> 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