It's a bird, it's a plane, it's

Everything here is my opinion. I do not speak for your employer.
August 2017
September 2017

2017-08-31 »

SimSWE part 1: Indecisiveness simulator

I made a simulation of what happens when release goals change.

In the simulator, we have N developers working on release-critical bugs in parallel, and new bugs getting filed at a constant rate (faster than developers can possibly fix them all). There are 10 separate features, and we initially define the release milestone as the completion of 2 of those features. The number of bugs remaining until milestone is the blue line. (Perhaps unrealistically, developers in my simulation actually work on bugs targeted for the release, switching to non-release-critical bugs only when there are fewer remaining release bugs than there are developers.)

The different charts indicate the effect on the release progress when we change the milestone definition. When we redefine the milestone goals, the number of remaining bugs for the release spikes, because suddenly we need to tag a bunch of new things for the release. (We also untag some things for dropped features, but since we've been making progress on those features, there are fewer open bugs dropped than added.) Also, some bugs are part of more than one feature.

First chart is ideal case (no changes). Second makes one change after 25 days (cheap). Third makes one change after 100 days (expensive). Fourth makes several changes early on while PMs argue, then settles down (50 days of waffling for only 25 days of cost!). Fifth makes one change in release goals every 50 days (never completes).

Too many projects are the fifth chart.

I'm CEO at Tailscale, where we make network problems disappear.

Why would you follow me on twitter? Use RSS.

apenwarr on gmail.com