Tuesday, April 25, 2006

Visual Studio 2005 and C++ Directories

I have been playing with Visual Studio 2005. Don't call me "laggard", I am from "Late Majority" :-) The good news for skeptics like me was that 2005 coexists nicely with 2003. The bad news it is doesn't bring much for C++ developers. Well, sometimes no news is a good news.

Among other things, I checked how VC 8.0 stores C++ global settings.

Why do I care to know? I need to switch between two C++ projects. One of them is a huge legacy application that relies heavily on global Visual C++ directories. So every time I switch I have to go to Menu Tools Options Projects VC++ Directories, change Includes, change Libs, build, and when I'm done, change them all back for the current project. Doesn't look very tempting, eh? The standard workaround is using command line build and environment variables, which is fine for a build, not so good for debugging. My old favorite trick has been swapping Visual Studio global settings.

VS 6.0 was using registry to store them. Easy: just deal with .reg files.
In Visual Studio .NET 2003 it is a bit more complex: the registry key is still there: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\VC\VC_OBJECTS_PLATFORM_INFO\Win32\Directories]. However, it contains only *default* settings. When you modify paths in Tools Options Projects VC++ Directories, this information is not persisted in the registry. Instead they are stored in your user application data directory. Look up VCComponents.dat at %USERPROFILE%\Local Settings\Application Data\Microsoft\VisualStudio\7.1\.

Visual Studio 2005 treats it exactly as 2003, except it is 8.0 instead of 7.1.

So whenever you want to save settings, distribute them to project members, or easily switch between different projects, deal with VCComponents.dat files. Make sure you don't have .NET running when swapping the files.

AddThis Social Bookmark Button

Monday, April 17, 2006

Harry Potter Style and TDD Coaching

I recently delivered my motivational presentation on Test Driven Development to a small agile team. From the presenter perspective it went OK: I got my points across, gave some food for thought, and sparked a little conversation at the end. But I was not sure what the team had taken home.

A couple of days later I spoke to another developer. He just started a new project and wanted to try Test Driven Development. We went out for lunch and he told me what his project was, how he was trying to approach it and where he encountered problems. As we talked about his particular problems and how TDD can help, I naturally made almost all the pitches from my TDD presentation, still hot in my mind. This time I knew they were well digested.

How come the little talk overpowered the full blown presentation? The objective was the same - to encourage and motivate Test Driven Development. The material was the same - everything I know about TDD :) The power toys I had at my command over lunch were way less impressive: in fact we didn't even have a pen to scratch on napkins. Yet it was clearly more effective. Why?

The answer came in form of a hilarious "Harry Potter and the Trainer of Dire" by John Salt. Salt claims it is a true story, and he backs it up with the use of Lego. For those who are not sure if they got the point right, he followed up with comments and explanations here and here.

Next time I talk about Test Driven Development, I should be less of Snape and more of Harry Potter. Go on, enjoy the articles; you'll see what I mean.

AddThis Social Bookmark Button

Wednesday, April 12, 2006

How Two Hours Can Waste Two Weeks

Your developers have just planned a two week iteration. The next day Sarah continues her work on the completion of an important New Project. And here it comes - Urgent Stuff:

>From: Project Manager
>Sent: 2nd Day Of Iteration
>To: Sarah, the Developer
>Cc: Yo, Dev Manager
>Prio: HIGH
>Subject: Coarechon needs Ezhibal

> I need you guys to find out if we can add "ezhibal" functionality to our old "Tounaf" project, and how much time this fix is going to take. We have a hot deal with an important customer who is almost ready to buy.

> Sarah please investigate ASAP. We can arrange a phone call to clarify requirements.

Soon there is a dialog that might go like this:

Project Manager: "Sarah, how long do you think it takes to check if it is feasible to add this 'ezhibal' feature?"
Programmer: "Well, I don't remember the old project details, but I can spend 2 hours to see if I can come up with something."
Development manager: "Sarah has her iteration planned. Why don't we stick to the plan?"
Project Manager: "What's the problem? It just takes 2 hours! What harm can it do?"

"It just takes 2 hours. It can't hurt!"

It can. We development managers learned it the hard way. We know how programmers think. We know how expensive switching their context is. If Sarah spends just two hours thinking of her old project, she loses a day of productive work on the new one. One day is 10% of a carefully planned iteration wasted if she spends 2 hours sidetracked.

In the wild nature of software development shops, however, it never takes 2 hours. 2 hours is the time Sarah is on the phone trying to clarify the problem. 2 hours is the time she is waiting for this phone call, reluctant to get into anything serious. 2 hours is the time Sarah is tweaking her development environment to build her old project. 2 hours is the time Sarah is spending to see if she can come up with a very restricted workaround. 2 hours is the time Sarah is on another phone call, explaining the potential workaround. Not enough time for real solution, no time spent on actually resolving the problem. 10 hours of unplanned and unproductive time is spread out over 3 days. 30% of iteration wasted.

At this point the planning goes down the toilet. The iteration is dead. The new project is slipping late. The rush around the old project yields little results either: with no time for a real solution the best bet there is a quick and dirty fix.

But the harm goes further. Sarah was eager to spend time on programming - she wasted it. She is robbed of her professional satisfaction, the good feeling of achieving the iteration goal and releasing project on time. On the next iteration planning session Sarah can't help thinking "Why kill time if we don't stick to the plan anyways?" The team gets the message: "We are NOT seriously doing iterative development. We are going ad-hoc".

Here is what I do:

* Tell the developer to stick to the original plan. Offer to protect her from switching her mind context. Remind her how cool it is to work single-mindedly on an important and interesting project. Ensure her that I'll handle the pressure. This is the good part; it is always well received :-)

* Tell the project manager that the iteration is carefully planned with a goal to release the new project by expected date. The plan leaves no space for switching the context daily. Our options are:
1) Put the issue to the back log and plan it for the next iteration.
2) Cancel the iteration, suspend the "new project", replan and work on the issue.
Let them make their call. This is the tough part; it is never well received. But I have to take a stand. I don't have the luxury not to do this.

The iterative development is an act of fine balance between adopting the continuous change and securing some stability for the developers to perform. We as development managers are responsible for keeping this fine balance. We do it for our team. We do it for our project. And we do it for our fellow project managers.

Cause we know something they don't always know: "How two hours can waste two weeks"

AddThis Social Bookmark Button

Sunday, April 02, 2006

The Power Of Mantra

I was reading Uncle Bob's "Clean Code: Args". It is a beautiful article written mostly in Java, with few English sentences. One of them jumped on me:

"To write clean code, you must first write dirty code, and then clean it".

You couldn't agree more. But you continue to write the dirty part in hope that one day you finally clean it up. Now you've got two problems. First: when too much dirty code is written, it hits a shit mark, and any cleanup becomes unthinkable. Second: when too much of dirty code is written it comprises a product, and they ship it. In either case, I bet you'll be browsing Workopolis. All in vain: good companies won't hire a developer who can't keep his shit under control. You'll find yourself in another shit factory.

Red. Green. Ship it!
This is the mantra of so called plan based development.
Put the whole program together. Make it work. Ship it before it falls apart.
And run away.

Red. Green. Refactor.
This is the mantra of Test Driven Development.
Make a little step. Make it work. Make it right.
And stay.

Which mantra is your Mani Wheel spinning?

AddThis Social Bookmark Button