Foundations

July 07, 2021

Every now and then, I have conversations with clients or managers who are not engineers. This is something quite inevitable: not everyone knows how to code. That’s fine, but it can be a frustrating experience for developers.

For those not versed in programming, most engineering explanations don’t make any sense. One of the few tough things to explain to non-technical or non-programming folks is the concept of constructing foundational dependencies.

Most people know what the word dependency means, but they don’t know what dependencies are in the context of building a software application, and they usually don’t know how long it takes to come up with a proper API for a particular feature.

In short, making things work well takes time.

Now, explaining dependencies isn’t the only difficult thing when talking to those unversed in the arts of code-fu: in particular, these topics are generally hard to explain:

  • Why we keep constructing frameworks or libraries (“foundations”)
  • Why sometimes major refactoring of existing code is required
  • Why it is necessary to write generic code in certain cases, but not in other cases

Not only are these hard to explain, most of these are also connected.

Sometimes, you need to construct something that will have a great impact on the rest of your code. This is usually some sort of underlying structure or system.

I often explain it to those folks with an analogy. Here it is.

The merchant and the builder

Today, I’d like to tell you a story.

One day a rich merchant, who was living in the countryside, bought a plot of land. This plot of land actually included a part of rather large mountain, so there was a lot of steep terrain. The merchant asked the builder to construct a beautiful villa on the side of the mountain.

The builder visited the location, and promptly explained that constructing the villa would take a long time. The merchant was keen to live on his new land, so he asked the builder to build a simple house first.

The builder’s initial estimate barely changed. The merchant was surprised. “There’s almost no difference between building the villa, or building a simple house!” he exclaimed. “Should I find another man who can do it faster?”

“Allow me to explain,” the builder said calmly. “I doubt you will find any other builder who can, because each and every one of them will need to put down a foundation upon which your villa can be built first,” he said. “Otherwise, the mountain’s slope remains too steep, and whatever we build will be at risk.”

So it was, whether a simple house or a villa, that a foundation needed to be laid before construction of any kind could begin here.

Building the actual villa took even longer than the builder’s first estimates. For the initial construction effort, the foundation was sufficient. The weather was fine.

But then, the foundation proved insufficiently sturdy — it required some modifications, some strengthening. Then, the weather went bad. Construction was halted for a while.

In time, the villa was built, but it took longer than anticipated. The merchant, however, was happy to see his villa built properly.

Parallels to programming

Similar to the story here, development work and writing code is the same: sometimes a combination of features requires a large amount of common changes.

Like the merchant, a client might ask you to cut corners or do something that you know requires a whole lot of technical work in order to get operational.

Perhaps during development you’ll change your mind — you might want to do a large refactor. This all is very similar to the story of the merchant and the builder above.

If management or your client is having difficulties understanding this, tell them that you cannot build a house on the mountainside without a decent foundation, and you cannot code without a good technical foundation either.

If they attempt to persuade you to do so anyway, instead, do this: offer them the equivalent of building a home on top of an already existing foundation, something which is certainly going to cost less. (But you have less control over.)

There is software out there you can buy, rent or license that might simplify your work. Perhaps that might help soften the blow.

In the end, however, a good foundation just cannot be omitted, no matter what profession’s yours. If the foundation is found to be lacking, things will crumble and fall apart, and no one wants that.