R there any developers here that confess to ignoring modelling 4 developing systems?

[Marcus Raphael]

Does anyone here beleive that modelling is a waste of time. There for you just go straight into coding??
Or do you value your modelling tools?
Do you use IDE's which support the 12 UML diagrams?
Dou you find this useful?
Do your projects deliver or fail?

[Lasse Koskela]

Does anyone here beleive that modelling is a waste of time. There for you just go straight into coding?

I believe that most of the modeling activities happening around me is a waste of time. Well, maybe not a waste of time but non-optimal use of time in any case. No, I don't go straight into coding. I model, but only enough to reach an agreement with the team that we're thinking about the same structure and agree on the responsibilities. None of that modeling ever ends up into documentation.

Or do you value your modelling tools?

Dearly. I would never give up my whiteboard and sketch pad.

Do you use IDE's which support the 12 UML diagrams?

No, I don't.

Dou you find this useful?

Huh?

Do your projects deliver or fail?

How do you define failure? We always deliver the software, mostly on time and when the schedules go bang it's not like we're 50% late. There was one huge project I participated that went really bad (the architecture was a joke, and reading the code made grown men cry...) but the reasons for that were to a great deal on the client-side (including some bad vendor selection decisions) and we actually got very much praise for being there to keep things from falling apart completely. The modeling that had taken place in that project before me was mostly a waste of time, I think. It was done using all the typical Big Dollar tools and the monstrous process required documentation for documentation's sake. Thank god it's over.
I once spent 6 months writing an integration platform for a client and that piece of software never went into production. The project was technically a success but the client made some strategic decisions before the system was deployed to production. A bit over a year later, I'm probably going back and rewriting that system to fit their new business strategy and technical environment, so I guess they were satisfied with the quality of the first one.
In my experience, the customers prefer having a slightly smaller scope done within the originally planned schedule. I bet that projects who go for the impossible (with all dimensions fixed) get burnt a lot worse because of just that.

[Marcus Raphael]

Round tripping: Now can be automated within an IDE.
This means change can be successfully managed with IDE's with products like Borland Together ControlCenter.
Coding stage is only meant to take 20% of the whole lifecycle, would you say you succeed this? Do you consider the modelling phase to be a completely seperate stage of the lifecycle?

[Vladas Razas]

Coding stage 20%... Well I know all big guys say that, it's very easy to implement something you just paint the diagrams for it. However I never eyewitnessed any such guru. I draw diagrams, mainly class diagrams when I need ones (I like activity or sequence charts too). I tried to make whole project architecture once before starting. I spent lot's of time on it. But what happened is that later I noticed flaws in my project structure and I had to change almost everything. Then I thought, heck I was drawing damn ideas for 3 weeks and this is ended-up with same result if I would spent one week. Even worse, if I would start coding some of them I would see that comming much earlier.
So my life experience says that for medium or big project:
- You may never think of every possibility in advance. Every attempt to do so will probably be just a waste of time.
- But before sitting to code you must know how it is supposed to work (but only the code you are going to write, not whole project).
- When you do your classes try to make everything small. It's the key to reusability. Even if interface has only 1 method it doesn't mean it's bad. If it has 20 it's big chance it's not reusable.
So my conclusion: split all work into parts, but do not attempt to imagine everything working together. For big projects it will make you go nuts.
Regarding UML: UML is good. You should use it. No doubt. At least for the sake of communicating to other team members.
And the last: I used word "you" here alot. I am not pretending I am better or have any grounds to mentor other people. It's just my english

[Vladas Razas]

By the way. This is GOOD. I found out if you can't explain to someone how that thing will work, chances are you don't know that too

[Lasse Koskela]

Everything happens in stages. That's just the reality. You always think before you type a statement into your IDE. The key is the size of those stages. For example, it isn't optimal to realize that you've been driving to the wrong direction only when the mileage suggests you should be at the destination...
I'd like to remind that even Winston Royce, the author of the so-called "waterfall paper", stated that the waterfall process is only viable for the most trivial software projects. He suggested to "do it twice", to incorporate the knowledge gained from actually seeing what you're up against.

[Marcus Raphael]

You did not comment on your opinion towards the automation of rond-tripping.
You dont see the potential in this?
I think it is a significant advancement!

[Kyle Brown]

Originally posted by Marcus Raphael:
Round tripping: Now can be automated within an IDE.
This means change can be successfully managed with IDE's with products like Borland Together ControlCenter.
Coding stage is only meant to take 20% of the whole lifecycle, would you say you succeed this? Do you consider the modelling phase to be a completely seperate stage of the lifecycle?

I'll agree. I've heard that 20% number before, and I've NEVER seen a project that actually happened in, in all the years I've been doing this. I'm with Lasse -- for most cases, the only modeling tool you need is a whiteboard and marker (and a digital camera if you really want to keep the diagrams around). There are some cases involving, very highly complex software with significant regulatory requirements around it (think military or government projects) that need more up-front modeling, but IMHO for 90% of all business software, a whiteboard is enough.
Kyle

[Marcus Raphael]

what do design patterns allow you to do?

[Marcus Raphael]

dont worry about it got the info!

[Lasse Koskela]

You did not comment on your opinion towards the automation of rond-tripping.
You dont see the potential in this?
I think it is a significant advancement!

Well, I haven't yet found a real need for round-trip CASE tools such as Rational Rose. Sure, it's nice to be able to tweak the code in both "views", but it's always been faster to just do it in Eclipse, for example. Yes, I think it's an advancement and a nice-to-have feature if an IDE can switch between "UML" and "Code" views and keep both in sync. I just personally don't feel the need.

[Ilja Preuss]

Originally posted by Lasse Koskela:
Well, I haven't yet found a real need for round-trip CASE tools such as Rational Rose. Sure, it's nice to be able to tweak the code in both "views", but it's always been faster to just do it in Eclipse, for example. Yes, I think it's an advancement and a nice-to-have feature if an IDE can switch between "UML" and "Code" views and keep both in sync. I just personally don't feel the need.

I agree - when I want to code, I want to do so in textual code. UML as a programming language doesn't seem to be effective to me.
So when I want a UML diagram, I want it to be more abstract, more high level than the actual code. Abstracting from the code in this way is more complex than just filtering by some simple means and involves some creativity, too, so I don't think it can be automated.
Actually my biggest problem with the "more advanced" UML tools is that they are too restrictive. It's ok if they remind me of the rules of UML, but if they don't allow me to break them to make my point in a more effective, creative way, it just gets annoying.

[Ilja Preuss]

Originally posted by Marcus Raphael:
Do you consider the modelling phase to be a completely seperate stage of the lifecycle?

I do not consider modelling to be a phase, but an ongoing activity throughout the whole project.
If it were its own phase, how would you *know* that you are done? How would you *know* that they will serve their purpose?

[Ilja Preuss]

Originally posted by Marcus Raphael:
Does anyone here beleive that modelling is a waste of time. There for you just go straight into coding??

I almost always have a model in my head before I start to code. Somehow I need to communicate it to my pair programming partner. Often I do this orally, sometimes aided by the use of diagrams on paper or the white board. (I do have one coworker who just doesn't understand diagrams well, though.)
I always strive to prove my understanding early by trying to code it.

Do your projects deliver or fail?

They deliver - and not only UML diagrams, but working systems, every handfull of weeks.

[Stan James]

My team went through a huge release with Rational mentoring and we did tons of Rose models. They were challenging and interesting the first time through each new architectural feature, but pointless for the next screen that worked just like the last one. Our Rational mentors tried to sell us on forward engineering and round trip engineering, making all API changes in the model first and generating code. It flat did not work - the round trip tools for PowerBuilder destroyed existing code.
Now we do zero modeling in Rose for design. Instead we do lots of quick boxes and arrows on a white-board to get basic structures and responsibilities down. I am a skeptic about MDA because by the time you get enough detail into a model to generate useful code, you could have written the code. Somebody may get real value from being able to generate an abstract model into multiple languages or platforms, but not me.
I'd have to admit our designs have some real problems. Looking at code that was rushed through is sometimes painful. We need to develop some other disciplines to improve ourselves, though, not UML skills but general OO principles. We can still communicate the ideas with simple boxes and arrows.
Now, one correction. We're just starting to use a new vendor product that generates object-relational persistence code from Rose models. They customized the Rose meta-model with many tabs full of new attributes. They wrote their own code generator. I have a great fear that this feature was developed because it was "geek fun" and it looks great in marketing brochures. Time will tell.

[J You]

I agree with above comment.
I'd say Modeling, OOD, Design Pattern etc are all GOOD things...they all look extremely RIGHT in textbook, but in reality I don't think they really help us that much (sure I am talking from my own experience)
If we have a lot of time to kill, I'd like to spend some time on the diagrams and documents - it doesn't help the coding, but makes me "feel good" ...But most time, we are in tight skedule, and most pain come in the second half of the process, and most time are not spent on coding, but "communication", not with your fellow programmers, but with clients, business managers, DBA, migration team, testing team ....

[J You]

One of my big fear as developer is to have a "geek" style "procedure" which so focuses on "Object Oriented under whatever circumstances" that it will "Over-OO" everything.

[Kyle Brown]

Originally posted by J You:
I agree with above comment.
I'd say Modeling, OOD, Design Pattern etc are all GOOD things...they all look extremely RIGHT in textbook, but in reality I don't think they really help us that much (sure I am talking from my own experience)
If we have a lot of time to kill, I'd like to spend some time on the diagrams and documents - it doesn't help the coding, but makes me "feel good" ...But most time, we are in tight skedule, and most pain come in the second half of the process, and most time are not spent on coding, but "communication", not with your fellow programmers, but with clients, business managers, DBA, migration team, testing team ....

I feel sorry for you on that because I HAVE seen OO Modeling and Design patterns help enormously in real-life situations, many, many times. Not in placing them all at the beginning in enormous, monolithic models, mind you, but applying them to situations as they are needed.
The key here is to remember to Refactor. That is where you find how your design is improved, and that's usually (8 times out of 10) where you'll find where patterns apply. If you can't make yourself refactor, you're dead in the water.
Kyle

[Andles Jurgen]

re: applying them to situations as they are needed.
This is exactly right. I have read a gazillion books on how to do the whole RUP and 14 diagrams thing - and it,s way too much for your average project, possibly even on your larger project.
I model most things on paper, or if it,s particilarly complex for me to grasp or explain I fire up a tool and do some print outs. But we never worry about modelling an entire system - nobody would pay us to do so, and it just does not work out to save any time in the long run.
There's theory, and there's having to get the job done.
Andy.

[Ken Krebs]

There is a good book that discusses these issues, "UML for Java Programmers" by Robert C. Martin (Uncle Bob). A couple of good points from this book are:
1. "Why do engineers build models ? ... Models are built to find out if something will work. ... We investigate designs with models when the models are much cheaper than the real thing we are building."
2. "UML is a tool, not an end in itself. As a tool, it can help you think through your designs and communicate them to others. Use it sparingly and it will give you great benefit. Overuse it and it will waste a lot of your time. When using UML, think small."
I find this to be sound, practical advice and highly recommend the book. It's whiteboards and scratch paper for my models.