Redesigning PLC Development

For 18 months, I had been buried in the PLC (industrial controls) world.

My original mission was to “rethink” the approach to PLC software application development because the state of the art of these systems is perceived as dismal.  PLC systems are seen as infested with bugs, or difficult to document, difficult to maintain, difficult to expand, or some painful combination thereof.  PLC culture has encouraged “one-off” application development, disregard for re-use, disregard for team-development, and tends to be ignorant of or eschew automation in testing and debugging methods.  PLC development culture has not demanded the integration of the advances in software engineering from the past 20 years or so, both in terms of tools and technique.  It is amazing, for instance, how many PLC developers are ignorant of the concept of unit testing or even source code revision control.  The lack of this demand may stem from the intellectual insularity of the culture and innocent ignorance.

My original mission was to overcome the downside risks of the usual PLC development culture and create a new culture, a new development methodology, and new infrastructure that could bypass the usual shortcomings and help us create applications of higher quality than had been expected to date.  The implementation of this mission however is expensive and fraught with risk (e.g., time-to-completion risk), mostly because of the dismal quality of vendor-supplied tools that PLC developers have no choice but to use.  These risks were known from the beginning.  The check-writer’s tolerance for such risks were not known for sure however, only what they said they could tolerate was known.  The spoken and actual tolerance for risk turned out to be very different after all.  No one has been surprised.

Alex Bell on the Disease that is UML

Alex Bell has written a lovely article on the use of UML called, “UML Fever: Diagnosis and Recovery”,

I admit to using UML from time to time.  I do so because a specific UML modeling tool may meet specific communication and data storage requirements I might have.  UML tools, for instance, make for interesting “object databases”.  I occasionally find the detailed grammar of UML helpful as a helpful guide for thinking through the details of certain classes of problems.  I use extensions to the grammar frequently.  As a generalized communication grammar however, UML is severely limited and should be ignored.  The appropriateness of UML is not well understood by a significant fraction of practitioners and its over use is certainly counter productive.

I believe that modeling tools are useful but must recover from the UML disease that has infected them all.  I have a specific evolutionary path in mind which I will write about in detail at a future time.

If you wish to improve the efficacy of communication of complex concepts between team members, I urge you to return to the basics of literature, philosophy, psychology, linguistics, marketing and art.  At the very least, read Edward Tufte.  The efficiency-through-standards argument of UML is a myth.