The code wants to go somewhere, listen

A seasoned designer knows that a trait of design dexterity is to know how to identify what to remove from a particular design, making it simpler, conveying the same intention with fewer elements, in opposition to just adding elements to it.

A curious problem facing some designers wanting to practice good design in front of mainstream designers is: the design context is screaming –so to speak– the removal or the prevention of some naïve generalizations that will just add unnecessary complexity to the overall design. Those generalizations or abstractions come from the need to achieve a buzzword-compliant product, not from facts of usability information, not from a thoughtful process through several design tradeoffs based-on design metrics, just from those typical designers incommensurable opinion of themselves.

An explanation about marketing demands is unacceptable, as is unacceptable to employ cheaper and below-quality materials in the construction of your home, or a dirty bistoury by a surgeon while he cut you open.

This is not ‘an engineering practice’; please not call engineering to that; perhaps a joke, a fiasco, an infamy could be a better fit.

Marketing personnel usually do very well, they know their stuff; they usually figure out how to do a good job without or with little help from technicians. Software design professionals should not be at the mercy of fashion and buzzwords, but at the mercy of customer real needs.

I remember the same thing happens with CASE tools, object orientation, frameworks, some programming languages, the web, design patterns, methodologies, XML, and recently with SOA. It is understandable considering the age of our craft, about 50 years, it is like childhood “I want that, no now I want this other thing, no I want those, …”. So forget to call this an engineering discipline by now, perhaps in another lifespan, maybe.

As a case for study consider an application with modest design working as expected, the relative success attracts some so-called ‘architects’ commissioned to improve the design to achieve bigger objectives to reach a larger user base.

What did they end doing?

Well, they bloated the design adding all kind of buzzword-compliant mechanisms and generalizations, taking neologisms from everywhere, obscuring the once reached conceptual integrity of the original humble design.

Untamed, uncovered complexity was the main theme when such a design comes to consideration. The costs of doing almost anything with that code continuously increasing.

Finally the time came when such a design passed to other hands, and when the ‘architectural’ team was asked about which were the essential components that make a first step in the adoption program?, and which ones makes the second step, and so on. Their answer was: “there is no such thing, this is an integral system and you take it or leave it as a whole”.

So the grandiose design, full of design patterns and many jargon words –but also with complete lack of understanding behind those jargon words– was in reality a monstrosity unable to set back into shape, a mess that can only be used all in its entirety or nothing at all; curious thing that they called it ‘a framework’.

Depressing is that the ‘architectural’ team forget what John Gall has already said about systems in “Systemantics: How Systems Work & Especially How They Fail”. Not that there should were explicit design goals about decoupling between identified and isolated components, but because there are software fundamentals that apply to any non-trivial design, coupling and cohesion and separation of concerns to say the very least.

Good design usually evolve incrementally (from 1 hour to few weeks increments) into a piece of software that can be used incrementally, useful parts or subsystems decoupled from each other so that lesser or greater capacity can be delivered.

A root cause analysis could show the lack of real designers in the previous picture, good designers know how to listen to the code; learn to hear where the design ‘wants to go’, it sounds weird but actually it happens when the team owns the software till the last detail and are very close to what entails the evolution of a particular software design.