From Wikipdeia:

Parkinson’s Law states that “work expands so as to fill the time available for its completion.” A more succinct phrasing also commonly used is “work expands to fill the time available.”

Hofstadter’s Law states that: It always takes longer than you expect, even when you take into account Hofstadter’s law.

The principles don’t require our belief for them to work.  I won’t spend time defending what does not need defending.  I want to write about how one can incorporate acceptance of these two laws into planning.  I think a good portion of Agile is directed at this.  I also think that Waterfall struggles against these Laws and ends up broken on the Lighthouse rocks.

Principles are like lighthouses. They are natural laws that cannot be broken. As Cecil B. deMille observed of the principles contained in his monumental movie, The Ten Commandments, “It is impossible for us to break the law. We can only break ourselves against the law.” — Stephen R. Covey

Here is the basic formula for living in congruence:

Growth Driven + Time Boxing + Small Iterations + Value Driven = Success

Growth Driven

When something is grown, vs made, it is almost always in a useable state.  When something is made it is almost never useable until it is finished.

Time boxing

Instead of trying to use cumulative task estimation as a lever for management decouple the deadline from the estimation.

Small Iterations

Keep the time boxes small.

Value Driven

Do the most important thing first.

In a short period produce as much value as possible, preferably the most needed value.  Do it in a way so that what is produced can easily be added to.

Let’s take a look at the anatomy of this solution.  The lynchpin is time boxing, everything else is there to support time boxing.  How do you keep a task from taking longer than you expect?  Stop having an expectation.  When time runs out you have no choice but to go with what you have.  Time is going to run out, there is nothing you can do about it.  So it is best to have as much value as possible.  How do you keep a task from getting to big?  Don’t provide time for large tasks.  This will prevent things like Student Syndrome and Coefficient of Inefficiency as well.  How can you deliver when you are not sure what will be complete?  Produce in a way that you are always ready to deliver.

I don’t feel the need to explain how Agile planning works.  There are plenty of sources that talk about how Scrum, XP, Lean, Crystal, etc do it.  What they share is the formula and an acceptance of the Law.

There are many ways to make a build fast.  Some solutions are technical and some are conceptual.  Some are made in the build script and some are made in the product.  I thought I should share some of the ways I have been successful at making builds fast.

1. When does the timer start?  Trigger the build when the developer commits, don’t poll.
2. Only some of the people are happy all the time.  Make a developer facing build and cut out everything that you can.
3. 9 woman can make a baby in a month.  Use asyncexec to maximize system utilization.

I have not been lucky enough to work on a project that maintained it’s own Subversion repo.  If I had I would of implemented something like TFS’s alerts, this should be a cinch with Captain Hook.  In TFS you can subscribe to the checkin(translates to commit) event and be called back on a web service.  I have utilized this functionality in CI Factory.   When a developer checks-in, TFS immediately calls CI Factory, triggering a build.  A developer checks-in and cctray immediately shows the activity as building.  This is a dramatic change from poll based triggers.  Remember the clock starts ticking when the developer commits not when the build actually starts.  This understanding can be a great lever.  If the poll cycle takes 2 minutes this is a huge opportunity.  The opportunity to remove 2 minutes from the build just by triggering the build on the commit.

Don’t try and do it all in one build.  Don’t try and satisfy Developers, Testers, and Managers in one build; their needs are not all compatible.  For example Developers don’t want to wait for the installer to be created.  Take a look at all the needs you’er trying to fulfill, workout which are compatible, and make a build for each compatible group.  A developer build can be incremental, a release build should be from a clean get.

If your build machine has multiple processors, which it should, you should be taking advantage of them.  Figure out what parts of your build can be executed concurrently.  The key word here is can, it was not make everything use asyncexec.  You will need to play around on the hardware that your build server runs on.  Play with the different combinations until you find the fastest.  Remember that many of the build operations are IO intensive.

A quick technical note.  The release build should not be building anything that has not already been built by the developer build.  The release build will be changing the version information files (assemblyinfo and productinfo).  There is no need for these changes to cause the dev build (if it is hosted on a different server) and the developers personal builds to rebuild projects.  Make sure there is a touch command in place to prevent this waste of time.

P.S. Michael we don’t record trending info on personal builds but it is a priority to make the personal build script soo fast that you prefer to use it over the IDE.  Soo fast that you always run it before your commit. 

Some people have gotten confused about what CI Factory is and is not: I use it as a platform.  Yes, you can use it as a canned solution.  However I have found that shortly after you get it up and running the requests start rolling in for more.  Hey, can you add this to the zip?  Can you add a second zip?  Can you manage the developers databases with it?  Can you deploy to the testers environment?  Can you publish to the release area?  Not to mention all the requests for additional private build script functionality.

I use it as a boost to get that much further than if I was going to set up all that stuff manually.  I lean on the structure and naming convention to allow me to move scripts and snippets from one factory to another without much if any fuss.  For the most part moving a script snippet will just work.  In fact I was hoping that this type of portability would allow people to share in smaller units than a Package.  I have already taken advantage of this portability to help diagnose issues reported in the user group.  I send a snippet, ask the user to run it, and they send me back the output.  It has helped immensely.

At my day job we used it to create a ultra fast developer facing build, a reset button heavy build, a release build, and most recently a release management area build.  We plan to add a heavy test build next month.  Some of my current work deals with DotNetNuke, creating web part zips, and packaging a site.

Last comment on this subject.  Some people see that there is too much going on, there are too many Packages, especially the Kitchen Sink Package.  The Packages are like a buffet.  Are your eyes bigger than your stomach?  The release management area build that we just setup only has the Subversion and CSDiff Packages with a little bit of custom scripting.  You can make a lite factory.