Why Software Reuse is Hard

If you were a software developer in the 1990’s or 2000’s, software reuse was kind of like the Holy Grail.

You probably thought it was a good idea in theory from the start. Plus, managers were always enthusiastic about wanting to get more of it.

But achieving software reuse in practice was, and still can be, difficult. It’s one thing if you can use really stable, trusted code libraries and treat them as black boxes in your code. Unfortunately this only works if those black boxes don’t run into problems, even when you deploy them on hardware that’s different than what the original writers used. (Good luck.)

Here’s why I think software reuse is difficult.

First, we need to note the difference between explicit knowledge and tacit knowledge. Explicit knowledge is what you get from books, or memos, or hearing a story or experience that someone else shares with you. Tacit knowledge is what you get from experimentation, mentorship, or exploration. (For example, I have no explicit knowledge of the vi editor – but I have extensive tacit knowledge of it, because when I open the editor my fingers know what to do, darting back and forth between ESC and : and other punctuation marks that my brain is not consciously processing. Perl is kind of the same way for me.)

If software is the executable representation of knowledge, then developing software is the process of codifying (literally!) tacit and explicit knowledge to make it executable. That’s a huge challenge that requires the developer to learn, reflect, experiment, learn, reflect, experiment… and so on. It’s a process of learning that ultimately results in software – a tool that hopefully will earn a life of its own, perhaps extending beyond the time that the original developer works on it.

What do you get by reading and exploring someone else’s code? Explicit knowledge. What do you get by writing code yourself, by uncovering each new function one at a time, by realizing you didn’t know what you were doing the first time, by refactoring, by trying out a new design (or maybe two or three), by bouncing ideas off of your colleagues, or by going back to the first design you had a long time ago? That’s tacit knowledge. You need both to write good software.

Unless there’s some way to get that tacit knowledge of someone else’s code, or you don’t need the tacit knowledge anyway (ie. in the case of the “black box”), successful reuse will be challenging… if not impossible.

(Related Post –> Software Reuse Antipatterns)


  • Pingback: Software Reuse Antipatterns « Quality and Innovation

  • Well said! And now I can reference you whenever I need to try to explain the whole “executable representation of knowledge” thing.

    I would go one step further and say that this framework can also be used to explain the difference between “good” and “bad” code: Good code represents the knowledge gained, bad code represents the learning process that led to that knowledge. Both may suffice to accomplish a given task, but having to trace through the entire history of another person or group’s learning process is a much bigger chore when it comes time for maintenance.

    The #1 question I get from novice programmers is “how do I know when to code?” (Vs. requirements, design, etc.) The answer is that you can code at any time—there’s often no better way to resolve an issue than to explicitly represent your incomplete knowledge and watch it fail. Then learn. Then, having learned, delete all that crap. It’s the deleting stage that most people fail at. Keep (re-implement) what you learned, don’t hang on to the now irrelevant details of how you went about learning it.

  • Just be aware it would be a circular reference – I cited you on the previous post! But hopefully that would be a plus. 🙂

  • I hate working alone. I don’t think I could explain as well as you just did.

  • Pingback: Software Quality Digest – 2009-02-04 | No bug left behind

  • Hi Nicole
    Excellent post. I agree that reuse is extremely difficult to achieve. Given the state of enterprise software, I think it is more likely to reuse services rather than libraries or frameworks. At work, I actually practice a lot of co-creation when designing and developing reusable components and services to address the challenges you have highlighted. It is challenging nonetheless.


Leave 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 )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s