Why software doesn't adapt
Searching for a project management tool
One of my students came back with his thesis and the result was quite a surprise. His topic was to define requirements for a new project management tool for an electronic publishing company and to do an evaluation of standard packages. After looking at close to one hundred such tools with a detailed analysis and trial of 15 he found none that did everything the company needed AND could be integrated into the current infrastructure. Now project management doesn't sound like such a special requirement to me so the result was really a surprise.
At the same time I am doing a class on design patterns and one on generative computing. We use eclipse and a filesharing system based on Sun's JXTA to create a professional development environment and learn about plug-ins for generation. The student will do a talk about his results next week and I will use this case to dig into the problem of adaptive software.
Why did the standard software not fulfill the requirements?
Lot's of features but some essential ones (for company X) missing
Unable to integrate with existing legacy applications - especially in the area of enterprise data (personell, projects etc.) which are kept in other applications.
No easy way to extend the product with custom features to make it fit.
Bad user interfaces. A project management tool needs two: one for the planners and one for developers to just fill in the numbers. Both have very different requirements.
Before we speculate about architecture we should take a look at what the company decided to do. Given that no standard product seemed to work for them they decided on an internal development based on the following rationale:
An internal development would only need to develop features that were considered necessary. No overhead would be carried along like those feature loaded monster applications.
Integration to existing applications would be a question of interfaces which would have to be developed.
Those arguments are quite typical to justify inhouse development. They sound convincing - at the beginning. My statement here is: The advantages with respect to flexibility last only FOR ONE RELEASE. Once the application is shipped internally it looks and behaves just like all the other standard packages - worse perhaps, because it won't have the extensions those already have. The internal product will not be extensible - it was developed within a short time frame (remember: only the features needed....) and nobody thought much about the fact that the companies OWN requirements will change as well. And there will be no architecture in place that could cope with those changes. Putting it in would slow down development quite a bit and kill some of those advantages which where used as arguments for an internal developement.
So far so good but that does not help the company either. They are caught between two impossible alternatives: pick a standard package which does not fit the requirements or develop something internally that - if done with extension in mind - would require much more resources than are planned for a small inhouse project. And since it would be an internal project the costs for development could not even be reduced by selling it to other companies. Because this would require extension features.
So why does software not adapt?
It's probably not because those companies which make the standard packages are just too lazy to put in all those features customers want. In fact - they put in already too many. It is important to realize that it is simply impossible to satisfy all customers with pre-built features. The companies should not even try to do it because doing so puts too many features into software - most of whom will never be used by most customers.
The software should be built with extension points built in. Extension points are implementations of so called "hot spots" defined during domain analysis. I won't go into domain analysis right here but I found a tool which I can use to both demonstrate what I mean and use to create extensible tools. I am talking about the open source project eclipse.
I will start to explain the anatomy of an extension point in the next article. And after some discussion of eclipse I hope to end up with some principles of domain analysis and production line software and why those architectures make sense even for inhouse projects.
