Some References for “Architecture Ethics”

I am waiting to obtain some consensus from my IASA peers with regard to the course outline.  Until then, I will talk obliquely about the content as it seems to be shaping up.  For now, let me give you a list of some of the references I will include these below.  I will also include references to some of the other classics, like Aristotle, Plato, Kant, and Hume, but here are some interesting readings from modern times.

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”,

http://queue.acm.org/detail.cfm?id=1053347

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.

Software Process, Like “Method” in Science, is Bunk

My response to James Turner’s article, Process Kills Developer Passion,

http://radar.oreilly.com/2011/05/process-kills-developer-passion.html

…you’re spending a lot of your time on process, and less and less actually coding the applications… The underlying feedback loop making this progressively worse is that passionate programmers write great code, but process kills passion. Disaffected programmers write poor code, and poor code makes management add more process in an attempt to “make” their programmers write good code. That just makes morale worse, and so on.

Software process, like “method” in science, is bunk!  I finally understood what the philosopher Paul Feyerabend was trying to say.  What is important is the data, or the stuff of reality, otherwise known as results.  Experiment (software tests), deduction and induction are all very important but no two people are going to arrive at their conclusions in the same way.  That is, no two people process data and leverage their capacity for deduction and induction in the same way.  One person’s process (method) is another person’s confusion.

If you want to de-motivate a creative scientist or software developer, force them to think like someone else who isn’t them.

Process is no substitute for knowledge.