Why click n? drag IT may elude us

TalkBack 3 of 12:: Next »; « Previous

Thread View
Flat View

The promise of technology: Every advance in programming technology comes with the promise that it will bring the holy grail of click-and-drag programming (or some variant thereof) with it. It's been this way since I started programming in the mid-80's and it may well have been that way from the day Charles Babbage designed the Analytical Engine.

It hasn't happened yet, and the only way it will ever happen is if AI reaches the point that computers are as smart and as flexible as humans.

I'm not suggesting that advances haven't been made; far from it. We have tools today that allow managers to do for themselves what professional programmers would have had to do for them 5 or 10 years ago. I've seen non-programmers write quite competent spreadsheet programs to solve particular business problems in their departments. Had such solutions existed 5 or 10 years ago, they would have been hailed as revolutionary. Today, they are simply part of every manager's tool kit.

What happens when you introduce new technology is that the expectations rise to exceed the capabilities of the technology.

Mainframes reached the point where you could design screens and map them to the underlying databases just as the PC was making real inroads into the workplace. Suddenly, you had the technology to empower individual users but you didn't have the tools to do so.

DOS development tools were approaching some form of click-and-drag when along came Windows (my apologies to the Apple programmers who were there long before the rest of us). Now, the demand was for graphical applications, ones users could interact with using a mouse or a touch-screen, and a whole new set of tools had to be developed to take advantage of the new technology. Those of us that programmed at the Windows API level in the early days remember the satisfaction of seeing labels and buttons line up perfectly in the centre of a dialog after an hour of twiddling with a resource file.

After GUI came GUI client-server, and a whole new set of business requirements followed; we left the managers to create their little dBase applications while we ran off and consolidated the company data into a central database.

Client-server begat the Internet and now some if not all the applications and data had to be made available to the rest of world. The Internet (eventually) begat Web Services and it was no longer enough to present the applications and data to the world, we had to make it possible for others to use the applications and present the data as they saw fit.

Despite all the advances in technology, most people are still limited in what they can do with the technology and those that have the skills to use it are still limited in how far they are allowed to go. No sensible corporation will allow users to arbitrarily add on to a central repository. You still need a business analyst to reconcile the requirements with the rest of the company and you still need a programmer to ensure that the integration effort is compatible with the existing infrastructure and applications. This will probably sound elitist, but ultimately you need someone with the skill to translate the business requirements into something the machine can understand. It's easy to say that you want some kind of semi-automated response system to handle the volume of e-mail you receive, but as you have found every requirement comes with a boatload of "Oh, by the way..." that will keep programmers employed for a very long time to come.; Posted by: Kevin Dean Posted on: 06/24/04 You are currently: a Guest | Members login | Terms of Use