Point Solutions Revisited
I have just corrected an egregious filing system algorithm error in my head. By that, I mean that I have fixed the filing system I carry around in my head. I don't mean that I have mentally fixed a filing system problem and will later fix it in the real world. The problem that needed fixing was in my head, not in the real world. I treat my head as the normative copy of my filing system algorithm. The real world is just the place I keep the physical files: not the filing algorithm itself.
Oh and yes, before you ask, I have thought of capturing the filing system algorithm itself on paper and filing it under "F". That would be appropriate on a number of levels. I don't intend to go there, however. Sometimes self-referential systems are best handled by steadfast avoidance rather than full on embrace. I think this is one of them.
One good reason for avoiding writing it down, is that I cannot write my algorithm down no matter how hard I try. It is a living, moving, breathing thing. It is me, myself and I, all rolled into 1. It ain't no piece of paper. I think the same is true of all people. Hence my endless amusement and bemusement at the sort of automated filing often associated with document management systems. But I digress. Actually, I have digressed on my original digression. Time to pop the stack[1] here.
My mental filing system used to have a rule in it that said something like this: "If a system design is a point solution based on a limited subset of the overall problem or 'wired' to particular volatile technologies, then file this under 'bad design'".
I have come across a number of scenarios recently where, it seems to me such "point solutions" have been entirely appropriate. The first example is in the mobile devices space. The design in question is "wired" to the specific capabilities of a number of today's mobile devices. The second example is related to a new business model related to virtual worlds.
My old filing system would have resulted in me approaching the designs thinking negative thoughts like this: "what if the capabilities of the devices change?" (in the case of the first point solution) and "what if the details of the business model changes significantly?" (in the case of the second point solution).
My old filing system would have resulted in effort being expended to generalize the problem; to anticipate changes in the constraints; to "soft code" rather than "hard code" judiciously...
Under my new filing system I still do this sometimes but not always. I have learned the hard way that prediction is very hard: especially about the future. If the future looks very volatile and very unpredictable, then there are times when "point solutions" to a currently known set of parameters is a reasonable thing to do.
I have learned the hard way to ask myself questions like this.
- How much longer will the design cycle be if I try to anticipate the future?
- If I can produce a design for a point solution quickly, perhaps a continual iteration of point solutions makes more sense than using a crystal ball?
The latter in particular goes against essentially everything I was taught about system design. But then again, when I was being trained to do this kind of work, nobody told me that the world would turn on its head every few years either.
The volatility of IT - especially front-end IT - is such that some problems do not stand still long enough to facilitate "design" in the classic sense. When that happens, build point solutions. Ship the prototype and keep shipping iterations of the prototype.
That may be as good as it gets.