On the Genesis of Bad Code
I was thinking about this the other day and I've had several discussions with people about this recently. This especially hit home with a project I've been working on. The schedule it tight, all the developers involved are working crazy hours and amzingly, for the most part, everything is humming along. But there are parts of the code, mine included of course, that could stand to use some refactoring. I was thinking about how some of this came about, and here is one way. In my C# editor I can type the following
myObject.Click +=
and the editor kindly adds in
myObject.Click += new EventHandler(myObject_Click);
and if I hit the TAB key twice at this point, the correct method is added to myObject's click event and myObject_Click is generated for me AND the cursor is moved down to start editing the function. How simple! WOOHOO!
Well, at this point, I more or less know the logic that needs to go into the click handler (I sometimes think before coding), so I add it in, as the editor was kind enough to get me going. With a couple of tweaks, I can get it working and move onto the next one. Well, I need to add another event for another object that does a similar thing. I'm not sure how similar. It's close enough that I can copy and paste myObject_Click's body and make the necessary tweaks, but far enough away where designing a more generic routine will take some real time. Plus, I have two more objects that need similar but not exact code. So, I type newObject += <TAB><TAB>, copy, paste, update, test until it works and repeat two more times.
At this point, everything works as far as the user would be concerned. Given that the project manager has been hounding me for a couple of days because she has a demo to give by the end of the week, I make the mistake of showing her how it is and getting some feedback. She looks and it does what she needs, so the next thing that comes out is "Great, now that you have that done, can you add features X, Y and Z. Oh, and make the background a lighter shade of mauve. And Kevin found this bug over here, but he doesn't have time to fix it, so can you take a look. And Larry has a potential sale with super mega corp but they need a customization on our Apple IIE version. I know you can knock that out pretty quick. Thanks."
Since these things usually are LIFO in order of importance, we unwind the stack by digging out the Apple IIE version of the code and getting the customization of super mega corp done (for which Larry will get a vacation to the Bahamas and I'll get a nice note saying "Great Job. We couldn't have done it without you!!" Why the two exclamation points?). Then we fix Kevin's bug because we like Kevin and hey, he's swamped. Or he just knows how to say no. Or whatever. I just want the bug fixed because nobody hates bugs more than I do. Then, since my brain is fried and Tuesday has already become Thursday, we tackle the horribly difficult and important mauve problem.
Now it's Friday and we have a choice to make. Do we make code that works, but may not later, more maintainable, or do we start tackling X, Y and Z? This is especially interesting because this whole exchange started with "Great, now that you have that done..." This gets even MORE interesting because there will be a status meeting next week, and I can go into it saying "Well, I got started on X" when my boss knows I could have gotten X, Y and Z done by the status meeting given that I would have started on Friday, or I say "I got X, Y and Z works except if you click on the Flooble button while holding down the shift key, which can be fixed by the end of the day". I know my boss's boss is applying pressure to get things wrapped up and shipped, so, not wanting to make my boss look bad, I go with option B.
And so a working but not optimally refactored piece of code hangs around. Features X, Y and Z get put in, and Y is a repeat of the four click event handlers. Unfortunately for me I'm not a super whiz bang guy that can crank out a reasonably elegant large application without some refactoring. I've actually worked with a couple of people like this over my career. At least, they do a better job of it than I do. The code more or less goes from brain to keyboard with little need for alteration, much like an Eddie Van Halen guitar solo. I'm more of the Randy Rhoads type. He would work painstakingly, writing and rewriting his parts until they were to his liking. I like to think that I can do a reasonable first pass, but I'm never, ever happy with my first pass and take the time whenever I can to go back and make it better.
I probably need to go read Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects. In the meantime, I think I just need to come to the realization that auto-complete is the genesis of evil code.
By the way, I did go back and fix those methods. Y could still use some work though... - Mike