Geeks With Blogs


Rotten Code it can always work better - but at least it should work
Most of us developers - in fact, all of us - have written some rotten code at some point. Some people learn quickly how to improve their code, improve architecture, whatever, but even today my first pass at code often gets improved by the time I finish a project - and I don't know of any code I've ever written that I might not be able to improve if I took another shot at it later.

Years ago, programming was a side hobby - I was a graphic artist and illustrator. I'm not going to go into the details of how and why I made a career change, but one thing I brought with me to programming was how to improve your craft, whether it be art or code. I had been using Photohop for years - I made a living at it, I kept up with releases, etc. But one day as I struggled with a design issue, a fellow artist gave me a stinging, backhanded compliment.

"You're problem is that you're one of those guys who's smart enough to figure out how to get Photoshop to do what you NEED it to do, but you really don't have expert knowledge," he told me, "you need to start by going to get a big fat book on Photoshop and actually get a fundamental understanding of the application."

It was true. I had figured out things like that all of my life - I just was smart enough to figure out the shortcuts and get by, but I wasn't an expert. I knew a lot more than the average person knew about image manipulation, but that's not a measuring stick of true competency. A boy scout can build a fire and put up a tent, which is more than the average person, but a British Special Forces agent can survive in the Amazon for indefinite periods of time.

So I started by buying a big fat book about Photoshop and read the entire thing- and in truth, I found that the difference between knowing enough to get by and knowing enough to be a black-belt at something was about 10% more knowledge. Having a fundamental understanding of WHY something works is the primary principle of how I learned to gain expertise.

This concept is still how I learn - when I attend training, I know that I have a grasp on 90% of what's being taught, but I desperately want that remaining 10% I haven't learned to help put it all together. This has led me to attend training or college night classes even for languages that I already knew really well - like VB 6.

At one point I had a great teacher who was actually a software architect for a Fortune 500 company - at the time, I was working hacking code for a much smaller company and was taking an advanced class. Here's the thing: Of all of the students in the 'advanced' class, only about 3 would ever amount to actual programmers. Almost none of them ever finished a project, and only myself and one other student finished every assignment, and to be perfectly frank I completed all of the code for the assignment in the first two weeks of class. But I was looking for that missing 10% or 1%, or whatever. The class was still valuable because the teacher was much more experienced than I was and a really nice guy - it was from him that I started learning how enterprise projects should be organized.

But one project I had written was thrown together. It worked, but I knew I hadn't put real thought into how efficiently it worked - remember, I wrote all of that assignment code in a two week spurt. I also had been exposed to programmers online – particularly C++ coders - who were scathing on ‘newbie’ code writers, pointing out nuances in code that appeared to mean that the code was so bad it was written by gerbils. I expected that all programmers would be like that.

So when the teacher reviewed my app, I said apologetically, "I'm sure it could work a lot better."

“Does it work?” he asked.
“Well, yeah, but…,” I replied
“Then it’s good,” he said, “all code can always ‘be better’, but first it has to work. Nobody else’s app is even close to working.” And he walked off.

I learned two important things at that moment.

One, that my classmates were TERRIBLE coders, because I had written a working app in a few hours that secured me an A for the assignment – and the teacher was experienced enough to have known it. I don’t think it’s because I was a great coder, but it sure put the divide into perspective. He just knew that I got it and the others didn’t.

Second lesson: He was right. First it has to work, then worry about making it work better. Realizing the value in rotten code that works was important. I’m not saying writing rotten code is okay, but now, years later, I see the value between coders who write code that never works right and coders who pump out working code all of the time.

So that’s the point here. ‘Making it work’ means it works, well. Not that it’s exactly efficient or perfect. But it works. Then make it work better. I’ve used this philosophy on small projects where I was the only developer and large projects where I was the project manager. The golden rule is deliver, deliver, deliver. Make it work. Users are far more forgiving if you are making tweaks later than if it never works to begin with. Posted on Tuesday, March 20, 2007 4:56 PM | Back to top

Comments on this post: Why Rotten Code?

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Marcus Shockley | Powered by: