programming and human factors
by Jeff Atwood
I was struck by this quote from a New Yorker article on Muzak:
"Our biggest competitor," a member of Muzak's marketing department told me, "is silence."
The problem with comparing something to nothing is that nothing is, well, nothing. James Bach elaborates:
I was watching Dr. Stuart Reid talk about model-based testing, some months ago. During the presentation, he complained that so few people used UML for model-making. Why don't more people use UML, he asked the audience?I suppose his question was rhetorical, but I couldn't help myself. I called out "Because it's clunky!"
"It's better than nothing," he replied.
Think about that. Think about that phrase. A comparison is offered between something and nothing. Who could prefer nothing? Nothing is a void. It's scary and black. It makes us think about death. Ick. But wait a minute, the comparison that matters is not between something and nothing, it's probably between something and some other thing.
As Bach points out, any comparsion that ends in "It's better than nothing" is an invalid one. There are always alternatives, whether the person speaking chooses to acknowledge them or not. Instead of UML, you could..
In my opinion, code is a perfectly reasonable place to model. That's why I was so encouraged by the fact that visual, two-way class modeling support was pushed down from Visual Studio Team Edition for Software Architects into almost all the editions of Visual Studio 2005 (Standard or better). It isn't formal UML, but it is a kinder, gentler modeling tool that a lot more people are likely to use.
| As code | As model | |
Do you mean some sort of two-way visualization of code into model?
Yes, exactly:
a href="http://blogs.vertigosoftware.com/teamsystem/archive/2006/04/06/2531.aspx"http://blogs.vertigosoftware.com/teamsystem/archive/2006/04/06/2531.aspx/a
Jeff Atwood on April 11, 2006 2:39 AMI took a course in UML and didn't really use it much until I got into some projects with larger groups. I'm currently working in a group developing a game and we're using ArgoUML http://argouml.tigris.org/ to create UML diagrams.
In reality, we're using UML as more as a communication/documentation tool than a planning tool. We planned out the basic class structure ahead of time, but we add the members and methods as needed just so everybody is on the same page.
Ian Muir on April 11, 2006 2:48 AMWell, I liked this a lot better without the Muzak vs. silence bit. In this context, silence is not nothing. (Maybe if he'd said "quiet" it would be clear that we mean more than the absence of intentional ambient noise).
orcmid on April 11, 2006 3:01 AMNot to miss the point of your article, but what the heck do those symbols in the diagram mean? Why is "blue cube" a member (right?) and "pink cube FLYING AT YOU!" a method?
I guess my point is that while I agree with what you wrote, Microsoft's continued horrible choice of visual elements makes this only slightly better than UML's backwards pointing arrows to me.
Well, I liked this a lot better without the Muzak vs. silence bit
I think it applies; the choice isn't really between Muzak(tm) or silence. It's a choice between Muzak and original music by the original artists.
Jeff Atwood on April 11, 2006 3:47 AMI think the problem with modeling code is the way it is taught. I remember getting the creeps from my study when teachers whom never coded or actually didn’t like to code was explaining me what UML was and how great it was, only to see that the diagrams they showed never would work well in practice. Of cause it didn’t help much with my geeky arrogance. But later on when you start to develop large and real applications you miss something, you draw a lot of diagrams and suddenly you realize you are drawing UML diagrams.
I wish that I have had more inspiring teachers, someone whom actually had professional experience with developing software using all parts of UML.
Most good developers I have met through my career are self-thought and when UML diagrams are used, it is more to sketch out overall class relations. But in most cases of my cases we just don’t have the time to do pretty diagrams or it seems like too much work, because “we already know how to do it *sigh*”. I actually failed pretty bad a job interview at Microsoft last year when talking about UML and design patterns, because I was simply too rusty. That happens when you use too much time hacking your own silly code instead of spending time learning how to design your applications… #61514;
The class designer of Visual Studio seems like a very nice approach, I have not used it so much yet, but I was wondering is it possible to extend it with some add-in? Would be nice if you could do some sort of snippets or templates with the class designer. How properties should look like etc.
I also came across this Class Designer Blog, though not updated very often.
http://blogs.msdn.com/classdesigner/
Heh, I just entered a comment on another blog which concluded with "it's better than nothing".... (in reference to cameras on mobile phones)
As for modelling in the code: Many years ago I tried to use Rational Rose with it's forward code generation feature. Despite the many shortcomings of Rose, the code generation seemed like a reasonable feature, conceptually at least. You model the classes as high-level constructs in UML, then click the go button and it generates the C++ code (ie stubs).
Unfortunately (or perhaps fortunately?) there are many ways to represent high level abstractions in C++, particularly when it comes to associations with 1 multiplicity. You can have an array of objects, an STL vector of auto_ptrs, etc etc.
What I found myself doing is spending more time trying to learn the intricacies of Rose to tell it how to map the high-level objects into C++ code than if I simply gave up and wrote it directly in C++.
To be clear, this wasn't (for once) a problem with Rose. It seemed to be a fundamental limitation of such modeling tools when coupled with gnarly implementation languages like C++.
Since that experience with Rose, I haven't had much hope for two-way code/model translation. From reading this summary of current ORM tools, it seems to (partially anyway) validate my view: http://www.kuro5hin.org/story/2006/3/11/1001/81803
You may want to design your domain model at 50,000 ft, but sooner or later the implementation technology will bring you plummeting back to earth.
Alastair on April 11, 2006 5:08 AM"I think the problem with modeling code is the way it is taught. I remember getting the creeps from my study when teachers whom never coded or actually didn’t like to code was explaining me what UML was and how great it was, only to see that the diagrams they showed never would work well in practice."
This was my exact experience in college. On occasion I've been known to whiteboard UML-like diagrams to explain a point, but the idea of a selling a tool to do just that for $2000 a seat always seemed ridiculous to me. .H files aren't THAT hard to read (or at least they shouldn't be).
"STL vector of auto_ptrs"
Containers of auto_ptrs (COAPs) don't work; you're not allowed to assign one auto_ptr to another, and containers assign their items all the time. You'll need to use something like boost::shared_ptr instead.
Alyosha on April 11, 2006 6:08 AMI think it applies; the choice isn't really between Muzak(tm) or silence. It's a choice between Muzak and original music by the original artists.
In elevators and supermarkets? I suppose that makes it a choice among four things (counting commercial radio), but I really don't have any Muzak at home.
I known there've been commercial free "closed-circuit" radio systems for putting music into public spaces, but I don't know how well-established that is if it even continues to exist. I suspect the fellow at Muzak knew exactly what the competition was.
No matter, more fun here about what conveys a model and when code is a model of interest (if ever).
orcmid on April 11, 2006 6:08 AMSince I bought an iPod, I find Muzak even more annoying - it's competing with my choices.
Paul Coddington on April 11, 2006 6:35 AMdude, you have to synchronize the transferfunds method, or you're in for a world of hurt.... :)
Tim Howland on April 11, 2006 9:29 AMI love this post. Comparison to nothing IS always invalid. However, in the case of UML, the point is moot, because UML is so clunky is is not even better than nothing.
Ole Eichhorn on April 11, 2006 11:10 AMGo analogue!!
http://www.disambiguity.com/2006/04/enjoying-analogue-wireframing-pencil-rules-ok-2/
Good post. The world is never black and white. But people trying to make an argument for or against something always try to distill it into an either/or choice which is NEVER valid. It's one of my many pet peeves.
matt on April 11, 2006 1:10 PMI agree with you, of course, but the first two comparisons for modelling not in UML aren't truely accurate. I think a lot of people model UML(lite) in their head, and the UML can certainly be used with sketches. It doesn't need Rose/Visio/Whatever to generate.
I think a lot of people use *parts* of the UML (class diagrams, ... OK, that's about it), but using the full UML is too labour intensive. Class diagrams and some sort of mutual team shorthand are the more frequently used alternatives from what I've seen. For all their nonstandardization (or perhaps because of), people find them more useful.
Kent Sharkey on April 11, 2006 1:37 PMOh, I forgot to add: I'm not entirely sure what you mean by "code is a perfectly reasonable place to model". The VS class designer isn't (IMO) code, but model. Do you mean some sort of two-way visualization of code into model? If that's the case, I agree with you, if you mean modelling using C# or VB (or whatever) syntax, I gotta say, "Hunh?"
Kent Sharkey on April 11, 2006 1:41 PMI think UML is a tool, but it ones of those specialized, expensive tools that sit in the toolbox for long periods of times between jobs.
Flowcharts, schemas, and other types of diagramming/modelling are the wrenches of design: they get used in every oil change, tune-up, and engine rebuild. UML is like the engine hoist: it's an extremely important tool for an extremely hard job. You don't need to break out the engine hoist for an oil change, but you couldn't take out/put back an engine with just a wrench.
boohiss on April 11, 2006 1:47 PMOnly working on small projects, I've not had a great need for UML style diagrams to plan. And I've found it difficult to design my code in the Class Designer as I like to get a bit more personal with the code. However, I have found the results of the Class Designer invaluable in explaining my code to others. Firstly it provides a quicker visual overview, and then I can elaborate further without having to walk my way through the masses of code. This also means it's language indipendant, and I can explain things to my Java loving teacher without him having to try and filter out the code to get an idea of what the classes, properties and functions are.
[ICR] on April 12, 2006 3:43 AMI don't mean to be rude here, but I think you missed an important point. The entire IT industry is literally competing, as well as each other, with nothing.
For example, the competition between, say, a VOIP product and 'nothing' is a question of whether it is cheaper to outlay money on building an IT-based solution and walking over to the person with whom you wish to communicate and talking to them face to face.
The competition between a dozen electronic database systems must also take place in the presence of a background competition - buying a larger filing cabinet.
There is, to some extent, a failure to recognise that not every problem really needs a solution, in the sense that we tend to think of it. Y'all must surely understand what Mazlow said about hammers and nails, right?
"In my opinion, code is a perfectly reasonable place to model."
If using a relatively high level language, I would go further and say its the _best_ place to model. Your example is telling. Why is the pretty picture with gradient shading, rounded corners, drop shadows and a little show/hide gizmo better then the actual source? Does it tell me more? No. Does it simplify the problem? Not really. If I collapse the implementation sections of each method, I arrive at two views that are quite similar. I also don't understand the relation between Account and InsufficientFundsException in the model view while its clear in the code view.
I think the code will always be more flexible, more current, more portable, i.e. more useful. How many people really find it better to design their classes in a modeling tool, then emit code stubs and work from there? And if you are going the other way - from code to a model - why?
Here's my first iteration of the model for your example in C# (or C++ or Java):
// Account
// Balance
// MinimumBalance
...
And here it is in Python (or Perl or bash):
# Account
# Balance
# MinimumBalance
...
(you get the point)
I just think its one of these ideas from academia that never really solved a problem (except maybe filling contractual requirements) that some people just don't want to let die.
Show me the UML diagrams for any visible software project? Linux? Apache? Perl? Mono? In my days at Microsoft, I don't recall ever seeing any. (They probably existed on some projects but I never saw them used as the points of discussion between engineers on the team).
Back on topic, I agree that comparing something to nothing is pointless so I don't know how to answer.
What I want to know is why doesn't the Withdraw method throw an InsufficientFundsException? It should be there - not in TransferFunds. Wouldn't catch _that_ in the model, eh?
David Avraamides on April 12, 2006 8:13 AM"I think it applies; the choice isn't really between Muzak(tm) or silence. It's a choice between Muzak and original music by the original artists." - Jeff Atwood
Jeff, Muzak only plays original music by original artists - they've been doing that for the past 25 years.
Karen on April 12, 2006 10:06 AMHi Karen,
Prior to posting this, I went to the Musak site to check out music samples, but I couldn't find any. Various Google searches also turned up nothing.
I assumed that Musak (admittedly, based on the little I've heard) was re-recordings of songs, eg, a cheesy pop synth instrumental version of the Beatles' "Yesterday".
Jeff Atwood on April 12, 2006 10:36 AM"I also don't understand the relation between Account and InsufficientFundsException in the model view while its clear in the code view."
It is possible to get more of an understanding by customising the diagram to show the relationship. But yes, the exact nature is hard to grasp.
The only real benifit I can see is as I outlined above, to aid in explaining in a non-language specific manner, or to provide a non-cluttered overview to review your code.
I am Blamzo Gorb, the Assistant Grand Vice Snarzle from the planet Muzak 11. These primitive discussions concerning “Muzak” are to little avail. Our subliminal project has been functional for many of your planetary cycles and your criticisms and attempts to analyze it are pointless. You see, part of the program embeds a switch that will soon trigger your mind’s memory center to wipe out any thoughts about “Muzak.” Then it is just a simple matter of relaying certain commands to clear away any posted evidence of your findings. Do not try to fight the mind wipe, Earth-Monkeys!! Resisting our program will only make you irritable and self-conscious! Now, just relax as the soothing sounds of yet another Phil Collins tune slowly, gently slip into your brain. Ahahahahahaha……
Blamzo on April 13, 2006 2:37 AMrandom trivia of the day:
I have a photo of Dana (featured in the Muzak article) on my cameraphone, taken during Sunday brunch a couple weeks ago.
The comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |