Useful Dependencies

libraries, utilities, devops glitter, etc….

I’m not a fan of adding to the tech stack without seriously thinking about whether this trip is necessary.

Suppose we need to write FoobyCalc’s file format, .foob

Bob the engineer says it’ll take him T days to write code to write .foob format. But there’s a utility, NiftyVert, that converts .blarg, which we already write, to .foob

Of course we all have to install NiftyVert, but that’s no problem. We have e engineers, and production, and test servers, n = e + 2, and it takes time t to install it.

So, T >> nt, we’re saving time….

BUT… we now have to install NiftyVert on every system, including all future hires, and Nancy’s machine after she spills her latte in the old one, we have to deal with new versions of NiftyVert, we have to keep fiddling with NiftyVert, a process that takes a small fraction of each engineer’s time, say k, where k is 0.01 or something.

So, if L is the development lifetime of the software, we invest Lnk in NiftyVert, as opposed to T in our own converter. k had better be darn small or Lnk is going to be larger than T.

And it gets worse when we do this over and over. Suppose NiftyVert’s no better or worse than anything else we install, and we install m things like NiftyVert. Now we have every engineer working at 1 –  mk efficiency, and time lost to sysadmin stuff is Lnmk.

Now, if we double the size of the project, things get even uglier.

Let’s ignore the mythical man month and say our team doubles in size. A bigger project probably also lives twice as long. n has roughly doubled (you probably now have a demo install for marketing, and one for the graphic artists to use). L has doubled because we’ve doubled the project lifetime. m has doubled, since the density of these things is constant in the size of the codebase. k hopefully goes down a little as you have more resources to make installs and such easier.

But still, at some point this rolling snowball is not only going to far exceed mT, but it can grow til it consumes most of the project’s resources. I’ve worked on projects, many of them, where it seemed impossible to get all the dependencies working, and mk was > .5

I’ve worked on a couple where mk was approximately 1.

Of course if you roll your own you’re going to find yourself extending it. So you can find yourself recoding Excel. At that point NiftyVert begins to look pretty Nifty. So keep a weather eye on Bob’s little converter he wrote, lest it become a department. If these decisions were easy, anyone could make them. Sadly, it seems no one actually makes them.

OK, everybody in the audience, raise your hands if you’ve worked on a project where it took more than a day to get a dev environment up when you were hired.

Now raise your hands if you’ve spent more than two hours dealing with something not working when it had nothing to do with what you actually were changing.

OK, everybody in the audience raise your right hand and say “I <your name> hereby promise to not shove random dependencies into the code”









About pathwaystoknowledge

An independent software developer working primarily in Second Life. Developer of the Pathways To Knowledge tool.
This entry was posted in Uncategorized. Bookmark the permalink.

1 Response to Useful Dependencies

  1. John Cowan says:

    Ghosting, VMs, AMIs, and Docker are all more or less successful attempts to flatten this problem. Of course, if you build it they will come (which is why widening roads is only a short-term fix for congestion), aka “What Andy adds, Bill takes away.”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s