No subject

[Michael Turner]

On 1/13/2010, "Steve Davis" <steven.charles.davis@REDACTED> wrote:

>I'd like to offer another benchmark:
>
>Net income in dollars generated by the application / hours of
>development and maintenance time.

I'd like to offer a further refinement of that benchmark: leave out
"maintenance time" in the denominator.  First, because, ultimately,
it's unknowable -- especially if you're successful. Measuring it
requires time travel into the indefinite future.  Second, you should
discount highly speculative future hours anyway, since if you're
successful, they won't matter as much as you think.  If you're aiming
for a market window, the cost of missing (usually, total failure) is
generally tiny compared to software lifecycle costs down the road.  A
particularly stomach-turning real-life example: once upon a time (the
1980s), there was this relational database company that routinely
shipped database software that didn't work very well.  The company
nevertheless shamelessly bought lots of advertising claiming all kinds
of features that its competitors said they were still working on getting
right.  Of course, that company should have died.  And gone to hell.  To
burn forever.  As a textbook case of How You Shouldn't Develop
Software.  Recently, however, that same database company bought Sun
Microsystems.

Perhaps the main strike against Erlang in the niches where it
(theoretically) shines is that not many people know it.  You might
struggle uphill against a significant learning curve for your new hires,
if your product hits the market window and achieves orbit.  I'm not
sure this is a huge problem at the moment, though. For one thing, there
are probably 10 times as many people who have learned some Erlang as who
are actually making money hacking in Erlang, and many in the first
category might jump at any chance to join the second one.  For another,
Erlang seems readily interfaceable with code written in other languages,
so if a function is ancillary rather than core, you could hire
programmers to write the function in another, more popular, language. 
In the meantime, many sales objections are readily overcome by simply
pointing to successful interfaces.

-michael turner