This fellow makes some interesting points, and challenged my thinking in interesting ways, but ultimately I think his argument fails: I don’t think software is buggier than it used to be. I’m old enough to remember Blue Screens of Death in Windows. And I didn’t trust Windows to sleep or hibernate a laptop until Windows 7. I am old enough to remember regularly getting “Bad F-Line Error” in Mac System 7. I’m old enough to remember when neither my IDE nor my word processor had auto save of any kind. Lose power? Lose your work. I am old enough to remember when my iPhone couldn’t meaningfully multitask. I am old enough to remember Windows software installations grinding to a complete halt over missing or incompatible DLLs. I am old enough to remember Quarterdeck Extended Memory Manager to get my computer to address more than 640k of memory. DESQview, now allowing multi-tasking in DOS!
In short, operating systems are so much more capable and stable than they were 30, 20 and 10 years ago that it’s hard to compare.
I am old enough to remember when building a literal pile of desktop machines seemed like the best way to scale an application at a serious enterprise. (5 nines lol.) Why didn’t we just run it in the cloud? There was no “cloud.” Enterprise software applications were so much less stable 20 years ago. I think I already mentioned in this thread that “the computers are down” was a standard reason for delays at places like the airport or the DMV. (5 nines lol.) I cannot remember the last time I heard that line from someone behind a counter or on a phone.
Software certainly is buggier than it should be. MS Outlook seems to have forgotten how to manage numbered lists properly (!). But is it worse than it was even 10 years ago? I doubt it. I’m strongly biased in favor of arguments that things are getting crappier. But I’m not buying it here.
My complaint about software is that it has become an idol. Software was made for man, but instead man is made to accomodate software. Among people, it is easy to agree to change procedure or make this or that exception and go by a new set of rules. But once things are set up in software, every person must conform to what the system requires and it is extremely difficult to change. Thus the servant becomes the master.
Not always. Ten years ago, people at the systemwide office overseeing the individual university campuses in my state got the bright idea that they could replace the ageing HR and payroll systems separately maintained by each campus with centralized modern software. They projected a cost of about $300 million but with $750 million in long-term savings. It sounded fishy to me, and in a perhaps never before seen alliance, the faculty joined with the administration at each campus, and all campuses united together to oppose the plan. To no avail – the systemwide office forced it through. It turned out to be a fiasco, but that did not become fully apparent until after all of the people who originally proposed it had safely moved on to greener pastures. The upgrade took nine years to complete, and a state audit reported that the cost ended up being about $900 million with ZERO long-term savings. And students are paying the price in higher tuition.
Why did this happen? Well, I’ve never heard the systemwide office provide any sort of explanation. My best guess as to the proximate cause is that the HR and payroll processes were vastly more complex than they realized and not amenable to easy simplification considering all the regulations, sources of revenue, and employee types across ten campuses, several with medical centers. The ultimate cause was the belief that software can magically decrease costs when ordered by managers who have the boldness to force change on an enterprise of which they have little on-the-ground knowledge or experience.
In the old days I could deal with a problem by calling up or walking over to the local HR office. That’s all gone. Now I must wade through a web portal and try to get a low-level agent to escalate my issue or (if I am persuasive enough) give me an unpublished phone number that would allow me to directly contact the centralized benefits office. I get better customer service from my cable company.
I’m a geek, and it has taken me a long time to understand this basic principle. But once you’ve got it firmly in your brain, you can see the tyranny of software - but, really, the tyranny of the people foisting the software upon you - everywhere.
This is true of any tool or technology. Think of how driving a car regularly changes your brain, not to mention your church or your social life. People who understand how to use the tools necessary to build a house view the world in different ways than those who don’t. (“You don’t want that wall there? It’s not load-bearing. I’ll come over this weekend and remove it.”)
This is the two-edged sword of scaling. Systems with lots of exceptions don’t scale well (including in software, actually). My current client’s current software is extremely open and flexible. This has led to (among other raging dumpster fires) the revelation that some customers have maintained credit balances for years and no one is sure if the credit balances are real (i.e. just cut them a check and get it off the books) or if the credit is due to a deposit for service that was rendered but never billed. There are certainly business processes that could help this, but with better software they wouldn’t be needed.
There is something beautiful about small systems. But they are out of fashion at the moment.
And actually I’d argue that software changes to suit humans far more than any other technology, for good and for ill. My house has hardly changed at all in 25 years. If you took my car back to 1950, it would seem a technological marvel, but anyone would be able to hop in and drive it away.
There is no boondoggle like a software boondoggle. Suffice it to say, there are project management techniques that can head off disasters like what you relate, but the closer one gets to a .gov domain name, the more allergic people seem to be to them. The techniques raise apparent risks in the short run by reducing apparent control. But something like this could have been headed off way upstream. That’s small comfort to you, no doubt.
I’ve learned through conversations with men at my church about the concept of tools coming with assumptions. A hammer presumes some things should be hit with a hard object. So a wise father teaches his sons to use it only properly. And the Amish do not shun all technology. In some cases they make careful, wise choices on how to adopt parts of some technologies. I’m not claiming they get it right, but that they may provide some good examples.
Yes, not always, but I do see it happening right now. Thanks for the detailed story, it’s an all too common thing. Makes me think of how and why Netscape died via delay and bloat.
But I very intentionally referred to HR replacements happening currently. Many companies have attempted to overhaul the national/global flight reservation system over the decades, none yet successfully. But I’ve seen decent success in the last year at two Fortune 500 companies (top 50) who purchased software from a Fortune 50 company.
The devil is indeed in the details. A huge part of the contract negotiation process, and a major contributor to the success of the project, is how much and how well the system can be customized to the needs of old, large corporations.