22 Mar 2010

Project Tax

Beyond the skill of the team, the amount of time to deliver functionality is significantly influenced by a combination of:

  • team size,
  • the process they use,
  • and technology they base their application on.
For example, it will take a large distributed team using complex technologies (e.g. Portlets, ESB, SOA) far longer than a small team using Rails to deliver the same functionality.

A nice metaphor to express this difference is “Project Tax”. I first heard this concept in a blog post comment by Steve McConnel…

“Some of our clients have used the "tax" metaphor. I've mostly heard it used to refer to overhead required to develop a component within a larger system. I.e., to create even a "hello world" program the tax burden to work with the other programs is 5 staff weeks--after that you can actually start adding functionality.”
Steve McConnel

Project Tax is not necessarily a bad thing. The tax helps pay for governance, standardization, along with potentially predictability and maintainability. But the degree of Project Tax may affect the nature and structure of the team.

Good developers may find it harder to shine on Project with a high Project Tax. Instead of delivering features finding themselves focused jumping through hoops – an intellectual dead end. My instinct tells me that great developers will avoid high tax projects.

“The distinguishing feature of nasty little problems is that you don't learn anything from them. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn't teach you anything, because the bugs are random. So it's not just fastidiousness that makes good hackers avoid nasty little problems. It's more a question of self-preservation. Working on nasty little problems makes you stupid. Good hackers avoid it for the same reason models avoid cheeseburgers.”
Paul Graham

With a higher tax the overall performance of the team may drop, which in turn reduces the delivery capability, which in turn increases the size of the team, which in turn increases the project tax, and so on. This would certainly explain the awful state of many large projects.