Programming Blog

Jeremy Morgan

Mostly Coherent Ramblings of a Silicon Forest Software Developer

Thinking About Reusable Code

The mythical “reusable code” idea has existed for decades. It showed up shortly after the first lines of code were written. We preach re-usability and sometimes strive for it but it rarely becomes a reality. I’ve seen various levels of success with this over the years. Everything from “we have a reusable library that 75% of us use” to “we have shared code libraries here, but never use them in your projects”.

A recent discussion led me to think about this. Why don’t more software development organizations have shared code libraries? It is the pointy-haired bosses preventing it? Team conflicts? Or is it the developers themselves? 

We can’t blame the pointy-haired bosses for this one. If you explain the basic concepts of reusable code to management, most would agree it’s a great idea. Building something once, so you don’t have to build it repeatedly? Easy to find the upside here.

Team conflicts can also contribute to it, which is usually people disagreeing about who gets to determine what code is shared. Developers themselves can also be opposed to it, due not having enough time to build them.

All of these are contributing factors to lack of adoption, but the question you should ask is do we need reusable code libraries at all?

What Are Shared Libraries and Why Do We Care?

If you have tasks your developers are building that contain code you can use for something else, you put that code in its own “library” to use later. This can be a DLL, a folder of snippets, a Node module, whatever. Connecting to a database? There’s no reason to write that code for every piece of software that accesses a database. Create a DB_Connect class, and put that in a file you can copy to another project later.

"Thinking about Reusable Code"

It’s easy. You take a function and if it’s abstract enough, parameterize it and make it available for other projects to use. When you start your project, you don’t have to write code to connect to the database, pull the library and enter your parameters. Here are some upsides:

  • You write code once and use it multiple times (saving cycle times)
  • If tested thoroughly, it cuts regression errors
  • It enforces standards other groups can follow

These are all great reasons to use shared libraries. Countless articles and books have been written about code reuse and most of you are familiar with them. The biggest selling point for this is not having to code “boring stuff” over and over and have wild variations of the same methods in the wild. This frees up time to work on exciting features.

How Are They Used?

Here are some ways shared libraries are used in business:

  • Internal Use Code that shared with internal groups and used for projects
  • External Use Code that designed for programmers outside the organization to use
  • Forked - Users can take your initial code and “fork” it to make it work for their specific needs

This falls in line with the DRY principle of software development. Don’t repeat yourself.

Do We Want Shared Code Libraries?

Why isn’t everyone doing this? Your organization may avoid shared libraries for a good reason. Not every project or team benefits from this and it’s not the magic bullet to solve all development problems. Here are some reasons not to use code libraries.

  • Distributed Monolith Problem - If you put something into a library and everyone uses it, that doesn’t mean it isn’t bad. An inefficient database connector design means everyone is using an inefficient database connector. Changes to your implementation can still have negative cascading effects. A small change to an API could mean every single system is now broken.

  • Dependency Hell - If every piece of software is relying on your library, there’s a tight coupling in place. There will be a myriad of dependencies in place, for instance, relying on a framework like Angular. If you have software built to use a specific version, upgrading it could produce a chain reaction amongst your applications.

  • Inflexible Design - Sometimes you’re asked to use a design in a certain way that’s different from what you actually need. Because “everyone else is doing it” you’re forced to make your code work around it, which can then increase development time. Wait, why did we build shared libraries in the first place?

  • Programming Language Lock-In - Too many times I’ve heard “well our library is written in ____ so you have to use that” which means you’re locked into a single programming language. This can lead to using the wrong tool for the job. So don’t assume because your team doesn’t use shared libraries means they’re unenlightened and don’t want better production.

What to Examine if You Want to Use Reusable Code Libraries

If you’re considering creating reusable code libraries, you should first see if it makes sense to do so.

  • Take a hard look at the design - Then look at it again. Will you really benefit from it? Do you have repeated code now? Are there any issues that may encourage tight coupling? 
  • Closely examine your dependencies - Are you creating dependencies others will have to work around? How often do they change? Can they bypass the ones you create? 
  • Start abstract as possible - You want your libraries to be highly abstract so that they perform expected functions, but can be overridden or extended to meet specialized use cases. Give them the basics but let them evolve it how they’d like.

How to Get Developers to Implement Them

So you’ve decided you want a shared library. Here are some ways you can help teams adopt your library:

  • Steal it from an existing project - This is the easiest way to start a new library. Take an existing project and remove everything that’s specialized and keep everything that can be re-used and feels solid.

  • Thoroughly test it - The last thing you want to do is introduce problems into the software. After building your abstract library, test it thoroughly so you can rely on it, and help developers find regressions. Don’t hand them garbage and expect them to use it.

  • Examine all current use cases - By digging in and understanding how people will use your library you can determine whether it will benefit them, and whether to make changes. Do this on a method by method basis to ensure that you’re asking them to use something that will work for them with minimum effort.  Like most anything in business, success will come from great communication. Top down design is not your friend here, you’ll want to examine the needs of the group and design a library from those needs.


Most of the organizations I’ve been involved with do not use a shared code library. They’re usually in some form of working towards one, and only two where they were implemented and working well.

At one end of the spectrum you have a pattern where all repeated code is in a library. On the other you’ll have no code library, and everyone builds software for their own projects. You’ll find success somewhere between the two. How far you lean toward each extreme will depend on your needs.

There are abstract functions that should always be shared. Some that come to mind are authentication/authorization, database connections and logging. It should be either a shared library you developed, or one that’s open sourced and built by someone else. Everything else should be examined, considering the overall design.

Don’t jump to conclusions and take on a large project to build a giant code library that will make developers lives worse. But don’t exclude the idea altogether. Be purposeful and observant to find which strategy will work best for your projects. 

Transforming Your Organization With the Andon Cord

Imagine you’re working in a factory. You’re assembling Toyotas all day long, then your part won’t fit. What’s going on? You do this hundreds of times a day but now the bolts won’t go in. No reason to panic, you pull a cord to get help. Two co-workers arrive immediately. They find out you have a box of bolts with the wrong thread. They swap out the bolts, and you keep going.

Comparing and Syncing IIS Configurations

Imagine you’re an administrator at ACME Widgets and it’s time to upgrade your IIS server. You’ll just copy over some folders and point the DNS to the new server and be done right? If you’ve ever done this before you know that isn’t the case. The new IIS server needs to be configured identically to the old one or you’re going to have problems, and you don’t have time for problems.

Using DISM to Create a Repeatable IIS Installation

Repeatable installs are all the rage in Devops these days. As developers we have this “automate everything” mentality, and for good reason. In this article I’ll show you how you can do that with IIS installation as well. There’s no reason to go hunting and pecking around the GUI every time you need to do this. This is the just one of many ways to automate IIS installs, which I’ll be covering in the next few weeks.

I also cover this in depth in my latest Pluralsight course on Installing IIS.

Unit Testing With Dotnet Core

So you’ve just started building .Net Core applications and really starting to gain some traction. You quickly learn how mature and thorough the .Net Core framework is becoming and think “I need to start writing some unit tests for this!”. As it turns out, it’s super easy and very intuitive, especially for C# developers.

Set Up Easy File Sharing With Samba

In this tutorial, I’ll show you how easy it is to setup file sharing on your network using SAMBA. You can easily share files between Linux and Windows machines with a pretty minimal amount of setup.

Windows to Go With the Spyrus USB Drive

What we need is a good bootable live USB stick for Windows. I’ve said this many times over the years, and hacked together things to make that very thing happen, but nothing that worked really well. So when the folks at Spyrus sent me a Windows to Go USB to check out, I was pretty excited.

Which Distribution of Linux Should I Use?

I’m often asked this question: “hey, you’re a Linux guy right? What Linux should I use? I have this friend who recommends _____ and I want to know what you think?” I usually reply with the same question: what do you want to do? So I decided to make a blog post about it that I can send people instead.

My Latest Virtualization Setup

Like many geeks of the time I spent the 90s and 2000s with at least 2 or 3 old computers in a closet, connected by a switch running various operating systems with various services running on them. Giant, loud, clunky machines whirring away.

Load Testing Your IIS Web Server

All the theory, calculations, and estimations in the world aren’t going to tell you how your website will truly perform under a load. If you’re deploying a new server, or doing any kind of performance enhancements you don’t want to test your results in production. It’s always a good idea to see how your system behaves before your visitors do. To do that, you can use a load testing tool, and here are a few I use quite frequently.

Update: I’ve featured these tools is my latest IIS course on Pluralsight, IIS Administration in Depth, check it out!