Instant Solutions?

This morning I picked up the April issue of JDJ, and Joe Ottinger's editorial "Looking for Instant Solutions?"  (which doesn't appear to be freely available, so no link, sorry) caught my eye.

His premise is that solutions aren't valuable in large part due to their inflexibility. The same for programmers. Both are stuck in the past, nailed up to prior experiences that adversely colour their reactions.

In part I like this notion, because it explains why some very bright developers insist repeatedy that Enterprise JavaBeans are the wrong solution - it is that they aren't evaluating in terms of the current application and current capabilities of EJB containers so much as they are evaluating in terms of their prior projects and frequently version 1.0 EJB containers.

But Joe goes a little too far with this thought, appearing (after skipping a couple of steps of his article) to recommend the use of meta-solutions over solutions. That is, he calls for a framework of solution creators, from which application-specific solutions can be constructed on the fly.

Perhaps this is an evolution thing. His thought reminds me of reports of the rennaissance, in which there was a vast explosion of creativy and advancement in design, thought, science.  What there wasn't was much standardisation. And in the time between then and now, the processes of constructing things has evolved quite a bit.

The economics of software construction should be of major concern to developers today. Without efficient end-to-end software construction/deployment/maintenance/extension/etc, net return isn't there, and can't flow to the developers. Read: downward cost pressure, which leads to offshoring and other amusements.

The evolution of processes (in the previous sense of the rennassance, construction, et al) has been driven by the same economics: these processes start off with artisans, and over time the grunt work is taken out (from one point of view) or the inefficiencies are removed (from another) or the room for creative craftsmanship is removed (from a third point of view).  Building a car, I no longer design my fasteners one-off.  Only the pentagon gets away with $500 toilet seats.

So long as we're still designing and building screws, we can't focus our brain cycles on the car. And it the car that makes a profit, and pays our salaries.

So while I can understand a desire to use meta-solutions, I don't believe they are efficient or that they help the economics of software development and really allow the field to advance. I certainly agree that a single solution doesn't apply in all situations, but the solution isn't to design the solutions one-off, but is instead to develop a more flexible solution or group of solutions that cover a range of our activities.

My big red tool chest has 4 sizes of Phillips screwdrivers, and 2 Robertson. And this is good. I don't need to craft screwdrivers on my own.