I have previously discussed the concept of “reuse”, from an engineering perspective. Something I actually learned really early in my career is that there’s a subtlety to the implementation of this concept.

It all begins the first time you learn about functions, or objects, or libraries. There’s this idea that code can be written once and re-used over and over. At the project level this is fairly easy to implement and in fact is pretty much trivial at this point in the industry. But some textbooks I’ve read seem to want to push it farther, in terms of reuse across your entire organization or even industry.

The explosive popularity of pypi and npm and CPAN and Github tells us that this is true. I’ve seen software projects with literally hundreds of third-party module dependencies, which tells me the developers made massive productivity gains via reuse. And that’s awesome!

But let me tell you about a different story, once that I’ve seen play out three times in my career. This is when a very large organization decides that some business use case, when abstracted, has enough similarities that there’s an opportunity for a common framework and library, and embarks upon a project journey to establish a team with the goal of creating said framework and library. In all three cases, it was a failure from a reuse perspective. None of the actual business case implementations were able to reuse any of the library modules, and instead you just had a bunch of library modules, each one used by exactly one deployment. So at this point it basically became just a shared repository.

So how come sometimes reuse is enormously successful, and sometimes it is not? What’s the differentiator? If you’re going to make a technical leadership decision, when do you decide to try and reuse something or build it yourself? If you’re going to make a technical leadership decision, when do you decide to try and publish your “thing” as reusable?

One option that I’ve seen be successful is the implementation of an internal “OpenSource-like” repository, where internal developers can publish all their code and its open for anyone in the organization to see, share, and search. Then I strongly encourage people to publish their code there. It can take time but eventually you can end up with a large repository that developers can use when they are starting new projects, or need something.

There’s an important cultural aspect to this. First of all, people want to get credit for their work, so if there’s a way to track, measure, or maybe even gamify how much people publish and how often their work gets reused, this can be a strong motivator for this idea to work.

(And note that this doesn’t just have to be code. This can be slide decks, whitepapers, design patterns, runbooks, How-Tos, and so forth.)

The second is that there needs to be a shared understanding on HOW to use this repository, and perhaps a culture shift. What I’ve learned is things are rarely copy/paste reusable. But having an existing codebase to look at as a pattern, reference, learning point, or starting point, can be invaluable. So people should understand they don’t need to reuse exactly what was built, but having it available as a reference architecture can save others tons of time.