Some time ago we had to write an impossible application. And like any other such application, it doesn’t showed up from the beginning how “impossible” it was. It was about a team scheduler which would assign different task to different team members, based on various constraints related to each member’s capabilities as well as to the project time line.
Why I remembered this? Because of some comments on a previous post made by Chris Rolliston and Ken Knopfli. Both made good comments with regard to the hidden complexity which most of the times surfaces during the application lifecycle.
And remember, the most common cause of failure of a software project is (according to Steve McConell) is it’s uncontrolled complexity. Also, Tom DeMarco & Timothy Lister note in their reference book (Peopleware – a must read) that not even a single project (from thousands which authors examined) failed because of a technical reason.
So, we took our weapon of choice (Delphi of course) and started to build the impossible… And after “a while” we succeeded! Oh, wait… we thought that we succeeded. We had a nice GUI and a ‘flexible’ Business Objects Engine which would take care to apply the constraints. You know: Team member #1 is in the Department #3, hence it cannot be in the same day in the Department #4 aso. And of course, “it worked” …till it came to use it in practice.
Our customer(s) were very pleased about our total solution but after a short period of time started to ask “You know, the Worker #5 doesn’t “feel good” (TM) to work in the same department with Worker #3. Can we program this?” … “Worker #7 gets tired if… “, “Worker #2 has also other duties and cannot…” aso. I think that you got the idea.
What shall we do? We must deliver. Fortunately we discovered that we had in the past somewhat similar situations which involved complex problems from a human point a view. We tried to find a solution but the ‘A-ha!’ moment was when someone said: “Why you cannot build such a system? Don’t tell me that the computer isn’t intelligent. I consider myself a rather dumb man and I can solve this…”
Of course, he couldn’t. But this was the key. A human is intelligent where as a computer is not. The computers are good to do the mass work whereas the humans are good to deal with the exceptions. It is very costly to model in software the exceptions or to try to cover automatically all the cases, if this is possible at all.
So we altered a little our Business Objects Engine in order to allow the user to break the rules. Of course, we put decision assistants (warnings, colors, messages etc.) but what was important was that from the point where the software couldn’t cope anymore with the problem, a human would take it and adapt to it’s human needs.
In the same manner we modeled a general popup framework (a very draft demo here) which is aimed to allow the user the freedom to build his own popups and/or drop down lists while the framework will take care of the boring and repetitive task of building the infrastructure for the user content. What is different is that this isn’t entirely automatic, the user having to specify some properties and call a method ( .Close ) in some circumstances. We tried to do the things as automatic as it goes but our main goal was to provide an ultimate flexibility and power for the developer while allowing him to concentrate on his own programming problem.
We put the above demo so early in order to gather feedback from you as early as possible, because we think that the worst bugs are the design ones. Please feel free to play with it and tell us what you think.
And I think here lies (or should lie) the power of Delphi. To be powerful and flexible and to not try to think in our place, leaving us the freedom to change the things if we want.