Skip to Content

Nuke that code, let us start over

if you like living on the edge – try this. Ask a room full of programmers “raise your hands if you want to work on a maintenance project” . Then get out of the room quickly,  close the door behind you and run. Don’t look back. If you are not quick on your feet – don’t try this at work, and instead just trust me that this will not end well for you. If there are actually programmers who enjoy doing maintenance work, then they are a rare species, and I have not had the pleasure of meeting them yet.


But whether they like it or not – a very large number of developers actually make a living doing maintenance work.  Most of them dream of the day when they will be pulled out and put in a development project. Since there are more maintenance projects than development projects, many of these developers don’t get to see their dream come true for long periods of time.


Irrespective of skill levels or experience – ask any developer how he/she would like to go about maintaining a given program. The most common answer that I have received so far is “It is an unholy mess..please let me start over..pretty please” or some variant of it. Interestingly, I also have seen some developers finishing up their “new” programs having the urge to start over.


I readily admit that this is exactly the answer I have told my managers when I was an ABAP developer. And the hypocrite that I am, this is the one answer that makes me the most upset when a developer in my team tells me this answer.  Why do I even bother to ask this to my gang anymore? I can guess 90% of the answers – and usually can add a few points to their list of reasons. But since I am the guy who has to make sure SLA is met, and since I only have a certain budget to make it work – I almost never agree with this option to nuke existing code and start over.


But off late, I have started thinking as to why such a large proportion of developers feel this way, and if something can be done to make things better.  I am going to leave aside the “how do you write maintainable code” topic for now. That horse has been beaten to death, and its spirit continues to get flogged in hell for bad karma.


So here is what I think, in no particular order.


I think most developers have a creative spirit. Excessive exposure to maintenance work dulls this spirit, but I don’t think it ever dies. Creative people generally don’t like any one else’s work – and can always think of a better way of doing it. This is true for not just developers – architects, painters, movie directors etc all have this trait. And creativity never considers SLA or budget as a serious issue.


Odd as it may sound to a non-programmer, writing code is more natural for programmers than reading code. Reading code is obviously harder if it is some one else’s code. So it is natural that most developers feel more at ease to write new code than tweak existing code. As one of my best developers joked a few years ago – “It is the compiler’s job to read code, not mine”.


Paradigm shift from procedural to OO over time also contributes to this urge to destroy and recreate. A lot of OO developers firmly believe that procedural code was developed by some inferior species of programmers, and all trace of it must be wiped off the system before they can rest. OO has plenty of advantages – no doubt, but procedural code works just fine in a lot of situations too. Taking a hard stance that one is always better than the other leads to a lot of grief – you cannot just replace parts of procedural code with OO code, That just adds to the trouble. Having a balanced perspective is key here for keeping every one in a project sane.


The people who create code are seldom the ones who have to maintain it. This, in my mind, is the root cause of the problem. If you never have to maintain code, you will not “really” know how to write maintainable code. This is especially true for consulting companies – a set of people with great consulting skills come in to do the development work, and a second set of people (sometimes from a different company) gets the maintenance work. Depending on constraints like size of the project, budget, location, legal issues etc – there might not be enough of a good transition between these two sets of people. Is there any wonder the second set would like to exercise the nuke option?


The above issue has a flip side too – since developers doing maintenance work do not get to understand why the original developer did something a certain way ( less time, changing requirements, or just plain stupidity) – they usually have to guess, and the easiest answer usually is that original developer was dumb. Unless more projects put their development staff through some maintenance work, and give their maintenance staff some exposure to development – I don’t see this changing ever.


And finally the all too familiar problem of documentation. Most development projects have good documentation till testing starts. From that point forward, it becomes painful to retrofit all the documents every time something needs to be fixed in code. But maintenance people are given this huge pile of documents – irrespective of whether it is updated or not. I have hardly seen a maintenance team express their happiness that they got great documentation from the development team. Usually maintenance developers learn the new system by hacking it for a while. Hacking usually gives you a good idea of micro design in most cases – but it is hard to figure out macro architecture by hacking alone. That usually needs documentation of some sort. And if you don’t understand macro design – it is not easy to maintain a system effectively.


Now what if the project was developed in an agile fashion, with minimal documentation? While I have tried out agile methods in my projects (with varying levels of success, and at this point I am of the opinion that it does not work well for the large gigs with a globally dispersed team) – I am yet to see it go into production support. May be a year from now, I will have some experience on how it works out. If any of you folks have some perspective on this – I am eager to hear about it.

You must be Logged on to comment or reply to a post.
  • Thank you Vijay for sharing, that was a pleasure to read you. I’ll make my team read your blog so that they think twice when they create awful code 😉
    • Glad you liked it Sandra. I, on the other hand, should probably distract my team from reading this – lest they find I had the exact same ideas as a developer 🙂
      • Dear SAP Expert,
        I am working as a Senior Developer on Microsoft Technologies with overall 5+ years experience and 3+ years of experience in OIL and GAS industry. Mainly i m working on ASP.NET/C# & now looking to shift my career from MS Tech to SAP.Can anybody advice which will be the best module for me to choose as a career in SAP.

        Thanks in advance



  • Hi Vijay ,

    Very true. Personally , why do you think you preferred creating code than maintaining an existing one?

    Maybe it has to do with human psychology too.
    I would say it’s more to do with being a creator than being creative. Even Gods who create are considered more powerful than the once who maintain.  🙂

    Love your style of writing.


    • Hi Bharathwaj

      Good question – I think my managers assumed that I would be a terrible influence on my co-workers if I was put in a maintenance project. My maintenance experience was usually the “lite” kind – where I go into a development project, and had to tweak some existing code. 

      You really got me thinking on that reference to gods – actually, I think the god who is credited with most power is the one who is the master of destruction (Lord Siva in Hinduism). Here is some Trivia. I was born and raised in Tivandrum, Kerala – and Trivandrum was how the British called Thiruvananthapuram, which translates to City of Anantha, the king of snakes. The god of “maintenance” – Lord Vishnu, uses Anantha as his bed (the reclining pose being refered to as Ananthashayanam). There is a big temple in Trivandrum for Lord Vishnu that is an absoulte work of art. If you get a chance you should go see it. 

      Sorry I went off topic for a bit here.


      • Hi Vijay ,

        I realized the fallacy as soon as I submitted 😀 .

        But this also had an interesting perspective dont you think.

        I have been around Kochi. Will definitely remember your suggestion , the next time I am there.

        Thanks for the tip.


  • While writing (creating) a new code I’m trying to think about the person who is going to maintain it. Maintaining is nothing more than making a change. I’m trying to write a code that is easily changeable. Object oriented concept helps here as it allows me to break the code into manageable parts. “Divide and conquer” works perfectly with OO. There is nothing wrong with the procedural programming, that is, until one program becomes one procedure with hundreds of pages of code. “Divide and conquer”…

    I do not believe in “micro documentation”. ABAP is the language of my micro documentation. “Macro documentation” has to be live to be useful. My ideal is a macro documentation as a Wiki. It can be easily changed as the project progresses.

    Next time somebody offers you to nuke the code. Ask them why don’t they want to nuke their house. The builder built (created) it and we are just renovating (maintaining) it.

    • Thanks for your comment, Edward.

      Since I try every trick possible to prevent my gang from nuking code, I have also used your question at times “hey, would you nuke your house”. The best answer I got so far was “Sure I would, if the foundation is weak”. That answer hs some merit if it is in fact the case. However, due to the dificulty in reading code – I think most people who give me this answer never bothered to check thoroughly if the foundation is in fact weak.

      Procedural code can also be modularized effectively to a large extent, but I agree that the discipline is better in OO.

      I totally agree that Wiki is an excellent way to hold the macro design and keep it updated. The difficulty, in my opinion, is not only in the tool used for documentation. I think the issue is that when a project has to decide on what can be sacrificed to move ahead in a cruch situation, documentation usually bubbles to the top of the list.

    • Edward,

      “Next time somebody offers you to nuke the code. Ask them why don’t they want to nuke their house. The builder built (created) it and we are just renovating (maintaining) it.”

         We are on the same page.

         In my opinion, maintaining (renovation) the house requires more creativity.


      • In the end, the only reason developers don’t always ‘nuke the house’ is the time it takes and the costs associated with redoing it all. I’d level my house and rebuild it just the way I want to if I had the money and could deal with the inconvenience. The same is true of that annoying software application. I guess the way we get around it for the most part, is versioning; easy with self contained applications but pretty tough when it comes to integrated solutions.
  • Vijay,

    I have a different perspective probably because I used to maintain my own code in late ’80s/early 90’s.

    A good developer, in my opinion, should decide whether to maintain or rewrite code based on the following:
    1) Complexity of the requirements
      By this I mean whether the program is standalone or linked with several other programs/modules.

    2) Criticality of the requirement
      How critical is the program(s) to the business.

    3) How rarely or frequently the program(s) fails to perform
    4) What are the strengths/weaknesses of the program(s)?

    5) Is documentation compatible with the code?

    6) Does documentation explain why the code was written differently than we expect? Sometimes the change in business requirements may open doors for implementing more efficient methods/procedures than the one in existing code. In this case(if possible), it would probably be wise to just change a portion of code than rewriting entire code.

    In my opinion, maintaining good(repeat good) code requires more  creativity than rewriting. Probably this is the reason why most developers would prefer rewriting the code. Also when you maintain good code, you might learn a few do’s and dont’s on coding).

    Additionally, I wouldn’t blame another developer without reviewing/reading his/her code.

    Finally, whether to maintain or rewrite, in my opinion, is a complex topic and I don’t believe there is a simple answer.


    • Almost all the issues I mentioned will go away if you are maintaining your own code. But this is seldom possible these days.

      I fully agree that maintenance is a lot harder than writing new code, and needs great reativity to do well. And you are right – you do learn a lot in the process. The difficulty is that when all your friends in development projects are working on flash islands and WDA, you are maintaining a decade old BDC program. So it is kind of hard for the maintenance fella to appreciate the finer points of the craft.

      • Do you know anyone who ALWAYS works/worked on state of the art technologies for a long time? If you do know, do you know how hard they work to stay current with the technologies and get hired in those projects?

        In my 20+ years of experience, I have worked both on state of the art and 20+ years old technologies. This is probably true in any profession. Life is like sine wave-has both ups and downs.

        “Almost all the issues I mentioned will go away if you are maintaining your own code” – I don’t agree with this. As long as program quality is good, a developer should be willing to maintain it based on cost/benefit analysis. I would consider this developer open-minded. I know it is hard to find such open-minded developers.


        • Sure I do, Bala – me ! I ALWAYS worked on new technologies throughout my development career. And I know several people who worked with me at that time who did. And I honestly never thought of it as “hard” work. It was very exciting – and no one pressured us into doing that. We just liked staying on top of technology. And if you look around SCN, you will see quite a few inclined that way.

          I am not sure what your disagreement is, Bala. If you are maintaining your own code, then
          1. you seldom need it fully documented.
          2. you can read your own code – unlike another guy’s code
          3. OO or procedural – it was your cncious choice, and you don’t need any one to tell you why it was done so.

          So – what is the disagreement with “most of the issues will go away “?

          And I totally agree that finding “open minded” developers is never easy. Except, if you ask any developer “are you open minded ?”, then invariably they all reply in affirmative 🙂

          • Vijay,

            I will first define “New Technologies” and then explain why good developers should develop the skill of reading others code.

            I will use an example to define “New Technologies”. BWA is my example. BWA (BIA until 2008) was introduced by SAP in 2006 Sapphire. This means SAP had been developing this product for a while.

            One of my customers implemented BWA as a ramp-up customer in late 2006. I worked on BWA for more than a year in 2006-’07.

            From developer standpoint, I would consider BWA technology was not new in 2006/07. SAP developers were probably working on this few years before 2006.

            When SAP was implementing this product at this customer site, BWA was not stable. SAP developer who wrote Python scripts flew in from Walldorf in May/June 2007 to address a serious issue we were having. He checked logs and mentioned the error was coming from the back-end (BW ABAP stack). Then he reviewed/debugged ABAP code (he was not a ABAP developer based on what he told us) written by another developer in 1996(11 years old code). He concluded what the problem was, explained it to us and advised us to open a message; in parallel, he emailed the situation to ABAP development lead.

            What am I trying to communicate based on the example above?

              1) When someone starts working on “New Technologies”, it would probably take a few years to see the results (proof of concept to real development to testing to production phases). Python developer who flew in 2007 was probably working on New Technology when he began his BWA work before 2006. However in 2007, when he flew in from Germany, BWA was not new technology. I don’t know his skill set so I don’t want to guess what new technologies were available to him in 2007. However I am sure new technologies matching his skill set were available in 2007; and I am sure few of his friends were working on those “new” technologies. In addition, he was also debugging code written in 1996!!!. (When I said I sometimes work in 20+ year old technologies, I mean reading mainframe COBOL code during integration efforts with new technology!!!)

              2) He was a Python developer. When he found ABAP error message, he didn’t suggest us contacting ABAP developer. Instead he debugged 11+ years old ABAP code and found the bug. In my opinion, his ability to read others’ code was probably one factor why he was chosen to develop new technology BWA before 2006.

            Bottom line: Vijay, I sincerely believe good developers should develop the skill of reading others’ code; yes, I agree it is hard to find “open-minded” developers;

            Question: is there anything we can do through to develop “open-mindedness” in developers? or is that skill critical to succeed?

            Thanks for your time,

          • I got you now – and apparently we were not disagreeing at all. Just so that you understand my point too – I did not mean to say that developers should not read others’ code – all I tried to say was it is not as easy as writing your own. As I mentioned before, I am all for open mindedness in developers (and evry one else too ) – but again, not an easy thing to find 🙂
          • ARRRGGGHHHHHH   !!!!  I hope you are being sarcastic….

            The 3 points above are exactly the challenge that maintenance programmers “live and die for”.  Sooner or later the hotshot developer moves on to the next release or technology and SOMEONE ELSE has to deal with….
            1. undocumented (or worse, incorrectly documented) code,
            2. understanding the hotshot’s code (especially if it was written as an entry in a ABAP / JAVA Obfuscation contest),
            3. OO or procedural – understanding why it was done so

            Develoepr issues aside,
            1) If management has the same attitude “that you will maintain your own code”, how do you get moved on to the new technology without leaving the organization ?
            2) Are you measured by the quality of your code or by the hours you put in or by meeting the functional specs ?  All are valid measurements, but NONE of them are standalone.  And I’ve left off a lot of metrics that are important to both the Customer (the one paying the bills) and the User (the poor bunny that has to actually use your creation).
            3) Historically, development is 20% or less of the effort expended over the lifetime of a given system or program.  Management needs to be aware of the Cost Benefit / ROI of placing / wasting the good coders in the 20% (or less) part of the SDLC.

            “Everything should be made as simple as possible, but not one bit simpler.” – Albert Einstein

          • Agreed, Martin. The idea of a developer maintaining his on code is not for “ever”. Original developer should be around just long enough while some one else gets comfortable with his design documentation and code, and then management can move him/her on to other things.

            How developers are measured is an interesting question – and my reflex answer is that usually they are not measured comprehensively. In the short term, if a person codes within budgeted time and has less bugs compared to a benchmark number – then he/she is hailed as a good developer. Since maintainability is usually only revealed over time, it is hard to define a measurement for it. QA teams usually have some checklist items on maintainability, but “check the box” way of checking maintainability only goes so far.

            And of course management is equally responsible for a lot of the maintenance issues. The ultimate aim for development projects is to make it work somehow on an certain date, and fix issues later. This is true for product development companies, as well as implementation projects.

  • Thanks Vijay, another excellent blog on a very relevant topic that many can relate to!
    From my own experience I can say, that when I was developing more, I always considered myself not good enough of a developer to nuke it and do it all better. I developed a big admiration for the colleagues that could do that, but my talent was always more in taking what somebody else had done that was still a little rough in some areas and smooth it out in terms of fitting even better to the business pain points or requirements.
    In that sense I always enjoyed “Maintenance” development better, as I was better at it.
    Sure enough though and obviously this is not always possible, I tried to maintain strong ties whereever possible with the colleagues that had developed the functions in the first place and possibly through my feedback and them “allowing” me to make certain changes on my own I built a trust relationship with them that probably also lead to code code, that would be easier to be exctended and fine-tuned in the first place. (as they would want to make it easier for folks like me).
    In my team in the last few years I always tried to staff projects with both “types” of folks, really good developers, that enjoy building things from scratch and are incredible good at it, but also folks that are more maintenance oriented (and maybe even a bit closer to the business requirements) as well as folks who enjoy documenting stuff (even those type of folks exist when you look for them).
    As things move more into agile development, scrum or lean techniques I believe this will also be one of the key concepts, to form small teams (no more than 10) with a mix of skills and ambitions and empower them to get it all done. All meaning getting a great new product or feature out the door, but also having it documented enough as well as easy to maintain going forward and obviously easy to consume too right from the start.
    • Thanks for bringing in the perspective from product development company’s side. Plus I know that you managed SAP’s own IT before you took the SCN job

      I always used to wonder how SAP does this – many of my friends who were developers in SAP labs moved around from CRM to HCM to AFS I was always kind of surprised that SAP could find the right people to provide level 3 support.

      Since SAP has been using scrum for a little while now, I assume there are a few such products out there which are now in maintenance mode. May be you could get one of your colleagues to blog about how they maintain these apps, given that scrum has a lot less documentation than traditional methods.

  • I’m working for one year now on the ‘giving maintenance’ thing, while sometimes creating new bits n pieces using wdp java.. you should think about ‘refactoring’ or even ‘re-coding’ when things start crashing, or when you band-aid or fix something and this causes other stuff to fail..

    I never saw a Project Manager saying: ‘lets ‘REFACTOR’ the code, I’m sure that our Project has grown more than it should and I also understand that you developers had some assumptions before that are not true anymore – the client is putting some money, since I proved them this is the way to go – we have a new iteration, we need the same Product running faster and using less resources – and these are the things we need to implement in our next milestone, and you should take it in consideration while refactoring..’

    Developers aren’t the problem in this equation, I think it’s Management.. prevention is not a popular word, and as a developer, when prevention fails, you know what happens right..? =)


  • According to me, every developer should work in maintenance mode for sometime. This will teach the developer how NOT to write code. I have seen many of subordinates who started their SAP careers doing fresh implementations. Smart developers but they don’t have the experience to think what issues they will face when the project goes lives and design stuff that is programmed for disaster after go live.

    Anyway, it is in human’s genes to be happy with crap (for the lack of better word) we put in and keep cleaning it but clean up somebody else’s mess. But unless you clean up somebody else’s mess, you don’t really appreciate how much it stinks.

    My 2 cents.


  • Hi Vijay,

    What you have said is very correct. And the way you have mentioned is superb and touches the core of truth. My opinion is that we have to live the fact you have discussed.

    One of my colleague used to say “Development develops the skills and maintenance SHARPENS it”. As per the opinion of Bas de baar, the programmers are also one of the stakeholders in the project, apart from the sponsors, core team members, users, management team etc. Everybody cannot be kept happy and satisfied all the time. Fulfilling the stakes and requirements of all the stakeholders needs to be balanced.

    As you rightly said, “Nuke the code” – where the programmer (one of the stakeholder) is interested, but not the other stake holders (users/management) since they are also concerned about the time and budget. The inclination for keeping things perfect(eg. retrofit of documentation, using best practices) cannot be kept sustained over a period of time and the main reason for this is “Scope Creep” / Changing Requirements, in my opinion.

    “Nuke that code, let us start over” – this is what the programmer feels really, and really only he/she feels it. Nobody else. Unless the old design creates continuous problems, only then we should target to re-engineer it. Since Re-engineering itself may give rise to certain other issues which may need to be solved apart from the old ones. If the need at all arises to start over again, then it would make sense that the stakeholders/client is fully aware about it i.e. the reasons for doing it and the risk and benefits against it.

    Amit Mittal.

  • You are completly right.

    Consulting companies (and from my experience I cant exclude SAP consulting and SAP SI from it as well as myself) develop the stuff and finally in the test phase when things are going to hurry to keep the deadline documentation and even “traditional” values like not doing changes in the productive environment are forgotten (i never did the last thing!).

    I worked as a consultant in development projects 🙂 and I do it again, with a 2 year break. I just wanted to see within these 2 years what nasty stuff I produce when it comes to maintenance. I had the feeling that I miss a very important part of development and my skills have a lack, not knowing what the consequences of my work are.

    I came to the following conclusions for myself:
    – Developement and IT in general serves and ONLY serves the business. Thats why I write down exactly the business problem, the decision. You simply cant understand the solution (coding) if you do not understand the problem. You cant understand an answer if you dont know the question!
    – I write down why I developed it this way AND WHY NOT in a different way. I just want to give myself and other developers an understanding what sick things went through my mind… 🙂
    – I never make “just an adjustment”. I hate all these little adjustment, out-commented coding. You simply lose the overview! Coding (and I speak here about object orientated stuff) have a dedication. If it needs to get changed, I review everything. The question changed, so better review your answer completly rather than changing little parts of it until you forgot what the answer it total is!

    But the most important thing is the following:
    We live in a world where most developers are just developers because SAP has a debugger. And developers use it like hell!

    But you cant develop stable and reliable coding by being a “debugger developer”!

    We have to force ourselves to develop the code on a piece of paper! We all have learn all the “silly” things of software development. So why dont we make use of it!

    I once spend three weeks just to draw a process orientated decision chart of an application and the project management already went crazy seeing “no” results because I only had 6 weeks to finalize. I then implemented it in 2 weeks and there was no single problem or issue with it!
    When you start to code the stuff without developing the solution from a higher perspective you WILL fail.

    But with this I did not only have a perfect coding without all these little adjustments that make me and the maintenance crazy. I had a process flow containing roles, business process steps, business decision all in one. A documentation that leaves to space for questions!

    But all the comments are right! A major problem is the management. When the project budget is 1 Mio $ and we finish with 1 Mio $ for nasty code management is happy! The 500.000 $ in additional to get all the errors out of it do to a different cost center and nobody cares about. Spending 1.200.000 Euro for good code on the project is a “no-go” because people would see that budget has not been kept.

    Anyhow: nuke code actually has its right to exists. Its an old rule in quality management that a lack of quality needs to get fixed at that point where it appears and not on later levels. So if its not going right, make it going right!

  • What are you going to do with our comment?

    I read a lot of very interesting arguments, approaches etc.

    Will you make a summary? Some kind of “problem->solution” overview?

    Please let me know.

    • Good question, Hendrik – I am not sure yet. But there is a good bit of knowledge here now. Let us give it a few more days to see is some one wants to add another perspective to our discussion, and then take a call on how to harvest this.
  • One rampant problem:

    You will find that many of the developers do not have the fundamentals of programming.  Many developers don’t have a university degree in computer programming.  They “jumped” careers at some point for one reason or the other.  Programming is one of the few careers where you can do this.  For example, I can’t get a chemist job if I don’t have a degree in chemistry.  But you can get a programming job by picking up a book and self-learning.  Problem here is, you won’t get the knowledge of a degree from a book or two.  The second problem is that people actually hire these “programmers” in the first place because they don’t understand the position requirements.

    • Yes – this is a widespread problem in the industry. For example – my own college training was in Mechanical Engineering and I specialized in Portfolio management for my MBA. Nether of those prepared me directly for a programming job, although I think they did help me considerably in an indirect way throughout my career. I, like many others,compensated for this lack of formal training by self study, getting mentored by experts and so on.

      And you are completely right again on such people hiring others. My manager used to tell us – “hiring some one who is not fit for the role is like breeding rats – they multiply at great pace, by hiring others who are not a good fit”.

  • Hi Vijay,
    Great blog! Looking at all these posts, I wonder if there might be vlaue in doing a follow up on the SCN Career Center. Perhaps on best practices around creating job descriptions, interviewing and hiring developers? What kind of info do you think SCN could provide that would help?
    • Thanks Claudine. A follow up on Career center might be a good idea. I do have plans to blog about my views on hiring SAP skilled people. Too many balls in air now on my work front – I will have to gt to this once things settle down a little.