XML-based software strategies offer the hope of longer lifetimes for software assets. When business logic manipulates self-disclosing XML expressions, instead of working with idiosyncratic binary data structures, IT builders may become more likely to improve systems incrementally, rather than by “rip and replace.”
If software lasts longer, any good business accountant will tell you that its cost can–and should–be spread across that lengthened productive life span through depreciation, rather than being charged against enterprise earnings during the first year. In accountant-speak, longer-lived software can be capitalized, rather than “expensed” (if youll pardon the ugly but common term that I once used every day as a chemical-plant cost controller).
“In the late 1990s, software life spans were measured in months,” observed Charles Stack, who is widely credited with founding the first Internet retail site (books.com) in 1992. “We built seven Web sites,” Stack continued. “The concept of reusing was ludicrous. Perl, C++, PHP, Java. … Now that pendulum has swung the other way.”
Stack sees organizations building new projects, he told me, “doing Web-services-like development–not necessarily pure WSDL modules, but anticipating future interfaces–and theyre expecting that work to have long life spans because theyre using XML and other technologies that should be relatively immune to technology change.” Stack now heads up Flashline Inc., the company he founded in 1998 to develop tools and practices promoting software reuse: another hallmark of capital, often defined as the kind of asset thats developed to improve the productivity of labor.
Software reuse is often held out as the dividend of adopting an object-oriented language, but thats not a simple cause-and-effect connection. If software is conventionally designed, then written in an object-oriented language, there will very likely be benefits in reduced cost for maintaining that application: The interfaces between modules will probably be more clearly defined, and there will probably be less breakage of working code in the course of making improvements or adding new functions. But the modules may only make sense as parts of a whole, whats sometimes been called “jigsaw puzzle” modularity: Yes, there are well-defined pieces, but they only fit together in one useful way.
People need an incentive to think about defining a class, or building some other kind of component, in such a way that its easily adopted–perhaps with further specialization, which is how object-oriented languages are supposed to work–to be used for some other business function. If new components are marketed, in effect, to the rest of a development team–if theres some kind of feedback on what people are using, and what they like, and what they wish they could find–then its only natural to expect more effort along these lines.
“We take an e-commerce, promotional approach,” explained Stack in describing Flashlines products. “These are the recently added code components, or Our leading author contributed these UML models this week, or These are the four most frequently extracted components this week.” A UML model, he added, might be linked to components in various languages that have implemented that model–and like a good online bookstore, Flashlines systems also keep track of choices that seem to be related. “We track what assets get deployed together in projects. If three components were all used together in two different projects, we point out those affinities,” Stack explained.
When projects constantly start from scratch, a shocking fraction of total value can be lost over several life cycles. Even if an assets contribution grows at only 6 percent per year, it only takes 10 years for the cumulative effect of that improvement to represent more than a quarter of the total contribution during that time.
If software is viewed as a way of capturing knowledge as capital, then steady compound growth of that asset through constant improvement is the only logical goal.