Monday, March 13, 2006

TocSim available at RubyForge

I have just set up a TocSim home page at http://tocsim.rubyforge.org/, and made TocSim available on RubyForge. There is no gem package or tarball available yet, so anyone interested will have to download directly from the repository.

2 comments:

Skott Klebe said...

Fascinating. I've been following your Variance Trap series with great interest. The value of small batches cannot be overstated.
Does your research show whether other planning techniques are effective in increasing predictability? It seems that one way to manage the variance trap would be to plan slack, another technique that almost no IT project managers use.

http://textiplication.com

Henrik said...

Planning slack is definitely one way to do it. There are methods that are a great help in planning just the right amount. The series will get there, eventually.

One problem with planning slack is that software development projects are prone to blockages outside normal parameters. For example, a friend of mine works in a project where his employer has not provided computers for all of the developers. Some of the machines they do have are so old and decrepit that the team has had to "borrow" memory chips from other computers in the work place.

I know three different companies where management deliberately slow development teams down because they work on time and materials contracts. The management wants to increase net profit. They do not realise that they are reducing the return on investment, and therefore loose money. Talk about being hoisted on their own petards.

In one web application project I worked in several years ago, the project manager decided to remove the web server, because he could not understand what it did.

In another company, management forbade running web servers on company computers after hearing a talk on security issues. Bad news, since every development project the company had was a web project.

You can't predict when random acts of management will strike a killing, blow to a project. In my experience it happens fairly frequently. Therefore, I favor methods that focus on measuring what happens, and then extrapolate the future from what has happened in the past.