Avoid extracting internal libraries

bookcase bookshelves bookstore business

Photo by Expect Best on Pexels.com

In a not-too-small software development company it’s very likely that you’ll manage multiple projects over time, with multiple teams and doing work for multiple customers. And for each platform/framework that you’d target (sometimes even cross-platform) you will probably determine that you could extract and reuse common components from code written by your developers in multiple ways:

  1. By extracting common components inside an application only, to better organize and maintain code for that specific project;
  2. Packaging some components to be reused by the same team and/or other teams in the company, for the same and/or other customers/partners;
  3. Publishing generic components as separate products that you could either sell or give for free to other developers too, with or without opening the source code.

I totally agree that points 1 and 3 are very good choices.

However, I think that packaging some components and distributing them only internally in your company, especially if this is done to be reused by other teams, is not a good approach, and this is for two simple reasons:

  • When you share code internally only, you tend to document it poorly, if you do it at all. Moreover, although for developers the code is the best documentation of itself, sometimes it’s difficult for colleagues to reach the original source code of such internal components or it would require asking many questions and obtaining appropriate rights to get to it;
  • When you share code internally in a company, you must ensure that the colleagues who could use it – including the newly hired developers from your and other teams – would know about what’s available and how to use the extracted common components correctly; as at first they only have knowledge and skills for the core platform(s)/framework(s) that your components rely on too, you’ll need to train them well before they could do work on top of the super-framework solution.

What to do then? You cannot just let all teams in your company to rewrite the common things (like a generic .NET unit of work/repository pattern implementation, for example) all the time, can you?

I’d say, why not? If the customers pay separately, then it’s fine – because each implementation will probably have something specific that will fit better for the needs of the customer who requested it or those of the project that it is reimplemented for!

And if you still say it’s not OK, then just go with point 3 instead, and extract a separate product out of the common code – a generic component library – that other developers could download and for which you’ll surely prepare good documentation, usage samples, and better overall quality. Of course, if legal agreements require it, talk to your customer(s) to allow you to extract, publish/sell that library separately, providing some of the outcome to the customer(s) themselves if the cost is shared as well!

About Sorin Dolha

My passion is software development, but I also like physics.
This entry was posted in Architecture and tagged , , , . Bookmark the permalink.

Add a reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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