Skip to main content

Refactoring in the Maintenance phase

By
In this blog spot I would like to talk about the maintenance phase of an application, especially from a developer perspective.
Usually a software product has the following life cycle:

  • Requirements definition
  • System and Software Design 
  • Implementation and Unit Testing
  • Integration and System Testing
  • Operation and Maintenance

At the last phase, you already have a working product that was deliver to the client and is used by users. A big problem at this step is the technical depth that not only exist but will increase with every bug that you fix.
When a bug is found, almost all the people recommend to touch only the part of the application where the issues was found and fix the problem with the minim amount of changes. The problem with this approach is related to technical depth and the garbage that you need to pull with you.
What is happening with the dirty fixes that are done at this step? Who and when you will refac. this parts of the application and clean the code.
A non-technical client will say that he don’t care about this, it is your problem to resolve this issues and all the things related to it. In the end he will not pay for additional tasks.
In the same time, a refac. or a clean up would mean changing a part of the code (system) that will required a full test of the application. This may not be possible.
Going back to the original question: When and how we should do this refac?
There are two possible things that can be done.
First one is the refac. that should be done in the moment when a solution for the bug was found. In that moment, before going live and send to the client a notification that the bug was fixed, you should look over the code and refac. the code that was changed for the current issues.
The second thing that can be done when we observe that there is a technical depth that don’t affect the application functionality is to add the refac. task in a queue. All the tasks from this queue should be prioritize, estimate and the risks calculated.
For example let’s suppose that you have in your application an algorithm that is critical for your client (calculate the wining chances in a casino) and is working as expected. But you don’t like the way was written. In this particular case you should not touch it and change because you think that is better in the other way. You could cause a lot of damages on the client side.
Also, don’t forget that all the refac. should be approved by the client, in the end it is his code and not your. We can compare the application code with a garden. You cannot change the location of a tree of cut the grass without the approval of the owner. The same thing is with the code.
In conclusion I would say that even the temptation is high to change and refac. the code, you should make a step back and wait client approval. It is very good to be proactive, to come with new ideas and designs, but in the same time you should wait the green light from the client.
Labels:

Comments

Post a Comment

Popular posts from this blog

Why Database Modernization Matters for AI

By
  When companies transition to the cloud, they typically begin with applications and virtual machines, which is often the easier part of the process. The actual complexity arises later when databases are moved. To save time and effort, cloud adoption is more of a cloud migration in an IaaS manner, fulfilling current, but not future needs. Even organisations that are already in the cloud find that their databases, although “migrated,” are not genuinely modernised. This disparity becomes particularly evident when they begin to explore AI technologies. Understanding Modernisation Beyond Migration Database modernisation is distinct from merely relocating an outdated database to Azure. It's about making your data layer ready for future needs, like automation, real-time analytics, and AI capabilities. AI needs high throughput, which can be achieved using native DB cloud capabilities. When your database runs in a traditional setup (even hosted in the cloud), in that case, you will enc...
Post a Comment
Read more

Cloud Myths: Migrating to the cloud is quick and easy (Pill 2 of 5 / Cloud Pills)

By
The idea that migration to the cloud is simple, straightforward and rapid is a wrong assumption. It’s a common misconception of business stakeholders that generates delays, budget overruns and technical dept. A migration requires laborious planning, technical expertise and a rigorous process.  Migrations, especially cloud migrations, are not one-size-fits-all journeys. One of the most critical steps is under evaluation, under budget and under consideration. The evaluation phase, where existing infrastructure, applications, database, network and the end-to-end estate are evaluated and mapped to a cloud strategy, is crucial to ensure the success of cloud migration. Additional factors such as security, compliance, and system dependencies increase the complexity of cloud migration.  A misconception regarding lift-and-shits is that they are fast and cheap. Moving applications to the cloud without changes does not provide the capability to optimise costs and performance, leading to ...
Post a Comment
Read more

Cloud Myths: Cloud is Cheaper (Pill 1 of 5 / Cloud Pills)

By
Cloud Myths: Cloud is Cheaper (Pill 1 of 5 / Cloud Pills) The idea that moving to the cloud reduces the costs is a common misconception. The cloud infrastructure provides flexibility, scalability, and better CAPEX, but it does not guarantee lower costs without proper optimisation and management of the cloud services and infrastructure. Idle and unused resources, overprovisioning, oversize databases, and unnecessary data transfer can increase running costs. The regional pricing mode, multi-cloud complexity, and cost variety add extra complexity to the cost function. Cloud adoption without a cost governance strategy can result in unexpected expenses. Improper usage, combined with a pay-as-you-go model, can result in a nightmare for business stakeholders who cannot track and manage the monthly costs. Cloud-native services such as AI services, managed databases, and analytics platforms are powerful, provide out-of-the-shelve capabilities, and increase business agility and innovation. H...
Post a Comment
Read more