My main reason for stating that, is this: that shiny new stuff at the front - it's relatively unstable and mostly untried. I'll take version 4.628 over version 5.0 every time. At least for those things we depend on for our business. And undoubtedly, the company that's selling you 5.0 will tell you about all the levels of testing it's been through. And sure, 5.0 will have its fan base, members of which will scoff and roll their eyes when you tell them you're still using an earlier version.
Don't join the fan club. I don't care if all the cool kids are doing it.
Because the bottom line is this: no amount of testing holds a candle to the "testing" it will get in the hands of users in a production environment. That is precisely how we got from 4.0 to 4.628 in the first place. Yes, it is a good thing that 200 users beta-tested your software. That does make a difference. But it's nowhere near as significant as 200,000 users testing it. Or two million.
In 2001, Microsoft released Internet Explorer 6.0. It included many fixes and enhancements. It was also a security nightmare. Malicious coders were able to run arbitrary code on users' computers if the user happened to visit the wrong website. And there was not just one, but multiple security holes in I.E. which allowed this. Though Microsoft released many patches to try to fix the problems, in 2004, the U.S. Computer Emergency Readiness Team urged users to discontinue using Internet Explorer at all. If you want a few more well-known examples, PC World lists this and many other technological terrors in its article The 25 Worst Tech Products of All Time.
Beyond limited testing, with technology that's new, there's the whole chicken-and-egg problem. My wife recently got a manufacturer's latest-and-greatest-model phone. She went to a popular site that interfaces with your phone. But it won't interface with hers. Not yet.
See, the people that write the interface don't work for the company that designs the phones. Often the developers writing really cool programs for your devices aren't doing so with the manufacturer's blessing, so, they have to wait for a piece of hardware to actually exist before they can write software for it. And it's a trial-and-error process.
Trial-and-error. It's an old expression with a very relevant meaning to the topic of new technology. It's a process that turns an exciting new idea into a foundation you can build your business on. People who insist on being on the cutting edge of technology are not learning the lessons of technology - that its advancement isn't charted with a simple line. It's more like a path with many forks that dead-end. And for every Google-like success, there are ten Pets-dot-com-like catastrophes.
And speaking of the dot-com bubble: that was when investors learned that the web was going to transform business. Subsequently, of course, they learned that it can transform business, but that the transformation doesn't magically occur when you tack a web interface onto a bad business idea. Stated another way, good technology doesn't yield good business.
Let's talk about some really old stuff. There are still many companies running multitudes of COBOL programs in production, and the only good thing I can say about them is this: they work. This is a point which should not be taken lightly. These are programs written in an ancient programming language, but they are still generating money for the companies that use them.
I worked for a company that had an application written in BASIC. Their business idea was solid, and their business made plenty of money. They defined their business process and the software was developed around it. Changes to the software were deployed very rapidly, and it was also very stable.
Just because your car is pretty, doesn't mean it can't break down when you need it most. The company I worked for was in the opposite situation. They had a useful and dependable piece of software written in a language with a bad reputation among developers and non-developers alike. But the reputation of the technology had nothing to do with the business being done.
I was in another position where we needed to automate the creation of reports from other reports. Not a terribly difficult job, only our department wasn't allowed access to the compilers on the mainframe where the reports existed. I wrote the report-scraper in CLIST, which is not too far removed from programming using DOS batch language. It definitely wasn't the right tool for the job - I can still remember writing code to compensate for CLIST not being able to add decimal numbers! And yet, it was the only thing available to me by which I could automate the process. And that automation saved 26 man-hours per week of work that had been spent manually compiling the numbers.
Don't get me wrong, companies should make strong efforts to progress in their technology. Technology has enabled companies to make great leaps in the amount and even the quality of work they are able to do. The moral instead is this: don't confuse the state of your business with the state of your technology. Make progress, but at a reasonable pace. Don't leap fearlessly to every new thing there's a buzz about. If your competition is on the cutting edge of technology, and you aren't, rest easy. They'll go through all the headaches and expense of ironing out the new technology so that, later, when it's stable, you can use it yourself.
