Be Lazy, But Not Intellectually Lazy

0 comments suggest edit

Lazy A while ago, Jeff Atwood wrote about the merits of laziness for successful software developers. Lest this become the mantra of sub-performing developers everywhere, I wanted to follow up with a clarification.

It’s fine to be lazy as he describes in the article, just don’t be intellectually lazy. What do I mean by this? First and foremost, when you are writing code, make sure you really understand what the code is doing. The classic illustration of mental laziness is encountering an off-by-one error.

When encountering the error, the lazy developer would simply append a “

  • 1” to the end of the stament, re-run the code, and if it seemed to work, move on. Or they might change a “< x” to “<= x” For simple cases, this may be the correct solution, but the problem arises when the developer doesn’t take the time to evaluate why the error was made in the first place. Sometimes, the simple fix only works for a narrow range of inputs and masks a larger error.

This solution is merely one example of a whole class of anti-solutions I call “Try It and See” solutions. The developer simply moves code around a bit and crosses his fingers to see if it works.

Off-by-one errors are only the tip of the iceberg. This class of anti-solutions often come up when when a developer is using a framework such as ASP.NET in which he is unfamiliar.

On a recent project, I noticed one of the developers had put nearly all of the page logic within the PreRender override. I asked the developer why he put it there, since the proper place would have been in OnLoad. He replied that OnLoad was too early to run that code because the controls didn’t have their settings from the inline control declaration within the aspx file.

Hmm, I’m pretty sure they would be there by then I told him, and he said in his experience, they are not. So I emailed him the order of events within the ASP.NET page lifecycle and pointed out that the method AddParsedSubObject happens after the constructor and way before OnLoad is called.

I believe that he did encounter a weird problem a long time ago with control declarations not filtering through, but rather than dig into the problem and really understand what was going on, he simply moved the code to PreRender, saw that it worked now, and cleared his hands of the problem.

I can understand that on a rush project, there’s a temptation to simply try things till they work and then move on, but you will save more time in the long run if you take a break and dig into the problem to get a real clear understanding of what is happening.

Likewise, spend time getting up to speed on the framework you are using. For example, ASP.NET has a usable form validation framework. Learn it. Use it. There’s no point in wasting time writing your own framework for validation unless you know the ASP.NET validation framework inside and out and really need to work around its limitations. And if you are going to write your own, consider buying a package first such as Peter Blum’s validation package.

So once again, be lazy, but not mentally lazy. Write unit tests up front where they make sense. Learn the framework you are using. Understand the code you are writing or debugging. And in the long run, you’ll be making your life (and your coworkers lives) easier. Perhaps that’s the true laziness.

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.



2 responses

  1. Avatar for Sharp as a Marble
    Sharp as a Marble September 18th, 2005

    I'm with you there. I'm awful when it comes to the "finger crossing" methodology sometimes. However in my defense, I'm known for my forensic abilities and I learn better watching things break.

    But I'm frustated in my current job role because I've been handed production applications written by some very, very, very poor developers. <b>ONE</b> class I am dealing with is 28 pages printed. And since it's production, I'm not given the time I need to accurately fix things. It's nothing but popsicle sticks, duct tape, and chewing gum for me.

    My main task is fixing the speed issues because our users refuse to use the application and the current system (Oracle Portal) has reached the end of it's supported life and needs to be shut down. But I'm not allowed to rearchitect the solution, I just have to find better uses of the chewing gum. Did I mention that the HTML data sent to the client is 756k to 1M? And that 80% of the fields require a postback?

    So, I don't want to be intellectually lazy, but I'm dealing with code written by a group who was. And you can't fight illogic with logic.

    Sigh... Sorry for the carping and bitching, but I'm feeling the pain of what you're talking about.

  2. Avatar for Haacked
    Haacked September 18th, 2005

    My situation doesn't sound nearly as sore as yours. The developer on this project is actually a very bright person who learns quickly. It's merely that he doesn't have much experience in ASP.NET specifically (I think his background is Java) and he's rushing things, which causes him to be lazy.

    28 printed pages! Egads! That's not a code smell, that's a code stench.