Tuesday, October 02, 2007
Abstraction -vs- Testing
During the MDUCDE 2007 in Seoul, just before my presentation, Asaf Degani did a great presentation about his work on UI correctness. Basically, he exposed how inconsistencies between the user model (what the user thinks about what the application does) and the user interface model can produce very frightening problems. The example he presented was a inconsistence in the aircraft autopilot... (I have the full paper in my notebook but I couldn't find it online).
"The conceptual approach for generating correct and succinct user-models is based on the fact that not all the system’s internal states need to be individually presented to the user".
That is, the user interface is a projection/view of the application. So, the user model is different from the user interface that is also different from the application/machine. Asaf modeled the user model from the user manual and he found that with the aim of reducing information overhead sometimes what the manual teach is not what the application/machine actually does.
Suppose the plane is planning at 5000ft, if the pilot enters 10000ft in the autopilot interface, then the plane will climb until that height.
Then if the pilot set a new lower height after the airplane has passed a special point, then the airplane turns into an undetermined state, and continues climbing indefinitely. The problem arises because the pilot thinks (because the user manual tells him) this special point is calculated in a way that is not the real way. From the pilot point of view, the machine is behaving in a non-deterministic way: sometimes it works as expected, sometimes it doesn't but he doesn't know why. Why did they write the manual in this way? Well... because with the information available in the user interface, the pilot couldn't calculate the real special point, so they decided to avoid "the details" [1].
Obviously, Asaf concluded that the UI is incorrect because it doesn't give the user all the information he needs to do the task. Maybe the manual is incorrect too, but what actually matters is that they are inconsistent.
From my point of view, this is a particular case of a wider topic that came again and again during the conference, in all the forms you can imagine (from cars to aircraft autopilots and smart factories). When you use different languages for each world you have to do a lot of extra work in testing to ensure you are keeping it consistent, because basically, what you are doing is to add more translations. The bigger the difference between the languages, the bigger is the probability to produce translation errors between them. In some fields, it may be still too difficult to unify both worlds in one only language, but in others, we are just not taking the right approach to solve the problems.
However it also happens in other models: software design, implementation, etc. If we were able to merge them, we could avoid testing the translations.
Some time ago I had a similar conversation with Andrés about this topic (he had written a post about it). We agreed that when you express things at the right abstraction level, testing is useless, because it becomes a tautology. Would you test that the += operator is working properly in C# or Java?. I wouldn't.
To put this in the context of Asaf's work, if the aircraft autopilot and the manual are made with the same language, his work would be useless. You wouldn't need to prove the UI correctness because it will always be consistent with the user model [2].
Obviously, taking this approach ought you to test your high-abstraction language... it is a trade-off, but in most of the cases this is a far simpler and better limited task than testing all the user interfaces, and sometimes it can also be "outsourced for free" as we do with the += operator.
I think Eugenio Pace said exactly this in a different way a week ago, talking about SaaS in the Genexus Meeting. He proposed something like the Law of Conservation of Mass for complexity and software. He said: you can't avoid complexity, but you can redistribute responsibilities and that is what SaaS is about.
I think it is also what DSLs are about, translating complexity until some day, when magically a lot of testing and translations disappear and you can focus on what is really important for your business.
[1] Yes, this is how an aircraft autopilot works today, but don't panic, it is a very strange situation and I believe they can take the airplane control again in any case. I can't remember the special point name, and the exact calculation, but it's not the important thing here.
[2] Asaf is currently working on how to automatically generate the UI from a reduced user model and avoid the testing by producing correct user interface by design.
Labels: airplane, Conference, DSL Tools, MDUCDE
