Software As Capital

Software as Capital: An Economic Perspective on Software Engineering by HowieBaetjer., IEEE Computer Society,

ISBN 0-8186-7779-1 See also :http://www.computer.org/cspress/catalog/bp07779.htm (cheaper than Amazon for members.) From the cover ... The concept that designing capital goods is a social learning process leads to interesting conclusions about software process models and methodologies. The book examines the main failings of the software industry when compared to other industries: the absence of an extensive division of labor for software components. It sets out the reasons for the problem, outlines the solution, and illustrates the benefits that will result from its solution.

CategoryBook

I read this on the plane on the way back from Lisbon. Fabulous new perspective on software. It makes some interesting predictions that I don't agree with, like the value of reuse. --KentBeck

I haven't read SoftwareAsCapital, but I am reading ComponentSoftwareBeyondObjectOrientedProgramming by ClemensSzyperski. Judging from the capsule description above, the authors may share an mindset. -- MichaelFeathers

One of the major points of the book is that longer and wider and more complex chains of capital are more valuable. An example of a capital chain starts with a hammer which gets value from the handle and the head. The head gets value from the machine tools and the raw steel. The raw steel gets its value from...

The self-sufficient pioneer family has virtually no capital chain. They make everything themselves directly from raw materials. As their chain lengthens, they can live better by purchasing glass windows, better farming tools, etc, etc.

Baetjer argues from this perspective that software suffers from short capital chains, since everybody pretty much starts over from scratch (this is getting better, but not very fast). He proposes reuse of software components as a way of lengthening the chain. In particular, he likes SuperDistribution as a way of creating an efficient and attractive market for incremental value in software.

I haven't been able to make this kind of reuse work for myself or my clients, but I believe Baetjer's arguments in the abstract. I don't have a convincing re-interpretation from my experience, but I think that patterns and development disciplines might constitute lengthenings of the capital chain in the sense that he means. Comments? -- KentBeck

I've heard people make the point that software is an executable specification, or plan. Anyone who has the plan (code) can make an arbitrary number of instances. We see capital chains for material goods, but we should ask whether people buying and selling plans in other industries constitutes as strong a capital chain as what he supposes we can have. Do people make much money selling plans for hammer heads? I don't think so. There are probably a whole bunch of different specialized kinds of hammer heads. How many different kinds of screws are currently manufactured? -- MichaelFeathers

"Chains of Capital" sounds like an example of specialisation. Buying your windows from a window specialist makes sense because it gives that guy the economies of scale which enable him to do a better job - he can invest in machinery and/or decades of study and experience. This leads to the production-line kind of thing, making hundereds of identical items.

There's also ComparativeAdvantage in this situation.

Then again, we have another kind of specialisation which involves tailoring a general tool to a specific context. Instead of hundreds of items all the same, they end up all different, all adapted to the exact place they are used. This is the kind that Alexander emphasises.

In our industry at the moment we have a tension between these two kinds of specialisation: how to make something standardised and re-usable and at the same time parameterised and adaptable. We have some techniques, like dynamic polymorphism, generic classes and suchlike variations, but they are not really adaquate. (Especially if we also want efficiency.) Patterns are successful partly because they provide reuse at a higher level. They don't depend on low-level language features for their adaptability. Instead, we modify each one as we use it, using the common sense that automated tools lack.

My own experience has seen a lot of success with reuse within my company, and much less with buying in 3rd party libraries. The libraries rarely do exactly what I want, and they're rarely high enough quality, so that it is usually about as easy to write the stuff myself as to adapt someone else's. I expect the situation will improve as we learn more about how to glue components together, how to specify them and parameterise them, and how to compile them. -- DaveHarris

It's interesting to note how accountants (in the US at least; if you're not in the us than YourKilometrageMayVary?) treat software and software development costs:

Software intended for internal use must be expensed. It may not appear as an asset on the books; any money spent on bespoke software development must be recorded as an expense at the time it is incurred. (This excludes money spent purchasing assets used for development, such as computers or software--that money may be capitalized; but the wages paid to programmers may not be).
Software which is intended for sale may be capitalized; in other words, the money spent on developing it (including programmers' salaries and such ) may be recorded as an asset purchase rather than as an expense. Many companies don't do so; given that there is ample room for abuse with this practice. (Certainly it would be inappropriate to value the software asset higher than any expected returns from its sale).

Now, in both cases the software is (or may be) developed for the financial benefit of the organization. In the former case, the reward is (hopefully) in increased efficiency and thus lower costs; in the latter case the reward is (again, hopefully) increased revenue. Yet the two cases are treated differently.

Related pages: SpecializationIsForInsects, TheThirdWave.

Unrelated pages: SoftwareAsLiability