

“Not invented here” syndrome is not unique to the IT world (2013) - matt_d
https://queue.acm.org/detail.cfm?id=2559901

======
thesz
Chinese wheelbarrow optimized for different operations than European one.

First, you have to lift load higher for Chinese wheelbarrow. Second, you have
to be more careful with Chinese one, because overloading of wrong end will
dump all load to ground. Probably, one man loads it while another man carries.

It looks like Chinese wheelbarrow is optimized for one scenario (separate
loader and operator) and European one for another (same loader and operator).

Also, you can drag European wheelbarrow instead of pushing it. This way you
get rid of many difficulties in operation. We did that when I was young and
had less power and worked in gardens and/or construction.

To conclude, author does not distinguish between different use cases for
seemingly same instrument (e.g. BerkeleyDB and SQLite) and he does not apply
enough reasoning against his own argument, just to be fair.

What many consider NIH is often deliberately optimized choice for some
specific and important use case.

------
dasil003
Great story and great article touching on many of the problems affecting the
healthcare.gov website. I don't disagree with any of the details, but I can't
really get behind the idea that NIH plays a significant role in the failures.

You can probably dig into the project and pick out thousands or tens of
thousands of objective mistakes that someone somewhere is capable of
diagnosing and proposing a better solution. And on the same token you can
probably do that same for good decisions which someone somewhere _thinks_
would have thought they knew better and attempted to fix what wasn't broken.

This is just the nature of large projects, and well understood in such
literature as The Mythical Man Month. And I would submit that it's not
technology projects per se, but rather the unforgiving literalness of computer
systems that throws the overall systemic failure into stark relief.

As the scope and required knowledge of a project increases, the communication
overhead increases non-linearly. Not only must thousands of leaders at every
level have access to the right information and make good decisions, they in
effect act as a distributed system to specify the technical implementation. It
will be extremely difficult, if not impossible for all the subordinates to
filter the information correctly such that the people at the very top have
exactly the right information to make the best decisions.

The reason a couple college kids end up creating something more impressive is
because they have the freedom to ignore intractable problems. If you threw
Larry and Sergey at this type of problem they would be nobodies today because
there's nothing you can do against that wall of legislation. The legal code is
like computer code that is never subject to performance benchmarks, the people
who touch it (legislators, judges, lawyers) are all well paid and have exactly
zero incentive to make it efficient. It's tragic because there are no doubt
places where 8-figures could be shaved off the budget if the implementers had
channels to the legislators to raise issues that make the system intractable,
but unfortunately the legal requirements are done in a too-big-to-fail
waterfall fashion where the hopes of ever simplifying the system are slim to
none.

~~~
ThomPete
I actually think its a really good reason why it often goes wrong in the sense
that most governmental agencies always think they need to somehow customize to
their unique needs.

I have seen this many many times when dealing with governmental contracts.

Another issue is the way these procurement offers are made. They are basically
forcing the bidders to define their way out of every issue they might
encounter just to make sure they don't suddenly get caught with having to do
the work after some huge issue and no budget to do it with.

So instead a lot of the proposal is about defining the scope of the projects
but in such a way that most of the budget is a buffer for when the project go
wrong.

In most cases these systems already exist and could be much easier build with
off the shelf based software. But because government think their needs are
unique they end up building themselves.

In Sweden the police were able to implement a new system without many issues
exactly because they used existing system rather than trying to invent their
own.

In Denmark they thought they needed their own and are paying the price with a
version they had to scrape.

~~~
snappy173
"I actually think its a really good reason why it often goes wrong in the
sense that most governmental agencies always think they need to somehow
customize to their unique needs."

yup! and it's the agency needs, not the needs of the actual user that are
unique and special and require customization.

a big reason that GDS in the UK is having success is that the user need always
comes first.

------
fishnchips
I know that this is an unpopular opinion but I've seen numerous cases where
NIH _is_ the optimal approach. I worked in a large company that insisted on
using open source everywhere they could. Except that making all of that zoo
work with a a single {build,logging,monitoring} system was a major PITA and so
folks often cut corners turning large parts of crucial systems into black
boxes. Also, some of the open-source stuff used was of suboptimal quality to
say the least and so the company was forced to start maintaining a whole bunch
of projects that no one else cared about. And if something stopped working
there was hardly anyone who understood how exactly a FOSS project X or Y works
and so countless hours were spent on digging through proverbial mud.

~~~
awinder
I don't think I'd ever use "nih" to describe making wise decisions to go build
a better version of something that exists in the community already. But "NIH
Syndrome", the one where every little thing requires a custom built library or
framework, is almost never wise or appropriate.

~~~
fishnchips
For my immediate team I required that a FOSS project be:

1) alive and well - judging by the number and recency of contributions; 2)
modular - monolithic binaries are a no-no but libraries are generally fine; 3)
use one of the few languages well supported by the existing build system;

Once we started using those guidelines most FOSS projects we considered were
dead in the water. (so were most commercial products BTW).

The only thing is that even though my immediate team saw the benefit of this
approach once I started talking about it in a wider circle my approach was
considered an extreme case of NIH.

------
jrochkind1
This is good, and perhaps less about "not invented here" then about trying to
solve social/organizational/human problems with blind application of
technology:

> mindlessly replacing human labor with technology instead of solving the
> actual problem.

------
ruricolist
About wheelbarrows: the Western wheelbarrow isn't unoptimized, it's just
optimized for a different purpose: loading instead of moving. Having the wheel
at the front allows for a deep body with low sides, which makes it easier to
fill (and empty) the wheelbarrow with a shovel.

------
exabrial
Incredible read and a great analysis of the problems with the IT side of the
Affordable Healthcare act. Unfortunately, the IT problems with the AHA were
just the beginning. The terms are non-negotiable since they carry the weight
of law. Agile boils down to having negotiable, discoverable requirements
during the engineering process, which is basically the complete opposite.

The AHA was intentionally "overengineered" and unfortunately we're going to be
stuck with the damage for a long time :/ The few good things that did come out
of the AHA could have been passed in smaller separate bills, for instance,
state health exchanges (Why hasn't this been done before?) ...But the point it
seems was to drill something down our throats and serve special interests. In
the end, not much has changed, yet somehow an incredible tax burden has been
levied on the people of the USA :/

------
qwerta
European wheelbarrow has lower center of gravity, it is easier to balance and
handles rougher terrain, it is mainly used on construction sites. To transport
cargo we use 2 or 4 wheels :-)

And I think HealthCare.gov was very successful. Its purpose is not to build
website, but employ large number of people and make a few people rich.

~~~
JoeAltmaier
Hey! Profit is the point of every free-market enterprise. You make that sound
like a bad thing.

The congressional budget office says 12 million newly insured benefitted
through this effort. Not peanuts. And remember it was coincident with changes
in Medicaid, and changes allowing young people to stay on their parents'
insurance. All combined it might have benefitted 18 million!

~~~
qwerta
I am talking about software project, not health insurance.

------
RRWagner
This is a great article, not just about the Not Invented Here syndrome, but
the efficacy of replacing humans with automation.

I'm very involved with educational technology, where there is indeed a lot of
work to replace the "person at the front of the handbarrow" (the teacher) with
"a wheel" (a computer). The proposed answer to that includes Khan Academy or
other videos, and a variety of online and "app" education sources. It's an
interesting effort, but this article is great at bringing back the
metaphorical reflections about which you'd rather have when the cargo is a
human (especially your child) in a stretcher vs. a load of rocks in a
wheelbarrow.

Then again, just to play the other side of wheelbarrow scenario, replacing the
other person at the front of the handbarrow with a gps-guided, obstacle-
avoiding, all-terrain, path-to-destination optimized robotic motive unit, then
we can just replace the human at the back with a wheel.

------
Htsthbjig
_"...where the Next Big Thing has been a seemingly infinite sequence of
concepts such as high-level languages, structured programming, relational
databases, SQL, fourth-generation languages, object-oriented programming,
agile methodologies, and so on ad nauseam. I think it is fair to say that none
of these technologies has made any significant difference in the
success/failure ratio of IT projects"_

Those are amazing tools when used correctly, but they don't work on their own.
They need people that knows how to use them.

In a big project you need a good design or all the structure falls down.

Nothing to do with NIH. More to do with how bad politicians are at choosing
who is best suited to carry a project.

They are mostly lawyers that prefer someone who gives a great presentation
than an expert on the field. Smooth talkers who say yes to design by
committee, mostly because they are not the ones who work on it, get the
projects.

Imagine you were to judge Donald Knuth by their presentation skills(he
stutters and use handwritten transparencies). That is what politicians do,
because they don't know better.

Also politicians have a vested interest in expending as much as they can.
Basically the more they spend, the more important they are, the more they
earn, the more influence they have.

Chinese wheelbarrow is better suited for some things, but is worse for others.
It is bigger and less stable, and splits the space in two, making harder to
transport some objects.

------
anigbrowl
Good article, but I feel he overlooked another problem; in any large
organization (corporation as well as government) it's quite hard to deploy a
minimal product and let it gain traction through organic growth. Small apps
from startups can take off in the marketplace because early adopters are often
willing to compromise on security or functionality or interoperability if a
new toy or tool does one thing really well, and if the popularity of the new
thing reaches critical mass then those other considerations get taken care of,
thanks to a combination of the early revenue and the foreseeable future
revenue.

But it's very hard to do that within an organization, whether governmental or
private. Most organizations are hierarchical, so ground-up IT innovations tend
to be politically unpopular to start with. But even if a company or agency has
an open internal culture, letting part of the organization use some new tool
risks sacrificing efficiency, by taking away resources from the existing
platform in the short term, or security, by making informational resources
available via the new platform without the existing access or audit
protections.

------
einhverfr
It's a good read. One of the points I repeatedly make is that technology
should support people, not the other way around. In other words, you start
with how people work and you build technological solutions to the problems
they face.

Now, Chinese and European wheelbarrows are very different. I would usually
choose the European one if I am working by myself because the Chinese one
looks like it is a pain to load, but one wonders if the differences are caused
by fitting into different workflows The same goes for a lot of IT tools.

The difficulty of course is always "how much needs to be invented here?"
That's a big question.

------
erikb
I just want to add another factor that I don't see discussed here yet. That is
an object like healthcare.gov is not just a website. It is a system. It
influences the work of thousands of people, institutions, dozens of local
governments, vastly different companies and people. All that doesn't mean it
would be efficient, successful, or reasonable all together, but just that it's
more than a website and organizing something of that size will cost a lot more
money than a website of equal quality and end user value will cost for a new 5
people start-up without customers.

