StateWORKS Newsletter 6/04
Why do we underestimate specification? - An end of year reflection.
20 years ago I made my first evaluations of CASE tools. In those days structured analysis and design in all possible flavours and variants was the "truth". I had the impression that a genuine software engineering discipline was evolving. You can imagine my disappointment when very soon I discovered that the expected benefits for the time and money invested failed to materialize. But I stayed with this topic, being a very careful observer of the scene, as my deep conviction had been and is that we will one day leave the type of programming we still do: writing programs often from scratch by using assignments and if-than-else structures, to express with these primitives very complex requirements.
The transition from "only coding" to "mostly specifying" was much more complex than I could have estimated 20 years ago. I have also begun to understand the complexity of the process and especially the influence of human factors which play a dominant role here. This was also the reason why the VFSM method and the StateWORKS tools emerged, where we went a different way from the main stream. StateWORKS is not a way to specify software but is a method to specify an application - which is than carried out by standard software.
Many companies produce more or less the same products during long periods of time. Some companies produce cars, others - telecommunication equipment, again others - machines, etc. They use the same or similar devices whose behavior stays the same or changes negligibly: a pump behavior, a motor control, gauge supervision, a protocol is today the same as 20 years ago. But the pump, motor, gauge, protocol, etc, were - in those same companies during the last 20 years coded anew several times. Any change of programming tools, hardware details, sometimes even of persons leads to repetition of the same exercise. We forget or do not want to see that a control task contains invariants which do not change - the factor that does not change is the required behavior. This behavior must not be hidden in code! The required behavior is independent of the programming language and operating system. Therefore it should be disclosed once, specified once and always used thereafter. The probability that in 20 years the control application will be programmed in present PLC languages or C is close to zero. The probability that a large part of the behavior will stay unchanged is nearly 100%. So why continue these exercises, coding the control problems again and again when you can do it once (as a specification by means of StateWORKS) and have it available for many years to come. StateWORKS is a wonderful tool for this once-done-always-use task.
With this recommendation I would like to close our year. Thank you for your faithfulness. The increasing number of subscribers proves that our idea is seen by more and more people. We will try to supply you next year again interesting news about our idea, mission and tools.
Merry Christmas and a Happy New Year for all of you.
F. Wagner