Sunday, November 8, 2020

Code Reuse is Overrated


As an engineer, I have often been conflicted about the interplay of code reuse and dependency management.  It is innate behavior for me to not want to repeat myself and it is through hard and painful experiences that I have learned to be hyper-critical of all new dependencies.

Why re-invent the wheel? Because the existing wheel comes with lots of strings attached.   This article does a good job of explaining the pitfalls in depth:

Redundancy vs dependencies: which is worse?

If it is my wheel and it breaks, I know how to and am able to fix it quickly and cheaply (measured in time).  If I depend on someone else's wheel, now I have lots of problems.  Will they fix it and when?  Will their new version introduce new things I am not expecting? Maybe they too have their own dependencies. That's to name just a few.

I was on a team where a large third-party Java library was added to the project for the sole purposes of using the "isBlank()" function.  That was not a good trade-off of re-use and dependencies. I hear the Javascript/npm world has this same sort of problem in spades.

Too often the Don't Repeat Yourself (DRY) mantra is used as a gospel, devoid of the dependency cost. I've seen development cultures where adding dependencies is done often and effortlessly: it does not even register that there should be a decision process around this. As a group, we need to be more thoughtful about the trade-offs we are making when introducing a dependency and to assign it the proper cost.

Here is another good article related to this theme:

Small Functions considered Harmful

Thursday, November 5, 2020

Fallacies of Distributed Computing

 

I came across this Wikipedia page:

Fallacies of Distributed Computing

It lists the fallacies as:

  • The network is reliable;
  • Latency is zero;
  • Bandwidth is infinite;
  • The network is secure;
  • Topology doesn't change;
  • There is one administrator;
  • Transport cost is zero;
  • The network is homogeneous.
  • We all trust each other.

These are all good things to keep in mind while you design a distributed system, but I think the use of the word "fallacy" is a bit overstated. I've seen a lot of designs (and existing systems) where some of those items have been neglected, but the reason is not because the author had "mistaken beliefs". 

Even for someone new to distributed systems, if you asked them "Is the network reliable?", they will rightly know that it is not.  If their first designs do not properly account for this, it is not because they had mistaken beliefs, but more due to their inexperience or oversight.

The same is true for the remaining items: if you asked someone the specific question, you will likely get the right answer, though their designs may still be lax in that area. 

If you forgot to pay your electric bill, I would not conclude that you have the false belief that electricity is free.