Kent Borg <> wrote:
> But this stuff doesn't work particularly well, and the
> more modern the design the worse the results. There was a
> lot of stuff that was computerized in the late '80s that
> still works today. How much of the stuff we are building
> now has a prayer of lasting just ten years?

Heck I built some computerized things in the /early/ '80s that are still
flying around the skies today (A320/777s).

But your assessment is rather glass-half-full, wouldn't you say? I built a
software tool for AWS deployments in Ruby/Chef back in 2013 that my current
employer is still using today, with 2 or 3 failed attempts by later hires
whose ambition was to replace it. Hopefully their next attempt will succeed,
'cause I'm tired of people taking that tool's name in vain. :-)

Today I'm working on stuff that can and will last the next 10 years; I count
myself lucky that I'm in a place, and at the center of a developer ecosystem,
that will be around for at least that long.

Dig that phone out of your pocket, or evaluate the cloud services that sit
behind it. Can you seriously make the claim that this stuff doesn't "work
particularly well" compared to the '80s or '90s? Back then there were maybe 1
or 2 million users on the 'net (I remember when there were only 2000). In
order to support billions of users, standards for user-experience and
reliability had to ramp up dramatically.

Whether you're looking at your own home setup or pretty much any
commercially-viable service today, or any thriving open-source project, the
standards for "works particularly well" are at least an order of magnitude
more difficult to achieve than they were 20+ years ago: and either these
higher standards are met, or whoever pursues them will fail. Just like those
ambitious souls at work who continually try to render my 2013 ruby project


Discuss mailing list

Reply via email to