Pitfalls of software development

Why it’s different from product development 

Yes, we can. A lot of companies that do product development and are good at it also think they are good at application modernization, while companies that have done application modernization say they never want to go through that painstaking process ever again.

What is application modernization and what are the pitfalls of modernization projects?

Application modernization is not product development.

Legacy modernization, or software modernization, refers to the conversion, rewriting or porting of a legacy system to a modern computer programming language, software libraries, protocols, or hardware platform. Legacy transformation aims to retain and extend the value of the legacy investment through migration to new platforms.

New technology will save us.

Developers love creating in new technology. Therefore, a lot of developers love to work from scratch. It gives them the opportunity, freedom and creativity to use all the latest technology they can find. As well, it can be quite the adventure.

It also solves a lot of current issues. It’s fun to work with and sexy. Next to this, it has a lot more status to say you are using new technology than to say you are still working in old technology.

The problem with new technology is that, next to solving existing problems, you will get new unknown problems in return. Over the last 10 years, you have eradicated all the unknown issues from the old technology making it really really stable. Getting into new technology leaves you with a learning curve and time needed to get the new technology stable.

Every change has consequences, but you rarely know the impact of the change at the time that you are making it.

The new technology legacy problem.

If you take too long to modernize your application it might mean that once you have modernized it, you have new legacy. Although younger legacy than what you first had, it is still legacy.

For instance: companies who embraced Silverlight spent years modernizing their old applications and now need to again transition away from that technology. Companies who spent a lot of time and money modernizing their technology to Angular JS now need to again transition away from that technology.

The key takeaway point here is that new technology also ages fast. Take too long to modernize and you might end up having spent your budget only to find yourself in the same position from which you started.

The estimation problem.

How long is this modernization project going to take? This is a question a lot of CIOs, and CEOs ask themselves. The problem is that the development time of the original product is greatly underestimated. People tend to look at the time needed to create version 1.0, and not how much time was needed to create the version they now have. If version 1.0 took 1 year with 2 developers, the time needed for the new version is 6 months for 2 developers. This is because new technology should be faster in combination with the things you learned and as such, things should speed up a lot.

If you look at the difference between the current version and the first version, this could be a timespan of 10 years with an increasing number of developers. Let’s say you have 5 developers now. Because of the time you spent on the latest version up until now, you can easily have increased it from 25 to 30 man-years of development. New technology brings great advantages, but also greater complexity. Software development is not always as fast as it used to be.

The factory problem.

To build an engine, we need to build a factory that builds engines. The factory in this case is the architecture of the new application. The engine is the program with its screens that you want to develop and that a customer is asking for. 

The problem with this is that when you ask for a progress update you get a progress update that says: We don’t have an engine yet, but the factory is almost complete. And when the factory is complete we can build this engine, but also new engines a lot faster. This leaves the CIO and CEO in the dark about the actual progress. Because the CIO and CEO do not know what the actual progress is, they cannot make informed decisions about what to do next. Usually a lot of money has been invested in the factory and stopping the project does not make sense if the factory is almost done. Companies can stay in this situation for years being held hostage by “the factory problem” and going bankrupt because of it. The sunken cost fallacy triggers a reluctance for people not to act: If we are almost done, we should not stop.

A project manager once told me the following: Remember a software project has 3 stages: started, almost done and done. For 95% of the time, it’s in the almost done stage.

Customers don’t like change.

Changing your product a lot will lead to, well, a new product. When you develop a new product, it is really hard to know when its done. Especially when the team has a lot of ideas for improvement, scope creep can be really hard to deal with. Because the modernized application does not work the same anymore, you need to also focus on change management and re-training of your customers. Companies rarely take this into consideration when modernizing their products.

Our experience also is that the changes are often thought of from within the company. Let us change this, because customers really love this. The team enthusiastically changes the product but forget to ask the customer about the changes they are making.

When developing something better, a common mistake is that some features of the product are left out. Sometimes this occurs willingly, but sometimes because the team simply forgets that the feature even exists or that a customer is actually using it. In some cases, bugs that are reported are being used as features by others.

Change in a modernization project. The resource problem.

To modernize your application, you need your best people. IT requires knowledge about your processes, your system and the overall architecture. The problem with modernization is that you need the same skill set for fixing bugs and making changes to the original product as you need for the modernization project. The problem is that every change you make to the original application increases its scope thus making the project bigger. At the same time, resources were also planned for the modernization project which gets delayed.

To close this gap, you need to keep either two separate project teams or adopt a technology solution that can cope with these situations.

Total cost versus monthly cost.

A modernization project can be done in numerous ways. Depending on the solution you choose, the investment will either be done in a short timeframe or a long timeframe.

Let’s compare two of the most common ways of modernizing a system.

• Using professionals to rewrite manually
• Using migration automation tools

Using professionals to rewrite manually

Companies that start modernizing the system by rewriting code manually have monthly costs. Monthly costs for their own developers and monthly costs of external developers. The monthly costs give a lot of control to the CIO and CEO because if things do not work out, you can influence these monthly costs directly. 

The problem with the monthly costs is that you do not know exactly when the product will be finished. Will it take 12 months or 36 months?

Using migration automation tools

Companies that choose migration automation tools to rewrite the code automatically have higher costs upfront. You translate 6M lines of code and you will have to pay for the lines automatically migrated. These costs might be as high as 24 months of development or as low as 6 months of development.

So, what makes more sense?

It depends on the REAL progress of your development team. If they say they can do the job in 12 months and they get it done, then it makes sense to do that. If the team says they can do it in 12 months, but it turns out to become 36 or even 48 months (not uncommon!), then it makes more sense to use migration automation tools.

The question is: What risk are you willing to take?

Early communication to customers.

This is an overlooked problem. Once you start telling customers you are working on a new version of the system, expectations are immediately set. Over a given period of time, customers will start asking for the new version. Having delays in modernizing your application and having customers asking for it is a situation nobody wants to be in. The worst place to be in is to have the software modernized and optimized just to find out that the customer does not like your new look and feel or it is missing features that are crucial to them.

Lose-lose situation.

Getting away from old infrastructure and accompanying licenses alone can be a compelling reason to modernize your application. Sometimes, the license fees for running legacy software in the cloud can add up to millions of euros each year. Getting away from those products can generate enough money to pay for the modernization. Getting away from this infrastructure can only be done if all customers (or a big part of the customers) have transitioned to the new product. By changing a lot of things in the product, it will take longer for customers to embrace the new product and therefore the positive return on investment will take longer. The more you change or leave out, the longer this process is going to take. More money needs to go into the product while money is still being spent on licenses, a lose-lose situation.

How to approach a modernization project.

Copy first, then innovate.

There are best practices you can follow that steer you away from the pitfalls and make sure that your application can be successful.

Why as-is is not a bad thing.

The fastest way to innovation is by going to as-is first and change and innovate after that step has been taken. It has a lot less risk and a lot more benefits. In the first step, it might not be perfect, but it works. Always.

This approach requires a change of heart apart from that of the development team. The focus should be on replacing the technology first and improving functionality and features later in the project. By focusing on as-is first you get the following benefits:

• Scope is crystal clear. If the old system does the same thing as the new system, you know it works.
• Customers know the product. No need for re-training the employees.
• If data migration is even required, it should be easy.
• You can transition away from old infrastructure and the accompanying costs (virtualization) more quickly.
• Less chance of customers going to competitors due to long overdue projects.
• After step 1, you have modern technology and you can use the cost savings from the old infrastructure as investments.
• After the project, the full focus goes to improvement and innovation.

What options do you have?

• Abandoning the old product.
• Change small pieces at a time.
• Complete manual rewrite by starting from scratch.
• Use automation tools to convert code and then change code manually.
• Optimize automation tools to convert as much code as possible.
• Outsource the entire project.

Abandoning the old product.

If there is no future in the application or modernizing the application is too expensive, don’t start. Find a new strategy or adopt an off-the-shelf product.

Change small pieces at a time.

This is an approach used by a lot of companies. Some do it in combination with outsourcing to lower costs. If you keep the above pitfalls in mind, this can surely work. It means small pieces of code or modules will be modernized 1 by 1. Changing the architecture on the go is a risk but can be managed if one is careful and does not allow for other changes. First the technology shift, afterwards a functional shift.

Complete manual rewrite by starting from scratch.

Loved by developers, hated by those who have to pay the developers. This is by far the highest risk option.  Only if you abandon the old product and want something totally different and perhaps simpler can this be a good option. As a method of doing a modernization project we would not recommend it.

Use automation tools to convert code and then change code manually.

It is not common knowledge that there are tools available that can automatically translate source code from one language to another, e.g., Visual Basic 6 to C#.NET. Depending on the tools that you use, the percentage of code that can automatically be migrated differs. Some tools require a runtime to keep running the new code. Other tools generate native target code. Just like with Google Translate, the code that you get from the automated translation might not be perfect and may need some adjustments. Using automated tools like this greatly speeds up the process of modernization. You can use outsourcing in combination with these tools to have an optimum balance between results and costs. Keep in mind to go as-is first.

Pricing for the use of these tools usually goes per line of code. The more code you have, the more expensive it will become. However, it will still be a lot cheaper than doing it manually.

Optimize automation tools to convert code as much as possible.

As an extension to the previous method, you can also invest in optimizing the migration tool for your project and code. It is not uncommon to achieve up to 99.9% automated migration. This saves a lot of time and effort in writing, and/or rewriting code, as well as bug fixing. It is as if you can optimize Google Translate for your document making modifications almost not necessary. The trick here is to find a balance between the investment in the tool and the investment that you must make to adjust the code.

Outsource the entire project.

If you do not want to do the project yourself, you can also outsource the entire modernization project. It is not uncommon that these projects are done with a fixed price / fixed timeline. You will get the same application, bug-for-bug and it will work. Guaranteed.

This option has the least risk but has the highest cost aside from rewrites.