Why Weakened Dev Teams Suffer From NIH Syndrome

(NIH = Not Invented Here)

So here’s the situation. Product Management says feature X must be built. Development scopes the feature and discovers that the “right” solution involves using code developed elsewhere. But unfortunately, the other team’s code uses different assumptions and will take some extra time to shoehorn into the new context. In other words, the right solution is too costly.

If a development team doesn’t have an architect who can advocate for the right solution based on first principles, then it uses the tried-and-true scope/schedule/resources lever (about its only negotiating tool) to push back.

The problem is that in this scenario, product management isn’t really forced to come to terms with the long term strategic consequences of doing things wrong. So the scope is adjusted, or the schedule is adjusted, or the resources are adjusted — but only enough to rescue the feature, not enough to do it right.

As a result, dev has to invent a half-baked alternative to the other team’s solution. Ad nauseum.

We look at the dev team and say that they have “Not Invented Here” Syndrome, because they never seem to use the solutions that other teams have built. In many cases, the real problem is that the Product Management and Dev don’t have an architect mediating and looking at the situation from the standpoint of maximizing the ROI of strategic technology investments.

Why People Are Part of A Software Architecture

I’ve been reading an interesting book — Beyond Software Architecture, by Luke Hohmann. In his first chapter he discusses the more people- and business-related aspects of architecture, and makes the following points:

  • Systems are designed to manage people dependencies, not just esoteric “code” dependencies.
  • Systems are designed by people with non-technical motivations.

Point well taken.

Schrödinger's Cat, from http://www.flickr.com/photos/drlovecherry/I wanted to chime in with one additional observation. An architecture and the people who actively develop and maintain it are difficult to separate. I’d argue that a company that owns the source code of a so-called “architecture” but that has no engineer that understands it doesn’t really have an architecture — as with Schrödinger’s cat, the human observer matters.

A stark example of this has cropped up several times as I’ve done M&A work during my career. I have seen less technical executives repeatedly assume that the source code of a system = the system. In other words, they think people are fungible and an architecture can be purchased and transferred *only* by shifting source. In practice, that assumption causes problems. The boundaries around modules don’t always exist cleanly in files and directories on disk; sometimes they are more of a mental construct in the minds of those who build and service them. If you grab a wad of source and plop it down in front of people who’ve never worked with it before, the institutional knowledge that contextualized the system in the minds of its creators is missing. This is why a mediocre engineer well-versed in the context of a given architecture is likely to be more productive than a world-class engineer dropped into the architecture cold. It is also why layoffs and RIFs are more dangerous than you’d guess by simply looking at raw staffing numbers.