As you probably know if you’re keeping in touch with the software engineering research community, there has been plenty of research on conceptual modeling in recent years. Most of it focuses on the creation, refinement, and formalization of modeling languages (UML, for instance). But the question of how do software developers truly use diagrams and modeling languages, if at all, is often left unanswered –researchers tend to assume that “if you build it they will come”, and hence (as I’ve complained before) their proposals grow more and more disconnected from the real needs and habits of developers.
This is why fieldwork studies that give us insights into the software development process are so valuable: they help to reconnect the software academia and industry.
A particularly interesting empirical paper on diagramming was presented by Cherubini et al. [1] at the CHI conference this year. It reports how and why software developers at Microsoft use diagrams, and what graphical conventions do they use. From the abstract: “Results show that most of the diagrams had a transient nature because of the high cost of changing whiteboard sketches to electronic renderings. Diagrams that documented design decisions were often externalized in these temporary drawings and then subsequently lost.”
There are several juicy bits in this paper. Here are just some of them:
- A distinction between the use of models for understanding, for designing, and for communicating, andthe differences in formality and effort put into each of them.
- A breakdown of drawing media used when modeling (interestingly, diagrams are almost always drawn in whiteboards).
- Some thoughts into the lack of use of graphical standards (“It is clear that UML does not, in general, reach a sufficient cost-benefit ratio in the minds of developers to warrant its use.”) and the lack of synchronization between models and code (“Visualizations in documentation were often out-of-date and they were rarely used for the core of the development process.”)
- Reports on very subtle design ideas that are elegantly conveyed through diagrams, but that are a real challenge to formalize: “We decided to give it this butterfly shape to emphasize that the contract in the center shouldn’t change and should be small…”.
- A discussion on levels of abstraction allowed by current graphical notations: “…developers need to understand both the microscopic details of the code and the macroscopic conceptual structure. (…) No current [standardized] view conveys both levels of abstraction simultaneously.”
It’s worth a read, but unfortunately you need an ACM subscription to access it. I’m sure you can get a copy if you email the authors, though.
—
[1] Mauro Cherubini, Gina Venolia, Rob DeLine, and Andrew J. Ko, 2007. “Let’s Go to the Whiteboard: How and Why Software Developers Draw Code“. Proceedings of the SIGCHI conference on Human factors in computing systems (CHI 2007).
Categories: Academia · Conceptual Models · Information visualization · Software development · UML
During the past Winter/Spring term, I lectured a course on Software Engineering for the Electrical and Computer Engineering Department at the University of Toronto. Although I’d been a part-time high school teacher for more than three years, this was my first time lecturing at the undergrad level, which in my case meant that I wanted to try a lot of things. Though some worked, others fell flat. I want to share them with you here. It’s been about three and a half months since I handed in the final grades, which means it’s very late for a postmortem, but better late than never:
The Course
- Previous incarnations of the course reflected heavily the interests of their lecturers, and I was unhappy with some of the material available. I chose to borrow as much material as I could from other courses not usually available to ECE students (in Software Engineering, Software Architecture, and Requirements Engineering), mix it up, and fill in the gaps with some ideas of my own.
- In the end, you could divide the lecture side of the course in two sections. The first concerned with high level software engineering and project management issues (from discussing why do we even call this “software engineering”, to eliciting requirements and estimating effort). The second section was almost exclusively focused on architecture and design issues, and more specifically in design patterns.
- The assignments side of the course consisted mainly of two team activities. First, every team had to make a contribution to a relatively mature open source project. (This was modeled after a similar exercise by Daniel German, at the University of Victoria.) And second, following a similar course by Greg Wilson, every team had to compare the architectures of two similar open source projects.
- There were 25 students. For the first half of the course we didn’t use any textbook. For the second half we followed the Gang of Four’s Design Patterns book (perhaps too) closely.
The Good
- The two assignments clearly helped students find out how software architecture and development happens in the “real world”, and this was evident in their reports. Since the open source assignment required them to have a patch accepted by a mature project, they needed to explore, contact, and negotiate with established development communities. The other assignment –the architecture comparison– allowed them to study how different teams tackle similar architectural challenges.
- I made an effort not to fall in the trap of the standard software engineering textbooks, which often present as truth that which is at best questionable practice. I tried to be as candid as possible. For example, I complemented the lectures on software estimation techniques and software process methodologies with discussions on their limitations. I also tried to be practical –pointing out those practices that have been tried, tested, and easy to use: prototyping and simple requirements elicitation techniques, for instance. I think these efforts paid off.
The Bad
- The open source contribution assignment turned out producing some very weak contributions. This was my fault: I had the final say on whether a proposal was ambitious enough, and several were not. As a result, some teams had it way too easy.
- We covered every single design pattern in the GoF book. This was unnecessary and confusing. You don’t need to study all 5 creational patterns in one go, anything beyond Factory Method and Abstract Factory is superfluous in our context. Same goes for the other kinds of patterns. Each pattern ate about half an hour of our time –not enough to learn it, certainly not enough to master it.
- As a result, towards the end, the lectures were too dry and boring. There’s only so much excitement you can draw from the next two design patterns in the list.
- I got sidetracked telling anecdotes and horror stories, more than I’d like to admit. I’ve noticed this defect of mine before; I did almost nothing to correct it.
If I were to do it again…
- Both assignments were brilliant as ideas, but mediocre in their execution. The open source contribution assignment is gritty and useful, but the bar for acceptance needs to be raised significantly. The architectural comparison assignment needs to be based on projects with complex and elegant architectures, with supervision from a qualified TA, for students to really learn from the best.
- In lectures, I’d drop about 70% of the patterns from the GoF book, and focus on exploring in depth the few remaining, and in discovering their application in seemingly disconnected domains.
- I’d cut time on architecture and design, and add one or two lectures on testing and quality assurance.
- I’d bring a couple of guest lecturers from industry to talk about real-world software development practices and priorities.
If YOU are thinking of doing it…
- Know that a course like this will eat about 20-25 of your most productive hours, every week, for four months.
- Know that many engineers have problems with subjective marking.
- Try and contact your TA well in advance, so that he/she can help you coordinate the tutorials and lab sessions.
Hope this will end up helping someone.
Categories: Academia · Software development
