![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
piggymouseAlistair Cockburn has been recently interviewed by ITConversations.com. The interview is available here as both audio recording and a transcript. Most of the conversation, unsurprisingly, rotates around themes from the seminal "Agile Software Development" book and the Agile Manifesto stuff. Alistair's soon-to-be-published book on Crystal methodology also gets some airtime. Alistair is as sharp as ever and gives a nice overview of the whole agile philosophy for those of use who doesn't yet have enough of it.
My personal favorite in the interview is Alistair's explanation of Agile Manifesto basics. I love the following paragraph most (emphasis added):
Second one: “Working software over comprehensive documentation.” It's a pretty obvious reference to ISO 9000 and the software engineering institute, the CMM levels where you see massive amounts of documentation being required. And while there's value in documentation — and I talk about that especially in the cooperative game theory — the punch line is, software has got this ruthless honesty to it. And you could have the nicest looking document in the world, and someone once said, “Bubbles don't break,”
the bubble-and-arrow diagram, so they all look good, but you can't debug them. They don't execute, so they don't break. So we keep coming back to, “Show me the software, show me the software! Does it run? Show it to me!”
In my opinion, the inability to debug any type of documentation presents one of the biggest challenges for the involved project roles. Moreover, the very impossibility to execute a document or a diagram, as compared to a piece of code, is actually a demotivating factor for their authors and, in my opinion, one of the main reasons why documentation activities are disliked and neglected.
One can recall the early days of software development when batch processing and limited CPU availability required programmers to read their code a few times before submitting the job for processing. I vividly remember doing this myself, although I was born too late and wasn't around during the golden days of mainframe technology. One skill that those code readings really sharpened was the ability to execute code in your mind, spotting bugs, bottlenecks, or other problems. Of course, it was (and is) never possible to catch all problems this way. Nevertheless, such practice definitely makes you a very competent and efficient code reviewer.
I'm often asking myself, if the same ability could be cultivated and applied to documents and diagrams. We can't literally "execute" a UML diagram, much less a requirement specification or, say, a CMMI process area definition, because, as Steve Mellor pointed out, they all lack strict action semantics. However, I'm pretty sure that the same skills that a good code reviewer possess – namely, the ability to evaluate a complex
As a next step in these reflections, we might assume that, once this ability is in place, the exercise of "
The weak spot of it all is that I personally do not know any systematic way, besides a continuous practicing, to actually cultivate the discussed ability. Maybe, some fellow psychologists may help us all with that – at least, by pointing to some research of human
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2005-07-21 01:45 pm (UTC)They all have _different_ semantics, tailored for the purpose of partucular type of the diagram. Collaboration, sequence and activity diagrams has action semantics _intentionally_. They express different aspects of action semantics _better_ than code itself. It's their only reason for existence.
Code is one way to view at the program. UML adds ten more views. More views is good. VS.NET even adds more views to the code itself (collapse all, regions). Mainframe way of thinking is so dead that I can't believe somebody brings it up in a serious article.
no subject
Date: 2005-07-21 03:05 pm (UTC)They all have different semantics, tailored for the purpose of particular type of the diagram.
Agreed, but please note that I was talking about action, or executable semantics, in the sense used by Steve Mellor in his "Executable UML" book and his numerous articles on the subject.
Basically, the idea here is that UML as defined in the OMG specs is too broad to be interpreted unambiguously. You can very easily draw state or activity diagram in UML that will correspond to a whole class of programs for any "traditional" (say, von Neumann) computer. The one program you actually try to model will only be one from that class. And the UML is so ambiguous, you can not make any interesting statements about programs from that class. This is not a problem when you use UML as just a convenient and ubiquitous notation for your whiteboard art. However, pure UML is in no way suitable for more advanced uses, such as code generation, MDA, and so on. In order to support this, UML metamodel has to be both extended (to include a complete enough subset of von Neumann or computationally equivalent language) and restricted (to remove intrinsic ambiguities and complexities of the full-scale UML).
Note that I don't discuss here if using UML for code generation etc. is a good idea at all. It's a completely different story and personally I prefer to stick to the "UML as whiteboard notation" camp.
Mainframe way of thinking is so dead that I can't believe somebody brings it up in a serious article.
I'll respond with two points.
Firstly, ideas and concepts from the mainframe era are not dead at all. If you have time and courage, try to flip through the pages of NATO Software Engineering Conference reports from late 1960s. Some themes and issues really seem to be eternal, as the industry continuously fails to learn anything from its own mistakes.
Secondly, there was nothing specifically "mainframe-ish" in what I was talking about. Strictly speaking, my first computers where I practiced my "personal code readings" were not mainframes (it was actually some obscure "Iskra" model, dull, but a perfectly "personal" computer, and CM-2M, which was officially classified as a "minicomputer"). Healthy development includes some form of code review regardless of the specific platform or technology. My idea is that the skills necessary for a code review in its traditional sense (that is, a quality assurance related activity) might be applicable outside of its borders.
no subject
Date: 2005-07-21 03:41 pm (UTC)but it IS used for code generation. what is MDA?
code review is another thing. if you need CODE REVIEW, you have to REVIEW THE CODE, it is just butterish butter (how is it in english?)
but during design, the less you think in mainframe aka procedural programming paradigm, the better. it's just my opinion, of course.
we are having another paradigm shift now, from OOA to SOA, so it is quite amazing to see that some people have not quite grasped even OOA paradigm yet.
this is just coming from my experience as application architect. hardcore signal processing people would most probably not agree with me. but they don't use UML anyway... what do they use, I wonder? are they up to structural programming paradigm yet? :-)
no subject
Date: 2005-07-21 03:42 pm (UTC)no subject
Date: 2005-07-21 04:09 pm (UTC)I'll answer this in several comments, one per point. :)
hardcore signal processing people would most probably not agree with me. but they don't use UML anyway… what do they use, I wonder?
AFAIK, the hardcore embedded/DSP/network developers still stick to SDL. This is a well-defined, computationally complete language used to design complex state machines, the kind you typically find at the heart of any sufficiently sophisticated piece of specialized HW/SW. It was standardized by ITU-T (recommendation number is Z.100), which makes it all the more attractive to the telecom crowd.
An interesting rival methodology (unfortunately, long dead and forgotten by now), was the Shlaer-Mellor method. This was an early predecessor of the modern MDA and, in my opinion, a superior one. Like UML, it defined a set of diagram notations, which were used to create what MDA calls PIM for a system. Orthogonally to that, other people created an analog of PSM, which was called "model translator", if memory serves. The whole approach was clean and simple. As the PIM notation was firmly centered around state diagrams, the methodology was quite popular among telecom people. Then, at some point in late-1990s, Sally Shlaer died and Steve Mellor switched his focus to the executable UML stuff, realizing he wouldn't be able to compete with the three fucking amigos.
no subject
Date: 2005-07-21 04:17 pm (UTC)no subject
Date: 2005-07-21 04:33 pm (UTC)no subject
Date: 2005-07-21 04:35 pm (UTC)btw, I liked Jakobson's notation better than Booch's.
no subject
Date: 2005-07-21 04:46 pm (UTC)no subject
Date: 2005-07-21 04:52 pm (UTC)Карл Маркс и Фридрих Энгельс
no subject
Date: 2005-07-21 04:17 pm (UTC)the less you think in mainframe aka structured programming paradigm
we are having another paradigm shift now, from OOA to SOA, so it is quite amazing to see that some people have not quite grasped even OOA paradigm yet.
Let me repeat – nothing in my post was specifically related to neither mainframes, nor structuring programming, nor any specific program paradigm at all. Your code and your UML diagrams can use any paradigm (and for any worthy project, they typically use every paradigm at different levels). What remains constant is your brain's ability to evaluate the code and the diagrams without actually executing them on a real CPU. I was discussing possible applications of this ability, not the paradigms used to create the work products being analyzed.
Speaknig about paradigm shifts, the industry seems to have them annually. Why forget the AOP stuff, for instance?
no subject
Date: 2005-07-21 04:31 pm (UTC)And btw, "some people have not quite grasped" was not aimed at you at all.
Also, UML is completely within OOAD paradigm, it makes little sense outside of it.
AOP is a paradigm all right, it's just not a mainstream one [yet].
no subject
Date: 2005-07-21 04:44 pm (UTC)It is also possible to write object-oriented code in any language. Although, trying this with Fortran guarantees you a huge pain in the ass. I recall some early OO book which contained a sort of mapping from OO to a bunch of popular languages, including Fortran. And we shouldn't forget the famous Xt, Athena and other early X widget sets, which were really big OO libraries written in the plainest C imaginable.
When you look at a large modern system at different levels, starting from the bird's eye view and descending to the very lowest level the programmers can be concerned about, you usually move from SOA (top-level architecture with a coarse-grained API), through OO (internals of a logical component, or package, with a fine-grained API), right to the plain old procedural style (algorithms within individual methods). All the paradigms coexist peacefully, you just don't consider them together at the same time.
no subject
Date: 2005-07-21 04:50 pm (UTC)Sure, but on each level of design you use only particular paradigm. Mixing would be bad.
no subject
Date: 2005-07-21 04:58 pm (UTC)no subject
Date: 2005-07-21 05:02 pm (UTC)no subject
Date: 2005-07-21 05:03 pm (UTC)no subject
Date: 2005-07-21 05:07 pm (UTC)no subject
Date: 2005-07-21 04:36 pm (UTC)but it IS used for code generation. what is MDA?
All code generation from UML I have ever seen is based on vendor-specific extensions. I'm not familiar with UML 2.0 yet, but all previous versions explicitly marked some crucial aspects as "implementation-specific" or "optional".
Let me give you a simple example. Here's how a Procedure is defined in UML 1.5 metamodel:
I won't bother you with long quotes from the specification, but you will sure believe me that the specification doesn't include any definition of what the "language" is or contains any mappings from UML to potential target programming languages (like, for instance, CORBA standard does). This is left to tool vendors, which are free to implement support for Java, C++, C#, and whatnot.
Theoretically, it is possible to define a, say, UML-to-Java mapping and fill the gaps in UML metamodel, so that code generation shall be possible. This is what tool vendors actually do. However, UML standard doesn't provide us (them) any help in this regard.
MDA is such a messy stuff I hate to discuss it. Here's the URL.
no subject
Date: 2005-07-21 04:46 pm (UTC)no subject
Date: 2005-07-21 04:48 pm (UTC)no subject
Date: 2005-07-21 04:55 pm (UTC)no subject
Date: 2005-07-21 05:00 pm (UTC)no subject
Date: 2005-07-21 05:05 pm (UTC)no subject
Date: 2005-07-21 04:49 pm (UTC)no subject
Date: 2005-07-21 05:00 pm (UTC)no subject
Date: 2005-07-21 05:02 pm (UTC)no subject
Date: 2005-07-21 03:27 pm (UTC)So it is not about problem-solving ability at all. It is about motivation. Does anyone remember how to make a cat eat mustard?:
no subject
Date: 2005-07-21 04:56 pm (UTC)Unlike (properly running) code, documents and diagrams normally do not stand between a person and his paycheck.
Oh yes, they do — albeit indirectly. For me, documents' main uses are knowledge dissemination and preservation. If these fundtions are inadequately implemented, the project may fail — hence, problems with paycheck (real ones).
So it is not about problem-solving ability at all. It is about motivation. Does anyone remember how to make a cat eat mustard?
The cat treatment you mention is definitely not the only way to motivate people (i.e. humans) and I'm not even really sure it's the most efficient one. My (somewhat Utopian) idea was that if it were easier for people to evaluate the documentation work products, it would make them more willing to produce and maintain them. This was based on an old observation about the "liveness" of software as the single biggest attraction of the programming as a trade.
no subject
Date: 2005-07-22 01:41 pm (UTC)Of course there are other things in life: peer recognition, craftsman's pride, chocolate cake, paintball match, sunset over Pacific,
blowjob fromintelligent conversation with Uma Thurman, you name it.Still, people are lazy. The skill in question emerged out of necessity. And it promptly died as soon as people could afford loosing it. If there was way to complete projects without writing code, people would be doing that. Wait, some of them already are!
People definitely can afford not examining diagrams today. It might be true that diagrams are paycheck-critical(*) for you personally. But for everyone else a simple alternative to diagrams exists: NO diagrams. It is quicker, easier, and cheaper (in short- to mid-term).
And everybody (including yourself, perhaps?) knows, that somehow code-and-patch will work out.
This must be very discouraging.
So, back to my original point. It is all about self-motivation. About your personal equivalent of chocolate cake/Uma Thurman.
I am sure there must be a book titled like "How to be effective at performing mind-numbing tasks instead of doing something really exciting".
(*) "Paycheck-critical" would be good name for a new type of diagram. Something like robustness diagram, but with little $ signs attached here and there.