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.