Kent Borg <kentb...@borg.org> 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 obsolete. -rich _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss