Two weeks ago I suggested a little programming contest intended to get people to see just how hard it is to fully specify a problem - even one as self evidently simple as summing the square roots of a real valued vector and printing the error bounds - a problem, incidently, for which there currently is no general solution.
The contest idea sparked some interesting comment, but nobody jumped up and down demanding the right to enter, so this looks like an idea that's going nowhere.
And that's too bad, because there's a lot to be learned from the fact that the simplest looking development problems tend to be, in reality, somewhat more difficult to handle than a frightened porcupine in a small room.
In my opinion that's the universal experience with real business applications - they look so simple you can't believe it would take more than a couple of days to code to the business requirements and then extend the thing to offer trapped-in-the-past users greater efficiencies, lower costs, or new opportunities.
Except, of course, it doesn't work out way - once you get started, you start seeing quills, and the more you dig into it, the worse it gets. You know what the truth is about real enterprise class business applications? they're 1% core business process and 99% exception handling - and that 1% is all you're likely to see at the beginning.
So how do you deal with that? Many people try to use applications to reduce that 99%, but I think the right answer is to do exactly what users do when they build their own pseudo applications using Access or some other unauditable PC tool: you encourage uncontrolled, ad hoc, change - except that you have to do it on a piece of enterprise software with 5,000 concurrent users and a whole team of hostile auditors dedicated to enforcing their 1930s derived world view on you and it.
You emphatically cannot do this with typical data center organisational structures or within the usual expectations about how Systems operates - but I think that it not only can be done, but will eventually become the norm.
So how? Simple really, just turn everything inside out so processing gets centralised and control gets decentralised. In other words: push resources at users instead of husbanding them, give your front line people real responsibility and commensurate control, retrain user expectations so they understand that Systems works for them - but that everyone works for the same organization - oh, and change your organisational alignment along with all of your hardware, software, and networking to meet the new needs and new expectations.
No harder than spending the weekend duplicating SAP using Visual BASIC (.net) on a PC - and right now generally about as practical. It isn't that hard to do this in small companies - I've actually done it twice: once for about four hundred users and once for about 120 - but imagine trying this at Roger's Company F?
Now that would be a challenge. Notice, however, that it wouldn't be a technical challenge: we know what we need to do, and we know how to do it; the constraining forces are organisational and perceptional, not technical or financial.
Thus the reason we normally can't do this kind of thing is simply that everyone knows we can't - and that's the fundamental problem: nobody has a clue how to make the necessary changes in the behaviours and thinking of thousands of job holders, managers, and systems people who know that Systems isn't meeting expectations but are absolutely certain that the organisational and technical structures in place epitomise the one and only right way to manage Systems.
With that contradiction in mind let me tell you something most people don't realize: the ideas that Systems should belong to the user community rather than Finance, that ad hoc change to user applications could become basic to user support, and that centralised processing could be coupled with decentralised control, were central components in the vision driving IBM's Future Systems project in 1968 through 1971 - a half billion dollar technical success that was scuppered at the last minute because the people comprising IBM's key System 360 markets freaked at the thought of giving users control and couldn't begin to understand what the technology -a database machine with a near 4GL prototyping environment- was either about, or could do.
And if that isn't enough consider this: today SAP stands for harshly authoritarian, my way or the highway, old style data processing - but do you know what they started out to do? Oracle Office with Oracle Financials: the exact philosophical opposite of what they became. What happened? commercial necessity: SAP was founded, in 1972, by a group of IBM Europe managers with early access to a Future System: people who saw in it the opportunity to create a truly user driven, enterprise wide, solution held together by a unified database running on a single machine - but who were forced to compete in data processing markets when IBM pulled the technology rug out from under them.
So what's the bottom line? People have known about alternatives to the data processing organization and its consequences essentially since the dawn of science based computing in the early fifties - but even IBM didn't think it could pull off the change in the 1970s and the problem hasn't gotten any easier since. Only more urgent.