Complacency Causes Legacy Developers to Reject Technology Upgrades

Developers of legacy products, applications, development kits, or even development languages seem to be suffering from an epidemic as they become complacent in the technologies that they use.

An epidemic plagues the software industry due to complacency by many legacy developers and project managers. Rejection of new, more powerful options seems to be more prevalent by these obstinate programmers, to the detriment of their products and organizations.

Many workers in contemporary business feel that the technology offered to make day-to-day operations more efficient or automated seems to move forward exponentially faster than anyone can hope to keep up with. Constant innovation, modernization and increasing focus on automation makes it hard to manage the steps to keep up with the constantly evolving market. This process can be even more difficult for software companies that have been in business for a very long time.

Developers of legacy products, applications, development kits, or even development languages seem to be suffering from an epidemic as they become complacent in the technologies that they use. They reject any notion of moving forward to new, and often more powerful, options for the product.

The result of this mentality can leave software companies fighting with their own legacy product or code to keep up with the breakneck speed that evolving technology allows willing competition to deliver. Developers spend their time deep in code working on deliverables to enhance or fix the product to meet user base expectations. You’d expect developers to form an attachment to the development kits, coding style, or even the dreaded workaround culture that creeps into software companies.

We also expect that when a development manager comes to their team with a new software development kit or platform that could modernize the product, developers often voice the first and most boisterous opposition to the change. Understandably, this can be a daunting prospect.

What does this mean for developers?

Getting complacent in the daily routine is human nature. Change is often scary, and in the technology world, it adds more stress to an already stressful job. Development teams spend much time trying to keep up with ever evolving requirements management passes down to them. No developer wants the prospect of piling on a new technology to analyze, create a proof of concept, and deliver on top of the already stressful day-to-day requirements. Without management allowing more time for a POC, or pulling back on deliverables during the learning process, developers get overwhelmed.

In some cases, developers worry that they’ll lose their jobs if they do not adapt and thrive to new technological advances. This creates a culture of pushing back against innovation to maintain job security even if it is not in the best interest of the company. In extreme circumstances, this means legacy developers defend outdated or overly complicated business rules or processes until they are blue in the face. Business logic overcooked by hundreds of hours of development, meetings, and reviews often leaves a developer too close to the project. Even small criticisms can trigger a negative reaction.

This is not to suggest that the developer’s concerns are not unfounded. Picking up what you have done and moving forward with something new will not be easy or painless by any means. But if they understand that moving toward technology that is easier to use, maintain and deploy makes their life easier from a long-term perspective, they will almost always be more willing to accept the change. The trick is getting your developers in the right mentality.

How are software companies affected?

For software companies, this mindset can restrict an organization’s ability to keep up with their competition. That’s fatal to their business. Within the business intelligence world, a software company may keep using an expensive development resource to maintain an outdated legacy platform or homegrown solution instead of searching out modern third party platforms. In the mobile application world, a development team may devote time to delivering one native Android application to their end user base. But their competition may use innovative hybrid application development tools getting them to market faster across every mobile platform.

If this sounds oddly specific, that is because I spent over three years as a mobile application developer and saw the ramifications of this mentality in the senior developers on my team. In just under four years, two different senior level software engineers led the mobile development effort.

The first of these was a native mobile developer to his core. When new management took over they chose a hybrid mobile development path. The senior level engineer took it upon himself to develop the same application in native iOS in his free time. He wanted to prove he could do it just as easily as using one code base to develop for both. Infighting between the senior developer and the management team brought the rewrite into a hybrid technology to a complete standstill. That held up the development team’s ability to deliver for a little over one year.

One developer’s unwillingness to adapt to new technology put the product on hold for an entire fiscal year. When the second senior level engineer took over, the mentality instilled by the first had clouded his ability to objectively examine the new technology to speed up development and time to market. Eventually, both lead engineers either left on their own accord or the company removed them from their roles. Unfortunately, the product never recovered from the initial pushback.

How can you avoid this?

In this situation, software companies could establish the product’s direction earlier and make the necessary adjustments to facilitate their vision. Clearing up a developer’s schedule to give the proper amount of time to scope and adjust to new technologies can help with the development team’s willingness to change and their morale.

Including the development team in the evaluation process gives an important perspective to the technology that is being reviewed. But it’s important to consider the pushback mentality when gathering opinions. If the development manager decides that updated technology is the proper path for your business, the company may need to make internal changes to move forward.

There are so many options to consider when trying to upgrade the technology behind product development in today’s market. Making sure your development team always looks to the future can be a daunting, but rewarding task. If development teams objectively look at potential changes to their product from a platform, development kit, or even language perspective, a business can thrive in the modern-day software world.

28 Comments

  • Andrew says:

    Great article. I known this first hand as well. Also just recently seen the reverse where the company wouldn’t follow the recommendations put to them to modernise their platforms and the writing is nor well and truly on the wall for them.

  • Pete Dashwood says:

    It isn’t complacency that makes ME resist upgrades; it is the fact that I am in the middle of a critical development, my system gets “upgraded” and suddenly, nothing works… When we have rollouts that can be trusted, when updates DON’T cause problems for developers, THEN I’ll gladly embrace something new. (I started writing COBOL decades ago on mainframes and have progressed to C# and Java on the Network, but I have deliberately deferred going into mobile development because the platforms are too flaky and the returns are poor.)

  • Mukesh Kumar says:

    Such a awesome article. Really like the idea of putting emotions of every party in an elegant way. Yeah, this is the truth that seniors or people with consistent experience of some technology are always in denial mode. Because they’ve learned something over the period of time. So, if their learning is being declared as outdated and they are asked to upgrade themselves, indeed, they’ll find it painful and to some heartbreaking. We should focus on a middle way that can actually help them becoming more adaptive towards changes rather than becoming resistive. Change in development and delivery process is required along with learning aspects.

  • steve says:

    YES!!
    Lets all jump on the bandwagon for THE NEXT BIG THING….

    Just PROVE to me first that it isn’t all fanboy smoke and mirrors.. please?

  • NoWay says:

    Please … what are you – 12 years old? The development of trained, experienced human capital and the costs in time and money of sales and attainment of market share will ALWAYS have a different cradle-to-grave life-cycle overlay than new languages and development kits, that come out every 2 weeks. It will take you years to develop a ‘bigger picture’ view – put those years in, before espousing ‘expert’ advice.

  • Brad Stevens says:

    Its not complacency, it’s not having the resorted to do the regression testing, the security testing, and it’s venot s dumping relatively untested products on the market and blaming complacency insteadof their own ineptitude for not getting acepted by the industry.

  • Greg says:

    except everything new…. on the last (almost 10 years) are 1 step forward… and 2 backwards… specially regarding resource abuse… and disrespect with programmers that learned how to control the machine… and are now expected to be controlled by the machine more than never… with sooo much constrained and limited behaviors… designed to help the masses that are programming illiterates… is like changing all olympic rules to integrate people with disabilities to be able to compete on regular class… a total absurd…

  • doug_b says:

    Yawn. After the product is ported / massaged / rewritten – you still have the same app. I’ve been in this profession for 46 years – the upgrades are the biggest racket and waste of time there is. Now excuse me while I go back and learn my 29th programming language – that will be better than all the others that I know.

  • stevev says:

    As a “legacy developer” myself, you have to look at all those new technologies that are in the trash heap today.
    The bleeding edge is red for a reason.

  • Complacency doesn’t causes ‘Legacy’ Developers to Reject Technology Upgrades. Smart developers realize every company that exists now is just reinventing the wheel. A new language comes along because a developer doesn’t like how another languages handles one specific thing, then tries to develop a new one to corner you into their specific set of products, and which also ends up with the same problems or ever worse different problems (Go, Swift are examples). We have systems that are using upwards of 20 layers of abstraction which still take just as long develop applications as it did back when people were using BBx and require server farms for them to operate even for a handle full of users. This of course goes with the time-sharing business model we have, which was the exact model everyone rejected when IBM was doing it with mainframes.

    Mathematics has tested the time, and no one wants to go back and change all of the notation for one person to understand it. You’re required to learn the existing notation. Software shouldn’t be any different. Get real and stop writing stupid blogs. I doubt you will post my response.

  • Jerry Sparkman says:

    Byron, stop being a troll…it sounds to me that you are one of those developers that are stuck in a particular technology and don’t want to hear about or learn about any new technologies. That’s fine if you want to be left in the past.

  • doug_b says:

    @Jerry: Byron is not being a troll. I received my MS in Comp Sci in 1971. Been programming ever since. IMO – the constant change in the software industry now makes it an undesirable, dead-end, burn-out JOB (not a profession, but a job). Imagine all the time spent relearning and rewriting the same app in some ‘new and better’ language. Time that could be spent with your family, or doing any number of things to improve yourself.

    I was lucky. I was in it at the beginning. Never thought it would go ‘through the roof’. I made a six figure living in the mid 80’s through ’05. This is no more. The occupation is now flat. There is nowhere to go. Does anyone really want to be a nano-manager project leader or worse IT director? And besides, how many of these positions are there?

    My advice is if you’re considering IT – look elsewhere. If you’re programming right now – plan an exit strategy.

  • Jerry Sparkman says:

    @doug_b: I’ve been in web development since 2000 and some of the newer frameworks make it easier to put applications together. Why would I plan an exit strategy for an area that is exploding right now with web applications and mobile applications everywhere?

  • Bhaskar says:

    Great article and really helpful

  • @Jerry Sparkman, I guess I am stuck on a particular technology. It is called the computer. The same out-dated technology you’re stuck on. Calling someone a troll, doesn’t make them one. All it does is show you’re ignorant about facts and have no other way to defend your argument.

    At some point in time it all becomes the same thing, and becomes about lining someones pocket book. I’ve been developing since the 1980’s. I know more computing technologies than most, I’ve never been one to push away something that was good. What is happening today is centralized computing under the auspice of “The Cloud”. Eula agreements used to be on a single card, now they’re more than 10 pages long and you have to give up all of your rights to just about everything including your privacy and your associates privacy, unbeknownst to them.

    People push “new” technologies, believing they’re new, when they’re not. One great example is Haskell. That language is older than Java, but if you ask any developer about it, they will claim it is a new technology. I suggest you pull your head out of “The Cloud” and think about how technology and specifically your data was personal at once.

    Here is a great example of a company that got bit in the rear from “new” technology and outsourcing. British Airways moved their entire infrastructure to the cloud, and their entire development staff to India. They were so stupid and believed in this “NEW” technology, they didn’t think about using an “OLD” technology called backup software.

  • kingpoop says:

    Complacency is not a bad thing. In fact, it has proven to be more cost effective and a wiser choice from my developer experiences over the past 27 years. I began professionally developing after college in 1985. It usually boils down to individual egos that want to prove themselves by pushing for some new technology or framework that actually did not contribute to the bottom line in the short run or long run. I have seen this countless times in micro computer industry, but not as much in the mid-range, mainframe, or supercomputer industry.

    The old school methods work the best and they always will outperform any new kid on the block because they have time-tested and proven institutionalized knowledge that works right the first time, everytime. If it’s not broken and contributes to the bottom line then don’t fix it otherwise you are doing nothing more than putting the company at risk. What does every company feed on? Money. It’s no different than telling yourself you are going to stop eating what you normally eat and try something completely new, unproven and different from what you are used to consuming. Want to risk your health because some new joker(s) show up with a big ego and act like they know what’s best for you? Go ahead and the complacent developers will always be the ones coming to the rescue.

  • You are right. Except for the hybrid app. Unless it’s a dumb app, you should never ever go with hybrid. Look at what facebook did.
    Programming is challenging, with all the new technologies, but you don’t have to learn them all, it’s enough to pick up the proven ones, not the bleeding edge.

  • SQLGuru says:

    I think there’s a fine line between “complacency” and using tried and true approaches to software development. I’ve been developing database-driven applications since the early 80’s, and I also teach courses on how to design and build database applications correctly. Currently, I’m working on a project that, if it were up to me, would be yet another relational database driven solution. The back-end would be built of the tried-and-true methods of 3rd normal form, with well tuned views and stored procedures to maintain the data. In the middle tier, I’d use the latest in web API technology, so that the front end developers can build the most beautiful, responsive, mobile-friendly apps. I’d build it so that the back-end would be strong and stable and long-lasting, and have the ability to be ported to whatever cloud makes sense over time. The middle and front-end systems developers can go nuts trying to keep up with the latest and greatest, and I’ll find myself right in there learning the latest cool widget for displaying the data. Because in my mind, it’s the perfect blend of the old and the new. Our small, focused customer base (no more than 25 users) would benefit from my 30 years experience of successfully doing these things.

    But it’s not up to me. The main contractor (I’m just a sub-contractor) hired a guy who speaks in terms of microservices, NoSQL and all other manner of *new sh!t* that has no place in this very straightforward business problem. I have voiced my concerns about being on the bleeding edge, but I am being branded as “complacent, old school, reluctant to change, dinosaur” etc… even though there is not a single member on this small development team that has any experience in the new sh!t. I have said many times to management: “They are choosing a technological approach based solely on the fact that it is new”, and that “the NoSQL approach doesn’t fit here”… but it’s falling on deaf ears.

    I asked for a chance to do prototyping (I really don’t need to prototype my idea, since it has already been successful… but I want to try some new stuff for workflows), but no money for that… But get this. One of the other developers says this to me: “Hey, just get on board! We can learn all this new technology while building the project! Why doesn’t that excite you?” Umm… because deadlines? Because reputation? Because budget?

    As KingPoop says: Go ahead and the complacent developers will always be the ones coming to the rescue.

  • Jordan Marr says:

    The headline reads like something straight out of The Onion.

  • Technical John says:

    Wow… I guess your article worked to attract some views and really stepped on some nerves!

    I’ve been in this game for “only” about 20 years, and it shocks me sometimes how some programmers have completely lost sight of the PURPOSE of software. It’s an interface between the human and the computer. Both Humans and computers are changing all the time. Humans change because they learn, and in turn the computer changes in response. This means that the LANGUAGE of the interface will change over time, to express the relationship in new ways.

    For example, when IBM floated the idea of a server-client architecture, it was rejected for 2 reasons: Humans had not yet learned how a networked existence could benefit them, and computers were waaaaaay too slow to network to each other efficiently. Move forward 30 years, and hey look at that, IBM was ahead of its time, but they are fading away because THEY WERE NOT FLEXIBLE NOR HUMBLE.

    Software is only a part of the picture anyway. Those who rode the bubble of 6 figure incomes for “software engineers” somehow got the idea that you could focus on one language, and one version of the computer, and one level of understanding by humans, and think that it would hold them forever… Well, guess you should go back to the Model-T, because why would we need anything different than that?!?!

    Software is a PART of a larger whole, and those who recognize this will contribute to a TEAM, willing to cross-train, and simply learn new things. Software programmers should have been learning how to LEARN, not digging a hole to a dead end mentality.

    This article is well written, and based on the responses shows how true his words can really be.

  • Here’s an interesting experiment for you.
    Write a program that calculates the square root of 1000 floating point numbers.
    First, write it in Fortran, then write it in ‘C’, then C++, then perl, then java, php, ruby or anything else ‘modern’.
    Then compare the run times, and ask yourself why Fortran produces the fastest run time.
    Then look at the other times, and see how much of an advance has been made in software languages.
    Have fun.

  • dav0id says:

    I read the first paragraph of this article and immediately thought “complacency or fatigue?”. Why switch to every shiny new thing (with a all the bugs that come with it) just for the sake of being new? Try being a maintenance programmer for a few years and you’ll appreciate the benefit of “old” (i.e. tried and tested) technology.
    Now to go back and read the rest of the article…

  • Marc Palacios says:

    Learning new technology and being proficient and productive with it takes time and thus money. To make real work you *must* stay with it for awhile. It doesn’t matter if it’s the last technology, but if it’s suitable technology for your project. Making the effort of upgrading to a new technology must be justified by a real need, not just because it’s newer. As an IT developer (firmware, software, hardware, whatever) your true goal is to complete real projects that go to market and behave according to its design specifications. If you spend all your time re-learining the nth upgrade iteration that serves the same purpose as the old one but in a different manner, you don’t produce anything useful.

    Some call old technology obsolete or useless, just because it’s not new. But we can also call old technology mature, tested, reliable. I’m not against change or upgrade. I’m against blindly upgrading to anything newer without questioning its real benefits.

  • JaFO says:

    Ever tried telling your customers/management that your next version will be a high risk tech-upgrade with zero new features that might provide benifits later ?

    Chances of getting the resources for that kind of stuff are practically zero, unless they happen to have believe the hype and are kept ignorant of the risks & viability of the ‘upgrade’.

    One can only do this kind of thing if the software company has the resources to do R&D so any switch in technology can be done with minimal risk.
    Good luck getting something like that started when management is not thinking 2 – 3 years ahead.

    Also do not underestimate the need for stability & comfort from the customers’ point of view.
    Why would they upgrade when there are no new features that benifit them ?

  • Philip Oakley says:

    Have you noticed that teenagers never learn? They always go down into the basement to meet the current version of the Zombie Apocalypse. Then they grow up a little, but new teenagers come along. The young adults do similar things, then they reach thirty. In your forties, maybe fifties, you start counting in decades, … Some lessons are learnt, most are not.

    There *will* be good stuff amongst the latest and greatest, but don’t be blinded by too many shiny things. Mainly it’s that Humans do not change as rapidly as the technology

    For a nice little read, have a look at “The life cycle of a Silver Bullet” by Sarah Sheard. It may be quite ‘old’ now, but see if it still rings true? (http://freyr.websages.com/Life_Cycle_of_a_Silver_Bullet.pdf from https://whatsthepont.com/2017/05/29/the-life-cycle-of-a-silver-bullet/, the original link http://stsc.hill.af.mil/CrossTalk/2003/07/sheard.html isn’t responding)

  • Oldernick says:

    Thats not a complacency. Lets call it a wisdom. ‘Legacy’ programmers prefer spent time on real problem solving, not new old bugs in old new things.
    Actually there is not so much really new and useful things in programming in last years. Industry spin one’s wheels, declare old things and ideas as a new one and concentrates on programmers convinience and simplicity not on software perfomance or usability .
    So old programmers have a very familiar feeling when looking at a new silver bullet and juniors not. Thats all simple.
    Works in outsorcing company and every year spent some time in solving projects stuck in new bright technology hell. When modern non-legacy developers leave the project with bridle up. I’d prefer to spent this time on more interesting tasks then sift through the sludge.
    WBR NB

  • Hollywood says:

    When technology changes as rapidly as it does, often for NO REASON other than the folks in Redmond, WA need to justify their existence with another new product that nobody is asking for, it becomes virtually impossible to keep up with all the changes.

    How much time and money has been spent developing applications and learning new tech just to have it killed off for the “next great thing”? Answer — too much.

  • Gordon Garnsey says:

    As an engineer with a graduate diploma in computing from 1975, I find these discussions quite interesting.

    The problem as I have seen it is that there is such a rush by software vendors to get to the head of the pack that they allocate too few resources to testing, useability, and the effective documentation of their products. It all appears to be more about marketing rather than the advancement of technology.

    Prior to 1984 I worked on engineering type systems on HP desktop calculators for about 5 years. My work was productive and I attribute that to the following factors:
    1.The (structured) Basic language. Easy to get started and very quick to debug.
    2. The 5 programmers manuals that came with the machine. Everything was there in the manuals and everything worked.
    3. The developers software was an interpreter on ROM. It was not subject to updates so one could rely on it continuing to work as documented through the life of the project.
    4. Although the hardware was limited in capacity , speed, and capability, this could be overcome by the writing of efficient software. That involved software to pre-process the data, pack the data bitwise and structuring the data files efficiently. One compromise that had to be accepted was to design the software to handle a specific task, rather than to make it general purpose.

    In 1984 IBM and Microsoft entered the industry with the Personal Computer.
    Business leaders all had the belief that “No manager had ever got the sack by ordering IBM”.
    The software and hardware gurus came from academia and mainframe environments. Hewlett Packard’s technology was effectively lost.
    Hewlett Packard threw in the towel, much to the dismay of their users who had come to terms with their technology.

    Despite the huge advances in technology over the succeeding years it has come at huge cost and the legacy of mistakes made in the early days remains with us to this day.

Leave a Reply