My recent epiphany about the benefits of formal upfront design in software has been somewhat marred by that most feared condition known as analysis paralysis. Of course it greatly has to do with my inexperience, but it serves as a reminder about the very real, very tangible gap between the aesthetic beauty in the succinct, clean theory behind some of software design, and the actual process of putting this into practise. I've taken on three fairly simply designs, and each time I have found myself being literally paralyzed by indecision. I seem to reach a stage where I cannot think how to proceed any further - I get stuck in an infinite loop of weighing the pros and cons of the options I have, and never being able to determine which way to go down. I start off with good intentions, and grand notions of coming up with a basic design and suddenly shouting "But wait! Separate abstraction from implementation! Bridge! Bridge!". What actually happens is that I reach a state where I can get literally fixated on one particular piece of a problem, and stare endlessly at the screen, weighing and reweighing my ideas but never reaching a decision. The resolution comes when I take the path of just going with my instinct; there's something to be said for that, but it would be far more satisfying if I could then provide some sort of rationale for me rejecting the other alternative. I am very interested in the higher-level thought processes that "good" designers apply when they are faced with such problems. Design, as with most problem-solving, seems to consist of (at least) two potentially torturous questions that one must answer. First, how do I begin? The big question that everyone has asked at some point I suppose. It's fascinating to record the different ways of approaching problems, especially problems across different fields. My very brief exposure to electrical engineering was enriching if only because it showed me how an engineer tries to solve problems. I remember in particular that during one of the later tutorials I had in the semester, as the tutor began writing up the solution to one of the exercises, it struck me that what I was seeing was very much a design pattern in engineering (probably a very basic one, but anyhow). I seemed to keep approaching problems from a mathematical perspective, and this alternative opened my mind to other ways of thinking. I left engineering with a new-found respect; I had started off with the impression that it would be very much practical and no-nonsense, and it was to some extent, although it certainly had some underlying elegance.

The second question I think is quite simply "Have I made the right choice?!"! At the moment, I seem to be totally unable to answer this question whenever it crops up.

For instance, I recently had a problem where MI (multiple inheritance) seemed appropriate. Of course, most people suggest that one look to alternatives to MI where possible, since it is easy to abuse (and tricky to get right). Very reasonable advice, but determining whether something is appropriate is, not surprisingly, never expounded on in any of the references I came across. There are guidelines, but the sad fact is that one has to apply some sort of intuition to one's specific problem. The same goes with patterns - they are powerful, but they are no magic panacea that one can throw at any given problem. Indeed, which each of my designs I have found it actually impossible to see the applicability of any simple pattern! Alas, applying them is not as easy as one would think!