Code Quality Tip #3: Switch Gears, Eat your Dogfood
Jomo Fisher--Recently, the whole C# product unit took a week off from our regular work to do some App Building. We split up into teams and competed to see who could build the coolest application and find the most bugs in VS 2005. Given where we are in the schedule we’re trying hard to reveal remaining hidden issues.
This leads me to code quality tip #3: Be aggressive about using your own software. Eat your own dogfood. This is a great way to put yourself in your customer’s shoes and to find bugs that have complex repro steps.
Here’s how App Week went for my team:
Day 1: Our team is two QA, one PM, three DEV (counting me). We meet and decide what to work on. Some of the ideas we put on the table:
· A C# compiler for the Lego Mindstorm.
· A tool to offload mathematical operations onto GPU (recent commodity video cards can push 40+ GFlops and they’re getting faster at better than Moore’s Law rates).
· A video game emulator.
· A Real Time Simulation video game (like Age of Empires).
We decide democratically to go with the video game and name our team War<Worlds>. This wasn’t my first choice, but I have an interest in AI and my vacation starts on Wednesday so I shouldn’t push for something that I’m not going to be here to support towards the end.
Day 2: We spend several hours sitting in a room trying to decide on interfaces for our game. Mostly this was a waste of time—we should have delegated this job to one person and accepted their decisions. Eventually we do pick a person to design the interfaces and he’s got something good early on Day 3…
Day 3: My coding on the AI begins in earnest. I’m a fan of TDD so, naturally, I want to set up a Team System test project. I really think the Team System Test framework is great—it’s solid and has integrated code coverage. The problem comes when we add the test project to source control. Once the project is under source control we can’t open it anymore (it doesn’t matter wither its Team System source control or Source Safe). Great! That’s a bug that would have been tragic to ship. By the end of day 3, team War<Worlds> has found three killer bugs and a bunch of annoyers and we’ve pulled into first place.
Day 4: More coding. I get to the point where the AI is functional but not likely to win any games. Unfortunately, I have to leave for vacation in the morning.
On Friday, while I’m boating on Diamond Lake with my family team War<Worlds> goes to demo the game for the rest of the PU (yes, they manage to get a minimal, but functional RTS going in five days). We enter the demo with a commanding lead in terms of the bugs that we’ve found. Sadly, the demo goes poorly and we lose points. We end up coming in second overall.
App Week was new to me because the VSCore product unit (home of my last team, MSBuild) didn’t do them. Now that I’ve seen one in action, I’m a fan. It was a great opportunity to switch gears and look at VS from a new perspective. I got to work and know some folks that I wouldn’t normally have spent much time with.
This posting is provided "AS IS" with no warranties, and confers no rights.