Second, ‘hooks’ was a poor choice of word. Good design is about things like a coherent conceptual framework (aka domain driven design), clear interfaces and reusable code. My contention is that these can be done much better with forethought.

This forethought is basically just an extension of the pattern matching that all programmers do. This is an iterative cycle, where each iteration sees specific code sucked up and rewritten as generic code. My contention is that this practice should not stop when the current work is done but continue to a natural end point.

Another way of putting this is basically OO design. It is obviously far simpler to write basic code than to think in terms of advanced design patterns. But those patterns can allow changes far more easily than the simpler code.

Arrogant though it might sound, I think that experience is what makes these decisions likely to provide future benefit. But if you don’t try then that experience will be very slow in coming.

Finally, I think the cost of unplanned (or at least unprepared) later change is far more than most people imagine. It is not just the cost of the code, but also the data restructuring, the deployment etc. All of these can be mitigated to some extent by decision made before the change is known about.

This presupposes that adding hook code early on is cheaper than adding hook code when you actually need it. Suppose that was not the case and that the cost was the same. In that scenario you’d be better off waiting because:

1) If it turned out you never needed the hooks you would have saved the wasted effort and added complexity of putting them in.
2) If you put them in when you needed them you’d have more information about the problem in hand and be more likely to put the _right_ hooks in place.

I would go so far as to suggest that it is worth waiting even if it is slightly more expensive to add the hooks later. That’s because adding the hooks in early adds hidden costs. The code is more complex which slows down all development. The other argument is an economic one. Consider work being done as an investment and the functionality delivered as the return on that investment. If you think of it like that then obviously you want to invest in areas that will quickly start giving returns. Adding hooks will take a long time to yield any return, investment that could have been made in areas that would yield returns quicker.

I haven’t even mentioned what happens if the hook code is not quite what is needed when you actually come to use it. In my experience this sort of code almost always needs changing to some degree at the point it comes to be used…

So the question is, what are the relative costs? Well the traditional thinking is that the ‘cost of change’ curve is exponential. So that making changes up front is much cheaper than making them later. That would blow everything I’ve said out of the water. However, there is growing evidence that using agile techniques can make that curve much flatter.

Scott Ambler talks about the cost of change curve here:
http://www.ambysoft.com/essays/whyAgileWorksFeedback.html

Martin Fowler talks about evolutionary vs up front design here:
http://www.martinfowler.com/articles/designDead.html