Limits of Reusability
Recently, I spent a bit of time with a client who was just beginning a reuse project. They were well aware of the potential gains to be garnered through reuse and asset-based development, and were looking forward to reaping them. Unfortunately, they had not positioned themselves correctly, and they were unable to take advantage of any of the potential gains. Somewhere along the line a belief had been formed that all you needed for reuse was a decent tool. Turn it on, and voila, instant reuse.
If it were only that easy. There is scale of reuse efforts, each level paying off in bigger ways as you progress up the ladder. For instance, every time a programmer brings an existing source file into her favorite IDE, hacks it a bit, and then does a file-save-as to create a new module from the old, she has engaged in the first level of reuse. However, ad hoc reuse such as this is at the bottom rung of the ladder. If you wish to gain more from your efforts, you need to go beyond the individual developer. Meaningful reuse only really begins with at least two people, and for the big pay-off, requires even more.
Much the same may be said for asset-based development. However, here, bigger payoffs require not only more people, but also a wider range of participants. Asset-based development breaks you out of the programming ghetto and involves a broader mix of people and roles than just a group of developers agreeing to share some code.
Because both reuse and asset-based development entail groups of individuals working on a common goal, you need organization, and with organization comes politics.
Now, politics is a funny sort of word. It has many connotations, most of which are highly charged and emotional. Just defining the word can be interpreted as a political act. However, my purpose isn't to try to convince you that politics is a negative influence, and that you need to eradicate it from your reuse or asset-based development efforts. As much as most of us in software development prefer rational argument, politics will never be eliminated. We all know it is simply a fact of life in any organization.
On the other hand, acknowledging the inevitability of politics doesn't mean you get to walk away in disgust, muttering to yourself that you'd prefer not to sully your hands, especially if you care about the success of your reuse project. There is a rather large, and growing body of work outlining the challenges of managing reuse or asset-based development projects. A quick survey of nearly a half-dozen, fairly recent articles yields a bumper crop of advice on where to expect various problems and pitfalls, and what you might do to avoid them. What's important to note is that much of the advice concerns non-technical issues.
For instance, Jeffrey Poulin's "Reuse Metrics Deserve a Warning Label" isn't about how reuse metrics work, but the fact that so many of them are open to interpretation. There are no standards regarding their usage. Do you count Lines of Code (LOC) for source produced by an interface code generator? Is it reuse or clever semantics when a programmer using an objected-oriented language claims reuse for any classes he uses more than once within the same application? Fundamentally, determining what metrics to use, and how to use them, is more a political than a technical issue.
Which brings us to the old saw regarding standards. Everyone loves a standard, and that's why everyone has one. A recurring theme among many of the articles I surveyed revolves around the notion of defining standards between groups, and then defending them against the many assaults they will face over time. Perhaps the most articulate example is David Kane and William Opdyke's "Managing Change in Reusable Software." They address the need to develop a shared platform, and then maintain it from the onslaught of the frequently conflicting goals of the groups sharing the platform.
Of course, who gets to decide what the standards are is political in and of itself. As Jack Harich points out in his article "Avoiding the Pitfalls of Components," there is roughly a 70/20 split between component developers and application assemblers. What happens as the process matures and finally reverses into the 20/70 split between developers and assemblers he predicts? Who has the better bargaining position? When? Why?
Then again, defining the standards is one thing, making them known is another. This is especially true for the informal, organic standards that spring up in any shop. Jim Highsmith discusses this tacit knowledge in "Reuse as a Knowledge Management Problem." Underlying his points regarding the difficulty of making tacit knowledge explicit is the assumption of the willingness to share this knowledge. The adage, knowledge is power, is particularly relevant here. Like the challenge of deciding upon who sets the standards, the how, when, and with whom knowledge is shared depends upon the shifting positions of the groups and individuals involved.
Having said all this, I don't expect the scales to magically fall from anyone's eyes. We all know politics exists in any organization regardless of size, or unity of purpose. And this isn't necessarily a bad thing. At the risk of sounding too corny, rational discourse is the cornerstone of a strong democracy, or any organization for that matter. Competing needs and ideas are a fact of life. You don't have the option of running your reuse or asset-based development projects based solely on technical grounds. To succeed you're going to have to engage in some old fashioned politicking, like coalition building, whistle-stop tours, and pressing the flesh. But, please, leave the stilettos at home.