Developer driven

[Stefan Bell]

It sounds that agile model driven development puts more control in the developer and takes less control from the modeler. Is this accurate?

[Lasse Koskela]

Why should the developer and the modeler be different people?

[Stefan Bell]

Originally posted by Lasse Koskela:
Why should the developer and the modeler be different people?

I model and develop but I also model for others, so what if they are different people?

[Lasse Koskela]

Originally posted by Stefan Bell:
I model and develop but I also model for others, so what if they are different people?

OK. So, you model for someone else but I still don't quite understand what you're referring to with the decreased control by the modeler?

[Andy HK Ng]

>> It sounds that agile model driven development puts more control in the >> developer and takes less control from the modeler. Is this accurate?

It is accurate. Developers' understandings on UML are different. Need a senior guy, eg Modeler, to control on the modeling aspect. Experiences told us that developers tend not to understand other's design, which result in chaos.

[Ko Ko Naing]

Originally posted by Andy HK Ng:
Developers' understandings on UML are different.

IMO, developers need to have the same understanding as modelers(if there are)... If not, there can be misunderstanding and the resulting output will be different from the original target, which is really undiserable...

Need a senior guy, eg Modeler, to control on the modeling aspect. Experiences told us that developers tend not to understand other's design, which result in chaos.

Right, there should be some kinda senior developers who are taking care of junior developers in understanding the given UMLs...

Or r u guys referring to senior developers as modelers?

[Corey McGlone]

I don't know that I'd really say that one person has more responsibility than another. If the modeler or the developer fails in their task, the application fails, it's just that simple. Even a wonderfully designed system won't work if the implementation is poor and a poorly designed system won't work well even if the implementation is wonderful.

UML is all about communication. The whole purpose of it is to create a way that different people can communicate ideas about software systems. In the case that your modeler and your developer are different people, the ability to understand UML really comes through to the fore-front. The modeler certainly needs to understand UML well but, if the developer doesn't understand it well, there will be misconceptions and errors.

[Stan James]

The communication described above is the key. If a modeler completes a model and hands it over to a developer with no other communication, the model has to say everything. It has to be much more complete and detailed with more of the tricky little UML decorations. If the modeler and developer doodle the diagrams together on a whiteboard they can communicate verbally about much of that stuff and leave it out of the model. If a developer models for himself on the back of an envelope he can leave out even more and just capture enough of the idea to start coding.

How does that fit with your concept of control?

[Sathya Srinivasan]

I think agile development blurs the line between a modeler and a developer, and at the same note, modelling phase and development phase. It recommends that they be done kind of in parallel - do the model for a piece and implement it right away; do the model for the next piece, implement, and refactor; and so on.

Going by this, the control would still be the same, but the modeller and the developer might be pair programmers. That way, the modeller can do modelling, the developer can do developing, but they do it together, thereby removing communication issues.

[Lasse Koskela]

Originally posted by Sathya Srinivasan:
Going by this, the control would still be the same, but the modeller and the developer might be pair programmers. That way, the modeller can do modelling, the developer can do developing, but they do it together, thereby removing communication issues.

Except that in Pair Programming, the pair is a pair of equals and both do the same activities (one at a time, taking turns, but still). Of course this does not mean that a modeler and developer couldn't collaborate as you describe. It just isn't Pair Programming per se but simply "pairing" or "collaborating".

[Stefan Bell]

So how important is it for the modeler to really understand the language? For example, if a person had been a developer/modeler in VB and then went to model (exclusively) in a Java environment. Would he normally have problems? How about similar languages say C++ to Java?

[Lasse Koskela]

Originally posted by Stefan Bell:
So how important is it for the modeler to really understand the language? For example, if a person had been a developer/modeler in VB and then went to model (exclusively) in a Java environment. Would he normally have problems? How about similar languages say C++ to Java?

I guess it depends on the skills of the modeler. If the modeler did good OO designs, it shouldn't be a problem to implement those designs in Java instead of C++. Then again, I guess VB "designs" are far from object-oriented so there might be a big gap between modeling VB applications and modeling C++/Java/.NET applications...

[Scott Ambler]

Sigh.

In Agile Modeling (AM) I do in fact try to blur the lines between modeler and programmer, and better yet between business stakeholder and developer for that matter.

One of the practices of AM ( http://www.agilemodeling.com/practices.htm )is to model with others, the AM equivalent of pair programming. You work together as a team, not as seniors and juniors. Yes, person A might be better at sequence diagrams than person B, but B might be better at data modeling than A and person C might be better at use cases than either A or B. So who is senior? Who is junior? I don't know and more importantly I don't care. What I do know is that if all three people were to work together on a project, if they were to follow the practices of AM, then all three would improve their development skills because they'd learn from each other.

- Scott

[Sunder Ganapathy]

Finally, Agile Modelling is about Team Building, working together with
better understanding of each other's strengths and weaknesses .
Agile modelling is about continous learning with total attachment to the
team . Agile modelling is not about creating silos os specialists .

[Scott Ambler]

Exactly. This is true between developers as well as between developers and stakeholders. One of the practices is active stakeholder participation ( http://www.agilemodeling.com/essays/activeStakeholderParticipation.htm ), the idea is that stakeholders can and should be actively involved with modeling. This is possible if you choose to adopt inclusive modeling techniques ( http://www.agilemodeling.com/essays/inclusiveModels.htm ) which use simple tools and simple techniques (e.g. sketches, CRC cards,...).

- Scott