|
Re: a small addition maybe...
|
Posted: Jun 14, 2008 8:49 AM
|
|
> In a sentence: Design should reuse (as in adopt) > generality, but create the particular.
What you are saying here is that component-oriented programming leads to Foundation Class Libraries that are so rich that you will never be able to use every class. In other words, components suffer from having fine-grained design. Building systems out of grains of sand is like lifting and shaping the whole desert to build a pyramid. In doing so, we're routinely revising the Seven Wonders of the Software World: For the most recent wonder, look no further than the United States government's Future Combat Systems' 63 million lines of code (13 million more than Windows Vista!), and their recent proclamation that they will achieve "Information Dominance". I'm only 24, but quick wisdom has taught me that you cannot compete by offering globules of sand. Like components, the grains of sand have to be re-used as-is, and so they are only latently re-usable.
Where I work, we're open about what we call "stick-built" software: software that has been tested for quality but ultimately brittle when things like entire business models change. Such software is usable, in the sense that we can sell it to customers conforming to specific tasks and processes. We realize the distinction between having to fine tune a product and having to re-tune a product. We're latently re-using the code in the sense we're selling the same product and changing (fine-tuning) a few resource strings and logos. However, we cannot mass produce it and sell it to a global economy with disparate business models, and therefore it is not re-usable. It does not have coarse-grained design.
Realistically, we have few project failures when we can deliberately re-use software and the waterfall model works great because we're skipping the design phase. For these projects, we're on time and and on budget. Deliberate re-use is all about figuring out a way to skip or shorten pre-implementation phases in the software development lifecycle. Most organizations do not target this sort of re-use, and are still aiming for latent re-use through component programming.
> > I digress a bit here but I think these issues > > are rooted in the misapplication of the reuse > > principle instead of the more correct > > understanding you demonstrate above.
Use and re-use are fundamentally different. Use sustains known degrees of freedom in thinking about a problem. Re-use introduces new degrees of freedom. In doing so, re-use reduces complexity on one axis (more generality) while increasing complexity on an orthogonal axis (less definiteness).
Use, in the "stick-built" software sense, isn't bad, though. Some people like working on stick-built software with an eye toward making it re-usable. However, as an ISV, it is much harder to score a business contract with a company if you need to develop an internal greenfield project just to fulfill the contract. Such a project is a start-up venture, and as with all start-ups there is a high probability of failure.
|
|