latest entries from
Piotr's R&D blog
I recently rescued a very insightful comment by Adrian Buehlmann to my original Morning After entry from the (generally effective, but in this case dreadfully inaccurate) comment spam filter. Adrian takes issue with Reef's fundamental principle of keeping diagrams in sync with code, and argues that Cadifra (the UML editor he's working on) is the right way to go. I think that Reef and Cadifra are complementary, and hope to convince the gentle reader that Adrian and I are mostly in violent agreement.
Let me first pull out some points that Adrian makes that I strongly agree with and that drive Reef's design.
The code is the design.
This is the point that Jack Reeves made back in 1992, and it's just as valid 13 years later.
Diagram editors must be very fast and easy to use.
This is critical, yet most of today's "model-based" diagrams fail the test as you are forced to edit an abstract underlying model "through" the diagram. These tools attempt to enforce strict consistency rules, and require that you cross your T's and dot your I's, severely impeding the workflow. Strictness has its place if the model must be interpreted by a machine, but...
Don't generate code from diagrams.
...the only reason to have machines interpret diagrams is to make them executable (or transform them into executable forms), and there's no good reason to do that. As Adrian says, if the code is too "dirty" to be the design, clean up your code (or improve the programming language!), don't try to escape the situation by making a higher-level model your primary artifact.
So where do we disagree? Adrian implicitly assumes that UML diagrams should only be used during development, as transient artifacts that augment a developer's working memory and help face-to-face communication. Once the ideas discovered through the diagrams are fixed in code, the diagrams are no longer useful. Given this assumption, synchronizing code with diagrams would be foolish, and all you want is computer-assisted diagram sketching, which Cadifra does very well (check it out!).
I believe, however, that UML diagrams are also useful to convey design information across time and space -- that is, for what is traditionally called documentation. Code by itself is not up to the task, since certain meaningful and important abstractions get lost or scattered beyond recognition when embedded in (current) programming languages. Furthermore, since this documentation will be used by people potentially far removed from the context of the initial development, it is critical that it be consistent with the underlying codebase. (That is, it should augment the design represented by the code and never contradict it.)
One could certainly argue that UML diagrams at this level are not useful documentation, and that the code (with comments) is sufficient. I think there are many indications that this is not true, but rather than argue about it I'm setting up an experiment to see whether some realistic maintenance tasks can be performed better given access to appropriate UML diagrams on top of the code. I'll report on the experiment's results here once it happens -- for now, we're still struggling with the ethics approval process.
In summary, I think Cadifra and Reef fill complementary niches in the UML tool pantheon. Cadifra is great for design sketching and discussion support, while Reef will prove invaluable for maintaining UML documentation for the long run. I think there's even potential for some synergy between the tools, but I'll address that some other day...
This is the most influential paper award presentation. Michael Jackson (from the panel) is rehashing some of the same points re: normal vs. radical design. From what I understood, normal design is based on experience and doesn't deviate too far from things that have been tried and are known to work. Radical design tries to build something new, based on theory or formal models. The best that should be expected of a radical design is that it not be completely broken, and provide the motivation for further design work. I guess that software engineering is doing mostly radical design so far, and Michael would like to see it move towards normal design. But is it possible that the nature of software precludes normal design a priori?
Pamela Zave is now talking about applying some of these principles to telecommunications. I didn't see the relationship to Michael's talk, it seemed to be about an architecture for composable telecom system features. I'm afraid I didn't quite follow, though.
The Evolution of Development at Microsoft
This talk flowed so well, I didn't want to be distracted with taking down details during the presentation. The basic premise was that Microsoft used to hack things up quickly because that's what the environment (other hackers) accepted; they just weren't bothered enough about bugs to make it worthwhile to invest into QA. The landscape has changed, and Microsoft now concentrates on quality a lot more. They are switching to agile practices, but each team (of 400+ total) chooses their own process. They do have common quality gates (e.g. testing coverage, coding standards, published specs, etc.) that all the groups have to pass through. The speaker encouraged people do "just do what makes sense": you need some rules to avoid chaos, but not so much as to stifle creativity and motivation. Mostly, it comes down to hiring good, ambitious people, and having them compete against each other.
Software Architecture in an Open Source World
Roy Fielding gave this talk, but while I admire the guy's work and his no-nonsense (if a little adiplomatic) attitude on mailing lists, the presentation was pretty bad. He spent most of his time talking about seemingly meaningless details of the various software systems he's been involved with. It's entirely possible that those details were meant to be examples of architectural principles, but if so he hid the relationship really well. Yawn.
What a contrast to Erich's talk... The speaker is apparently a marketing guy serving a warmed-over business presentation with generous servings of rethoric and argument by assertion ("you know it's true!"). His argument boils down to: naughty developers don't follow the architectural models handed down from on-high, so we must automate the transformation from model to code (...and fire the programmers?). To be able to automate anything, machines must be able to understand the models, so clearly purely visual diagrams that only communicate to humans are inadequate. (This reminds me of the Web vs. Semantic Web debate: the web is only human-readable, while the semantic web makes all that information computer-understandable. Now, which one is wildly successful and which one can't seem to take off even with Tim Berner Lee's personal backing? One guess only!)
The speaker has finally gotten around to talking about MDA proper. It's the usual PIM to PSM to code flow chart, but at least he freely admits that the PSM will need lots of hand-tweaking to actually work. But then he goes right back and claims platform-independence, longevity, filling in pattern templates, etc. Blah. Interestingly, a guy from Motorola stood up and claimed that they're doing MDA successfully, precisely as presented. Gotta look into this to figure out what kinds of applications it's appropriate for.
This speaker promises to explain how his organization migrated from a plan-driven (waterfall) development process to an agile one. He starts out by defining plan-driven and agile processes, including a good analogy: plan driven is like building a bridge, agile is like exploring where and how to cross a river. The difference can also be characterized by the tradeoff between YAGNI and DOGBITE: You Ain't Gonna Need It vs. Do it Or you'll Get Bitten In The End.
There follow lots of details about how to convince stakeholders to accept an agile process, and how to set up the process to have the best chance of success. I won't bother scribing all this stuff; if the slides aren't posted eventually on the ICSE site, you can probably get most of the same information from books.
- The strongest motivator by far to switch to agile development is failure in previous projects.
- Expect resistance from Software Engineering Process Groups (in large organizations). (A solution: rotate staffing of SEPG.)
- The traditional procurement approach -- write requirements specs, invite for tender, select cheapest offer -- does not work for agile development. (Anecdote: WTO contracts prohibit requirement writers from bidding on the project, and limit with bidders!)
- Completely discarding change request processes would be like throwing out the baby with the bath water. (Suggesting to have a lightweight feature request process to avoid duplication and repetition.)