Saturday, March 07, 2009

Design issues

James makes the point that design decisions usually have an effect time span that is usually longer than the tenures of the people that make the decisions in the first place. There are two sides, basically: ship it now, or get the design right.

Of course, neither is perfect. To me, what seems to work better stems from accepting you will never get the design right. That is basically a utopia that will just not happen.

That does not mean no thought should be spent on design either. The critical observation is what do you do when you know your design is not perfect. The goal becomes reaching v5.0 and keeping your sanity, not just v1.0 and 50% hair loss.

It is then that you design for flexibility. In practical terms that means design principles such as no isKindOf:, no respondsTo:, no switch statements, no hot methods that every addition to the image wants to modify in incompatible manners, no implementing functionality in a way that paints you in a corner from where you cannot back out, no unloadable code, no writing code in the first person, and using classes to explicitly express what is implicitly meant by a web of ifTrue:ifFalse:.

If the implementation of a piece of functionality needs to be mostly reimplemented due to a small change in requirements, then it was not designed with flexibility in mind and it just represents latent homework for the future --- either a maintenance nightmare or a rewrite from scratch.

With practice, however, the techniques you need to avoid this homework end up costing you less time than a more traditional approach would take you in the first place. This is not magic, it is just a matter of identifying and eliminating deleterious side effects.

Finally, this is also a reason why I think the Fundamentals books are important.


Stefan Schmiedl said...

Can you give an example for "writing code in the first person"? I understand the other design principles and probably am guilty of violating this one, too. But what is it?


Andres said...

Basically it refers to being unable to let go. So instead of delegating responsibility to objects, there is code that reads "now, object X, do this... now, object Y, do that"... as if it was some sort of military command sequence. This, to me, is an expression of the programmer speaking. IMO, there should be none of that.