This entry was posted on Tuesday, May 12th, 2009 at 7:26 am and is filed under Reuse. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
1. The inability of many programmers to do good functional decomposition. (The “top down” part of design)
2. The (related) inability of many programmers to see, from a particular problem, the general solution. (The “bottom up” part of design)
3. The (also related) inability or unwillingness of many programmers (and their management) to refactor code when it is changed, to avoid code bloat, cloning, and dead code.
4. A lack of commitment from software development management to reuse. It takes an investment of time, effort, and money, but pays off handsomely. Many development shops are too much in “crisis mode” to make the investment.
5. The lack of a “reuse librarian” whose responsibility is maintaining a base of reusable software, with good keywording for searches by programmers.
Ideally, when a new project is being designed, the “top down” functional decomposition is accompanied by a “bottom up” effort to identify and design the lower-level primitives that will be needed by the higher-level functionality. Typically these two design efforts should meet in the middle, with a good API for the top to use in invoking the bottom. The “bottom up” part is where the reusable code comes from.
Capers Jones, a famous expert on software metrics, says that reusable code has excellent potential for reducing software defects (assuming that the reusable code is itself well debugged) — far better than CMMI, Agile, or any other “methodology”.
Great comments! Thanks for the input. I agree specially with the point about a lack of management commitment and development shops being in crisis mode. In my view, reuse is incredibly hard – it needs tech leadership and developer discipline along with the management commitment. Reuse librarians are invaluable – if done right this role can effectively bridge business needs with existing software components/services and identify new ones as needed
[…] Align Your Software Assets To Be More Reusable Thank you for giving me your vote on the hurdles for software reuse. From the results, it is clear that the number one reason for not being able to build reusable […]
Fill in your details below or click an icon to log in:
You are commenting using your WordPress.com account. ( Log Out / Change )
You are commenting using your Twitter account. ( Log Out / Change )
You are commenting using your Facebook account. ( Log Out / Change )
You are commenting using your Google+ account. ( Log Out / Change )
Connecting to %s
Notify me of new comments via email.
Create a free website or blog at WordPress.com.