Wednesday, June 22, 2005

Two principles of software engineering

1. Write throwaway code.
2. Never write throwaway code.

I find myself supporting each one at different times and in different circumstances. I don't think that statements that broad really have a place in software engineering. If scientists can't tell me if eggs are good for me, then software engineers can't tell me to or not to write throwaway code. Sometimes it's a great idea, and sometimes it's a terrible idea.

I think that, assuming an eventual goal of quality software, the key is to make throwaway code obviously hacky. Fill it to the brim with asterisks and the word "HACK." Give it an ugly red button that doesn't match anything else in the UI. This will give you constant reminders that it's crap, and make it much harder down the line to say that it's good enough. IvoryTower is just chock-full of throwaway code... I moved into the dorms one year, sat down, and said, "oh crap, it's not even close to finished." So, I hacked things together. But, I'm kind of anal, and I like coding, and I had some spare time, so I hacked things together pretty well. Pretty soon, I stopped caring that it was throwaway code.

I wrote a small portion of a feature I built at work as throwaway code, because we hadn't decided exactly how something was going to work yet. I allocated strings like I was getting a 15% commission on all memory allocated. When it went through code review, everyone who looked at it raised their eyebrows to me in email. It doesn't matter, because it's going to be changed in a month or so anyway... but maybe it would have been better to have made it extremely obvious that it was getting replaced in a matter of weeks.

I think that people who say that throwaway code is universally bad are just narrow-minded. There's a place for everything. I can say with relative certainty that what I did at work will result in higher-quality code in the end, and require less rewriting. Sometimes you depend on events that are out of control, and sometimes you have to write something quick and crappy to take the place of things that are coming in a little late. Throwaway code is great for this; you get to start testing your system early, and it takes schedule pressure off. Just do what you can to make sure that throwaway code doesn't get a promotion.


Henry Schimke said...

I agree, generally. I write a great deal of throw-away code... The problem, of course, is that sometimes I don't go back and throw it away properly. I think that in some ways, at least, programming for the internet tends to lead to more bad coding practices than other fields though...

Kerjo said...

I agree, Henry. I think 30% of the code I've written since school ended has been throw-away code. Of that 30%, 25% wasn't meant to be that way, but that's what it became once A) a meeting was held, or B) the client changed their mind. This has probably convinced some small part of me that code I write possibly won't matter, so it doesn't have to be perfect.

Anonymous said...

Wow, Kerjo, you should find yourself right at home in software engineering, pulling those bullshit statistics out of the air.

Travis said...

Hahahahaha. That was probably the most painfully disappointing class ever.