July 12, 2006
Plan-driven Reuse (& Other Costly Mistakes)A few years ago I consulted for a short spell with a very large client who had hired in a very large team of very experienced (and therefore very expensive) architects and component-based development experts to work on a very ambitious project with a very lofty goal - namely to create a framework of reusable components out of which all new business applications could be "glued together" in a fraction of the time it takes to write them from scratch.
Phew! Long sentence; I'm out of breath writing it...
The logic went something like this:
"How much did that last project cost?"
"$10 squillion (and 31c)"
"What does it do?"
"Something to do with our business, I guess."
"Don't some of our other business applications do this sort of stuff? Surely some of these problems have been solved already?"
"You're quite right. Out of $10 gazillion (and 31c), $10 bongozillion was spent on reinventing the wheel (and 31c was spent on writing the 2 lines of code that was genuinely new)."
"If only we could somehow leverage our original investment in solving each problem so that we can apply that solution over and over again and then we don't have to waste $10 megabongozillions solving those problems all over again from scratch."
"You mean... reuse those solutions?"
"Yes, that's a great word for it - reuse. Quickly! Someone call a patent lawyer!"
And so a $megamongobongogazillion project was created to solve those problems once and for all and to make those solutions reusable on all future projects. Eventually, 6 years later a CD-ROM was the end result, and on it was about 1.5 million lines of reusable code - what some among us like to call a "framework" for building industry-specific applications.
Those of you who are beginning to see the parallel with a certain mega-intelligent computer called Deep Thought will probably have already guessed where this anecdote is going...
Anyway, the very, very experienced CBD consultants produced this CD-ROM of reusable solutions, and it was printed in volume and shipped to every developer - and there were thousands of them working for this company at the time - along with copious documentation and the obligatory invitation to register for a seminar at a low, low introductory price where they could:
a. Learn all about the $megamongobongogazillion framework, and
b. Learn all about exciting offers for WebSphere training in their geographical area (in a vain attempt to at least recouperate their 31c)
4 years later and I have it on good authority that no applications written since then have used the framework. Why not? After all that money's been spent and after all that hard work?
It occurs to me that even though their $megamongobongogazillion framework might be the solution, nobody has yet to figure out what the actual problem is.
This is the fundamental flaw in the big megabucks up-front resuable framework approach to development. A good framework takes common elements from multiple applications and generalises them into reusable components. Knowing what these common elements are going to be before you've written the applications from which they're being extracted is verging on precogniscence.
In my experience, the best resuable code comes as a result of refactoring existing code and extracting the abstractions and removing duplication. I find it incredibly difficult to guess in advance what those abstractions are ultimately going to be.
In short - frameworks are discovered, not invented
Posted 3 weeks, 5 days ago on July 12, 2006