I was struck by this quote from a New Yorker article on Muzak:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/04/its-better-than-nothing.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/04/its-better-than-nothing.html
I 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.
Well, 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).
Not 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™ or silence. It’s a choice between Muzak and original music by the original artists.
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. 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.
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.
“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.
I think it applies; the choice isn’t really between Muzak™ 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).
Since I bought an iPod, I find Muzak even more annoying - it’s competing with my choices.
dude, you have to synchronize the transferfunds method, or you’re in for a world of hurt… 
I 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.
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.
I 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.
Oh, 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?”
I 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.
Only 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.
I 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?