- Whether to mention a pregnancy in a job interview
- A possible meeting protocol
- What are an end-user's responsibilities?
- Another take on opening PCs, or not
- Getting some process going
- Selling a more open environment to management
- Running an effective meeting
- Licensing rules for virtual machines
- The ROI of metrics
- Legal challenges to virtual machines
December 10, 2007 | Comments: (0)
Why re-using is harder than building for re-use
Dear Bob ...
I don’t agree with your point below:
“…Exceptional performance? That means repeating the results of others, not having them repeat yours,” (from "Creating a learning organization," Keep the Joint Running, 11/26/2007).
Many of us are faced with the challenge of global standardization. We are focused on the harmonization of disparate legacy regional processes. Leading other teams to repeat our repeated successful results is the measure of exceptional performance.
Perhaps I didn’t understand your point ...
- In the lead
Dear Leader ...
My point was simple: If you want to encourage the broader use of anyone's success, you have to make it clear that making use of someone else's ideas is the engine that makes this happen much more than creating re-usable something-or-others. Otherwise, instead of (for example) using the existing Pricing service that another developer wrote, a developer will be more likely to develop a new one, for all the standard reasons.
You might think you can lead other teams to make use of your repeated successes. If they are paid more to create their own instead, the outcome is entirely predictable.
Put it differently, and more broadly: You aren't leading unless they're following. Voluntarily because they want to, not because you're dragging them.
It takes a lot to create that sort of environment - much more than building the reusable somethings. Supply side economics doesn't work here. You also have to create the demand.
I'll add one more point I didn't make in the KJR column: Reusing the processes and components created by others is, in many respects, more difficult than building them in the first place.
Software is an opinion about how to automate part or all of a business process or practice. Business process designs are opinions about how a particular business function should run.
Those who build these things the first time have the privilege of their opinions defining things. Those who have to adopt them do not, and wherever they disagree, they have to subordinate their disagreement ... their good judgment about how things ought to be ... to the greater good of re-usability.
When you re-use the work of others, you're forced to accept a different view of the world than your own. That can be a whole lot harder than turning the view you have into software and swim-lane diagrams.
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on December 10, 2007 05:24 AM
RATE THIS ARTICLE:
-
- COMMENTS
...and it just this problem that has impeded code/procedure/function/object reuse for decades.
Creating software components designed for reuse requires planning for the future, and an implicit social contract for support of those objects. However it has the ego rewards of "I built that. It is a creation of mine and it reflects me." It has the immediate benefit of being necessary for a current project and carries a promise for the future too.
Adopting another's pre-built component simply does not have the same ego rewards. You have to trust the originator. You have to expand your horizons beyond the current project. You have to conform to the components requirements, and not the other way around. If you find a flaw not relevant to the original context, the originator won't thank you. By definition you've created external dependancies too.
Worst of all, having built a successful system, almost no one will reward or acknowledge you for doing so. You can get tarred for failure but there's no upside if you succeed (beyond the truism "that's what was supposed to happen").
As a result, numerous software architectures have promised a lot on the code reuse front, and delivered precious little. The problem isn't technological. It's political, organizational, social, and economic.
Posted by: Brian at December 12, 2007 11:50 AM|
Three books. Three ways to change the world, your life, or at least Bob Lewis' bank account. Leading IT: The Toughest Job in the World distills the world of IT leadership into eight learnable skills and gives you concrete, practical techniques for each one of them. Bare Bones Project Management: What you can't not do makes project management manageable, even for first-time project managers with no formal training in the discipline. ManagementSpeak: What managers say/What they mean … well, it won't help your career, and won't make you a better manager. Mostly, it will make you chuckle, guffaw, and maybe even chortle. Make friends - it's the perfect gift for anyone who has ever suffered through one of those meetings. Order your copies today! |
TOP STORIES
ADDITIONAL RESOURCES
- Virtualization: A Step by Step Approach to Success
- Dialing up Agility with Business Transformation
- 5 Things You Need to Know About Storage Virtualization
- Is your smaller organization ready for High Availability?
- Is system maintenance doing more harm than good?
- Virtual Test Lab Automation: Manage development infrastructure
