Bit I see, bit I want

Bit I see, bit I want

Before object-oriented programming, developing was quite easy in terms of architecture and design. C or assembler did not play a big part except for a few optimisation algorithms for binary trees or bounded lists. With the arrival of object-oriented programming, this started to change. Design patterns…

ByteBefore object-oriented programming, developing was quite easy in terms of architecture and design. C or assembler did not play a big part except for a few optimisation algorithms for binary trees or bounded lists.

With the arrival of object-oriented programming, this started to change. Design patterns, programming paradigms and GoF, among others, started to appear and object-oriented design became so broad and the programmer’s creativity so effortless to take advantage of, that it suddenly became very easy to create a new idea or software pattern.

As it happens with everything that is innovative, it became slightly distorted in some cases. During the 1980s and 1990s, over-architecture filled the designs, applications were oriented to the “big architecture” were able to absorb any requirement and were ready even for unlikely developments in time.

Eventually, it was noticed that the life cycle of some applications was not that long and that the over-architecture filled with abstract interfaces was not going to be used forever, or was not even going to be useful. It became clear that designing a skyscraper in order to store a shoe box was maybe taking the concept of design too far and that the “just in case” notion is not applicable since, if there are things that are unlikely going to happen, they simply will not happen.

This idea has been appropriately drawn up in concepts such as KISS or DRY, but when taking a closer look one can distinguish how many concepts and ideas are constantly and sporadically arising. Most of them are barely visible to the critical eye and, besides the ones already mentioned, there are many others such as “reusing”, “refactoring” and “decoupling”, among others. In the past, style meant over-architecture, then it was the minimalism of KISS and DRY… we went from the tedious bureaucracy of CMMI to the agility and insolence of SCRUM.

In some cases, these trends take root in the IT community. In fact, a domino effect happens: a few people scatter the seeds and a lot more cultivate them. And out of the blue, an apparently simple and logic concept becomes dogma and is mentioned every time there is a chance to do it. The community pays attention and welcomes in awe, for example, the simple fact of explaining the need of a simple code by using acronyms. From time to time, some characters appear and explain with a wealth of detail all these new advances as if they were dogma of a new church created from of the innocence of a few and the ignorance of many others.

Surprisingly for those inside and outside the industry, computer science obeys trends that, in a cynical way, leak into the community with new ideas brought back from the past, from old and shabby books. Since these volumes have not been scanned or uploaded to the Internet, they are ignored by the new generations and come back as renovated old trends that try to rise as new concepts but are just a reformulation of an obvious and forgotten one.

This causes spontaneous outcry within the community to the cry of “The code needs to be decoupled!”, “Let’s refactor!” like cheers in the galleys, like opposing concepts coming from rival terraces in a stadium, as if there were only current but not past concepts and there was no chance of fusion but only confrontation.

Not every idea should be brought face to face. The idea in vogue is not the only right one. Not everything is acceptable at any time. Not always the code needs to be decoupled or refactored. Concepts exist on their own, but merely as an aid, not as an absolute truth that conditions or redirects any development. True design is guided by the right idea, not by the prevailing concept at the time.

Time teaches the concept of distance. Ideas cannot be isolated, they can only be twisted, stretched and contracted in order to be reshaped. History shows that many of these ideas have already been discussed. Providing them with a new package does not imply necessarily that they are a whole new concept or design. Crying out forgotten ideas should not make them stronger. Creativity designs towards the future, but common sense prevails over the past.

Concepts may come back, and acronyms may change. What is heard today will be heard tomorrow with a different name. An idea does not, or should not, lose the value it has for a listener subject to the concept. It is good to know about it, but it is even better to differentiate it by finding out the origin of the idea, the reformulated but already known concept. One should not lose this ability to differentiate or to locate the essential meaning within rambling paragraphs. This way, one will be able to realise there is nothing else to read about it and kill that idea, and by doing so, create a new one. Although it might sound contradictory, the greatest ideas often appear when all the previous ones are known and what could result in an idea based on the past, becomes an idea that arises from the past.

I, Architect
Josu Uribe Sainz

 


 

Use of cookies

This site uses cookies for you to have the best user experience. By continuing to browse this website you accept their use and agree to our cookies policy. Learn more about our cookies, following this link

ACEPTAR