Do you feel like you’re overtaken by new technologies? We live in a world where technological environments are continually evolving. It’s a long time since we could invest in a computer system and keep it as is for years. With the appearance of smart phones, tablets, and virtual-reality glasses (e.g. Google Glass), what used to work perfectly on our old computer is no longer sufficient. Clients want more. In addition to technological novelties, our nice providers of operating systems are trying to do more and more in order to remain competitive. For instance, every two years or so, Microsoft is proposing a new version. What can we do not to stay behind?
Why change it if it works?
Your organization must constantly adapt to the market to remain competitive, your software applications too. One could wrongly believe that your software will always fill your needs, but it’s usually not the case. Furthermore, it is important to make a distinction between of-the-shelf and custom software. Regarding off-the-shelf software, the only way to evolve is to buy the latest version. Even though manufacturers deploy great efforts to limit the impact of a migration, there often are compatibility issues. Certain features can be affected by upgrades. Furthermore, you have to adapt to the vision of the manufacturer. If they change the way things should be done, you are also affected. Regarding custom software, it’s a completely different thing. Instead of going radically from one version to the other, changes can be smoother, more gradual. We’ll see how further below.
Fear of change
I often hear the clients’ fears relating to changing their software. There are many reasons, such as: Will I lose the investment made in the current software application? Will the new one be really better? Will I have to re-enter data? Will the users find their way through the new software app? Let’s use these questions as a starting point.
Improving the profitability of your software investment
Your custom software has been written based on your specific needs. Time and great efforts were required to develop it. It is paramount to keep this investment and integrate your new needs. The beauty of software development is that it is quite easy for an expert to find how a system operates and to reproduce it, indeed improve it. Since it has been written, new technologies exist, and new techniques are being used. Even with an extensive documentation of your business processes, the odds are that your software knows them best. Moreover, quite often, the documentation is outdated right from the beginning of the software development. Documentation that is not up-to-date is even worse than no documentation at all. It hides truths and does not reflect reality. It can even lead to bad decisions. When I have to understand a software product, the original documentation gives me a good idea of the intention. However, the code gives me the most accurate information about how the product operates.
Improving without breaking everything
In the field of software development, we are used to change and we are equipping ourselves with a rigorous continuous improvement process that could be streamlined like this: planning, action, and assessment/or/evaluation. Planning allows us to have a vision that is quite precise over a short period of time. Beyond a few weeks, we content ourselves with a vision that is vaguer, but aligned with meeting the objective. Action is an intensive development phase with the sole objective of executing the plan arising from the previous phase. During this phase, it is often tempting to accept to add or modify things that had not been planned. However, it is important to refrain from doing so for 2 reasons. First of all, the plan often involves an entire team. Any change will impact the other members of the team, which could compromise the quality of their work. Secondly, by definition, the plan is a sequence of events that will not happen exactly as expected; we have to accept this. The fact to stick to the initial plan allows us to evaluate more easily the gap during the third phase, that of evaluation. It is by measuring this gap and trying to explain the reasons for it that we will be able to draw inferences, which, once transformed into action points, will allow us to improve ourselves. When applied to software development, this method allows to transform the product in small pieces without risking to break everything. If an improvement proves to be harmful, it can be corrected rapidly or simply given up. It is similar to launching a rocket to space. Engineers know exactly how to plan the best trajectory to reach their objective. However, during its ascent, corrections will have to be applied constantly so the rocket does not deviate too much from the original plan. In fact, winds, atmospheric pressure, and other external factors can influence its trajectory. In the case of a rocket, this trajectory is evaluated many times per second. Therefore, it is easy to avoid great deviations. But, if unfortunately a deviation greater than expected should occur, the mission would immediately be called off, as it was the case for NASA’s Antares rocket on October 30, 2014. However, before calling off a mission, first we need to evaluate the cost. Is it more expensive to maintain the mission or to interrupt it?
Preserving data at all costs
When making major changes to a software application, it is sometimes necessary to even have to change the data structure that is being used. Thus, it is mandatory to include a strategy to retain relevant data throughout changes. Various strategies are available. At one end, one can imagine the development of a new solution while using the existing one and plan complete data migration at the end of the project. To do so, the migration process has to be entirely automated and frequently used to keep the new system’s data up to date. The only drawback of this technique is that the new application has to be entirely completed to be able to use it. At the other end of the spectrum, it is possible to maintain the structure as it is and to only make restricted changes in order to limit the impact on the existing application. If a major modification would ever be requested, we would have to decide whether to create a new structure and plan data migration or change the existing application to respect this new structure. Depending on the applications and nature of the changes, different shades of these techniques can be used. For instance, one can choose an approach that is more secure and avoid changes to the structure. It will never be too late to introduce small changes during the project and even to swing the project (in whole or in part) into a new structure if the changes required force us to do so.
Making sure not to lose users
The best software product in the world is worthless if not being used. The software adoption by users is the key to its success. I would even say that it is important to attract the interest of users by consulting them and asking them to take part in the changes. Even if a lot of time is spent analyzing the software operation in order to understand the way it works, an important part of the business knowledge is often missing. Most software products have limitations, and users are often very creative in order to bypass them. So, it is important to ask them questions such as the following ones: What does the software application do not do for you? What do you have to do manually? What features do you find useless? What are the software problems? The goal of these questions is to find any manual processes that are hidden or any bypassing that the users learned to use to avoid usage problems. It is important not to forget for whom the product is being developed… Usually, those paying for the software application are not those who will be using it. For example, an organization acquires a software product to manage the timesheets of their employees. This system will be used by them, but paid by the boss. In this case, it is obvious that this boss will have expectations regarding the software product and, since he/she is paying for it, naturally, we will be tempted to listen to him/her. However, if the users are not happy with the software product, they will not be inclined to use it.
Making change successful
All changes are difficult. And the most difficult aspect of change is the human aspect. Since people are interacting with software, it is important to take into account the impact of software changes on them. How can we ensure that changes go smoothly? As I previously mentioned, users must be included in the change process. It is important to involve them. They have to understand the benefits of the changes required. During a course when I was in high school, we had to simulate the marketing of a product. In fact, I don’t remember much, but I retained an important thing: before launching a product, it is imperative to have already planned its innovation. I’m sure that when Apple launched the iPhone 5, the iPhone 6 was already on the drafting table. They only waited feedback from users before putting the finishing touches to it and begin production. It is the same thing for software development, even for your internal software. If you are able to deliver small innovations for your software, the level of trust of your users will increase. However, for trust to materialize, quality must be considered too. It is very difficult to deliver a software product without any flaws. Development environments do not allow to test the software product in its “natural habitat”. We have to be able to have it “really” tested. I’m presenting below 2 techniques that can be used to mitigate risks related to the impact of a problem.
It is possible to provide a feature enabled by a switch. Let’s take a timesheet management system as an example. It is possible to offer data import from an Excel sheet. This feature can be triggered through a software configuration. Thus, this function can be easily removed if a major error is discovered without having to redeploy the entire software application.
By invitation only
Sometimes it is too complicated to isolate a function with a switch. For instance, when it is part of the system core and it interacts with other parts of the system. In this case, it is possible to redeploy the system partially or by invitation only. It is also possible to control the access to the new version via security rules. In all cases, what we want is to give access to a limited group of users in order to get their feedback about the software product without disturbing the great majority of users. We can even think about using a waiting list to have access to the new version. This way, we limit damages in case of problems and use word of mouth to promote adoption. We can count on a user to notice that a colleague has the new version, but not him…
It is possible to make something new out of something old and to do it smoothly. By breaking down your software base into smaller pieces, their migration to new technologies is possible without losing related data. I remember of a time not too long ago when it was the custom to redo everything from scratch. I believe that with a little bit of intelligence and creativity, it is possible to keep a software product for years. We only have to believe in it and to be ready to deploy the necessary efforts.
Find out how Done can develop your custom software. We specialize in custom development for clients seeking unique solutions and wanting to maximize the value of their investment. For over 13 years, our development team has demonstrated its Agility, creativity, collaborative spirit and unwavering commitment to our clients.