15 September 2006 - 21:53Über architects and über developers

Sometime ago I was going thru the codebase of a project in order to become more accustomed with it when I detected a code-smell: an interface used for error handling had 2 very similar methods: one for producing a list of issues and another one for taking a list of issues and producing another list of issues from it. The methods were so similar to the point of being identical, and an inspection of the class tree derived from this interface confirmed my suppositions: the second method was basically appending the issues from the first method to the input list.

Obviously, this is a pretty bad error. The result was, among other things, a lot of copy and paste, a lot of redundant code and a lot of gotchas. This was pretty bad. I don’t know why, but the first thing that got into my mind was that this thing should be scrapped, which was obviously a very bad thing. Solely the fact that that code has gone from a half of dozen rounds of testing and has been deployed in production for a year made this code very valuable, because re-testing a new code-base implementing the same functionality would have been prohibitive. The correct way to look at it was not as at a pile of garbage, but rather as at some building blocks that could be used further. New contracts should have been developed for better alignment with the process which was getting implementing and the existing code blocks should have been adapted to these new contracts.

I was once listening to a JEE expert talking about a failed JEE project. He was talking with the lead architect and pointed out a flaw in their architecture. The architect decided to neglect the flaw and go ahead because time was running out. The end-result, according to the JEE expert, was that 12 months later the work of 40 developers was scrapped because of that flaw. I refuse to believe this. I cannot believe that the work done by those developers for one year could not be salvaged. I don’t know. I have seen projects going the way of the do-do bird but at the end various pieces could be salaged from the mess they were in. For example, a catalog module of an e-commerce application that never went live could be abstracted and plugged into another application (say, an application managing photo portofolios). Sometimes the application is way less than the sum of its parts…

Regarding the team in which you are working: odds are pretty good that you will not get a Rod Jonson to architect your application and that your team will be composed from pretty ordinary developers. Well, they are the people with whom you will develop your applications. Chances are they will make mistakes, chances are you will make mistakes, what is important is to deliver what you have to deliver. You have to find value in what has been developed and exploit that value as much as possible. (Looking at what has been developed from a functional perspective helps). Chances are whatever you are working on will change later and become obsolete. You have to deal with this change, and waking up one day to declare a whole code-base obsolete is not the right way to go about it.