Why do we build Houses of Cards?
I cannot remember where, many years ago, even before I joined the computer industry, I learnt -
"Why make something difficult when, with a little more effort, you can make it bloody impossible."
The worsening problems of the computer industry remind me of this on a daily basis.
Many people are aware that there is a real problem, but rather fewer seem to understand what it is, and fewer still look for a solution that will make
any real difference. New tools, methods, gizmos, etc. are constantly appearing, and many are put forward as routes to the promised land. I have seen so
many that have arrived with trumpets blowing and which have failed to deliver and then just faded quietly away. All these tools do, even when they work, is
to add to the complexity, and ensure that, since we cannot be an expert on all methods and tools, we can eternally debate their merits as no one really knows
what is best. If we are to make any real difference, we have to stand back and look at the problem of application creation as a whole, rather than simply
tinker with the little bit we understand. Debates about the merits of Java totally miss the point. The problems are much more fundamental. Yet we all
love to promote a particular methodology, such as our favourite program language or the best way to build client server applications, etc.. We forget that
any methodology is only a means to an end. Surely our objective is to give our users what they want when they want it within reasonable time and cost
scales. The systems must be stable and able to evolve in line with the ever changing world of users. If we are to achieve this, we must go for simplicity,
not complexity.
Of course, computers today are doing far more than they did a few years ago, and this may disguise the underlying problems, but these are getting ever
more accute.
We make the task of application development extraordinarily and unnecessarily difficult, so that the systems we create are houses of cards, which, if we
are honest, are, even on their best days, in a state of unstable equilibrium, best left untouched. This situation is made worse for many companies by poor
operating systems with inadequate robustness and security, particularly on PCs, so that it can be necessary to restart a PC several times a day, often with
the loss of an unknown amount of data. At least, AS/400 users don't have to worry about the reliability and stability of their platform.
At the same time as companies become totally dependent upon their computer systems for their very survival, those systems are becoming ever more frail
because of their extraordinary complexity. Today, few companies, whatever their size, have control of a stable, integrated, corporate database. Unless steps
are taken to correct this, the companies may not survive. Stringing together disparate databases on multiple servers and giving the process a fancy name
is not a solution.
I could take a lot of space proving my case, but I think that "Y2K" will do. It may now be history, but if you think that this was a one off,
think again. It was and is a damning indictment of the tools and methods that we use in computing today. We can't blame general management or our hardware
or development tool suppliers for the Y2K problem. Lack of budgets for the changes is no excuse either - we, or our predecessors, should never have built
systems that were not Y2K compliant. It was down to us IT experts alone - we had enough warning. Now you have solved the problem, then, presumably, your
systems would cope with the Y3K problem, etc.. If not, have you just "fudged" it?
Of course I am not talking about your company's systems, just the guys' down the road. But if you think it does not apply to you, rethink. Can you say
that you had NO Y2K problems? Are your applications really stable? Are your applications all totally integrated, sharing the same corporate database,
without ANY redundancy? Do you have REAL control of this database? Do you have an audit trail for all changes to data definitions and user data? Are you
able to keep your applications all absolutely up-to-date, meeting all user requirements as they arise? Are your systems really secure and can you back
them up whilst live? Can you change database definitions and applications whilst they are live, on a large multi-user system? If you have to answer "NO"
to any of these questions, then there is room for improvement (to put it at its politest).
If we had to shut down our brains every time we had to learn even the simplest thing, we would still be in the stone age, just like application
development. Our brains cope all the time with new data types that cannot be anticipated, without even noticing, without physical database design and
without reprogramming. Why do we program our computers? Programming is surely the most inefficient process ever evolved by man in any field of human
endeavour. It may be fun for masochists, and I may be one, but productive it is not! It isn't necessary.
I assume that our brains are not reprogrammed from above every time we learn something new. We could apply this idea to building computer systems. If
we used intelligent database techniques, we could, for instance, add new attributes to an entity type whilst it was in use by multiple applications without
having to consider the implications for those applications, without shutting them down, without affecting their performance whilst making the change, even
on a large multi-user system, without changing any existing applications unless we wanted to make the new attributes available in them, and without
having to propogate lots of "null" values in the empty new attributes. This is possible - today. There is no need to worry about physical
database design, normalisation, redundancy, joins, etc.. Integration is automatic, and, most of the time, there is no need to create (or generate) or
change any program code.
NO - that cannot be right! The only way to make computers work is to program them - we all know that!
Businesses are getting more and more market driven and markets are changing at ever increasing speeds. If we purchase an ERP package, it may take 18
months or more just to implement it. Our whole world may be totally different by the time it is working. If we don't use dramatically simpler techniques
for system building and maintenance, we, the IT experts, will be responsible when our companies are unable to react, and they wither away and die. If we
stick with our existing methods, we will all be out of a job.
We may be too busy fighting our day-to-day battles with our bows and arrows to seek out and evaluate new machine guns, but if we don't, we will lose the
war. If we lose it, and we are dead on course to ensure this at present, we (yes - us!) could bring down the whole fabric of society. I am deadly serious.
Rob Dixon
Erros plc
25th July 2000