wuetender-junger-mann.de

Now we got continuous integration, pair programming, TDD and many more things and still manage to pile up heaps of problems. So today Szczepiq and I were wondering, what to do about this. Of course we need a new acronym and we are cold-heartedly stealing one BDD (Sorry!) . Trouble is people always come up with excuses shitlloads of bloated code: “it’s not code it’s only a template”, “it’s just configuration”, “well in the testcases duplication can increase readability”, too mention a few. This not only makes extending and refactoring a system hard. It also tends to increase build times, which in turn makes it hard to get your work integrated quickly (especially if the build fails erratically).

Budget-Driven Development to the rescue. It’s all about budgeting time and space. So for a given amount of features you are given a budget. You get a specific amount of lines of code and a specific amount of build time (including tests). As it is somewhat difficult to measure the amount of features we are happily going for time. Per developer or pair you get something like 50 lines of code per week plus say two seconds of buildtime. It seems essential not to allow for too much of a constant upfront code and build time.

There could be tooling that actually prevents you from committing stuff that is exceeding your budget, or at least raise a warning. If you feel your budget is not enough to achieve a certain feature you are forced to refactor the existing code base to free up some budget. It would be possible to introduce weights, e.g. one line of XML config costs as much as two lines of java code. You could also factor in a complexity measurement.

Projects that are in deep trouble, could actually use zero or negative budgets to motivate the cleanup.

It might also be fun to try to cope with constraints. Back in the 80ies DOS a German computer magizine run a Kilomark competition. Each month you could win DM 1024.- for the coolest program written in 1024 bytes.