[Haskell-cafe] A backhanded compliment and a dilemma
jo at durchholz.org
Thu Oct 20 19:58:04 UTC 2016
Am 20.10.2016 um 09:32 schrieb Imants Cekusins:
>> the "choose" group has to take the rest of the chain into account
> Choosers rarely consult and listen to the other groups even when those
> other groups are present and voice their preferences.
They consult with their architects if they have no personal expertise.
If they have personal expertise, they usually *are* the architects.
Architects tend to stick with established technology because switching
is costly (loss of productivity because programmers have to relearn,
loss of codebase that's incompatible with the new ecosystem, loss of
tool integration that needs to be prepared for the new ecosystem, loss
of programmer time who need to rewrite stuff), *plus* it is risky
because nobody can guarantee that you will ever recoup the losses, let
alone gain an edge.
Just do the math: assuming a developer-year costs USD 100,000 (not too
absurd in Western countries though there are obviously differences), a
team of ten developers working for a year to embark on a new language is
a full million dollars that needs to amortize.
And you need to guarantee that the transition is done after a year, and
that programmers will be more productive by 50%, and then it is still
three years until that expense is amortized.
You simply don't do that. You cannot (or at least should not) bet your
company's existence on that kind of stuff, particularly if those
guarantees are not available.
In practice, drastic coding infrastructure changes tend to take decades.
Large businesses (i.e. those who have the money to actually experiment
with disruptive stuff) are currently in the process of migrating their
applications from mainframes to webservices, and the typical timescale
for that is in years, sometimes decades, even for them.
Things change if you get a guarantee. If a competitor is able to make
their business processes substantially more flexible, then there you
have your guarantee, and then you'll find the employers who are willing
to use^Wtry that disruptive technology.
Webservices and enterprise buses were such changes, for example - and
they are still migrating.
> Job ads where
> employer is open to suggestions about the language are not common.
Well, changing the language in a running business process is a
high-risk, dubious-reward proposition.
You will have a hard time convincing anybody of trying that out.
> If the same group and people within that group did all the stages:
> choose, begin, complete, maintain, they'd make a more balanced decision.
Talking as somebody who has seen both sides of the fence, I can say that
these decisions cannot be made "more balanced".
You have to balance risk against reward, all while taking constraints
like developer availability, in-house ability to actually make use of
the advantages, retraining costs and overall profitability into account.
Going just by qualities of the language would be the unbalanced
decision, I'd say.
More information about the Haskell-Cafe