back
21 comments
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.

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.

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.

"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.

Hm, very interesting. I don't have any response to this, but I just wanted to let you know that I find your comment compelling and I'm rethinking my position.
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.
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.
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.

As the saying goes, FOSS is only free if your time is worth zero.
As the saying goes, closed-source only costs the sticker price if your time is worth zero.
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.

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.
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 :/

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.

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!

I am talking about software project, not health insurance.
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.

"...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.

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.

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.

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.