Multithreaded

I’m a FogBugz user. I think it’s a great bug-tracking system. So much so that I paid money for it rather than opting for BugZilla. It looks like it’s about to get even better with the new version 6 release.

One of the key new features is Evidence-Based Scheduling. Joel has posted a long article describing it here. What really cracks me up, though, is that the article is really just describing the planning and tracking method used in Extreme Programming (that XP, not the other XP) and other Agile methods.. The foundation of estimation in XP is basically “estimate that you will do as many units of work next week as you did this week”, and by getting the developers to estimate the tasks and then track how much time they took to actually deliver them, you get a very good idea if you are ahead or behind the estimates.

Even this description of what to do if the schedule says you can’t deliver everything by the desired date:

4) A schedule is a box of wood blocks. If you have a bunch of wood blocks, and you can’t fit them into a box, you have two choices: get a bigger box, or remove some blocks. If you wanted to ship in six months, but you have twelve months on the schedule, you are either going to have to delay shipping, or find some features to delete. You just can’t shrink the blocks, and if you pretend you can, then you are merely depriving yourself of a useful opportunity to actually see into the future by lying to yourself about what you see there.

is pretty much exactly the same as what XP describes, though XPers do it by laying index cards out on a table, rather than putting blocks in a box. What is most striking about the article is the way it talks about putting so much of the responsibility and control into the hands of the developers, as opposed the traditional method of “project planning by dictum” controlled by the management or the client which is what leads most projects to fail. This idea of sharing the responsibility and, more importantly, the authority, is a cornerstone of XP and Agile. Trusting the developers to make the best estimates (because, after all, they’re the ones who actually do the work) and not letting managers and the client override them are key. In XP parlance, “time, resource, scope - the client can have control over any two of those, as long as the team is given control of the third one”.

Joel claims not to be a fan of Agile techniques, yet time after time, he has published articles describing the way he develops software which are simply Agile methods re-cast into his own metaphors. For example, in his article on the Project Aardvark Spec he makes the claim “I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema”. However, the spec document that he links to at the end of the article would be completely unrecognisable to anyone who has worked with true Big Up Front Design in the past, and contains nothing, apart from the coding conventions which he admits doesn’t belong there in the same article, which you wouldn’t find written on an index card in an Extreme Programming shop.

Come on Joel, it’s time for you to finally admit that you are as Agile as they come, even if you’ve expressed all the ideas and techniques in your own way (which is a totally acceptable thing to do.) If you don’t think so then please read the Agile Manifesto and tell us which bits you disagree with.