3 years ago (wow that went fast!) I wrote a blog post called Do not rewrite. The main points in it was to never rewrite whole applications. Never. Instead gradually rewrite one feature at the time whilst still delivering new business value.
I also wrote a more recent post about Paper cuts and broken windows. Which emphasises the importance of fixing problems straight away and not let them fester.
I want to extend these posts to include you should rewrite all the time, even when not immediately necessary.
Extracting the main points in the previous blogs why big rewrites are bad and continual rewrites are good, and to also sum the obvious why no writes at all are very bad.
There are other perhaps unexpected but important benefits not raised in the previous post.
Every time a refactor or minor rewrite takes place the knowledge of that part is refreshed and stay current in the company. If a system is not touched for a long while the knowledge of it may be forgotten especially if staff involved has moved on.
If a critical bug or urgent feature needs to be added to that system then the turn around is exponentially different between a recently updated system and one forgotten.
This is also true for the technical part of a system, the how, not just the what and why it does something. An old COBOL or complicated legacy custom build Java application will take a long time to work out compared to a contemporary tech stack application. You might even have to hire new staff or expensive contractors to fix it.
With up to date knowledge it will be a lot less risk that they might not do it properly.
If a new feature needs to be added then to any system then getting people ramped up and delivering it will be much quicker if it is on a contemporary and well known tech stack. If a new system needs to be integrated with existing systems then the API integration will be smoother and a lot quicker.
If a mass migration of a technology stack is needed, perhaps migrating from in house data warehouse to a public cloud based provider, or moving from monolithic to horizontally auto scaled instances, then having most systems on a contemporary and probably quite similar technology stack will speed any urgent migrations. This will avoid/reduce the need to for many deep cave explorations of old customised mystery legacy applications.
A very important reason to rewrite applications and features and in general keep technology up to date is staff retention. (Obviously a million other reasons exists for staff churn as well).
If you avoid death by a thousand paper cuts and broken windows staff will not mind working on the products. A negative culture will be less likely.
If you migrate to newer technologies and let people frequently learn new stuff they will be much more interested in the work and less likely to want to move elsewhere. (refer to my blog post Peak interest - the learning and sharing curve).
If word spreads that you keep an up to date and interesting technology stack then hiring new members of staff will be a lot easier, and you will hopefully attract more qualified candidates. On boarding will also be quick and people will be up to speed quicker with newer well known technology.
If the applications are continually refactored and evolved (as long as it is not done in a hacky ninja rock star development fashion) the architectures will become modularised, scalable and leaner in general.
Not necessarily a micro service architecture but a lean architecture that are more likely to be adaptable for the future.
Hopefully a lean architecture and highly skilled retained staff will also lead to / need a lean organisation so the business is more likely to succeed.
I would also suggest people and organisations refactor and rewrite when they do not see the obvious reasons for it.
I do not entirely mean rewriting applications on a whim when there is no features to be added or bugs to be fixed, after all I do emphasise the need for delivering business value along with all rewrites.
But I do think even when the obvious pain is not there that you should try to refactor and update applications. For example if the application is just one or two version behind the latest but still seems fine then still update it. It will be less painful than when it next time is 3-4 version behind with a bigger delta of change.
One type of no business value rewrite I would suggest is a good idea is to encapsulate legacy systems API as soon as you come across it.
Even if you are not changing a legacy system but merely reading data from for example, then adding a contemporary facade to it straight away will be of value in the future when you do need to update it.
Another important staff retention technique on top generally keep up to date with technology is to let them experiment with new technology.
I would avoid core systems, especially customer facing systems, but internal tools is prime candidates for field testing technology.
This will also lead to discovering technology that you can use in other applications if proven useful that otherwise would have been missed or delayed.
Naturally these experimental applications should also not be abandonware and be rewritten as often as other systems. Though they will probably always be good candidates for next set of technology experimentations.
Certain system never comes involved in new features so will not be included in a normal rewrite. These will consciously have to be found and rewritten without business value. Though probably just as a contemporary facade initially.
Leaving these as abandonware is not a good idea. Either kill them or update them.
The main points was already covered in my previous blogs, but I hope people see the value of rewriting frequently to especially keep staff, organisational architecture and company in general up to date for whatever happens in the future.
A utopian expectation of all applications being up to date is too much to hope for. At the other end where companies that rarely and/or minimally update their applications, they are doomed to fail. The grey scale in between decide whether companies will wither and eventually die or survive.
I also wrote a more recent post about Paper cuts and broken windows. Which emphasises the importance of fixing problems straight away and not let them fester.
I want to extend these posts to include you should rewrite all the time, even when not immediately necessary.
Recap
Extracting the main points in the previous blogs why big rewrites are bad and continual rewrites are good, and to also sum the obvious why no writes at all are very bad.
Big rewrite disadvantages
- Cost
- No business feature - no value
- Risk
- Big deployments
- Forgotten features
- Likely to never finish
- Not fully replacing old system
- Support yet another system
Continual rewrite benefits
- Reduced risk
- Smaller delta
- Quicker feedback
- Modularising
- Faster - less bottlenecks
- Leaner
- Remove features and bloat
- Actually finishing
No rewrite disadvantages
- Death by thousand paper cuts
- Even the smallest change becomes slow and painful
- Broken windows
- People do not care if they introduce bugs or break other things
- Staff exodus
- Few wants to work with painful systems
Less obvious benefits
There are other perhaps unexpected but important benefits not raised in the previous post.
Business domain knowledge
Every time a refactor or minor rewrite takes place the knowledge of that part is refreshed and stay current in the company. If a system is not touched for a long while the knowledge of it may be forgotten especially if staff involved has moved on.
If a critical bug or urgent feature needs to be added to that system then the turn around is exponentially different between a recently updated system and one forgotten.
Technical knowledge
This is also true for the technical part of a system, the how, not just the what and why it does something. An old COBOL or complicated legacy custom build Java application will take a long time to work out compared to a contemporary tech stack application. You might even have to hire new staff or expensive contractors to fix it.
With up to date knowledge it will be a lot less risk that they might not do it properly.
Quick turnaround
If a new feature needs to be added then to any system then getting people ramped up and delivering it will be much quicker if it is on a contemporary and well known tech stack. If a new system needs to be integrated with existing systems then the API integration will be smoother and a lot quicker.
Technical migration
If a mass migration of a technology stack is needed, perhaps migrating from in house data warehouse to a public cloud based provider, or moving from monolithic to horizontally auto scaled instances, then having most systems on a contemporary and probably quite similar technology stack will speed any urgent migrations. This will avoid/reduce the need to for many deep cave explorations of old customised mystery legacy applications.
Staff retention
A very important reason to rewrite applications and features and in general keep technology up to date is staff retention. (Obviously a million other reasons exists for staff churn as well).
If you avoid death by a thousand paper cuts and broken windows staff will not mind working on the products. A negative culture will be less likely.
If you migrate to newer technologies and let people frequently learn new stuff they will be much more interested in the work and less likely to want to move elsewhere. (refer to my blog post Peak interest - the learning and sharing curve).
Recruitment
If word spreads that you keep an up to date and interesting technology stack then hiring new members of staff will be a lot easier, and you will hopefully attract more qualified candidates. On boarding will also be quick and people will be up to speed quicker with newer well known technology.
Lean technology - lean organisation
If the applications are continually refactored and evolved (as long as it is not done in a hacky ninja rock star development fashion) the architectures will become modularised, scalable and leaner in general.
Not necessarily a micro service architecture but a lean architecture that are more likely to be adaptable for the future.
Hopefully a lean architecture and highly skilled retained staff will also lead to / need a lean organisation so the business is more likely to succeed.
Rewrite when not needed
I would also suggest people and organisations refactor and rewrite when they do not see the obvious reasons for it.
I do not entirely mean rewriting applications on a whim when there is no features to be added or bugs to be fixed, after all I do emphasise the need for delivering business value along with all rewrites.
But I do think even when the obvious pain is not there that you should try to refactor and update applications. For example if the application is just one or two version behind the latest but still seems fine then still update it. It will be less painful than when it next time is 3-4 version behind with a bigger delta of change.
Rewrite encapsulation
One type of no business value rewrite I would suggest is a good idea is to encapsulate legacy systems API as soon as you come across it.
Even if you are not changing a legacy system but merely reading data from for example, then adding a contemporary facade to it straight away will be of value in the future when you do need to update it.
Experiment and rewrite experiments
Another important staff retention technique on top generally keep up to date with technology is to let them experiment with new technology.
I would avoid core systems, especially customer facing systems, but internal tools is prime candidates for field testing technology.
This will also lead to discovering technology that you can use in other applications if proven useful that otherwise would have been missed or delayed.
Naturally these experimental applications should also not be abandonware and be rewritten as often as other systems. Though they will probably always be good candidates for next set of technology experimentations.
Rewrite exploration and euthanasia
Certain system never comes involved in new features so will not be included in a normal rewrite. These will consciously have to be found and rewritten without business value. Though probably just as a contemporary facade initially.
Leaving these as abandonware is not a good idea. Either kill them or update them.
Summary
The main points was already covered in my previous blogs, but I hope people see the value of rewriting frequently to especially keep staff, organisational architecture and company in general up to date for whatever happens in the future.
A utopian expectation of all applications being up to date is too much to hope for. At the other end where companies that rarely and/or minimally update their applications, they are doomed to fail. The grey scale in between decide whether companies will wither and eventually die or survive.
Unless otherwise specified, all content is licensed under Creative Commons by Attribution 3.0 (CC-BY).
Externally linked images and content are not included and are licensed and copyrighted separately.