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.
