Monday, September 29, 2008

Dealing with Legacy Code

I found this piece of advice on how to deal with legacy code on a slashdot post by eln.

1.) Spend 2 weeks looking at code you don't understand.
2.) Loudly complain about the poor quality of the code, particularly algorithms that you don't understand.
3.) Make derogatory comments about the previous developers. Be sure to paint them as monosyllabic imbeciles who probably got dropped on their heads multiple times as children.
4.) Make minor changes to the code. If they blow up in your face, blame the previous developers for their poor grasp of basic programming practices. Make references to the previous programmers' relationship with their mothers.
5.) Delete the whole thing and start from scratch.
6.) 18 months of fumbling around later, realize that the previous code may have been better than you gave it credit for.
7.) Deny this.
8.) Release cobbled-together mess that lacks half the features of the previous codebase and features twice the bugs.
9.) Get job elsewhere.
10.) Company hires new programmer who starts the process over at step 1.

Point taken! And seriously defining legacy code as code without tests is a pretty bold statement. This means that there are some developers out there who are literally writing legacy code. This fact begs colleges to consider teaching testing as part of a CS curriculum.

0 comments: