Question for Joe Marasco

[Robert Paris]

I've been working as a Proj. Lead for 3 years now and just recently my company decided to have everyone "certified." So I have to take the SCEA test. I don't know if you're familiar with the "teachings" of this strain, but I've been a bit unsatisfied with some of the process guidlines laid out for projects. So, to my question:

1. If you are familiar with SCEA teachings, how do your real-life experiences differ?

2. How much have you found that UML (and in particular the interaction diagrams) helps/hurts in the process?

3. Is a project more/less likely to succeed if the many (Dev/Deploy) roles on a project are actually filled by different people as recommended in SCEA?
J2EE Product Provider
Tool Provider
Application Component Provider
Enterprise Bean Developer
Web Component Developer
Application Client Developer
Application Assembler
Application Deployer
Application Administrator

Thanks!

[Lasse Koskela]

Originally posted by Robert Paris:

3. Is a project more/less likely to succeed if the many (Dev/Deploy) roles on a project are actually filled by different people as recommended in SCEA?
J2EE Product Provider
Tool Provider
Application Component Provider
Enterprise Bean Developer
Web Component Developer
Application Client Developer
Application Assembler
Application Deployer
Application Administrator

How do you define success?

Having different people fill different roles has a number of effects on certain characteristics of your project, including the inevitable overhead of having all those people communicate with each other, the cost of fixing mistakes caused by having to communicate (it's never perfect no matter how hot and wide the medium/bandwidth is), and the mere salaries of all those people. Not to forget the problem of "only Jack knows how that thing works and Jack is on sick leave until Tuesday"...

As you've probably read between the lines by now, I'm personally not in favor of spreading the roles just because Sun Microsystems' blueprints say so. There's a well-known generic method that's quite applicable to software development as well: it's called common sense.

[Ilja Preuss]

Originally posted by Lasse Koskela:
Having different people fill different roles has a number of effects on certain characteristics of your project, including the inevitable overhead of having all those people communicate with each other, the cost of fixing mistakes caused by having to communicate (it's never perfect no matter how hot and wide the medium/bandwidth is), and the mere salaries of all those people. Not to forget the problem of "only Jack knows how that thing works and Jack is on sick leave until Tuesday"...

Another effect is that a single person can cause the whole project to slow down - because he is the only person able to do an important task other "roles" are waiting for to be finished.

See http://www.poppendieck.com/overview.htm#Workcell for an example of a different approach.

[Ilja Preuss]

Originally posted by Robert Paris:
2. How much have you found that UML (and in particular the interaction diagrams) helps/hurts in the process?

It's important to notice that UML is just a language that can be used in many different ways.

In my important, knowledge of basic UML is quite important, as it can significantly improve communication between developers. I mainly use "UML as sketch", though (see http://www.martinfowler.com/bliki/UmlMode.html) - don't know what SCEA promotes, but I guess it's more along the lines of blue prints?

[Joe Marasco]

I am unfamiliar with the certification you mention.

My experience is that "high ceremony" organizations that focus excessively on process and certification often miss the forest for the trees.

The most important thing on any project is to get great people. They may or may not be "certified". You need to interview them for skills, compentency, and character, none of which can be guaranteed by passing a test. On the other hand, sometimes "uncertified" people will have the mix you need. So I would focus more on what candidates can bring to the table, as opposed to rigid notions of certification.

UML is only one part of the total picture. It is useful and helpful, but not a panacea. I think the more important notions to assimilate have to do with iterative development. The RUP is one instantiation of this, an instantiation that has worked on large projects.

In the end projects are successful because of a conjunction of good process and great people. Overdependence on things like CMM levels will inevitably lead you astray.

Hope this helps.

Joe

[Naina Si]

"3. Is a project more/less likely to succeed if the many (Dev/Deploy) roles on a project are actually filled by different people as recommended in SCEA?
J2EE Product Provider
Tool Provider
Application Component Provider
Enterprise Bean Developer
Web Component Developer
Application Client Developer
Application Assembler
Application Deployer
Application Administrator "

In real world scenario, its very rare that EACH of the above mentioned jobs are done by different people. Generally, all the developement (EJB's, Clients, etc) , assembling and sometimes even deploying can be done by the Developer.
Administration can be done by a different person as opposed to the developer doing it as administration needs more in-depth understanding ...