Transition time

We're at the point in the process for VS2005 where there is basically no work left for devs to do.  (The product hasn't shipped yet, but devs are not busy.)

Before starting the next product cycle, there are a few things that we're doing differently.  One of them is "transition time", a form of slack.  The end of a product cycle is always a lot of hard work, with a lot of pressure.  We strive for maximum efficiency, and a lot of other important things get pushed off.  The slack time is a chance to restore balance.

The first part is 7 days of self-directed time.  These are work days, but there is nothing scheduled.  Different people are doing different things:

  • Talking to teams that are exploring long-lead ideas about new technology

  • experimenting with retrofitting our legacy code for unit tests

  • cleaning & rearranging their office

  • building applications with VS2005

  • reading

I have been reading the new XP book (Extreme Programming Explained: Embrace Change, Second Edition, by Kent Beck).  Combined with the first edition, it's very good stuff.

I have moved in to a new, larger office.  I'll have to get some pictures to share & gloat.

my side project

I have been working on my side project, which is written in C#.  It's not something that would be useful outside of Microsoft, so I won't go in to details about what it does. 

I always wrote it in C# 1.0, so I could deploy on the 1.0 CLR.  However, I can soon require my users to install the 2.0 CLR without it being draconian.  It's really nice to be able to use generics and anonymous methods. 

It's a command line app, and I've always struggled with the command line parameter handling.  What does a good syntax look like?  How should I parse it?  I've been rewriting the parser in a more generic way, so it's easy to expand the syntax as the tool grows.

The original implemention has sparse unit test coverage.  Of course, retrofitting is hard; your code is no longer well-factored.

However, the new lexer & parser were implemented from scratch, in isolation, and done test-first.  I've been using unit testing for TDD, as well as using FIT for acceptance testing.  A powerful combination.  I just wish I had a pair to make up for all my pesky weaknesses.

The second part is 3 days of comp time (days off), where we get to meet our families, rest, go sailing, etc.  Not sure what I'll do with that time... we'll see.


Comments (3)

  1. bao says:

    Ahh, command-line parsing. I’ve written a variety of command-line programs, and ended up implementing a unified parser for all of them. As for syntax, I opted for the familiar switch syntax with ability to parse both “-switch option”, “/switch option”, “/switch:option”, etc. An interesting idea you can try is having the possible switches discovered from a class via reflection, so that you can pass an object to the parser and have it drive command-line parsing.

  2. Keith Hill says:

    I’ve used the Command line parser that somes with Ghengis. It works pretty well and you don’t have to write much code to have a parser. It is mostly declarative using attributes:

  3. andersonimes says:

    Get paid to read instead of being forced to do it on personal time? Sounds too good to be true.

Skip to main content