Vukoje.NET

Vukoje's blog about software development

Is ALL code important?

Few days ago I saw same ordinary scene on street while going to work that got me thinking... about code off course :) Car driver was complaining to parking service employee about a parking ticket he has just received. He said that he was late for only 15 minutes (parking ticked is valid for 2 hours and drivers are notified with SMS 15 minutes before expiration). At the first moment I taught that 15 minutes isn't that much of a big deal, but then I started thinking what about 20 minutes? Still OK? And 30 minutes? Too much?


The real question is where to draw the line? Because we obviously can't do this, the right answer is that there should be no tolerance. OK maybe 60 seconds :)

 

You said something about code?

 


Unfortunate driver reminded me about a question I often encounter on my work. Is all code important? Should really all code follow best coding practices and coding standard?

Same day I heard that driver complaining, my collage and I asked ourselves if small repeated blocks of code in Unit Test Mock classes are really important?

If we assume that all code is not important (which will usually happened) you will be constantly wondering where to draw the line between important and not so important code? The answer is same as for parking time overdue, the line can't be drawn. You will end up with universal excuse for having sloppy code, although you have adopted best practices and maybe you even created a full coding standard.

 

But could we have saved time if we could draw the line?

 


I think not. If some code is less important, rarely used, and doing trivial staff, than it's usually easy to implement and hard to get it wrong. This means that code probably won't need any refactoring to enhance its design. I said at my previous two presentations, and I will say it again, I can write code by coding standard in same time as if I didn't code by standard. In fact I can maybe write good code even faster than bad code because I'm already constrained by the standard so I don't have to wonder or think about lowest level solutions (Event design, choosing between Class and Struct etc.).

I hope that this statement provokes you to show that I am no better than you because I know that everyone can write good code with just a little focus and discipline.

Write good code or find a better excuse.

Comments (6) -

  • Andrija

    12/21/2009 8:45:00 AM | Reply

    Vukoje, you gave us a great theme for thinking, but I have to disagree with you. I think that every norm should be measured again and again depending on situation. That make us agile. And, certainly, who can draw a line between good enough and code that is not good enough. I think that only answer on that questions lies in the context. That makes you right when you talk about parking, but I think that software development is not that simple.

  • vukoje

    12/24/2009 7:00:30 PM | Reply

    Andrija,

    Dear collage, as always your opinions are forcing me to think harder Smile

    Yes, I also believe that you should evaluate intended code quality based on its context... BUT that is in case when you are deciding on OK-good-very good-excellent code scale.

    In the post above I was referring to situation where someone write code that he knows from start is BAD and uses code importance as excuse. Maybe some other excuse would do Smile

  • nemke

    12/27/2009 10:35:42 AM | Reply

    As always the truth is out there. If you are working on completely new project, using unknown tech, the goal is to make it work as quick as possible in order to see if that suits the need for a project.

    Of course when you are on the known ground, with longer ongoing project, there are no excuses to skip all goodies of code convention.

  • vukoje

    12/27/2009 5:12:35 PM | Reply

    Yes Nemke,

    Intentional technical debt is always an option when there is a reason for it, like you stated above, off course you have to be aware of it. Smile

  • Phil Ruse

    1/22/2010 3:34:47 AM | Reply

    This rang a bell particularly when discussing quality within unit test classes - a discussion I think programmers the world over have Smile The intentional technical debt is interesting and I can see how this might work in an agile environment - but I've seen it done and never get addressed. We had one "quick and dirty" project (which thankfully I never had to work on) which wasn't addressed for five years! But then, we weren't working in an agile environment - which is why I read blogs such as yours Smile

  • vukoje

    1/22/2010 5:01:17 PM | Reply

    Well Phil,

    We all seen such projects, I guess they are a reason we are going agile Smile
    I can even live with intentional debt that never gets addressed, but there should be very good reason for it.

Loading