It happens to me once in a while that I get the feeling to be overwhelmed by the complexity of all the electronic stuff I am working with.



Programs that I use as tools, libraries that I use to write code and the source code I write myself. They interplay. They may work or they don't. It may be my fault or not.
And there are those thousands or maybe millions of tools and libraries out there that I could use but haven't heard of. Maybe I would find the perfect solution within the next click on Google? Where is it?

This article by the creator of one of my favorite leisure time surf sites brings another issue to the point: Software projects, ours included, fail way more often than we like to admit. OK, we felt that this true. Building nice, reliable software is hard. It's somehow an unsolved problem.
But here is the punchline: You can call a project successful when it lasts 15 years.

15 years. Somehow I knew about this, but I never consciously thought about it. It's true. Today, especially in information technology (but not exclusively), putting something out there that lasts for 15 years is almost all you can hope for.
It happens if you're really good.

In five years, there will be new ways of doing things and your project will be considered old. They'll probably think your code has that old-man-odor and it takes another two years until someone finally rewrites it, but that will be it, mostly.

It's stuff to make you throw the keyboard away and run away to start a new happy life in the forests.
With software, it feels like the effort needed to be put into the work to make it last a few years is ridiculously high.

But then again, maybe we can take joy in this modern craftsmenship again by  accepting that it's faster, but it's not so different. I love this story from David Humphrey, who swims through the ocean of Open Source software trying to make sense of it. He learned about his grandfather and found out how much the things they do/did are/were alike, even with 50 years difference:

[ed: Like him,] I take things that were never meant to go together and work with them until they fit, patiently refusing to give up - even when it’s not clear I can make it work. Where she and my grandfather worked with pump motors, I work with source code.

Maybe not even the success rate changes so dramatically. As more programs get written (aka. as more tools are made), there is more success and more failure, both of those numbers go up.
What changes is the time frame. It's faster.
And also the standards rise. Less people feel they need to keep that ol' piece of software when there is so much innovation out there.
It's the way of the world.

However, maybe we are telling our kids the same stuff again one day: "When I was young, you could fix or build most of the software yourself. Today, it seems impossible!! *cough*"