I released five new sample lessons from my Test With Spring course: Introduction to Spock Framework

Reusability is Overrated

I remember a time when I used to believe that the ability to create reusable components was a sign of a professional software engineer. This is definitely true if you are building a framework or a library. However, I am not convinced that reusability is valuable when a framework or a library is used for implementing an actual application.

In fact, I believe that in that case the reusability of software components is overrated, and in most cases the effort used to implement reusable components does not create any additional value. I argue that reusability is overrated because

  • It does not add value to the customer. If the customer’s requirement can be fulfilled with a component that implements only a one function, the only thing that the customer cares about is that the needed function is working. For example, if the customer needs a component providing CRUD functions for a car, the customer does not care about the fact that the component can provide the same functions for airplanes or trains as well. And most importantly, the customer is not willing to pay for the extra work, which is needed to provide a generic CRUD component. And you know what? The customer is absolutely right.
  • It adds waste to the source code. Creating reusable components requires more code than implementing a component, which has only the functions required by the customer. To make matters worse, it is more than likely that the additional code is never user for anything else. However, it still has to be maintained and tested every time when changes are made to the source code. This is more expensive and error prone than maintaining source code, which does not have unnecessary waste in it.
  • If you do not know all the requirements, you have to guess. The requirements of a certain component covers only such use cases, which are relevant to the customer. Thus, if you implement a reusable component instead of a component fulfilling only the given requirements, you have to guess what the customer might need in the future. This dangerous for two reasons: First, you do not most likely have the needed information or expertise to make such decisions. Second, making a wrong assumption may prevent you from fulfilling the customer’s requirements in the future without making changes to the component’s source code. Therefore, it is a lot wiser to play it safe and implement only the required functions. Remember that it is a lot easier to extend a simple component after the requirements are clear than to fix a reusable component, which cannot be used to implement the new requirements.

I have now described you the reasons why I think that reusability is overrated when implementing applications, which are used to solve customer specific problems. However, I also realize that there are situations when the creation of a reusable component makes sense (even when creating customer specific applications). I just do not believe anymore that reusable components should be created just for the sake of reusability.

About the Author

Petri Kainulainen is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book.

About Petri Kainulainen →

5 comments… add one
  • This is a great post. Thank you and Google for chance to read it.

  • Petri, Reusability is the biggest myth of our industry. Crosstalk magazine once posted an eye-opening paper containing an economic analysis of software reuse. You can find it online at: http://www.crosstalkonline.org/storage/issue-archives/2004/200412/200412-Jensen.pdf

    • Kevin, I agree!

      In most cases it is a total waste of time and money to implement reusable components which are not reused by anyone.

      I took a quick look at the paper and it looked quite interesting. I will read it through when I have a chance to print it.

  • In general I agree. There is only one aspect that I would like to mention. Sometimes, it happens (at least to me) that when I make a component/class/function more generic (more reusable) I come to better, cleaner design. Which is a good thing.

    Cheers! :)

  • In my very long experience the value of building components for (re)use between applications has the highest return. These components not only abstract common chores like emailing, serializing, data access etcetra but also they shape the application design for the better. Components that are re-used within the app dramatically reduces the burden involved in debugging, unit testing and alterations.


Leave a Comment