8 ms·

There's a longer term issue that appears to be missing here. At what point do you change? There must be a point otherwise we'd all be here writing COBOL/CICS w

There's a longer term issue that appears to be missing here. At what point do you change? There must be a point otherwise we'd all be here writing COBOL/CICS with some whizzy Javascript interface library. Over time it becomes harder and harder and more and more expensive to maintain old technology. Because frankly maintaining old technology is pretty boring and career destroying so you need to be paid more and more to do it. The marginal benefit of the new shiny is indeed an overhead you should try and avoid, but also you have to dodge the trap of being stuck in a technology when everybody else has moved on. Anyway back to the Adabas support...

Cthulhu_ 7y ago
Well you can sit down and do the maths; you mention Cobol, which you can actually map to the cost and availability of developers. The cost of that technological choice just keeps growing and growing. You can compare that to the cost of converting it to e.g. Java (and multiply that cost by 2-5x because it's very hard to make an accurate guess). This goes for all technological choices. The cost is not static, but varies over time depending on market forces.
- carlmr 7y ago
  If everybody stayed with the boring tech, cobol developers would be abundant and cheap.
vasco 7y ago
2-3 years after you read it on Hackernews is a good rule of thumb.
openfuture 7y ago
You never change, at some point a competitor arises that chose different technology and it kills you.
- sametmax 7y ago
  Competitors don't kill you because they chose a new tech. They kill you because they can either: - solve a new problem - solve an existing problem better - solve an existing problem cheaper A new tech MAY allow that, and it MAY be used successfully toward that objective, but even in that case, that's hardly the core of it for most cases. Not saying it does not happen, but there are much more at play.
  - trm42 7y ago
    In my experience this all boils to the fact that usually it's not the actual chosen technology stack but the missing craftmanship when making the stuff first time. Then you either end up refactoring the whole setup for years (which usually is expensive, slows down the business development velocity) or rewriting it from scratch (or as a new implementation next to the old one). If the original implementation would've been sanely made. Then making new features on top of it (or partial replacements or micro-services etc) wouldn't be that big issue. But usually these beasts are more like godzilla-level monoliths with bad architecture etc so it's probably easier to rewrite the whole thing.
thunderbong 7y ago
Adabas brought back memories. And now when I see all the hype about NoSQL, I'm remember Shirley Bassey's fantastic song - 'History Repeating'
- barbecue_sauce 7y ago
  Is NoSQL even still hyped? I thought the hype cycle had moved on to NewSQL at this point.
rlonn 7y ago
Recipe for getting things done: 1. Place every new & cool technology into mental quarantine for 3-5 years. 2. If, after that: a) the tech is still widely used, and doesn't seem to be getting overtaken by something else b) you're about to start a NEW project where the tech would help c) you're not in a rush and feel like trying something new ...then go for it. Learning complex tech that just arrived is a waste of your life, if you want to accomplish things. It's only useful if your aim is to appear knowledgeable and "in the loop" to your developer peers.
- ovi256 7y ago
  This works, but it does force you to ignore new enabling technologies that make new use cases economical, where most innovation and value creation is. You'll be very efficient at accomplishing old use cases, which is just as well, because you'll need it - the market for them is most probably commodified, very competitive, and with low margins. Dominated by big actors with economies of scale. Not a comfortable place to be. You'll probably get into very few new use cases, because by the time your 3-5 years quarantine passes on their enabling technology, they're already explored, if not conquered, by several competitors. The exception to this is new use cases without a new enabling technology, but those tend to ressemble fads, you'll have no tech moat, so again they'll be a very competitive, low margin market. New techs create value only when they solve some use case more efficiently for someone. This creates value. Not all new techs do this. God knows that especially in software engineering, people deliver new techs for fun and name recognition all the time. Managers allow it as a perk, because of the tight labor market. But it's a mistake to consider all new techs to be in this later category. New techs are also tech moats, giving you negotiating power to capture some of the created value. Without the tech moat, you better have a non-tech one (regulatory, institutional, market structure, economy of scale) because otherwise the value you capture will quickly be pushed to your marginal cost - if that - by competition.
  - macspoofing 7y ago
    You're talking about a tech stack, which is not the same as, for example, a modern web application. You can build a perfectly modern web app with 'old' Java/JEE stack, backed by an unsexy SQL-based database. You don't need Node.js with MongoDB. Techstacks very very very rarely enable new use-cases. They are the equivalent of fashion statements by young developers who haven't learned what it means to support software for 10-20 years.
virgilp 7y ago
You know, it's the same as with financial advice. Good financial advice is good.... except if absolutely everyone applies it, then it becomes a disaster. Fortunately, there's no risk of that happening. Same here. No matter what you do, leave others to try the cool new stuff & get burned by it & work to fix it (when/if possible). Stay informed, but don't be an early-adopter. It's sound advice - though it wouldn't be if everyone applied it. Fortunately, there's no risk of that happening.
- hyperman1 7y ago
  To quote Terry Prattchet: The second rat gets the cheese.
reallydontask 7y ago
I spoke once with a Microsoft consultant, he was advising us on upgrading strategy, as our customer had a mandate to be at least on version N-1, that is the customer must be on the latest major version or the version before, so at the time we were migrating off Windows 2003 as Windows 2012 was going through internal validation. He mentioned that on a bank he'd been advising, the mandate was the opposite, namely at most they could be on N-1 and were in the exact same position as we were, except that they were migrating to Windows 2008 and we to Windows 2012 as the N-1 mandate in practice meant that we'd upgrade services every other release, except when there was a waiver, which was often and explained why when I left in late 2012 we still had some Windows 2000 boxes. As a techie, it was always a pain going back to an old box as you'd try to do something and realise that it was not possible as that feature had only been introduced in later versions. Even worse, was when it was possible but extremely convoluted and error prone. It's interesting how everybody thinks that it's career suicide to support old stuff when it actual fact most people are hired for a mixture of their knowledge and their capacity to learn. I appreciate that it's lower risk to hire somebody with experience on the exact product but would you rather have an extremely good engineer with no experience in your stack or a good one with experience in your stack?
- murgindrag 7y ago
  In personal life, I do the something similar, actually. I have a state-of-the-art digital camera circa 2012, a state-of-the-art camcorder circa 2011, and similar. I'm always around five years behind the tech curve. The cost is often 1/2 to 1/10th, and I'm not sure I lose anything by being five years behind in terms of happiness or much of anything else. As with anything, there are exceptions. My phone needs security updates, and 4k displays make me more productive at work, so there were places I bought the latest-and-greatest. And when I need to develop for a platform, well, I get that platform. But for personal life? A used iPod touch 4th gen sells for $20 on eBay. XBox 360 can be had for around $40. Exceptionally nice digital cameras from a decade ago -- workhorses professional photographers used -- can be found for around $200. The way I figure, I just behave as if I were born five years earlier. I use the same technology at age 25 as was available at age 20.
  - 7y ago
murgindrag 7y ago
I'll contradict everyone here: You figure it out on a case-by-case basis. Generally, risks go down over time and with broad use. SQL, as a technology, is 100% risk-free, having been around forever, and widely used. COBOL is high risk, since while it's been around forever, hardly anyone uses it anymore, at least on modern projects. Moving your Cobol app to Android is fraught with unknown-unknown risk. Something that's been around 2-3 years is generally much lower risk than something which came out last year, and a good 10 years drives risks down further most of the time, but not always. It depend on whether people seem happy with it. Mongo seemed like a really good idea first few years, until people figured out (1) it had wonky performance issues (2) it was really hard to query for some type of queries (3) and what was the problem with postgresql again (it seems to do JSON pretty well too!)? Things change too. Java was the bedrock, stable, safe choice. It wasn't the fastest to code in, it was a bit clunky, but it was THE safe choice, and enterprises flocked to it. That is until Sun died, Oracle happened, and litigation+monetization kicked up to try to treat Java as a cash cow. The flip side is why would you use it? When I was building an app a while back, I chose React although React Native had just come out at that point. It let me build the app once, and run on web, Android, and iOS, instead of 3 times. I figured cost savings of building and maintaining one codebase outweighed the risks. On the other hand, in most cases, the upsides of switching away from Python -- now three decades old -- are usually negligible, so with the exception of a specific need (run-anywhere, above), I almost never pick something different. And the final piece is code complexity, abstraction, and modularity. I don't feel bad adapting new numerical algorithms. It's usually a few hundred lines of self-contained code. If a better algorithms comes out, I might swap it out anyways. On the other hand, a programming language or framework is a lifetime commitment. You work through all the risks and upsides, figuring maintenance is 90% of the cost, and you sometimes end up around the rules-of-thumb everyone gave. But not always. Trick is to learn probability. It give a good mental framework for estimating expected costs and benefits. You don't usually do this explicitly with equations (what's the probability-Oracle-screws-us times costs-of-Oracle-screwing-us versus cost of upgrading to Python?), but it gives a language to think about risks.
- jacques_chester 7y ago
  Oracle created a brand new market in Java support contracts which didn't exist before, so that they could enter it and make a buck (wherein FUD is a standard sales tactic for them). They probably viewed their position on the OpenJDK as subsidising a public good, which in general is slightly out of character for Oracle. Most enterprise vendors have, or will soon have, comparable products for sale. My employers have Pivotal Spring Runtime[0]. You can also get OpenJDK coverage from Red Hat[1], Amazon[2], Azul[3] and so on. Incidentally I resent that I sometimes wind up defending Oracle's decisions. I think it was globally suboptimal but I can understand their reasoning. [0] https://pivotal.io/pivotal-spring-runtime https://pivotal.io/pivotal-spring-runtime [1] https://access.redhat.com/articles/1299013 https://access.redhat.com/articles/1299013 [2] https://aws.amazon.com/corretto/ https://aws.amazon.com/corretto/ [3] https://www.azul.com/products/zulu-enterprise/ https://www.azul.com/products/zulu-enterprise/
wastedhours 7y ago
Probably when there isn't a pipeline of people across the skill spectrum who can understand, maintain and deploy that tech. If you can't find either a senior or a junior who can both use the same tech you need to perform the business task, then you might be too early or have to think about changing. The difference in your requirements for juniors and seniors probably tells you about your potential rate of change. If you're based on a recent JS framework, those two will be closer together than a finance org running on COBOL.
taneq 7y ago
You change when the new tech becomes boring. Boring indicates well known, reliable, and efficient. Play with the cool new thing in your R&D time. Stick with tried and tested in your implementation time. That's the difference between hacking and engineering.
nickjj 7y ago
For me, change happens when I see a real improvement in almost every way possible which is usually determined by building a few things and letting my brain simmer on the technology as a whole so I can look at it with a logical and unbiased perspective. I remember looking at Node when it first came out and got mildly excited, but that excitement quickly went away after writing a couple of small apps with it. It just wasn't for me. The same thing happened with Go. I didn't see enough wins to switch over to using either of them for building web apps. On the other hand, for me Rails and Flask stood the test of time. Nowadays I'm working with Phoenix and I'm past the hype phase and it looks to be another winner. But in all 3 cases (Rails, Flask, Phoenix) I typically don't switch away from them for good. They just become another tool that I know. Of course I will gravitate towards the one I'm the most happy writing code with, but it's not a black / white progression from 1 to the other. I don't think there's really a definitive answer on when to change. Like 3 weeks ago I picked up a Flask contract and it was a pleasant experience, even though I'm using Phoenix to build a side project currently. You don't always need to throw the old thing out. You can use multiple technologies in harmony. You change when you start dreading writing code in the old thing, which is very user specific. In other words, write more code and you'll quickly find out what you like and dislike.
- malvosenior 7y ago
  Go is a compiled language and Ruby/Python are interpreted scripting languages. There are domains where it's a much more appropriate choice (distributing binaries, performance sensitive code). The type system is also quite nice vs. dynamic typing (in most situations). It's weird to see people comparing Go and Python in this thread as they solve entirely different problems and shouldn't be interchangeable, not due to developer preference but due to fundamental features of the language.
  - nickjj 7y ago
    > It's weird to see people comparing Go and Python in this thread as they solve entirely different problems and shouldn't be interchangeable, not due to developer preference but due to fundamental features of the language. Yes but when Go first came out, a lot of people jumped on the bandwagon and started proposing they would use Go for web applications too. There's definitely some overlap in building web services with Go and Python so I wouldn't say they solve completely different problems. Go and Python are also pretty related for command line apps too. You could totally use either one to build a CLI tool.
snaky 7y ago
In 2016, Software AG announced that Adabas and Natural would be supported through the year 2050 and beyond. I'm not sure MongoDB will be there in 2050.
bpyne 7y ago
COBOL/CICS was supplanted mostly because mainframes were supplanted due to smaller organizations, that wanted to use computer technology, not being able to afford a mainframe. Companies could lease time. But I don't remember it being the norm. Mini's and then Unix systems allowed us to develop systems with newer technology. Wintel systems expanded it further. My point is that the new technologies came about via need: it allowed more people to utilize computer technology to solve problems. As needs change, we'll continue to see an evolution of technology to meet the needs.

Cthulhu_ 7y ago

Well you can sit down and do the maths; you mention Cobol, which you can actually map to the cost and availability of developers. The cost of that technological choice just keeps growing and growing. You can compare that to the cost of converting it to e.g. Java (and multiply that cost by 2-5x because it's very hard to make an accurate guess). This goes for all technological choices. The cost is not static, but varies over time depending on market forces.

carlmr 7y ago
If everybody stayed with the boring tech, cobol developers would be abundant and cheap.

vasco 7y ago

2-3 years after you read it on Hackernews is a good rule of thumb.

openfuture 7y ago

You never change, at some point a competitor arises that chose different technology and it kills you.

sametmax 7y ago
Competitors don't kill you because they chose a new tech. They kill you because they can either: - solve a new problem - solve an existing problem better - solve an existing problem cheaper A new tech MAY allow that, and it MAY be used successfully toward that objective, but even in that case, that's hardly the core of it for most cases. Not saying it does not happen, but there are much more at play.
- trm42 7y ago
  In my experience this all boils to the fact that usually it's not the actual chosen technology stack but the missing craftmanship when making the stuff first time. Then you either end up refactoring the whole setup for years (which usually is expensive, slows down the business development velocity) or rewriting it from scratch (or as a new implementation next to the old one). If the original implementation would've been sanely made. Then making new features on top of it (or partial replacements or micro-services etc) wouldn't be that big issue. But usually these beasts are more like godzilla-level monoliths with bad architecture etc so it's probably easier to rewrite the whole thing.

thunderbong 7y ago

Adabas brought back memories. And now when I see all the hype about NoSQL, I'm remember Shirley Bassey's fantastic song - 'History Repeating'

barbecue_sauce 7y ago
Is NoSQL even still hyped? I thought the hype cycle had moved on to NewSQL at this point.

rlonn 7y ago

Recipe for getting things done: 1. Place every new & cool technology into mental quarantine for 3-5 years. 2. If, after that: a) the tech is still widely used, and doesn't seem to be getting overtaken by something else b) you're about to start a NEW project where the tech would help c) you're not in a rush and feel like trying something new ...then go for it. Learning complex tech that just arrived is a waste of your life, if you want to accomplish things. It's only useful if your aim is to appear knowledgeable and "in the loop" to your developer peers.

ovi256 7y ago
This works, but it does force you to ignore new enabling technologies that make new use cases economical, where most innovation and value creation is. You'll be very efficient at accomplishing old use cases, which is just as well, because you'll need it - the market for them is most probably commodified, very competitive, and with low margins. Dominated by big actors with economies of scale. Not a comfortable place to be. You'll probably get into very few new use cases, because by the time your 3-5 years quarantine passes on their enabling technology, they're already explored, if not conquered, by several competitors. The exception to this is new use cases without a new enabling technology, but those tend to ressemble fads, you'll have no tech moat, so again they'll be a very competitive, low margin market. New techs create value only when they solve some use case more efficiently for someone. This creates value. Not all new techs do this. God knows that especially in software engineering, people deliver new techs for fun and name recognition all the time. Managers allow it as a perk, because of the tight labor market. But it's a mistake to consider all new techs to be in this later category. New techs are also tech moats, giving you negotiating power to capture some of the created value. Without the tech moat, you better have a non-tech one (regulatory, institutional, market structure, economy of scale) because otherwise the value you capture will quickly be pushed to your marginal cost - if that - by competition.
- macspoofing 7y ago
  You're talking about a tech stack, which is not the same as, for example, a modern web application. You can build a perfectly modern web app with 'old' Java/JEE stack, backed by an unsexy SQL-based database. You don't need Node.js with MongoDB. Techstacks very very very rarely enable new use-cases. They are the equivalent of fashion statements by young developers who haven't learned what it means to support software for 10-20 years.

virgilp 7y ago

You know, it's the same as with financial advice. Good financial advice is good.... except if absolutely everyone applies it, then it becomes a disaster. Fortunately, there's no risk of that happening. Same here. No matter what you do, leave others to try the cool new stuff & get burned by it & work to fix it (when/if possible). Stay informed, but don't be an early-adopter. It's sound advice - though it wouldn't be if everyone applied it. Fortunately, there's no risk of that happening.

hyperman1 7y ago
To quote Terry Prattchet: The second rat gets the cheese.

reallydontask 7y ago

I spoke once with a Microsoft consultant, he was advising us on upgrading strategy, as our customer had a mandate to be at least on version N-1, that is the customer must be on the latest major version or the version before, so at the time we were migrating off Windows 2003 as Windows 2012 was going through internal validation. He mentioned that on a bank he'd been advising, the mandate was the opposite, namely at most they could be on N-1 and were in the exact same position as we were, except that they were migrating to Windows 2008 and we to Windows 2012 as the N-1 mandate in practice meant that we'd upgrade services every other release, except when there was a waiver, which was often and explained why when I left in late 2012 we still had some Windows 2000 boxes. As a techie, it was always a pain going back to an old box as you'd try to do something and realise that it was not possible as that feature had only been introduced in later versions. Even worse, was when it was possible but extremely convoluted and error prone. It's interesting how everybody thinks that it's career suicide to support old stuff when it actual fact most people are hired for a mixture of their knowledge and their capacity to learn. I appreciate that it's lower risk to hire somebody with experience on the exact product but would you rather have an extremely good engineer with no experience in your stack or a good one with experience in your stack?

murgindrag 7y ago
In personal life, I do the something similar, actually. I have a state-of-the-art digital camera circa 2012, a state-of-the-art camcorder circa 2011, and similar. I'm always around five years behind the tech curve. The cost is often 1/2 to 1/10th, and I'm not sure I lose anything by being five years behind in terms of happiness or much of anything else. As with anything, there are exceptions. My phone needs security updates, and 4k displays make me more productive at work, so there were places I bought the latest-and-greatest. And when I need to develop for a platform, well, I get that platform. But for personal life? A used iPod touch 4th gen sells for $20 on eBay. XBox 360 can be had for around $40. Exceptionally nice digital cameras from a decade ago -- workhorses professional photographers used -- can be found for around $200. The way I figure, I just behave as if I were born five years earlier. I use the same technology at age 25 as was available at age 20.
- 7y ago

murgindrag 7y ago

I'll contradict everyone here: You figure it out on a case-by-case basis. Generally, risks go down over time and with broad use. SQL, as a technology, is 100% risk-free, having been around forever, and widely used. COBOL is high risk, since while it's been around forever, hardly anyone uses it anymore, at least on modern projects. Moving your Cobol app to Android is fraught with unknown-unknown risk. Something that's been around 2-3 years is generally much lower risk than something which came out last year, and a good 10 years drives risks down further most of the time, but not always. It depend on whether people seem happy with it. Mongo seemed like a really good idea first few years, until people figured out (1) it had wonky performance issues (2) it was really hard to query for some type of queries (3) and what was the problem with postgresql again (it seems to do JSON pretty well too!)? Things change too. Java was the bedrock, stable, safe choice. It wasn't the fastest to code in, it was a bit clunky, but it was THE safe choice, and enterprises flocked to it. That is until Sun died, Oracle happened, and litigation+monetization kicked up to try to treat Java as a cash cow. The flip side is why would you use it? When I was building an app a while back, I chose React although React Native had just come out at that point. It let me build the app once, and run on web, Android, and iOS, instead of 3 times. I figured cost savings of building and maintaining one codebase outweighed the risks. On the other hand, in most cases, the upsides of switching away from Python -- now three decades old -- are usually negligible, so with the exception of a specific need (run-anywhere, above), I almost never pick something different. And the final piece is code complexity, abstraction, and modularity. I don't feel bad adapting new numerical algorithms. It's usually a few hundred lines of self-contained code. If a better algorithms comes out, I might swap it out anyways. On the other hand, a programming language or framework is a lifetime commitment. You work through all the risks and upsides, figuring maintenance is 90% of the cost, and you sometimes end up around the rules-of-thumb everyone gave. But not always. Trick is to learn probability. It give a good mental framework for estimating expected costs and benefits. You don't usually do this explicitly with equations (what's the probability-Oracle-screws-us times costs-of-Oracle-screwing-us versus cost of upgrading to Python?), but it gives a language to think about risks.

jacques_chester 7y ago
Oracle created a brand new market in Java support contracts which didn't exist before, so that they could enter it and make a buck (wherein FUD is a standard sales tactic for them). They probably viewed their position on the OpenJDK as subsidising a public good, which in general is slightly out of character for Oracle. Most enterprise vendors have, or will soon have, comparable products for sale. My employers have Pivotal Spring Runtime[0]. You can also get OpenJDK coverage from Red Hat[1], Amazon[2], Azul[3] and so on. Incidentally I resent that I sometimes wind up defending Oracle's decisions. I think it was globally suboptimal but I can understand their reasoning. [0] https://pivotal.io/pivotal-spring-runtime https://pivotal.io/pivotal-spring-runtime [1] https://access.redhat.com/articles/1299013 https://access.redhat.com/articles/1299013 [2] https://aws.amazon.com/corretto/ https://aws.amazon.com/corretto/ [3] https://www.azul.com/products/zulu-enterprise/ https://www.azul.com/products/zulu-enterprise/

wastedhours 7y ago

Probably when there isn't a pipeline of people across the skill spectrum who can understand, maintain and deploy that tech. If you can't find either a senior or a junior who can both use the same tech you need to perform the business task, then you might be too early or have to think about changing. The difference in your requirements for juniors and seniors probably tells you about your potential rate of change. If you're based on a recent JS framework, those two will be closer together than a finance org running on COBOL.

taneq 7y ago

You change when the new tech becomes boring. Boring indicates well known, reliable, and efficient. Play with the cool new thing in your R&D time. Stick with tried and tested in your implementation time. That's the difference between hacking and engineering.

nickjj 7y ago

For me, change happens when I see a real improvement in almost every way possible which is usually determined by building a few things and letting my brain simmer on the technology as a whole so I can look at it with a logical and unbiased perspective. I remember looking at Node when it first came out and got mildly excited, but that excitement quickly went away after writing a couple of small apps with it. It just wasn't for me. The same thing happened with Go. I didn't see enough wins to switch over to using either of them for building web apps. On the other hand, for me Rails and Flask stood the test of time. Nowadays I'm working with Phoenix and I'm past the hype phase and it looks to be another winner. But in all 3 cases (Rails, Flask, Phoenix) I typically don't switch away from them for good. They just become another tool that I know. Of course I will gravitate towards the one I'm the most happy writing code with, but it's not a black / white progression from 1 to the other. I don't think there's really a definitive answer on when to change. Like 3 weeks ago I picked up a Flask contract and it was a pleasant experience, even though I'm using Phoenix to build a side project currently. You don't always need to throw the old thing out. You can use multiple technologies in harmony. You change when you start dreading writing code in the old thing, which is very user specific. In other words, write more code and you'll quickly find out what you like and dislike.

malvosenior 7y ago
Go is a compiled language and Ruby/Python are interpreted scripting languages. There are domains where it's a much more appropriate choice (distributing binaries, performance sensitive code). The type system is also quite nice vs. dynamic typing (in most situations). It's weird to see people comparing Go and Python in this thread as they solve entirely different problems and shouldn't be interchangeable, not due to developer preference but due to fundamental features of the language.
- nickjj 7y ago
  > It's weird to see people comparing Go and Python in this thread as they solve entirely different problems and shouldn't be interchangeable, not due to developer preference but due to fundamental features of the language. Yes but when Go first came out, a lot of people jumped on the bandwagon and started proposing they would use Go for web applications too. There's definitely some overlap in building web services with Go and Python so I wouldn't say they solve completely different problems. Go and Python are also pretty related for command line apps too. You could totally use either one to build a CLI tool.

snaky 7y ago

In 2016, Software AG announced that Adabas and Natural would be supported through the year 2050 and beyond. I'm not sure MongoDB will be there in 2050.

bpyne 7y ago

COBOL/CICS was supplanted mostly because mainframes were supplanted due to smaller organizations, that wanted to use computer technology, not being able to afford a mainframe. Companies could lease time. But I don't remember it being the norm. Mini's and then Unix systems allowed us to develop systems with newer technology. Wintel systems expanded it further. My point is that the new technologies came about via need: it allowed more people to utilize computer technology to solve problems. As needs change, we'll continue to see an evolution of technology to meet the needs.