Image

We hear allot about design…..

  • Simplicity of the design,
  • Durability of design,
  • Beautiful design,
  • Failure in design, and
  • Blah-Blah-Blah design.

What the heck is all of this stuff about design?  Thousands if not tens of thousands of books have discussed, formulated and promoted design as the key to outcomes.   But as we see the buck stops at the talk and often goes no where beyond that stage.  Why is this happening?

Image

Myth #1 – Design is not a Title

Sure you may have the word in your position but design is not reserved to one person or one group.  Everyone does some sort of design.  Design is not a task but an interconnected set of events that compositely give us a sense of doability, complexity and direction in which to advance the development of a product or solution.  I’m sure that most have sat in meetings in which business units will sketch out what they are doing and what they would like to have happen… this is design.  Albeit possibly not to the formal liking of the purists it is none the less design, don’t make fun of it!  Even the administrative assistant who is arranging that all important luncheon meeting is doing so by design.  Some possibly from experience and habit and in some cases by a sketch of things to do and organized into some paradigm that they (or others) can utilize.  So design is not reserved just for those titled but everyone is a designer unto their own rights.  If we think back to our childhood, the moment we observed things and later picked up a crayon, pencil or pen our goal was to design something.  Maybe it was a big red barn, a portrait of our family (in stick figure form along with fido) or maybe it was a more ambitious project to form shapes that lead us to the creation of letters.  All of this is design.

Image

Myth #2 – Design is Necessary

I prefer to think of design as not being necessary but merely the natural bi-product of thinking.  The human mind cannot process chaos, it strives to have order and seeks out some place where past experiences have had similarities.  The freeing of process to seek a base of information is essential but in doing so we need something that gives us certainty about so so many questions.  Some look for solutions, others question the importance and some even wonder whether we have got some reasonable level of completeness.  To answer these and many other questions we look for help and to achieve this we look to formed methods and techniques.  Experienced individuals will have their own preferences and even some custom made methods that they rely upon to acquire design awareness.  I have relied on tools such as Unified Modeling Language (UML) (structural, behavioral and interactive models) to exercise the multifaceted features of an application project but my design toolbox isn’t limited to this one approach.  Such techniques as high impact inspections, test driven design (TDD) and rapid story creation have been equally valuable and gratifying. These all are beginnings leading to a design vision.  It very well can be and often is more than one, and this is okay.  Multiple options give us flexibility and alternatives which we are most often going to need during the course of a project.  In the case of Agile projects if we look at the arrangement of stories into families, usually surrounding the notion of work to be performed we have a design that can be lifted from it.  In the more classical context of waterfall or v-model methods we are more apt to conceive design as a bi-product of understanding and embracing design.  Both the same yet achieved in difference ways (and possible with prejudice different expected value to be achieved from each of the approaches).

Image

Myth #3 Design Is Magical

This is where it gets a bit dicey…. is design something you do regardless of sound engineering principals being applied or not?  Those who are proponents of building and exploring (which is by definition research) really do so without a design.  I would, from practical experience, say yes.  Its not that its not important or necessary its because the process being used is intended and focused on doability and the possibilities that can be exploited, nothing more. For this reason this sort of work is intended to lead to knowledge, which in classical terms is a defined requirements vision, to which the formalization for completeness can be exercised.  Unless we intend never to do anything more with it, including repair work, then design is not needed.  However, most will reverse engineer a design from what is produced to not only create a positive maintenance atmosphere but also to definitively answer the question about whether the endless possibilities of the research has been reached.  For others design ‘anything’ are used as guides to form work and task lists of things to be constructed to achieve the desire outcome.  This includes a definitive understanding of how the piece parts will work in harmony or contention, based on the desire of the design outcome (and requirement visions).  The creative aspect of design takes place as the result of formation and the convergence with specific technologies be it hardware, software or idiom (SaaS, Cloud, Big Data, etc.).  Its this exercise that we start to seeing balancing, or the absence of, occurring.  We hear the term dependencies to reflect the level of cohesive and interdependencies that exist in design.  There are reasons for tight cohesiveness, often centered around constraints (memory, bandwidth…) but sometimes its caused by gross negligence and poor practices.  Design management cannot be taken lightly, it required purposeful and dedicated attention to insure that all is made right.

images

Myth #4 Design Is a One Size Fits All Proposition

Will the concept is rational, at least in so far as the initial deployment, subsequent activities that involve changes and modifications results in an erosion to design.  This produces some interesting challenges for such paradigms as the software reuse factory, refactoring and agile driven modularity.  So how can this be overcome if at all?  Since it is a foregone conclusion that our lives will not remain static we have to assume change.  We might even have a pretty good idea as to where it will take place, when it is like to occur and to what extent it can be expected.  If we have even the slightest idea about any of these things we can insult our general design in two possible ways.  The first is by utilizing a plug-n-play approach where pieces can be exchanged in an out of the solution set.  The second more difficult approach  involves design retrofitting, the act of redesign taking place as changes occur.  In order to sustain durable and reliable design one must have software support to provide us with real time dynamic vision  into the solutionset.  Using this information is like having a dashboard that permits us to address the impact of change as to the target design it is being made against.  Not all design is evil.  In fact it can be a welcomed relief for legacy applications and those in which design was really never a strong point from inception (e.g. may be caused by rapid response driven deployment or first time out solutions).

imagesMyth #5  Design Mastery Can Be Taught

There are some things that you simply can’t teach without experiencing it.  It takes practice, failure, listening, observing and mentored guidance to become not just the ‘titled’ individual but one that clearly understands and has mastered design.  Disciplines such as structural and civil engineers mandate not just schooling but also board examinations and a period of internship.  Yet in information technology certifications are a matter of choice and not one of mandate.  Some might argue that the risks are different, but are they?  Maybe the most compelling reason for experience is the result of converting intellectual visualization into an habitual endearment to the means of achieving designs that work.  We sometimes make the mistake of thinking about the end and not about the means of achieving it.  In the immortal words of Steve Jobs, “Design is not just what it looks like and feels like.  Design is how it works.”.   Maybe this is why Steve Jobs worked so so well with his long time friend Steve Wozniak.

 

Advertisements