Geeks With Blogs
I [heart] code! .NET musings from the chick side

We've all done it. More often than we'd like to admit. Yesterday I spent half a day working on an issue where the end result turned out to be SO SIMPLE as to make me ashamed to call myself a developer. There was the feeling as I slogged through the problem that "This shouldn't be this difficult". When the problem resolved with 4 simple lines of code, my giddiness with solving the problem was tempered by my feeling like a complete idiot for having spent half a day producing those four lines. Hearing that I was the third person to tackle this issue, that two others had tried and failed made me feel only marginally better.

Software development is extremely rewarding and mind-numbingly frustrating at the same time. You can go for days, even weeks, where progress is steady and the project marches along right on schedule, maybe even a bit ahead. And then you hit it. The problem you can't solve - the functionality you can't quite implement, the bug that you just can't fix. And there you sit, working on one stupid little thing for hours, perhaps a day or more. You go home feeling as if you have made no progress, as if you have produced nothing for all your laboring at the keyboard.  Then you finally solve the problem, and all you have to say is "Duh!" And the task that was supposed to take 4 hours has morphed into a two-day effort. And  now you're behind schedule.

When estimating projects, I know to add 30% to whatever number I come up with. This is my "fudge factor". A fudge factor that allows for the inevitable "Duh" moments not accounted for up front, even if I make an effort to be conservative as to the anticipated productivity in my estimate. Breathing room for the things that pop up during a project.

Thirty percent sounds like a lot. And it is. I always feel as if I am padding the estimate. It is tempting to to be the hero who can deliver the project in an impressively timely manner. But the stress and loss of credibility of delivering late more than cancels that out. And time and time again, I am grateful for that thirty percent. I am glad that I planned for "Duh!"

What was my latest "Duh!" you ask?

I was working on a web application that was using the asp menu control. One section of the app was to function as a wizard, with "Continue" and "Back" buttons serving as the navigation, and the menu simply indicating which step of the wizard the user is at for non-authenticated users. The desired behavior for a non-authenticated user was that the menu be completely disabled, with the menu items indicating which step the user is at by which one is selected. An authenticated user would be have the ability to use the menu to land on which ever step (page) they desire. Hmm, that's easy. Just make the menu disabled for non-authenticated users. Oops, now the page won't load because it can't reference the selected item in a group that is disabled. Move this to the end of the Page Load. Now the page loads fine, but the menu item of the current step does not appear as selected. Assumption: Setting the Enabled or Selectable properties of the menu or the menu items would cause the menu to be rendered with no item appearing as selected when the page finished loading. DID NOT TEST ASSUMPTION. Onto another path. Playing with style sheets. Playing with the controls' methods. Playing with javascript because we don't even want to post back if the user clicks on the menu. Getting another set of eyes to look at the problem, and demonstrating to him that setting the Selectable property of the menu items to false at the end of Page Load renders the menu with nothing selected. Umm... it's working as I need it to. The menu is disabled and non-clickable, but the current selection is highlighted on the menu. Click through the wizard, and the highlighted menu item changes. My assumption held true only for the menu control and it's enabled property, not the selectable property of the menu items.

protected void Page_Load(object sender, EventArgs e)


if (!User.Identity.IsAuthenticated)
        LeftMenu.Items[0].Selectable = false;
        LeftMenu.Items[1].Selectable = false;
        LeftMenu.Items[2].Selectable = false;



Four hours. Four lines of code.


Update: I should point out that the 30% addition applies only to the development phase, not the estimate in its entirety.

Posted on Thursday, July 3, 2008 10:30 AM | Back to top

Comments on this post: Planning for "Duh!"

# re: Planning for "Duh!"
Requesting Gravatar...
I know this may have been considered in the design process, but why not just use the built-in asp:wizard control? It seems like this might work better/easier unless this application is not being developed on .net 2.0 or later.
Left by The Wolf on Jul 03, 2008 1:24 PM

# Good Reply
Requesting Gravatar...
I do not know where the design decision came from- I just got put on the project yesterday. If I had to guess, it would be because for the vast majority of the users (the authenticated users) they want it to function as a menu, and didn't want to duplicate the page.
Left by Kirstin Juhl on Jul 03, 2008 1:29 PM

Your comment:
 (will show your gravatar)

Copyright © Kirstin Juhl | Powered by: