Nuking code and starting over – revisited


I had an extensive debate recently on why monoliths are not universally such a terrible idea, where a young developer told me “Most of the code you would have written in your time as a developer is now what we call legacy code” .

I don’t blame the young man for thinking “legacy = bad”. I believed it too when I had his role many years ago . And then my thinking evolved over time and I am sure his will too.

I wrote this blog “Nuke that code, lets start over” nearly a decade ago, and I think many of the points discussed in there still hold true . There is a lot of wisdom in the comments section under the blog that I just finished reading again .

The young man’s comment made me think a bit about all the code I have written – from games in BASIC that I have sold to others for 50 rupees on cassettes while in high school to C/C++ , ABAP and java Programs that did more “Enterpisey” stuff for big companies across the world .

“Most” of the code I wrote probably have not lasted very long at all !

Some of the best code I wrote never made it to production – because priorities changed, projects were shelved , acquistion happened and a host of other reasons .

Most of the code I wrote has been refactored – some times by me , but mostly by developers who owned those repos after my tenure . I know of a couple of places where a bit of my code still runs in production – but it’s a tiny fraction of what I have written in total .

Legacy code survives because of many reasons – some good and some bad

1. It does something exceedingly well and it’s hard to make a case to replace II

2. It is way too complex for anyone in the team to rewrite now – usually due to poor knowledge management , not because the code itself is bad . Even with sophisticated tooling – it’s hard to understand logic completely from code, DB schemas and logs .

3. Refactoring is a routine activity in good tech shops . But the truth is that vast majority of large enterprise shops have ignored the importance of refactoring for a long time . They paint themselves to a corner and then need massive modernization projects to get out of the mess and cater to the business needs of today’s and tomorrow’s market . It also shocks me that some shops after finishing the modernization, they still refuse to follow any structured process to refactor along the way !

4. Another common pattern I have seen is that modernization is attempted purely for “tech fashion” – and usually with tragic results . I was quite amused once to watch the code of MRP process be rewritten to a new technology only to realize that even though the results now showed up in a fraction of the time of the old system, it was all wrong and hence useless !

Being honest about the need to rewrite is a good starting point in all modernization projects . There is only limited time, effort and money available and there is never a good reason to waste it by doing a project for the wrong reasons .

“we need to modernize because mainframe is dead” or “we need to move to NoSQL because RDBMS is dead” or “Our code base is a big monolith and we need to be serverless for our future” . It’s very common to hear these kinds of reasons being touted as the reason to start a modernization project . These are not bad reasons by themselves !

These statements are all good starting points to explore what is the real issue – do you take more time to deliver a new feature that business wants , and is that leading to less than optimal business results ? If the answer is yes – is it a tech problem or a process problem primarily that causes it ? Can you quantify the value of changing to a new system and prove that it is greater than the estimated cost ? What happens if the modernization project fails – how much risk can you take ?

Bottom line – you need an honest case for why you want to modernize . This case will then serve as your North Star in your modernization journey . It also will serve as a dose of reality check – which we will all need from time to time . The case itself has a shelf life – so it’s important to revisit periodically to check what changes are needed .

Big Bang vs Incremental changes – how do you decide which is the best way to go ? I will share some thoughts on that in another post . For now , I need to get back to my day job 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s