Reusability is a feature of good software design.

Is reusability an acceptable gloss ("brief notation of the meaning") for good software design? Why?

  • I would argue that flexibility is more important. Having an underlying architecture that tries to accommodated the reality that something will probably change or get add later is key my opinion. Reusablity almost comes for free at that point.
    – Pemdas
    May 11, 2011 at 17:35
  • Your use of flexibility sounds exactly like reusability. May 11, 2011 at 17:39
  • "Reusability is the likelihood a segment of source code that can be used again to add new functionalities with slight or no modification" - en.wikipedia.org/wiki/Reusability May 11, 2011 at 17:45
  • I'm impressed that the majority of the answers below says no. This would now have been the case just a few years ago (well... 5-10 years), when reusability was all the rage something highly desirable. May 11, 2011 at 21:26
  • @MartinWickman Reusability is good, but it's not free.
    – Caleb
    Feb 8, 2012 at 17:30

7 Answers 7



Reuse is an indicator of good design. It indicates that the coupling of the system is loose enough and the cohesion of a particular unit is high enough to facilitate reuse without running into dependency issues or having to rewrite most of the code.

Reusability is largely an illusion. It is verifiably impossible to measure the "reusability" of a unit without knowing in advance where or how it is going to be used. Many developers will try to design "reusable" components and often find out later that the specific aspects they tried to make "flexible" are exactly the ones which didn't need to be.

I would use a different "gloss": Testability.

Now I am not an advocate of TDD, nor do I feel the need to unit test anything and everything. But writing tests for a component will give you a very good idea of its coupling/cohesion characteristics, and very quickly. If it depends on abstractions, then that is loose coupling; you will find it easy to mock out the dependencies and that suggests a good design. If it has a clear purpose (see also Single Responsibility Principle) then its behaviour will be relatively intuitive, you will find it easy to figure out what to test, which again, suggests a good design.

That does not, of course, guarantee a good design; the actual implementation or even the whole architecture may be entirely inappropriate for its stated purpose. But at least it tells you that you are not working with spaghetti code or God Objects.

Please, do not try to make wild guesses as to the "reusability" of a component, especially not to use as evidence of "good design". That is something you can only establish in hindsight, once it actually gets reused, and by then the design may have changed significantly.

  • Good answer. You answered the question I should have asked: "What is a good gloss for good software design?" May 11, 2011 at 18:47
  • +1: Especially for "Reusability is largely an illusion".
    – Kramii
    Feb 8, 2012 at 15:40
  • It's only an indicator of good design if reusability is a goal. It often is a goal, if an implicit one, but spending time and money to make components reusable when they don't need to be is just wasteful.
    – Caleb
    Feb 8, 2012 at 17:06


Reusability is a good feature to have, because it can speed future development. (Though in practice very few organizations see future development speeded by nearly as much as they hoped it would be.) However any significant piece of software has parts that are specific to that application. And furthermore when people without domain experience try to write reusable software, they usually obfuscate that piece and reduce performance without actually succeeding in making it reusable.

Therefore good design is modular, and reusable only where you can see that the piece can be reused, and where you have the expertise to actually achieve reusability. Elsewhere you should attempt to make things clean but don't worry about reusability. (Except in the back of your head where you're making notes so that on some future system you'll have an idea how to make that reusable.)

  • What about automated testing? Aren't unit tests a form of reuse? May 11, 2011 at 17:41
  • @Matthew-Rodatus: Unit tests are part of your software deliverable. Reuse usually refers to reusing code in some other piece of software.
    – btilly
    May 11, 2011 at 17:51
  • Good point. I guess I'm using "reusability" in a ontological sense, which is confusing. However, observe how the features of reusability are also features of testable code: en.wikipedia.org/wiki/Reusability May 11, 2011 at 18:02
  • 1
    @matthew-rodatus: Reusability is not, "Has this laundry list of features." If you try to get reusability in that way, you'll fail hard. Trust me on this.
    – btilly
    May 11, 2011 at 18:09
  • Good point. I see now that I did not ask the question I meant to ask, but it's still an interesting dialog. May 11, 2011 at 18:49

I belive (and this is my personal belief) that the relationship between reusability and good design is not reflexive, so the basic and simple answer is no. If you're interested on some good design guides, check this wikipedia article.

A good software design must be reusable, at least in some core parts, I think that very little people do actual reusing of source code, due to the fact that it's extremely complex to design the core of a system to be reusable at many different contexts (And I'm saying this out of experience)

Consider a class with a huge amount of responsabilities (a.k.a a Blob) performing all the tasks you need well but without any sort of design considerations at all, perhaps you've seen the case. Most people with a class like that would use it over and over and I think that we'll have to agree that it's reuse, designless reuse.

Hope I didn't mess my explanations too much

  • That's why I said "gloss" (by which I mean that, practically, reusability captures most but not all of what we mean by good design). May 11, 2011 at 17:43
  • My point is that you need reusability to have good design, but having a lot of "reusable" code deosn't mean that you have a good design so I'd still say no, not even as a gloss May 11, 2011 at 17:53
  • That makes sense. I'm not sure I agree, but +1 for a well thought answer. May 11, 2011 at 17:57

I think a better indicator of good design is adherance to fundamental ideas such as the single responsibility principle and maintaining cohesion of each component. By using abstractions with a clean and concise interface and maintaining compliance with the Liskov Substitution Principal we encourage reuse while not trying to predict what will and will not be reused.

Sticking to these fundamental design principles makes code easier to test and easier to reuse.

Good design == good design, reusability is a by-product.


Reusability is often an implicit design goal. If you can create a component, or an entire design, in such a way that it can be reused later, it seems obvious that you should do that. What's not always obvious is that it can take a lot of time and effort (and money) to make something reusable, and the benefit of reusability must therefore be weighed against its cost.

A reusable design that costs twice as much and/or takes twice as long to build than what the customer needs is not a good design from the customer's perspective, particularly if the customer doesn't need reusability.

There are a number of similar attributes that are often considered to be implicit design goals because they seem obviously good:

  • minimizing cost

  • minimizing development time

  • minimizing complexity

  • maximizing reliability

These things are all objectively good, but may not always be important to a particular client at a particular time, so it's important to fully understand what your customer needs (even if that customer is just your boss). There are a number of aphorisms that are meant to remind us of this fact (e.g. "Done is better than perfect" and "Good, cheap, fast: pick any two"), but it's still easy to fall into the trap of trying to make software that's great in every respect when in fact great in every respect isn't always needed.

To get to the title question, then: No, reusability is not synonymous with good design. Reusability may be a useful component of a particular good design, but only when it's required.


Not necessarily. If you make something reusable that is clearly never going to be reused then that's bad design.

For example, if you are writing a file full of data which is unique to your company and that data is to be imported once to somewhere else, why bother making it reusable?

That said, if your framework doesn't have one already, the code to write to a file may need to be reusable. That would be good design.

  • How do you know for sure if something is never going to be reused? May 11, 2011 at 17:39
  • 1
    @Matthew - That would be my definition of a good designer: Someone who usually gets that question right
    – pdr
    May 11, 2011 at 19:02

I would say no, mostly because it only describes a small segment of code. I have found that where usability is most important is at the very core and at the outer edges of utility territory, not so much in between. I will give a few examples of things where I think reusability is a useful metric of quality design.

Core Stuff

  • Webform templates that allow a page to be added easily and consistently (or for any sort of UI)
  • Design pattern helpers like a ViewModel base class that will be included in all of my MVVM applications

Utility Stuff

  • Email class that sends an SMTP message (use it all the time)
  • A GIS distance calculator class (used in a bunch of our apps)

For the CRUD stuff that takes up 70-80% of most apps, I just do not think reusability is a valuable metric at all.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.