This post originated from an RSS feed registered with Agile Buzz
by Laurent Bossavit.
Original Post: Modeling, systems and software
Feed Title: Incipient(thoughts)
Feed URL: http://bossavit.com/thoughts/index.rdf
Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different.
For quite some time I was content to write programs without ever bothering to draw diagrams (UML or some other kind) before. I rarely resorted to math or formal algorithmic techniques, either.
A lot of the industry talk on modeling strikes me in the same way as the religious talk on sin: intended to make people feel guilty so that they'll toe the line (and line up to buy tool support). So I tended to feel at home in the Agile camp where such forms of modeling are not regarded as a mandatory ritual.
What made me sit up recently was reading Jean-Louis Le Moigne's book on general systems theory, "Théorie du Système Général", the subtitle of which is "Théorie de la modélisation", a theory of modeling. I've been immersed in Jerry Weinberg's books for some time, both the ones explicitly about the systems perspective and the ones which merely take their inspiration from that perspective. And I had previously read Senge's "Fifth discipline", which stresses the importance of mental models. But Le Moigne's exposition is finally making something click as to the connection between models in the most general sense, and what goes on in software development efforts.
I suspect that what we call "development" today consists not so much of programming, but of modeling; not "modeling" in the sense of drawing boxes and arrows in the Uncouth Modeling Language, but more broadly "the act of designing mental structures which aid our dealings with reality, in the context of specific purposes having to do with smaller parts of that reality". Information systems are models of what goes on in a business, software products are models of this or that human activity, etc.
Nowadays, of course, a lot of software is models for dealing with all the software we've surrounded ourselves with. Development tools, languages, lifecycles, etc. embody models of the development activity.
The main problem with our understanding of "modeling" is losing track of the "specific purposes" part of my definition above. Models are not true or accurate in the absolute, only relative to some purpose - generally to some *person's* purposes. The nasty undercurrent in UML advocacy is the suggestion that it's possible, and worthwhile, to shoot for "the one true" model of something. This also leads to the notion that UML itself is "the one true" way to design models - supported by various assertions such as that visual models are better because more abstract, or even: better because visual.
Another area of puzzlement is why all the approaches to "modeling in the context of building software" assume that what is to be modeled is the system as built, finished and seen from a detached and neutral point of view. No one ever seems to discuss building a genetic model linking the system to be built to its ancestor systems, or a developmental model taking into account various "iterations" of growth of the system or stepwise deployment (*), or in general any number of classes of models which it would make sense to use. There are exceptions - Alan Cooper's approach of interaction design consists essentially of modeling users, for instance.
Also, if all "programming" or "development" activity consists of modeling in that sense, then the most generally useful of all models are our models of how we design models - our self-models. These receive scant to nonexistant attention from the industry.
(*) I am finding echoes of this concern in Jim McGee's recent entry on "Learning caution": " I still believe that carefully designed and deployed technology is essential for organizations and societies that hope to survive. But that design has to factor in how human systems shape designed systems over time."
Previous Topic
