Seriously, you need to think twice if your class has 2800 lines of code! And please don't comment your code with obvious sentences. Having no comment is a lot better than having a stupid comment.
Stupid comment example 1:
// Checks if total is greater than limit.
if (total > limit) {
doScrewThePerson();
}
Stupid comment example 2:
/**
* returns the favourite person
*/
public Person getFavouritePerson() {
return this.favouritePerson;
}
Few months ago I started working on a software that is in production now for I don't know how many years. My assignments primarily were supposed to be maintenance sort of tasks, but I somehow ran into this situation in which I didn't believe patching the code to add new features was a good idea. I skip my justification at the moment for it is not the main idea of this entry.
In any events, I started evaluating the existing code and no matter how I looked at the code, I didn't find a straight way to keep the existing code. My assessment was the back-end layer should be completely replaced, the front end should be modified to adhere to technology standards, build files should be revised throughout the system, and packaging needed a serious attention. My rough estimation of how much time I needed to do this was something around a year. This may sound stupid since no one is going to wait for me for a year to have a new system that does (I am crossing my fingers) exactly the same thing as before plus a minor new feature! On the other hand, this is not totally stupid because after the changes are done the system is better maintainable and new features will roll in as they are needed.
Having considered the above criteria, I started to think what parameters help one think his/her way out of these situations. I mean one needs to plan what to do first, and he/she should find a way to keep everyone happy. After all, technical managers don't like setbacks and delays and product managers want to be able to make promises to customers (and possibly meet those promises). One possible guide to find what to tackle first is to determine business value of each change. Most likely many changes do not have an immediate business value; therefore, they should be given a lower priority. Changes that possibly take a long time should be broken into smaller parts that can be finished in a shorter time, even if this will make the whole thing take longer. My point here is that business people do NOT care how perfect a code is, but they seriously appreciate seeing something that works but is a little slow or doesn't have A or B. This is something that developers don't usually understand.
I will try to give an example of how I think things should be in another entry.
