• The product of human creativity
• The creation of beautiful or significant things
• A superior skill that you learn by study and practice and observation
• Visual representations in a printed publication

I would decompose the process of design into the following ingredients: ingenuity, domain knowledge, technology knowledge, design patterns, heuristics, hands on development experience, analytical reasoning and prior design experience. I would further qualify these attributes into two broad categories, ingenuity and elaboration techniques. The nucleus is the art, the stroke of genius, while the rest of the process is intelligent elaboration. Post zygotic stages are well understood and predictable but it's the nucleus which takes that rare stroke of lightening in the primeval broth for life to emerge. Although elaboration techniques form the bulk of the design process, it's the art which infuses the soul in the design.

In almost all the cases, design processes turn out to be elaboration exercises. Structured elaboration forms the key to any iterative endeavor, may it be design, building a clay sculpture or cooking dinner. If we introspect on the elaboration techniques, we will quickly realize that everything rolls up under 'heuristics'. "A commonsense rule (or set of rules) harvested from prior experiences which are intended to increase the probability of solving some problem", is how heuristics is defined :). Experience or heuristics is of two types, collective experience and individual experience. For example, design patterns is a collective knowledge base while hands on development experience is individualistic. You can assimilate design patterns, but you have to strive to aggregate prior design experience.

Having made all the above profound statements, let me try to supplement philosophy with tangible data points. Let me give you an example. Once upon a time, I was faced with a unique problem. I had to design an offline batch system with high throughput requirements. It was a porting project with emphasis on staged migration of functionality, design catering to functional scalability (resilient to business logic changes), high reliability etc.

After a few days of brooding and listening to Nirvana, I came across the following diagram (to the left top). Looking back, this was possibly the most demanding effort in terms of creativity in designing the solution. The conceptual solution formed the nucleus of the design, which was iteratively elaborated to form the final design (shown below).

Each of the iterative elaboration phases were quite easy in themselves, essentially turning out to be optimization problems. For example, in one of the iterations we dealt with the problem of sweeping the processors before reaching the terminator to ensure that no workers were left operative before the terminator was invoked. The solution (second from top) flowed quite logically in terms of the need to wait on each processor for it's workers to finish. The waiting in turn was controlled by a count-up-count-down latch which was incremented/decremented during the pre-processing and post-processing stages of the workers. So on and so forth.

For many weeks, I thought that the initial pen sketch design was the bolt of lightning, the art, which could not be arrived at by deductive analysis of the problem. But then, I realized that even the pen sketch was heavily influenced by the constraints I was dealing with and my previous experiences. For example, you can clearly see influences of 'service bus' (mediator), 'chain of responsibility', 'activator' and 'executor' patterns. I had worked with each of them individually in the past but possibly never in this permutation.

It was quite disheartening to see my feeling of ingenuity dissolve away. I have observed that in most of the cases, ingenuity is expressed in assembling prior knowledge in a suitable permutation to solve the problem at hand. It is the art of assembly and the swiftness with which one is able to evaluate multiple alternatives against the constraints and choose the optimal one, that makes the difference between a good design and a not so good design.

The success of a design, I have realized, lies on three pillars.

a) It is very important to realize all the constraints that the design needs to satisfy. Constraints include documented requirements (functional and non functional), implementation platform limitations, team strengths etc. The cost of missing out on constraints goes progressively high as you elaborate through the design.

b) Knowledge of patterns, tools, techniques and reusable components. It is said that design should be tools/technology agnostic. I find this statement to be grossly misinterpreted. It's only the conceptual design that has minimal influence from the platform of implementation, rest all start getting progressively influenced by implementation tools and techniques. For example, the knowledge of the Executor pattern was quite fundamental is coming up with the specification level design. If I have had no clue of the executor pattern, the design most probably would have been radically different.

c) Solutioning and their evaluation. Each of the design constraints can be solved in a multitude of ways. However only fixed combinations of solutions cater to all the constraints put together. It is important to understand that a design is never right, wrong, good or bad on an absolute scale. A design is good or bad in reference to the constraints it tries to solve.

Well, so what's new? These three points form the basis of any solution irrespective of domain or kind of work. Understanding constraints, having the required knowledge to solve the constraints and evaluating possible solutions are things we do even when shopping for vegetables or shoes. What's so special about designing a software solution? Is it just that the tools, knowledge and evaluation criteria are different than that for vegetable shopping? And what about the philosophy of 'art' being a part of design ?

I had started off this blog trying to project designing as a by product of a superior thought process, but then it is not true. Software design is just like solving anything else, it's just the knowledge of technology, understanding of constraints and ability to evaluate solutions that makes the difference. And none of them is rocket science. All it requires is knowledge, practice and logical thinking.

Oh btw, forgot to mention, to acquire these three qualities it takes time, devotion and practice, lots and lots of it.