Comments on: Why Software Reuse is Hard

By: vijaynarayanan

vijaynarayanan — Sun, 05 Apr 2009 18:25:28 +0000

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.

Vijay
http://softwarereuse.wordpress.com/

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

Software Quality Digest – 2009-02-04 | No bug left behind — Wed, 04 Feb 2009 19:53:30 +0000

[...] More Perspectives – Nicole Radziwill collected a few opinions about software reuse, also see the original posting Filed in [...]

By: Ron DuPlain

Ron DuPlain — Wed, 14 Jan 2009 05:23:55 +0000

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

By: Nicole Radziwill

Nicole Radziwill — Wed, 14 Jan 2009 02:26:33 +0000

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

By: Eric Sessoms

Eric Sessoms — Wed, 14 Jan 2009 02:17:21 +0000

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.

By: Software Reuse Antipatterns « Quality and Innovation

Software Reuse Antipatterns « Quality and Innovation — Wed, 14 Jan 2009 00:30:43 +0000

[...] learning, Software Quality, technology « Continuous Improvement Begins With Standards Why Software Reuse is Hard [...]