crumble |ˈkrəmbəl| verb
break or fall apart into small fragments, esp. over a period of time as part of a process of deterioration: (as adj. crumbling)
Software is like a huge city that can expand up to 10 times the current number of residents in a moment's notice. You could move the entire city (at some expense) to run above a stretch of water. We can repaint the walls of the city at the flick of a button. Similarly, you can remove an entire quadrant of buildings on a whim. The megacities have flying routes as well as dirt roads. They become more and more complex, more and more powerful.
They also can crumble in an instant.
We've all seen it. Our favourite website is suddenly down. The airport lady smiles, noting that our delay is due to " a problem with the system". The clerk at the office is unable to serve us today, he says, because the "system" is rebooting. And every now and then your computer stops working for unfathomable reasons.
The system is everywhere. It runs our cars, our water supply, our traffic lights and our banks. People accept them for good reasons: they make things faster, more accurate, shinier and apparently less error prone than pen-on-paper or human-operated mechanical systems.
The mystery of digital items is that no one ever really sees them, touches them. Even the datacenters, our closest physical representation of the "system", are somewhere in remote facilities. We further the trouble by naming and moving things to the "Cloud".
Having been inside the city walls for what is now 9 years, I have to tell you, I'm mildly surprised computers manage to start every day. This post by Jean Baptiste Queru is a very neat explanation of all the little digital cogs inside the machine that are put in motion when you try to reach google.com via your browser. See also a more humorous take on this.
This is just you, connecting to google.com. Now imagine the system that runs our water, the traffic, our banks.
We accept that we don't know how the bits and pieces end up from one computer to the other. There's a disconnect that happens in most people heads when they try to comprehend the "system". You might as well be telling them of purple tap-dancing zebras on a giant keyboard relaying the information at the core of the "system".
My current nomenclature is that of Software Architect. Besides soliciting oh-that's-so-cute laughs from Real Architects, it entails that I create the blueprints of such a system. In order to be successful, I must gather information and get all parties to agree on a set course; find the cogs and bits that will solve the problem and think how they can work together; future-proof the system ; convince the team to follow my ideas and then stay the course; make a solution elegant and simple enough so that I can brag about it to my fellow colleagues.
The reality is fraught with multiple contributors, legacy code that few people know how it works anymore, maintenance work done just to keep it running, ambitions of young developers eager to show their skill and ready to ignore previous wisdom due to its age.
This is an industry born 60 years ago. We've rushed from platform to platform, technology to the next, improving and disrupting, dismissing entrenched principles and recycling them 10 years later. The internet is now in your pocket and the world is a virtual one.
I wish that one day we will have regained our users' trust. That software takes humans seriously so that humans will trust software. So we can be trusted the same way structural engineers are responsible for our buildings. I will probably hear back that we now have processes, methodologies, unit testing and continuous builds! That things are so much better than only 4 years ago.
It is true, somewhat. We've come out of the dark ages and started a user-centered renaissance.
We still have so much work to do.