What you’ll write tomorrow is not what you think today
My favourite idea from Extreme Programming is that you should not run your imagination wild and try to conjure future requirements from a chrystal ball. Instead, you should design and write something lightweight that works for current requirements and refactor it later, if needed.
Why have I grown fond of this philosophy? Wouldn’t it be easier to implement those future features if they have already been taken into account? Maybe, in theory. But along the way, I have seen enough really bad code (oops, some of it written by me) that tries to fulfill some needs that were imagined to be worthy one day. Of course, requirements changed as they always do (unless you work in some dreamy place with thick forests and a nice waterfalls), and the feature was never fully implemented. Often, the feature had never even made it into the requirements list.
As the application doesn’t really support the anticipated feature, it is confusing to read and hard to understand such code. Since the feature was not needed at the time, the feature was not thoroughly tested, so there are inevitably some bugs that might even hinder useful parts of the code. And since some later changes have not taken into account the fancy feature-ought-to-be, the code has become stale so awfully that it would be much easier to design the feature from scratch anyway.
Of course, as any useful idea, this practice has its limitations. For an intended public API, you’ll want to get as much of naming, structure and scope nailed down as possible before considering the work done. Any reorganizing you’d want to introduce after publication would break applications that have already been written against your API. That would eat up your API’s trust quota quite fast. You’ll need at least three applications experimentally using your API before you can consider it generic enough for wider use.
6 comments October 3rd, 2006