Combatendo a Síndrome "Not Invented Here"

A SD Magazine publicou um direto, curto e excelente artigo sobre a nossa eterna mania de "reinventar a roda". Saca só:

Squashing the Syndrome
As we know, those who ignore the past are condemned to repeat it—so let’s eradicate the “not invented here” nonsense that continues to plague the software development industry.

Looking back at the history of the software industry, I’m amazed that with every new technological advancement, we face the same challenges. Yet, instead of building upon our predecessors’ work, we constantly reinvent the wheel.

For instance, consider pointers and memory management. In Fortran, developers performed memory management manually (without pointers), and were troubled by common blocks. C attempted to resolve this problem by adding pointers, but pointers required mallocs, so many developers felt pointers were too complicated. When Java was introduced, pointers were removed. Yet, despite all these “advancements,” the same developers that were leaking memory in Fortran also leaked memory in C, and are still leaking memory in Java.

How do we stop this trend of not learning from the past? We need to remove its root cause, the tendency to reject existing solutions because they were developed externally—the “not invented here” syndrome.

Surveying the Syndrome
Universities often don’t teach computer science as a pure science, so students don’t study past innovations or learn how to build upon them.
Why is this syndrome so prevalent in our industry? In part, the very nature of software development itself. As a creative process, it requires the ability to think independently and the boldness to try new methods. The creative process is an arrogant one, requiring the creator to assume that he’s capable of producing something better than existing products. Without this boldness, developers would lack the drive needed to invent something new. However, the software industry often takes this creativity (and its related arrogance) to the extreme. Many developers think that their own work is always different, more innovative and better than anything that went before. The “not invented here” syndrome can also come from the folly of youth. In an industry that’s still an open frontier, developers often feel the need to behave like pioneers, discovering and inventing everything on their own. However, though the territory is new, it’s not untried: Others before us have dealt with challenges similar to those we face today, and have already invented solutions that could help us overcome our own trials.

The syndrome’s third source comes from academia. Universities often don’t teach computer science as a pure science, so students don’t study past innovations or learn how to build upon them. Rather, their education is focused on learning the skills needed to excel in the latest and greatest technologies. By neglecting our industry’s most valuable knowledge base—its own history—universities produce new generations of computer scientists who are barely acquainted with their discipline’s past, much less prepared to leverage it.

Mainly because of these three sources, the “not invented here” syndrome is all too prevalent in the industry today, causing a widespread failure to learn from others’ mistakes. In another unfortunate side effect, code is rarely reused as often as it could (and should) be.

Optimistic Indicators
As our industry grows, this constant reinvention will become unbearable, and we’ll eventually be forced to recognize and build upon the work of our predecessors. In fact, I already see signs that the industry is moving in this direction; specifically, the trend toward leveraging legacy systems through Web services, which allow clean definition of interfaces. Another sign is developers’ growing respect for and use of libraries. In both cases, developers are learning how to reuse someone else’s inventions and to engineer new systems based on previously built components. I hope that this encouraging trend will push the industry to recognize and learn from its collective knowledge.

Adam Kolawa came to the U.S. from Poland in 1983 to pursue a Ph.D. at the California Institute of Technology. Four years later, having earned a doctorate in theoretical physics, he founded Parasoft, a software company based in Monrovia, Calif.


Adam não cita, mas creio que MDA (Model-Driven Architecture - e, em outro nível, Design Patterns), SOA (Services-Oriented Architecture - ele fala de Web Services) e RAS (Reusable Asset Specification) ajudam bastante na extinção desse péssimo hábito. Outro fator crucial é a forma como a equipe é estruturada e o processo de desenvolvimento utilizado. Vide o modelo (?) de desenvolvimento de Software Livre - do GNU/Linux especificamente. Há 'refactoring' o tempo todo, mas em níveis diferentes da "hierarquia". Tratarei o aspecto "Organização" no próximo post.