Fix bugs, then write new code

I have found this to be a good practice after finishing an Iteration. The code is fresh in your mind and you can fix the bugs faster than if you wait until a couple weeks later. Fixing those bugs should be included in your iteration planning.

Back in 2000 Joel Spolsky wrote his well known 12 Steps to Better Code article and he makes some interesting comments regarding having your code ready to ship at all time. (http://www.joelonsoftware.com/articles/fog0000000043.html)

Comments

  1. UnknownJuly 26, 2010 at 8:41 AM

    Well, it’s not that easy. We get software version updates almost every month or so. These

    apply to different years of production and models. Usually BMW will mail you a notification

    of an emission related update or if the vehicle is in the shop for a repair that needs

    coding or programming the shops computer then will check if any other control unit needs

    updating. A 745 can have up to 80+ control units. Only the dealer can do this type of work.

    But there has to be some type of problem before we will update the software on any given

    control module. It is not recommended by BMW to upgrade the software if there are no

    problems concerning that control module. These systems are pretty fragile and updating can

    sometimes cause other problems or kill a module.
    http://www.airia.co.in/

    ReplyDelete

Post a Comment

Popular posts from this blog

Resharper 4.5

Finally, after being away for a couple days, I was able to upgrade to Resharper 4.5. After using Resharper for a couple years I'm so used to Resharper that it would be hard to use Visual Studio without it. The new version has been improved. I noticed right away that the solutions are loading faster and Visual Studio is more responsive. All licenses purchased after Dec 21, 2007 qualify for a free upgrade to ver. 4.5 If you haven't used Resharper I recommend to give it a try. ( http://www.jetbrains.com/resharper/download/ )
Read more

Flag Arguments

Passing a boolean as an argument into a method is not good practice. It complicates the method signature, indicating that this method does more than one thing. It does one thing if the flag is true and another if the flag is false! A method or function should do one thing and do it well. In order to avoid passing flag arguments you should split the method or function into two, using a very descriptive name for each of the methods. Try refactoring the code in your current project and see if this small change improves the readibility.
Read more