The Parable of the Cog

Engineering Insights

My first programming job was in 1976 in the U.S. Air Force, and my supervisor at the time imparted to me the following bit of wisdom:

Once upon a time, there was a young mechanical engineer who was just starting a new job and was eager to prove himself. And so his boss came to him and said, “I need a cog. I need it to be such-and-such diameter, with this many teeth, and so on.”

So the young engineer said “Sure thing, boss!” and immediately sat down at his drafting table and began to design the cog. By the end of the work day, he had produced a beautiful design exactly to his boss’s specifications.

But his boss’s reaction was not what he expected. Instead, the man reached over to a large shelf and took down a dog-eared sales catalog, flipped to a well-worn page, upon which was the exact cog that he had just designed.

And the boss told him, “You spent a day drawing what you could have had with a five-minute phone call.”

So the first lesson is, don’t build what you can easily buy. Of course, every engineer knows this, or should.

But a second lesson is, engineers like to build things. Designing is something that they do as naturally as breathing. This means that there’s a built-in bias towards designing and building. Even knowing that there are off-the-shelf solutions, it can sometimes be difficult to get engineers to see that the 3rd-party solution is worthy of serious consideration. Until you actually show them a live demo of it working, the design that they are forming in their head of the thing they want to build is more “real” to them than a product for sale on some distant website.

This is one source of the well-known “Not Invented Here” syndrome, in which engineering departments have a bias against anything originating outside of their work group.

Of course, we all know that purchasing a complex third-party product has its own perils. I remember another time where I was asked to evaluate a very expensive workflow management system, including having me attend a 3-day training course at the vendor’s office. And it turned out that it was a really crappy product, and yet they had managed to conceal this fact all the way through the training course, and only when we had plunked down the money and tried to install it on our system did we realize how crappy it was. Had I been more on the ball, I could have saved my company $250K.

It also doesn’t help that some vendors lay on the buzzwords so thick that you can’t even tell what the product does.

So “build or buy” is a delicate balancing act, and it’s one of the most important skills for a senior engineer to learn.

In fact, this skill is even more important today than ever — a web engineer has thousands of open-source packages to leverage, and some of them are great and others are crappy, and it’s often hard to tell which at first glance. Does the project have many followers? Is it maintained regularly? Are the maintainers reasonable and likely to incorporate your suggestions? Is the code written in a clean, maintainable style? Does the project even have a GitHub repo?

I sometimes feel like a significant portion of my job these days is just curation. And part of this skill is not just making judgments about solutions that people present to you, but knowing what solutions exist.

A senior engineer’s job responsibility includes continually learning about new solutions. This can be done by attending technical conferences, or subscribing to some of the many high-quality online journals out there.

So when faced with a difficult technical challenge, just remember the old saw:

“When the going gets tough, the tough go shopping!”

Read more in the Engineering Insights series.