File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Am I missing the point of UML tools? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Am I missing the point of UML tools?" Watch "Am I missing the point of UML tools?" New topic
Author

Am I missing the point of UML tools?

Chris Johnston
Ranch Hand

Joined: Dec 13, 2004
Posts: 85
Hello,

I am trying to evaluate different UML modeling tools to see which one best fits my team's needs. Our requirements are fairly simple:
  • Some form of cross diagram communication. By this I mean that I should be able to create a new class in a sequence diagram and have it available throughout the rest of the project and I should be able to create new methods/operations in a sequence diagram and have them automatically show up in the class and in any class diagrams that contain the affected class.
  • It should make either full round-trip engineering or at least code import and code generation easy.
  • Should allow for, when importing code, the automatic generation of more than class diagrams. Should be able to select a method and have the tool generate a sequence diagram
  • Should integrate into Eclipse (as that seems to be the IDE we are standardizing on)


  • To me, these requirements seems fairly obvious. However, almost every tool that I try fails on the first one and fails on either the second or the third item. The vast majority of the tools that I have tried do not support (in some form) creating new classes or methods within a sequence diagram. You can create a method call in a sequence diagram, but all you are doing is giving it a name. Without the ability to actually create the method and have it appear as part of the respective class these tools seem pretty much useless. All they are are drawing or design tools.

    Here is a short list of tools that I have examined:
  • Borland Together Designer 2005
  • Borland Together for Eclipse 7.0
  • Borland Together Design Community Edition
  • Magic Draw 9.0
  • Visual Paradigm for UML Professional
  • Visual Paradigm for UML SDE for Eclipse
  • Enterprise Architect
  • Poseidon for UML CE and Professional Edition
  • And 1 more that I can not remember the name of


  • I guess my real question is: Am I expecting too much of these tools? Am I missing the way that they are suppose to be used? Is a sequence diagram not suppose to be used to help discover classes and class methods?
    [ January 04, 2005: Message edited by: Chris Johnston ]

    www.fuzzylizard.com
    Jef Cumps
    cowbird
    Ranch Hand

    Joined: Nov 14, 2001
    Posts: 53
    maybe try enterprise architect. Not sure it meets all your needs, but I guess it covers the first en second. Don't know about EA and Eclipse.
    kri shan
    Ranch Hand

    Joined: Apr 08, 2004
    Posts: 1382
    Try Eclipse plugin EclipseUML.
    Chris Johnston
    Ranch Hand

    Joined: Dec 13, 2004
    Posts: 85
    Thanks for the replies.

    I have tried Enterprise Architect and it actually functions the best of any programs I have tried so far. It is one of the few that passes my first requirement. It is not the most intuitive program to use, but at least it makes sense.

    As for EclipseUML, I tried the free version and it failed requirement #1. However, I will take a second look at it.

    Although the integration with Eclipse is a requirement, so far, I have been less then impressed with UML programs that do integrate with it. None of these programs seemed to function in any manner that makes sense. Things you can do easily in Together Designer you can not do in Together for Eclipse. So far, all UML programs that integrate with Eclipse seemed to work not as design programs but as documentation programs. By this I mean that as long as you have code, they work great at creating class diagrams. But if you want to use the programs to create code and discover classes and methods, they don't work.

    Does anyone actually use these tools for proper round-trip engineering or code creation? Or do people generally only use UML tools for drawing pretty pictures?
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Chris Johnston:
    I guess my real question is: Am I expecting too much of these tools? Am I missing the way that they are suppose to be used? Is a sequence diagram not suppose to be used to help discover classes and class methods?


    Well, not sure about the specific tools you tried, but there are certainly different ways to use UML: http://martinfowler.com/bliki/UmlMode.html

    I mostly use UML As Sketch, by the way, so most of the programs you tried are already much to heavyweight (and constraining) for me...


    The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
    Chris Johnston
    Ranch Hand

    Joined: Dec 13, 2004
    Posts: 85
    Originally posted by Ilja Preuss:

    I mostly use UML As Sketch, by the way, so most of the programs you tried are already much to heavyweight (and constraining) for me...


    But why would you want to go to all the trouble of creating a diagram that communicates your design and then have to recreate all of that in code? I can understand the need to sketch out one aspect of existing code, but does it not make more sense to use a tool that can automate this process for you? In addition, if you are designing a part of a system, does it not make sense to use a tool, that once the design is done can create the code for you?

    I guess I don't fully understand the point of UML as Sketch, I tend to see UML more in the UML as Blueprint way.
    Mark Spritzler
    ranger
    Sheriff

    Joined: Feb 05, 2001
    Posts: 17260
        
        6

    Well we did a whole study on UML Tools for our work, and we tested

    Together
    Visual Paradigm
    Rational Rose, the new RSA which is in Beta and runs on the Eclipse framework.

    Our final decision was sticking with Together. It does round trip. If I create a method in a sequence diagram, it automatically includes it in the class diagram and also in the actual code. We also need to create Documentation and Together allows us to do that.

    RSA came pretty close, but it is too UML 2.0 centric. Meaning we still use UML 1.4 and we could not create 1.4 diagrams in RSA, and the learning curve was large.

    VP, didn't even come close. But I like it the best for simple drawing only, no round trip or such.

    Good Luck.

    Mark


    Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
    How to Ask Questions the Smart Way FAQ
    Jeff Langr
    author
    Ranch Hand

    Joined: May 14, 2003
    Posts: 762
    Originally posted by Chris Johnston:
    But why would you want to go to all the trouble of creating a diagram that communicates your design and then have to recreate all of that in code? I can understand the need to sketch out one aspect of existing code, but does it not make more sense to use a tool that can automate this process for you? In addition, if you are designing a part of a system, does it not make sense to use a tool, that once the design is done can create the code for you?

    I guess I don't fully understand the point of UML as Sketch, I tend to see UML more in the UML as Blueprint way.


    The UML sketches we do at a whiteboard are part of team collaboration. These sketches help us determine only significant information: what are the abstractions, where are the dependencies, what are some of the significant methods, etc. The sketches don't include information on non-public methods, attributes, every method parameter, etc. These models take only a few minutes to put together, so it's not "all that [much] trouble." For this purpose, the whiteboard is far more effective than using an LCD projector and tediously manipulating a diagram in a tool.

    The main goal of these UML sketches is to think through a problem and offer some possible approaches for a solution.

    These sketches are rarely accurate with respect to the final solution. We find that these diagrams are usually a good starting point. But almost always, we find that the need to code for testability creates an improved design. Restated: we often find that the only way to demonstrate the value of a proposed design is to actually realize it in code.

    As such, we are coding when we discover concerns or problems with the original design proposal. Jumping back to a UML tool to diagram the improvement and then have it generate appropriate code into the existing code base doesn't seem effective to me, but that's one person's viewpoint.

    As far as the effort involved in recoding (i.e. translating from UML into, say, Java), that's negligible given the amount of detail and effort that went into the sketch.

    In short, the value of UML as sketch is in problem solving and quick communication of ideas, not about saving time by drawing a picture.

    UML as sketch makes a lot of sense to me, and UML as Programming Language makes some sense from an idealistic standpoint (but the language and tools are not there yet). But UML as Blueprint goes too far toward the flawed idea that you can produce a perfect design to throw over the wall.

    Your mileage may vary.

    -Jeff-


    Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
    Chris Johnston
    Ranch Hand

    Joined: Dec 13, 2004
    Posts: 85
    Originally posted by Jeff Langr:

    The main goal of these UML sketches is to think through a problem and offer some possible approaches for a solution.

    ...

    In short, the value of UML as sketch is in problem solving and quick communication of ideas, not about saving time by drawing a picture.

    UML as sketch makes a lot of sense to me, and UML as Programming Language makes some sense from an idealistic standpoint


    When you explain it like that, it makes a lot of sense to me as well. I was not thinking of UML in this way. When I think of UML, I think of it as a way to discover the entire design of a project and a way to work out all the major classes and methods in that solution. This is probably a rather utopian view of the abilities of UML.

    Originally posted by Jeff Langr:

    But UML as Blueprint goes too far toward the flawed idea that you can produce a perfect design to throw over the wall.


    Can you explain this a little bit more. Why is this idea "flawed"? I realize that design is iterative, however, should not the UML reflect the code in each iteration?

    I guess I think that if one is using UML to its fullest, you should be able to look at the UML and gain a full understanding of what the system is doing. Obviously you can not express individual method algorithms using UML, but you should be able to express the method calls between objects and this should communicate what the overall system does.

    However, as I said, this may be a rather naive and utopian view of UML. If it is, please let me know (I am a UML newbie trying to understand how it is actually used in the industry and how tools relate to that usage). So far, my understanding has definitely broadened. Thanks.
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    My experience very much matches that of Jeff, so I won't reiterate it.

    Originally posted by Chris Johnston:
    Can you explain this a little bit more. Why is this idea "flawed"? I realize that design is iterative, however, should not the UML reflect the code in each iteration?


    Well, before we actually coded it, it obviously can't. And after we coded (and adapted the designs to the needs we discovered by coding it), I typically don't see that much value in updating the diagrams.

    We once reverse engineered a class diagram from a part of the system we were working on and had troubles to fully understand. We then printed the diagram and pinned it on a wall in the team room.

    The experience of creating the diagram was enlightening. But now that they exist, noone seems to need to take a look at them any longer.

    I guess I think that if one is using UML to its fullest, you should be able to look at the UML and gain a full understanding of what the system is doing. Obviously you can not express individual method algorithms using UML, but you should be able to express the method calls between objects and this should communicate what the overall system does.


    But if I need that level of detail, I can at least equally well get it directly from the code, can't I?

    To me, the value of UML comes into play when it shows me *abstractions*, when it doesn't show *all* of the details, but only an overview, and those details that are interesting to my current task. I don't think that can be automated until we have AI that can totally replace the developers...
    Jeff Langr
    author
    Ranch Hand

    Joined: May 14, 2003
    Posts: 762
    Originally posted by Chris Johnston:
    Why is this idea "flawed"? I realize that design is iterative, however, should not the UML reflect the code in each iteration?

    I guess I think that if one is using UML to its fullest, you should be able to look at the UML and gain a full understanding of what the system is doing. Obviously you can not express individual method algorithms using UML, but you should be able to express the method calls between objects and this should communicate what the overall system does.

    However, as I said, this may be a rather naive and utopian view of UML. If it is, please let me know (I am a UML newbie trying to understand how it is actually used in the industry and how tools relate to that usage). So far, my understanding has definitely broadened. Thanks.


    Hi Chris and thanks for the response!

    I don't think your viewpoints are naive nor are they utopian. Many shops use UML in exactly this fashion. What Fowler points out with his categories is that there are different approaches for how you might use UML as a tool.

    What I was referring to as flawed is that you can ever do a single design for an entire system and have that hold up throughout complete implementation. You are absolutely correct, design is best viewed as iterative. And yes, you can update the UML to reflect code in each iteration. I was addressing more what I read as Fowler's definition of "UML as Blueprint," specifically its goal of being able to pass a design off from a designer/modeler to a coder.

    Ilja as usual makes some great points that I'll have to agree with. The idea of producing a UML snapshot per iteration--to reflect the actual system--is a fine one. The problem with using a tool to do this is that, as Ilja suggests, it usually hides the trees in the forest. It takes time to trim the resultant diagram to the essence of what we need to concentrate on. This usually ends up being more time than inspecting the code and producing a quick whiteboard sketch.

    Best regards,
    Jeff
    [ January 05, 2005: Message edited by: Jeff Langr ]
    Chris Johnston
    Ranch Hand

    Joined: Dec 13, 2004
    Posts: 85
    Thanks for all the replies and information, it is a big help.

    So even with UML diagrams there is a point were complexity will win out and a diagram, no matter how well laid out, will be too complex to interpret? This makes sense.

    What about the idea of creating code and refining diagrams in tandem? What I mean by this is you do a design and then you attempt to implement it. Obviously the implementation will not necessarily match the design. However, when you run into problems, before you can simply code up a solution, you have to go back to the UML and design out a solution. This way, both the code and the design are kept in sync with each other all the way through each iteration. Is this a realistic scenario? Or is this something that most developers/programmers would abandon very quickly?

    The shop where I work is in the process of converting from C and Perl to J2EE and we are trying to figure out where UML fits and how to best utilize it in the design and implementation processes. That is where all these questions are coming from.

    One idea that people have is to use the UML diagrams as the final authority for the system. Therefore, before any code can be implemented, fixed, changed, or refactored (not an exhastive list), the UML diagrams must first be consulted, updated, and approved.

    Is this level of detail something that can be reasonably implemented in people's opinions? I have the feeling that some people are mistaking UML for good communication and planning.

    Once again, thanks for the discussion.
    Jeff Langr
    author
    Ranch Hand

    Joined: May 14, 2003
    Posts: 762
    The idea you're suggesting--keeping code and models in synch--works for some shops. It's not terribly hard to manually keep a class diagram up to date as long as it doesn't show method level detail or attributes. But it can become onerous very quickly, particularly if you insist on more detail in the UML.

    So of course this is where the tools purport to help. I've tried a few of the big ones (Rose, XDE, Together), and to be honest, most of them annoyed the heck out of me. More trouble than they were worth. But some people swear by these tools.

    I've been in a lot of shops where they produced a really nice class diagram of a sizeable system and proudly displayed it outside a cube wall--several large sheets of paper taped together. I never saw anyone on these teams actively refer to it. But it looks good!

    Your last point is interesting. Indeed, UML is just a standard specification for a modeling language. How you use that language is up to your team members. The best thing to do at this point is figure out what your project values are and how your team wants to approach development on the project. Most shops that care much about having a process in the first place use either some form of RUP, some form of agile software development (Crystal, Scrum, XP), or a hand-grown waterfall-based approach. How you use UML during the project depends on what your metholodogy believes in. So perhaps learning about a specific methodology is a more appropriate place to start. The methodology should guide the use of UML, not the other way around.

    A good book that discusses how to approach using UML within a process is Fowler's book UML Distilled (disclaimer: I've not read the latest edition), which also teaches the rudiments of key UML diagrams. Its emphasis is more geared toward RUP, although I've been able to make good use of its ideas on agile projects. As an interesting contrast to his above-mentioned three categories of UML diagrams, in UML Distilled Fowler discusses the distinction between the level of detail in UML depending on the RUP phase that you're in (inception, elaboration, construction, transition).

    best regards,
    Jeff
    [ January 06, 2005: Message edited by: Jeff Langr ]
    Jeroen Wenting
    Ranch Hand

    Joined: Oct 12, 2000
    Posts: 5093
    In my experience most of the time when people start using UML (or other diagrams) they end up placing more importance to the tool and the diagrams than to the final product (the code).
    You seem to be doing much the same thing, valueing the tool over the usefulness of the results.

    A diagram should be used to aid in design, not to dictate it.
    In all places I've worked where diagrams (usually created with Rose...) were leading in the development process the resulting software was completely unmaintainable and extremely bloated (100MB source for a glorified address book with automailing functionality anyone?).

    On the other hand in places where diagrams were used to demonstrate concepts and document the existing code applications were usually better, smaller, and easier to maintain.


    42
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Chris, I'd advice you to take a look at http://www.agilemodeling.com/
    Chris Johnston
    Ranch Hand

    Joined: Dec 13, 2004
    Posts: 85
    So if I understand what people are saying, the only real way to truely discover classes, objects, patterns, etc is through the creation of code? UML can be used to abstract this process to a certain degree and communicate that abstraction, but in the end, the real method of discovery is through writing code. The real power in UML is learning how to do that abstraction -- what to show on a diagram and what to hide in order to communicate an idea or concept.

    So what about the idea of using UML to document the code? The classic argument that if a programmer gets hit by a bus and dies (not sure why it is always a bus) the rest of the team should be able to look at the UML and see exactly what that programmer was working. This is not my argument, but that I have to deal with as my shop discovers what process will work for them.

    This argument seems flawed to me from the start. This should be what proper documentation -- design documents, javadocs, etc -- are for and not the sole responsibility of UML. Would this be a fair observation?

    I am definitely going to have to read Fowler's book, thanks for the suggestion. I am also slowly reading my way through the Agile Modeling link provided, thanks.
    Jeff Langr
    author
    Ranch Hand

    Joined: May 14, 2003
    Posts: 762
    I wouldn't say that the only way to discover classes and methods and so on is through the creation of code. There is still some value to producing an initial design, using whatever mechanisms you think are helpful. Some people like to have a CRC design session. Other people like to detail requirements in use cases and use them as a basis for helping come up with candidate objects. Some people like to model complex flows or state using sequence or state diagrams. I don't have a problem with any of that--it still has some value.

    Just (a) don't set that design proposal in stone and (b) don't spend too much time on it. Again, it's a means of getting people moving in the same direction. As a metaphor, consider a cross-country drive. You can come up with a plan that takes you mostly on I-70 and a few other key highways. It'll take you 15 minutes to come up with this good-enough plan. When you hit the road, however, you'll discover the realities of construction, rush hour, detours, weather, and so on. You could attempt to plan for all these eventualities, and spend a lot of time putting such a plan together, but your plan would never be able to account for all contingencies.

    I'm not saying that past knowledge can't help, either. Given experience and feedback, you can hope to do a better job of coming up with an initial design each time you tackle a problem. You might even spend a few more minutes on things like method flow, since you've seen it all before. But I've been doing OO design for almost 15 years (and non-OO for a number of years prior to that) and there are still plenty of things that I do wrong in my up-front designs. I still invest some time in up-front discovery, but I just don't put as much faith in its ability to hold up.

    Now, to play devil's advocate: the agile movement, and XP specifically, suggests that you don't need to do as much up-front design. That's true, but in order to make that claim work, you have to (a) fully understand what bad and good design really is and (b) adhere to specific detailed practices that will allow the design of your system to stay clean. Things like code review (or pair programming), test-driven development, code refactoring, group code ownership, and so on all go toward keeping an optimal design in your system. If you don't keep the design of your system clean at all times, any form of incremental design and development will ultimately collapse.

    Of course, that's reality for up-front design as well. The problem with up-front design is that it can only take into account the details of the requirements at hand. Consider that most systems aren't done after the first delivery. New or changed requirements start creeping in almost immediately, sometimes the day after you think the requirements are frozen. Trying to hack requirements into a rigid design can quickly corrupt a multi-million dollar investment.

    Better that you spend your efforts in understanding how to keep a design clean, than in learning how to do a perfect design with no feedback.

    -Jeff-
    Jeff Langr
    author
    Ranch Hand

    Joined: May 14, 2003
    Posts: 762
    As far as using UML to document the code, there are lots of tools that can produce UML snapshots of the system, at any point in time. I have no problem with doing that, but I've found that it's usually far easier to sit and ask someone who knows something about the system. The same argument applies: what are you going to do with a comprehensive set of UML models against a 2000-class system?

    I would suggest documenting a few key things in the system and keeping these as core artifacts. Perhaps the core message flow through various layers, a state diagram that shows how something moves through the workflow, and so on. Then at each iteration finish, you might update the UML to see if/how the changes have altered these core parts of the system.

    -j-
    Chris Johnston
    Ranch Hand

    Joined: Dec 13, 2004
    Posts: 85
    Originally posted by Jeff Langr:
    I wouldn't say that the only way to discover classes and methods and so on is through the creation of code. There is still some value to producing an initial design, using whatever mechanisms you think are helpful. Some people like to have a CRC design session. Other people like to detail requirements in use cases and use them as a basis for helping come up with candidate objects. Some people like to model complex flows or state using sequence or state diagrams. I don't have a problem with any of that--it still has some value.


    I think what I was trying to say, albeit, very poorly, was that UML and design can only take you so far and in the end, the only way to truely understand the problem and discover the solution is through code. As you say, you can plan for a trip, but the only way to fully understand the trip is to take it.

    I find that to be an interesting insight and it means I need to do a lot more coding!

    And yet, without first planning for the trip, you make the execution that much more difficult. In fact, if you do not do some planning, the only way to actually go on the trip is if you fully understand the trip to begin with, i.e., if you have done it before.

    Originally posted by Jeff Langr:

    If you don't keep the design of your system clean at all times, any form of incremental design and development will ultimately collapse.


    The idea of keeping a system and a design clean is an interesting one. Actually, it seems rather self-evident, but there may be something more to this than what appears on the surface. Can you elaborate more on what you mean by this and what would make for a clean design and system?
    Stan James
    (instanceof Sidekick)
    Ranch Hand

    Joined: Jan 29, 2003
    Posts: 8791
    One thing I found in trying to do elaborate Rose models is that you can model forever. You go home thinking you've got a really good design then come in the next morning and see ways to improve it. That never ends, and it does not deliver software. One of the agile movement's core discoveries is that it's often more efficient to put an early, rough design into code and refine that. You'll discover more problems and more solutions more quickly than by modeling because you have your fingers right down in the code. Plus you have a running product way sooner. It takes top notch skills, merciless refactoring, excellent tests and most of the other agile practices to make that really work.


    A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Chris Johnston:
    I think what I was trying to say, albeit, very poorly, was that UML and design can only take you so far and in the end, the only way to truely understand the problem and discover the solution is through code. As you say, you can plan for a trip, but the only way to fully understand the trip is to take it.


    Yes. With other words, the only way to really assess wether your design is a good one is to code it.

    I find that to be an interesting insight and it means I need to do a lot more coding!


    And yet, without first planning for the trip, you make the execution that much more difficult. In fact, if you do not do some planning, the only way to actually go on the trip is if you fully understand the trip to begin with, i.e., if you have done it before.


    I disagree. Another way to do it is to be very responsive to your current situation - to be able to "read the landscape" and decide what to do next "just in time" based on your current findings. Actually that's the only way to do it if you travel into unknown waters...

    The idea of keeping a system and a design clean is an interesting one. Actually, it seems rather self-evident, but there may be something more to this than what appears on the surface.


    Actually is quite conflicting to another truism: Never touch a running system.

    Can you elaborate more on what you mean by this and what would make for a clean design and system?


    Agile methods, and probably most vocally Extreme Programming, require that you "Refactor mercilessly", that is, every time you see a way to improve the design of the system, you are required to do it. You think the name of a class could be improved - rename it. You see a way to remove duplication by introducing another class - introduce it.

    That only works with reasonable risk if you can verify that the system still is working as expected after each change on a button press. That is, you need an extensive automated test suite.

    Extreme Programming even has a definition for Simple Design. A Simple Design (in priority order):

    1. Runs all the tests (which also means that there *are* tests, which requires the system to be reasonably decoupled)
    2. Communicates intents/expresses the developers ideas (preferably without using comments)
    3. Doesn't contain duplication (neither obviously duplicated code, nor subtly duplicated logic)
    4. Contains the minimal number of classes and methods (doesn't contain any unnecessary code.
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Jeff Langr:
    I'm not saying that past knowledge can't help, either. Given experience and feedback, you can hope to do a better job of coming up with an initial design each time you tackle a problem. You might even spend a few more minutes on things like method flow, since you've seen it all before.


    The opposite can be true, too: the experience can give me confidence that I can do it with much less planning - now that I do know how to effectively read the traffic signs and what to do in the case of a traffic jam.


    Of course, that's reality for up-front design as well.


    To me, it's even *more* important with up-front design, because it can't take into account the learning that will take place while coding the design!

    See http://www.coderanch.com/t/130263/Agile/Simple-Design-sufficient for an earlier experience report from me...
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Chris Johnston:
    The classic argument that if a programmer gets hit by a bus and dies (not sure why it is always a bus) the rest of the team should be able to look at the UML and see exactly what that programmer was working.


    In the version I know, it's a truck. I also heard people suggest to use a lotto prize instead, because it's more political correct (no developer got hurt in this metapher). Actually the problems can already arise during a simple vacation.

    The problem with UML is that it typically isn't very good at catching the most important information: what was the developer thinking when deciding about the design? *Why* did he do it that way, what forces drove him?

    The most effective practice for dispersing this knowledge I know of is Pair Programming.

    I've also heard of teams video taping (and indexing) design discussions on the white board, but never tried it. Sounds interesting, though.
    Jeff Langr
    author
    Ranch Hand

    Joined: May 14, 2003
    Posts: 762
    Great points Ilja. I do almost zero up-front design anymore, at least on paper. It's either all in my head or emerges via TDD.

    -j-
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Jeff Langr:
    Great points Ilja. I do almost zero up-front design anymore, at least on paper. It's either all in my head or emerges via TDD.


    Ditto. I find that I do a *little* bit more up-front design in a team, though, because of several reasons:

    - I at least need to agree with my pairing partner on what class to write tests for.
    - I need to estimate the costs of a feature for planning. Often this involves thinking about how it will roughly get implemented ("When we introduce an Abstract Factory for the Booze, implementing the Do A Tuliwoop feature will be a breeze.").
    - I like to discuss things with my coworkers. It's probably a personal misconduct, but I enjoy it too much to abandon it...
    Jeroen Wenting
    Ranch Hand

    Joined: Oct 12, 2000
    Posts: 5093
    Originally posted by Ilja Preuss:


    In the version I know, it's a truck. I also heard people suggest to use a lotto prize instead, because it's more political correct (no developer got hurt in this metapher). Actually the problems can already arise during a simple vacation.


    And it can indeed happen.
    Mid 2003 the main architect (who also a big wrote part of our lowlevel code) died suddenly.
    He was in the habit of not documenting anything (a major problem in this company I'm slowly chipping away at and management is now finally starting to see it as a problem as well as several other core people are retiring in a few years and noone else knows what half the code even does) and as he was rather brilliant and used obscure code constructs with nonsensical variable and method names noone else understands what he coded very well and are therefore afraid to touch his code).

    In his case I doubt forcing him to use a design method would have done much. Him being the core player in the development team AND on the management team AND part owner of the company he could get away with whatever he wanted anyway.

    In fact I've serious doubts as to whether forcing a tool or methodology on people ever does much more than move the problem elsewhere while making them unhappy.
    forcing techies into a mold only breeds rebellion, causing the good ones to leave so only the ones who have nowhere else to go stay behind, which hurts your product.

    Originally posted by Ilja Preuss:


    The problem with UML is that it typically isn't very good at catching the most important information: what was the developer thinking when deciding about the design? *Why* did he do it that way, what forces drove him?


    yes, diagrams should NEVER be more than an aid in the process, they should not BE the process (which is so often the case).
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Jeroen Wenting:
    In fact I've serious doubts as to whether forcing a tool or methodology on people ever does much more than move the problem elsewhere while making them unhappy.


    True, imposing a tool, methodology, whatever on a development team won't work. The good developers will either work around/ignore it or use it without force, the bad developers will either work around/ignore it or use it the wrong way.

    On the other hand, you *need* a solution - just crossing fingers wouldn't be an option to me. Good developers will recognize this, and a good team will work on finding and implementing a solution. If you don't have such a team, in my opinion you are in serious trouble and should work hard on getting one!
    Jeroen Wenting
    Ranch Hand

    Joined: Oct 12, 2000
    Posts: 5093
    Of course, you need something. That's why development teams should ideally have a budget they're free to spend (within reason of course) on productivity tools and be given a standard set to start with (email, word processor, spreadsheet).

    What I see far too often is that there's either no tools budget at all or (less frequently) that someone in an ivory tower calling himself chief architect, manager of IT, or some other lofty title, decides what everyone should use out of some catalogue or after IBM gives him a nice lunch and a salespitch and nothing else is allowed to be used even if the given tool is totally inappropriate (I chose IBM because in my experience they're usually the party chosen when the process goes like this).
    Chris Johnston
    Ranch Hand

    Joined: Dec 13, 2004
    Posts: 85
    With all the good information that is in this discussion on the proper use of design and methodologies (or not using methodologies), how would you suggest that a team go about picking tools, methodologies, etc if they have no real experience and no one capable of guiding them?

    This is the situation that I am in. My current team is a group of C and Perl programmers who are trying to make the jump from procedural programming all the way to J2EE. They have just been through the implementation of a software prototype that just barely worked and was delivered three weeks late and are now in the process of attempting to find a method that will avoid this in the future. They have also all been on a one week course on UML and RUP and believe that it will save all their woes. Is this a reasonable expectation? For some reason I am skeptical. (And I am at the bottom of the pile when it comes to this team.)

    So my real question is this: How does one go about doing agile modeling if you do not have the proper experience to know how to do it correctly? If you have a team that has maybe 6 months of experience working with OO languages and are still writting procedural Java code, how do you take that team from that point to the point where they are able to use Agile Modeling and can design and create clean code? And how do you do all of this when there is no senior developers or architects in place who have years of experience working with Java and J2EE? Is the team doomed?

    The ideas presented above all seemed well and good if you have the experience to pull them off, but I have seen code that was created without enough design work being done and it can be horrendous. It seems to me that Agile Modeling is something that can only be done once you have the experience needed to do it. But that sounds a lot like a catch-22 to me.
    Jeroen Wenting
    Ranch Hand

    Joined: Oct 12, 2000
    Posts: 5093
    First thing to do is get your people some solid background information.
    A good way might be professional training in combination with some good books (Robert Martin's book "Agile software development" is excellent, so is Headfirst design patterns and Rod Johnson's "J2EE design and development").

    Then you MAY want to bring in an outside consultant experienced in such things to act as a coach and handhold you through the implementation of the new development system.
    Just make sure you're not getting one who's so entrenched into one way of thinking (or more usually the use of one specific tool) that he's incapable of seeing alternative options. This probably means you should not hire anyone who has a lot of experience with Rational Rose (or anyone from one of the major consultancy firms).
    Some of the books by Kent Beck and the pragmatic programmer series can also help at this stage.
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Chris, I don't think your team necessarily is doomed. That very much depends on the people - if they are willing to make mistakes and to collaborate to correct them, to learn together - and if there is enough slack in the project plan to do so - you might well succeed.

    In my opinion, there are four vital things you should do:

    First, very regularly reflect on how you are doing and what you can do to improve. Do daily Stand Up Meetings where everyone tells for a minute what he is doing, what problems he faces and where you can initiate to organize help where help is needed. Do weekly Iteration Retrospectives where you reflect on the last week of development, what worked well and what didn't, and decide on what to stop doing, what to continue doing and what to try to do more.

    Second, build a team culture of learning. For example, decide to read a book together. Meet weekly to discuss the last chapter everyone read since the last meeting and discuss it, especially how you could apply the newly learned to your current situation. Do regular code reviews. Definitely try Pair Programming - it's one of the most effective practices to disperse knowledge and foster collaboration.

    Third, get massive feedback on how you are doing. Do rough release and iteration plans for your project and track how you are doing against it. Learn how fast you really can go and update the plan against that learning. Learn how to write tests that tell you wether what you did really worked. Get feedback from stakeholders and real users early and often on wether what you are doing is really what they want from you.

    Fourth, plan for mistakes and correcting them. No matter how much upfront design you do, it *will* be wrong, and you *will* have to correct existing code. No matter what the users and stakeholders tell you now, once they see a running system they *will* tell you that they want to have it a different way. So one of the most important practices to learn is applying changes to your code without breaking the system, namely refactoring and automated testing.

    I think it can be done. But if you can, you definetely should get an experienced coach, at least for the starting time. It will increase your chance of success by a big amount. If you can't do that, at least get as much help from communities surrounding you as you can. Posting a question here at JavaRanch is a good start...

    You might also want to take a look at the practices of Extreme Programming. I think they are very appropriate for a team of beginners.
    Chris Johnston
    Ranch Hand

    Joined: Dec 13, 2004
    Posts: 85
    This discussion is a huge help, thanks.

    One question though regarding the use of pair programming: How can pair programming be faster or more productive having two programmers working on the same code as opposed to each programmer working on separate code? Should it not be faster to have each programmer working on their own thing, that way you get two things done instead of one?

    I am sure that the above is the first argument people have against pair programming, but I am interested in knowing what the argument used to answer the above question is.

    Now the only real question is how to influence all the managers above me when I am at the bottom of the heap, hmm...
    Jeroen Wenting
    Ranch Hand

    Joined: Oct 12, 2000
    Posts: 5093
    the traditional argument is that people working in pairs produce less buggy code because there's an extra pair of eyes on what's being produced and that they also work faster because they (each) spend less time thinking and more time coding.

    Personally I think especially the latter argument is bogus
    I find I work best with a small group, each working on separate but related tasks, in which people aren't afraid to ask each other questions.
    That way everyone gets to do his own thing yet can ask for help from the others if needed.
    Jeff Langr
    author
    Ranch Hand

    Joined: May 14, 2003
    Posts: 762
    I've made a bunch of posts in various other threads on pair programming. Yesterday I finally threw together some of these thoughts and produced an online article on pairing. As such, I'm not sure it's terribly cohesive, but it covers a lot of concerns.

    -j-
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Jeff, I just skimmed over that article of yours, but it looks quite good. Thanks!
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Jeroen Wenting:
    the traditional argument is that people working in pairs produce less buggy code because there's an extra pair of eyes on what's being produced and that they also work faster because they (each) spend less time thinking and more time coding.

    Personally I think especially the latter argument is bogus


    I agree, and I actually don't remember that argument being stated anywhere. Do you have a reference at hand?


    I find I work best with a small group, each working on separate but related tasks, in which people aren't afraid to ask each other questions.
    That way everyone gets to do his own thing yet can ask for help from the others if needed.


    I don't remember - did you already tell us somewhere how you found that out, what you tried and what you experienced?
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Chris Johnston:
    One question though regarding the use of pair programming: How can pair programming be faster or more productive having two programmers working on the same code as opposed to each programmer working on separate code? Should it not be faster to have each programmer working on their own thing, that way you get two things done instead of one?


    To me, productivity in software development mostly is about finding ways to have to write (and change) less code, not to write more code faster. The former is a rather creative activity, and I find that two minds actually perform much better at it, as they can inspire each other and come up with solutions they wouldn't have been able to come up with when working alone. This effect is even increased when you pair program promiscuously.

    There are other effects at work, too, such as the "driver" being able to concentrate on the code at hand (use a for- or a while-loop?), whereas the co-driver can keep an eye on the bigger issues (what needs to be done next; how does what we do fit into the whole system?).

    You can read more about those and other advantages at http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF


    Now the only real question is how to influence all the managers above me when I am at the bottom of the heap, hmm...


    Well, that depends heavily on the culture of your company.

    We convinced our project manager to let us try PP for a week on an important task to see how it works. He was quite surprised by the result, and now we are allowed to do as much PP as we see fit.

    It probably helped that we already had some private experience with PP, though. If you don't have that, you shouldn't expect it to work well from the beginning - it's a technique that needs to be learned like any other.

    I'd advice you to get a copy of Linda Rising's "Fearless Change": http://www.coderanch.com/t/93700/Book-Reviews/Fearless-Change-Patterns-Introducing-New
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Am I missing the point of UML tools?