Coding 24hrs Straight, do you gain in time?

scbarnes — Sun, 27 May 2007 07:02:31 GMT

I mentioned on Friday/Saturday that I decided to roll-up my sleeves and help out the iTraveller team with some coding issues they had in WPF (mostly just binding stuff). It was an interesting night to be had, everyone was stressed emotions were high and low at times but overall they are were all determined to have a first release ready by Saturday 7am.

We then proceeded to stay-up all night and all the way through to 7am (I feel asleep for an hour at around 4am and was booted out for snoring) but was awake again around 5am. The developers were stuffed, exhausted and barely made the 7am deadline.

It's all to common in the programming world, where you have a deadline and are about to deliver but come to the realization that you're about 5-6hrs shy of meeting it. You could argue poor project management but if you cross over into this discussion you'd need to start looking at all the ingredients, specifications, resource capacity, skill sets within each resource and so on.

It's not a perfect answer and I've seen even the best project managed solutions hit this wall all to often, as it's usually the small stuff that trips you up. That and when you are using something for the first time? how does one gauge the length of time it takes to assemble? you base it off other benchmarks, languages or technology you've used in the past to interpret an answer of some kind.

Bottom line though folks, is that no matter what never work 24hrs straight as you lose time more then you gain.

Your body needs sleep, to ignore that will result in emotional tug of war with yourself and others around you.
You lose interest in the project rapidly due to the above.
You may gain 5+ hours of actual work time, but in reality you are probably working at below 50% of your potential and may introduce more bugs due to fatigue.
You loose that 5+ hours the next day, as usually everyone is on deck in the office, you're not and you at times become out of sync with one and all. You also feel like absolute crap the next day and feel like sleeping more so then normal (it's the tax you pay).
Your immune system can take a beating, as I type this I'm coughing up a lung and have a head cold, as I was enclosed within a small office with more people then usual and I'm sure our germs got to know each other very closely.
You usually find that all that hardwork and you ship on time, results in carefactor from the client. I've found this all to often, back when we worked 72hours back to back to ship Billabongs website(s) in the early days (when I worked for agencies). It was shipped, someone looked at it for a total of 5 mins and said "I'll look at it later this week, i'm to busy to go into detail on it just yet" - so heart breaking.

Overall though, the iTraveller team was given an impossible deadline, they've never used WPF in their lives and were able to ship something at 7am that left me quite amazed at the level of detail they had gone to (3D Carousel of Blogs with Meegos for example? wtf!)

I'm getting to old for 24hr code jams, as my body feels like crap but please, understand you don't gain, you actually lose from doing this.

WPF and SVN, it's good but also bites.

scbarnes — Fri, 25 May 2007 18:03:34 GMT

I'm currently sitting in with the team behind iTraveller.com.au, a WPF application that is being shipped locally here this week. It's down to the last hour(s) so to speak and everyone is tired, over worked, stressed and have taken Expression Blend (May Preview), Orcas and XAML out for a nice hard run.

Problems the team faced are stupid stuff, that we (Microsoft) are hopefully going to fix, and it's nothing over the top in terms of concerning, just small annoyances here and there. Example would be that when you are in Expression Blend, you double click on the XAML tab (Design to XAML), one would expect that the XAML pad would go full screen, negating the need for panels and so forth to be visible (as the Tool doesn't understand you are eding the current node item at the given time). It doesn't, it just stares blankly at you like you're some kind of ass whom is a bit slow on the uptake. Not to worry, I've got a list of these little annoyances an arm long and will shoot them through to the internals as constructive feedback.

One thing I will say though, is that when working with a team of developers at present, not having Visual Source Safe extension(s) in place is quite obviously hard and annoying, as each designer gets to play around inside WPF / XAML quite happily enough. Yet, when it comes time to throw their Resource Dictionaries or individual XAML pieces into the main pile, well this is where it gets interesting very quickly.

To combat that, the architect behind this project opted for Tortoise SVN, something I've used in the past for many years. It works a treat, but the catch is that one person has to own the .sln & .csproj files or kind of be the gatekeeper in the very least.

There are a lot of ways we could counteract this with some smarts in the room, but overall that requires time and these folks have managed to build a 6 month project in under 6 weeks (which is a testament to WPF and the Tools that support it).

There are some more interesting things I've managed to uncover from this project and once it's launched i'll sit down with the developers for a debrief and get their raw (unprompted) thoughts around it all. The entire project has had video diaries through out, so expect to see some footage of how it went from concepts drawn on "napkins" through to living breathing WPF based 3D goodness mixed with Meegos and Web 2.0.

I can't say enough positive things about this project at the moment and i'm looking forward to showing it to one and all once it's launched (mid next week).

Special thanks goes out to: George Pattersons Y&R, omniEffect.com and TravelTrain Holidays for their persistence and commitment to taking WPF to a new level.

The MossyBlog Times Archives 2007 - 2009 : iTraveller

Coding 24hrs Straight, do you gain in time?

WPF and SVN, it's good but also bites.