Project Management Tip of the Day

by Nick Monday, July 31, 2006 10:01 AM

Make your TODO's TODONE!

I'm not actually a project manager, but I do share in some of those responsibilities on my current project, in so far as I'm considered the lead developer and architect.  One of things that I've learned over the years, and I try to push for before every major release to production, is to have all the developers on the team go through their code and clean up TODO's.  Today was a perfect example why.

Right now we're working on a 2.0 release, which involves a lot of rewrite since the 1.x branch.  However, we still have to support the 1.x branch which is in productions until we release 2.0.  Friday we got a call for a production problem, and we were able to narrow down the problem this morning.  When I found the offending code, there was a TODO which described the fix that needed to be made.  The defect was actually rather obscure, and I'm surprised it came up... but nonetheless... someone at some point in time anticipated this happening, and stuck a TODO in there which perfectly described what needed to be done to fix the defect.

Had that TODO been turned into a TODONE... this problem would never have occurred.  At some point in time prior to a release, you should always go through your code and try to get to a 0 TODO count.  Granted, this rarely happens in real life, but you should at least evaluate every TODO in your code to see if its really still an issue.  TODO's that are in code too long should also be noted in defect logs as well, so that they begin to elevate the chain of importance, and can be evaluated with other code changes that have to be made.

Finally, all TODO's should have initials next to them.  A one line TODO can often times be very vague, and so its helpful to be able to go back to the original offender and get more context from them as to why they put in the TODO.  Sadly, this particular TODO was nameless, although it was fairly descriptive.

The Geek Hierarchy

by Nick Friday, July 28, 2006 4:12 PM

Via Samantha Burns comes a bunch of really good geeky links.  First there is the Geek Hierarchy Tree.  I've examined it, and it seems pretty close to me.  Then there are some great computer quotes for you to enjoy as well.  They're pretty good quotes, but nothing beats this collection of Computer Stupidities which I've had in my favorites list for a long time.

The Law of Additive Annoyances

by Nick Friday, July 28, 2006 2:10 PM

Everyone has little annoying things that they do which you probably could do without.  But we handle them because, we know we have them too.  But sometimes, there is a person who has so many, that suddenly everything they do drives you nuts.  Even just small things that they do, which normally wouldn't really bother you, start driving you insane!  I call this the Law of Additive Annoyances.  And God help you if the person who sits in the cube next to you fits into the category.

Warning to All My Feed Readers

by Nick Tuesday, July 25, 2006 12:39 PM

Just wanted to give you all a heads up that I'm going to start using FeedBurner to supply my RSS feeds.  Fortunately, dasBlog is so cool, that if you give it the location of your FeedBurner feed, it will automatically redirect people who use your existing feed to the new one.  So hopefully, you'll never know it happened.  But if for some strange reason you stop receiving my feed, you'll need to come back to my homepage and get the new feed address.

Actually... You Didn't

by Nick Friday, July 14, 2006 9:18 AM

I review a lot of code during the day.  Some people's code I review after they check-in to source code control, while one person in particular has to show me their changes before they're even allowed to check-in.  Whenever she comes to me with her code changes, she always says "I fixed the bug"... and after looking at her code I always have to respond, "Actually, you didn't."  This is quickly followed by, "Yes I did... that thing doesn't happen any more."  And while that's always true... her solution was to simply comment out the offending code, instead of fixing the offending code, which results in a new bug to replace the one she supposedly fixed.

It's as if the function she commented out was called InsertDefectWithoutDoingAnyRealWork(), when in reality it's called DoSomethingAlmostRightThatStillHasToBeDone().  And then after I tell how her that her solution will cause functioning code to not function any more, and that she needs to go back and really fix the bug... as she leaves, she always says, "OK, but this did work."

No it didn't!  Fixing a defect by causing 5 more is not fixing a defect at all!  Fixing a defect by commenting out code is not fixing a defect!  Every line of code was written for a reason.  It may not do exactly what was intended, but there was a purpose to it's being there.  So before you simply comment something out, you need to understand that purpose in order to make sure that by the time you're done, that functionality is either deemed to truly not be needed, or has been fixed.

That is when a defect is fixed.

About Me

Nick Schweitzer Nick Schweitzer
Wauwatosa, WI

Contact Me
I'm a Software Consultant in the Milwaukee area. Among various geeky pursuits, I'm also an amateur triathlete, and enjoy rock climbing. I also like to think I'm a political pundit. ... Full Bio

Community Involvement

Twitter

Archives

Flickr Photos

www.flickr.com
This is a Flickr badge showing public photos and videos from Nick_Schweitzer. Make your own badge here.

Standard Disclaimers

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2014 Nick Schweitzer