5 ms·
I think the most interesting lessons of this story have to do with the following expectations. First, the expectation of support timelines. It seems in tech t
by russnewcomer 11y ago
I think the most interesting lessons of this story have to do with the following expectations.
First, the expectation of support timelines. It seems in tech that support is promised for products far beyond when the vendor should reasonably be expected to support them. Companies make large investments in technology that ultimately aren't long-term enough.
Lesson: Any company doing a major project where there is significant cost (as a percentage of the overall cost) in hardware or software, and that selected hardware or software is not commodity level or has low market penetration in their industry should seriously reconsider the projections of TCO, as long-term support will get increasingly expensive over the life of the project (Contrived example, supporting Windows XP via virtualization vs OS/2 Warp)
A second expectation is the timeline of viability for technologies. Non-technical business people of the past generally seemed to have an expectation of viability that was around 15-20 years. More recently, stated expectations seem shorter, but are actually not.
Lesson: Businesses that make serious investments in technology need to consider length of that investment, and technical people should probably take those estimates and double or triple them, because that's probably how long hardware/software will be in use. Companies providing technology or support need to have realistic timeframes of support.
As a corollary to this lesson, I have spent some of my career thus far doing IT support-type roles for small organizations, and while I haven't encountered quite the same level of obsolescence as the author, I have seen people using NT 4 for critical server infrastructure in 2012, I've set up DOSBOX[1] in Windows 7 for clients to continue to use that version of Lotus 1-2-3 they paid for and have been using since 1987 , and I've tried to figure out, in 2011, why Netscape Navigator on, I think System 7, ( using dial-up! ) wouldn't properly render a webpage. People keep tech a long time, and people in the tech world need to expect that, and plan accordingly.
The final expectation is one that technology companies have, which is that tech should be replaced. While there are many use cases where tech gets old, breaks, has to be replaced, there are lots of cases where it can be functional for almost indefinite periods of time, and industries that will expect such.
Lesson: Tech companies in should not neglect the future, but should also strive to design objects of technology that can last a very, very long time. Companies that do so will find a niche and make money because there will always[2] be enough customers to support them.
[1]It was going to get some use on an iPad via LogMeIn and there was some reason I've forgotten why DOSBOX was a better choice than the command prompt
[2] Subject to prevailing economic winds, of course. You can still buy buggies and buggy whips, but it's not a growth business.
- kragen 11y agoA couple of other things this inspires in me: 1. Your systems can last longer if they're based on free software, so you don't have to worry about a dependency going away and you not being able to fix it. (And of course effective copy protection here is the kiss of death.) 2. Your systems can last longer if they have less dependencies. (I tried to compile a six-months-old Guix from six months ago from source for several days. This was difficult because it depends on so many things.) 3. Your systems can last longer if the dependencies they have are more popular. Installing DOSBOX today is a lot easier than installing an emulator that will emulate the Tandy 1000 version of MS-DOS. (I think Lotus 1-2-3 had a Tandy version, right?) This is synergistic with the previous two: your free-software dependencies are still going to be a pain to handle if nobody else uses them. 4. Your systems can last longer if they're internally simpler, so that you can fix them when they do fail.
- xj9 11y agoI agree with you, but most software engineers seem hell-bent on ignoring the discipline that every other kind of engineer is required to learn in order to exercise their craft. I don't mean to say that software engineers are not engineers, but I do think we should put more emphasis on shipping correct programs rather than merely functional ones.
- bitwize 11y agoWhat often happens is that a company no longer wants to support a product that's still in use running production stuff. So the company sells off the support accounts to some other company which makes money supporting that product. This is how dBASE, filePro, and Framework (Ashton-Tate software) are still around. It's how OS/2 morphed into eComStation.