你如何处理过去的编程暴行？

Question

None of us started off as experts (and most of us still aren't). Sure, we all knew how to write programs in our preferred languages, but writing quality applications and writing syntactically correct programs are two very different things. We work, we learn, we struggle, we keep learning, and eventually we reach that threshold where others can learn from us.

If your learning process was anything like mine, you probably wrote a few perfectly functional, reliable applications that are still used daily, yet can't help but drop your head in shame whenever you think about them. Procedural code? Mixing business and presentation logic? SQL injection vulnerabilities? Wastelands of code barren of any comments? The list goes on.

Unfortunately, none of us can expect our employers to allow us to go back and rewrite our old applications just because they give us nightmares whenever we think about them. Worse, some of us have to actually work with our old applications, but know that it would be way too risky and/or time consuming to do a whole lot of good as far as refactoring goes.

How do you deal with the past programming atrocities you've committed and with the people who discover the dirty secret that you didn't always know what you were doing?

Answer 1

No regrets. If you're not ashamed of the code that you wrote last week that means that you've not improved as a programmer ;-)

Seriously though, my approach has always been to fix stuff that's dangerous (SQL injection vulnerabilities for instance) with urgency and then to refactor other code ugliness if and when I happen to be working in a particular area that needs refactoring. When fixing bugs or introducing new features I often keep a list of bits of code that require refactoring and then refactor the code after I'm done with my 'real' task. It usually doesn't take an inordinate amount of time to do and I have unit tests to make sure I didn't break anything (if your code is not unit tested, this is a great reason to get it tested!).

Jeff Atwood wrote a great blog post on this some time ago ( here ).

Answer 2

Whenever I did something less-than-optimally as a child, my father would kindly say, "Well, life is a learning experience." Our applications can learn too:

In every release of our applications, we deliver a mix of changes:

• A big new feature or two
• A set of smaller improvements
• Internal changes that make our lives easier
• Gradually deprecate and remove worst offenders

So gradually, we work to replace troublesome code with the third and fourth items.

Sometimes you can leave your mistakes behind. I know a senior developer who was once hired away from a company and asked to produce something similar to what he had written for the first company, but better . They gave him the staff and the tools, and he did .

Answer 3

My first programs exist only on TRS-80 cassettes where the iron oxide has flaked off. A couple are printed out with a seven-pin 40-column thermal dot matrix printer which burned the letters onto a special silvery metallic coated paper. All that paper turned black in the attic one summer.

I think I'm good. My oldest atrocities are safely destroyed.

---

Actually, there is one atrocity that continues to gnaw at me. I created a video mode for the Amiga called " Sliced HAM ," which was popular for a while. It changed the base colors per line to allow more photorealistic image with less fringing.

I quickly wrote a converter and viewer. In the viewer I sat in a busy loop waiting for the user to close the image. This was not acceptable on the Amiga--the first mass market multitasking computer system. I should have waited for the window's close event.

For ages, people said the video mode was slow, but it was just my lousy example viewer. The graphics coprocessor was doing all the work per scan line.

Still haunts me.

Answer 4

That's a great question.

Unless you are writing open-source software or just dumped your old code online, I don't think that it is as big a problem because future employers won't see your past indiscretions. You are also likely not bound to your former employers and they won't release the source code.

Most (good) developers improve over time, and past peers will realize that you are probably better today than you were then, just like they are likely better as well. Your employer paid you based on your experience then rather than your experience now, so they got what they paid for.

If somebody else besides you cares enough about your application and uses it daily, then they are free to maintain it (if they have the source code). Code goes stale. An application that doesn't get maintained, improved and re factored is either perfect (unlikely), or not important enough to be worth the effort. If a former employer keeps making money on your old application without maintaining it, it's their problem and the problem of their clients, and eventually the cash cow will run dry.

If you feel that your application is widely used, the code is freely available, and something there is likely to be featured on the next thedailywtf post, go ahead and fix it. Otherwise, be glad that there is enough old mediocre code out there so that you won't attract attention.

I think a bigger problem is the textual crap we leave around from our earlier years - old forum posts, incorrect blog posts, flame wars over language features, and the like.

Answer 5

Maybe you are at an organization in which you may or may not have an opportunity to correct past errors.

What you can do is remember to stay modest and helpful to people who are now at a stage where you once were.

Answer 6

This used to bother me more than it does now. I've come to the realization that it's just a part of the development process. No one started (or even does now) writing perfect code from day 1. Many times the code you wrote was sufficient given the technologies and resources you had at that time. It's not fair (for you or anyone else) to compare code you wrote 10 years ago with a 1 week deadline with what you could do today with current technologies and skill sets.

Answer 7

I apologize publicly. I would like to take this opportunity to apologize for INewWindowManager. Sorry.

Answer 8

If it ain't broke, don't fix it.

I know the feeling that something could be done a lot more simply and elegantly, maybe because you understand the framework better by now or because you learnt some new techniques. But that's really only relevant when you want to extend or change some code, otherwise just let it run if it works. If it doesn't work (ie if it's buggy, too slow, eats resources etc.), you should still be fixing it to begin with and hence have little regret just yet. Otherwise, well, what are you worrying about? Beauty in code is so fleeting... ;o)

From the other perspective, if you come in to work on somebody else's code, or even your own old code, you shouldn't be surprised to find sub-optimal code. We all do it. In fact, it's an opportunity to feel smug and play the hero when you successfully refactor the old code.

Non-optimal code is just part of the job. We should expect it around every corner and always be prepared to refactor old code when we need to touch it. That's only a problem if management doesn't understand it and doesn't allow you the time to do it.

Answer 9

Given that the job is still there and you still have chance to commit new stuff, fix the crap and check in! It's never too late for a bug fix. And it's nothing to be embarrased about. Everyone makes mistakes.

I also believe in honesty and that a good offense is the best defense. Just say loud, "this is my code and it's crap" and people will laugh with you :) There's no need to try and hide your code. It's there in your VCS, with your name on it anyway.

Answer 10

There's a new service for coders: Bad Code Offsets . Pay to make up for past programming atrocities...

Answer 11

The best way to deal with these bad memories is to learn from them, as I am sure you have. It is also important as you ask for forgiveness from your team members that you extend them the same. Most importantly, when you should remember these 'bad examples' when you are mentoring junior members of the team.

Answer 12

It can be a balancing act. I've been bitten by "improving" some code that was working, but I thought was ugly, and introduced some stupid new bug.

On the other hand, on several occasions in my career, I've struggled with some badly designed piece of crap code (written by me or someone else) - sometimes for weeks - because I didn't think I had time to fix it.

In each case, I finally bit the bullet and did it over again properly, and the problems went away almost immediately. Then I wished I'd fixed it sooner - would have been faster in the long run.

Focus your efforts on the sections that are giving you actual grief - the sections that you need to work on (new features, bug fixes), but you're afraid to touch because they're so fragile, or hideous.

That's probably a good indicator - the more you're afraid of it, the more it needs to be fixed.

-Tom Bushell

Answer 13

I release it anonymously on the net and make others suffer! No wait, I do it on my blog, and probably get laughed at by my peers.

Answer 14

I make sure I have a backup of the old stuff first, both 'just in case I'm not as clever as I thought I was' and 'If I am as clever as I thought I was, I can prove it!' :)