The Hindu Business Line : A code for change

For most of us, the word `re-write' has dreaded connotations of angry teachers looking scarily over their spectacles at untidy schoolwork. It is of comfort to know that some people never grow out of it — especially a certain segment of the software coding world.

While this may conjure up images of angry project leaders stalking rooms and making hapless coders plough away at realms of code, the scenario isn't quite like that.

Bharat Ahluwalia, Vice-President-Delivery, Aditi Technologies, captures the picture. He says, "The concept of software rewriting isn't new but is all set to make a comeback." Excerpts from a chat with eWorld.

When and how did the concept of rewriting software develop?

The concept of rewriting software has always been around. Software has always been fast evolving and every few years a new technology comes into being, making it attractive to rewrite software. This time it is the advent of the new technology stack from Microsoft, Software as a Service (SaaS), Web 2.0 and other similar phenomenon, which is fuelling the rewriting boom.

As software companies depend on software for their revenue generation, they have conflicting demands on them. At one end, they are compelled to adopt new technologies to stay competitive, at the same time they have to wait till the technology matures to ensure that they don't adopt an unstable stack.

When do companies see the need to rewrite software? What role does Aditi play in rewriting software projects?

The following are the main reasons why companies go in for rewriting software:

New benefits: New technologies typically offer new benefits. Companies that have products in these areas are then compelled to adopt these so that these benefits can be passed on to their customers, thus making them more attractive than their competition.

Standardisation: There are times when a new technology becomes a standard. Companies that had developed their own custom solution then switch over to the new technology. One of our clients had developed an XML-based scripting framework, but as the .Net framework gained momentum, they decided to switch over to it. Now they can concentrate on developing their application rather than the base framework.

New Markets: As companies start targeting new markets, it is important to be able to work with other products in the same market. In some of these cases, a switch to a newer technology is required. In one case, a company wanted to enter the SMB segment in education. Microsoft is a major player in this segment and therefore the company had to decide to move their product to the Microsoft stack so as to be able to integrate with related products in the same segment.

Competition: With the advent of wide impact technologies, migration is important to stay competitive. E.g. with the coming of the Web phenomenon, nearly all products had to develop solutions on the Web stack.

Aditi plays a role in nearly all the phases of the rewrite. Typically, rewriting has certain phases.

Discovery phase: In this phase, the client and Aditi work together in figuring out how to migrate the software onto the new stack. At this time, it is very important to keep the focus on the product management aspect of the migration as well as the technical.

Proof of Concepts (POC): Most of the time after the discovery phase, it is important that some small POCs are developed so that the client can see the new technologies in action as well as see some of their modules implemented on the new technology space. Aditi develops these POCs and then works with the client to take inputs from these into the planning phase.

Implementation phase: In this phase, Aditi works with the client to develop detailed technical and functional specifications and then implements the same.

What is the common criticism against rewriting?

The biggest criticism in rewriting software is that the newer version does not fully exploit the base functionalities of the new platform. In other words, if you are not driving the rewriting correctly, you will just get the same product working on a new platform, which to a large extent negates the whole purpose of doing the re-architecture.

The other concerns are: As rewriting is generally a long-term effort, management is not able to track whether it is going smooth or not. For this kind of effort, it is important that rewriting follows an iterative process and that short release cycles are implemented.

Technology will keep changing, why should we do a rewrite now: The biggest reason to migrate/modernise your product is for business reasons and not because of technology. Companies should never undertake such an effort if they are not convinced that there is business value in doing it.

Keeping the following points in mind is important to ensure that rewriting is a success:

Putting up 3-4 business goals for the migration, for each point detailing out how the new product will meet that goal.

Ensuring that the rewriting effort starts from a look at the base architecture. If you don't make fundamental changes on how the product is designed, then you are not leveraging the new platform enough.

Keeping releases short and verifiable.

Tracking technology changes during the migration phase and ensuring that any important change, which is related to the product, is adapted earlier than later. In other words, software development is like a treadmill, once you have a couple of releases out in the market, future developments happen on top of the base technical and functional architectures developed. Therefore, when you are making the investment of rewriting, you must ensure that you develop a stronger and modern base architecture.

What problems would a technology partner face while rewriting software and what problems would the client face? How are such problems resolved?

The following are important for successful modernisation:

Business reasons: It is important that both parties understand the business need for the migration and always keep it in mind during the entire phase.

Technical Depth: The technical partner needs to have an in-depth technical understanding of the new stack to best exploit all its features.

Product Management: The partner should have a good understanding of the product management function. It should be able to evaluate the new stack and then change the functionality of the product to generate business value from the features of the new stack.

Communications: At all times it is imperative that the client and the partner have a high level of communication between them. Most customers prefer to do some analysis of the market for the products on the new stack or do detailed ROI (return on investment) studies for benefits of migrating to the new stack before undertaking it.

On the teams working on such projects....

The teams working on these projects are ramped up over time. In the initial stages, the team has a technical architect who works with the client and understands the need for the change as well as what kind of ROI the client would see after the movement. This is then discussed with the client and after it is clear that the ROI is sufficient, the next phase begins.

In the next phase, there is a functional analyst also present along with senior development leads. Based on the earlier discussion, a functional specification is developed along with a high-level design and then once the client is comfortable with both, it results in a normal project with a normal project team.

What is the scenario like post-rewriting? What kind of support is required?

After migration to the new stack, a system of continuous evolution is important. As the client has already made a heavy investment in modernisation, it is important that the product continues to evolve with the technology and keeps exploiting the newer features for best return on the investment.

Next is the migration of consumers. After the software has been migrated to the new platform, its consumers need to as well.

How well does the Indian academia prepare its software engineers to deal well with such challenges?

Currently Aditi trains fresh software engineers on different technical stacks. It would be good if our college syllabus had more `whys' in it. Like why are there different stacks? Why is one stack better than others in a given scenario? It is important to understand the `whys' to be able to make the right decisions when different stacks are being considered. There should be more training in more modern technologies than there is today. At the same time, it has to be acknowledged that our current syllabus does a good job in training students in the fundamentals of software.

paromita@thehindu.co.in