Need Help With Team Design Dynamics!

[TrtnJohn]

Currently I work with a fairly small team that does not have assigned designer roles.  Each team member does their design work and reviews it with the team.  After review is complete, they implement.  In the beginning, this seemed like a reasonable approach.  But, now I am starting to have my doubts.  The biggest problem I am having is that certain team members just don't seemed to be cut out to be designers.  Their C background and experience constantly tells them that the only way to design is to write it.  I've tried introducing Use Case Analysis, Domain Modeling, Sequence Diagrams, ...  But, they:

A)  Cannot appear to look beyond the code
B)  Still can't see any benefits
C)  End up trying to write code using UML

They just cannot back off and look at things from a higher level.  This problem has been going on for nearly 2 years  

Either I am a horrible teacher or this is just NOT going to happen with these people.  I am sure I am not the only one to run into this kind of roadblock.  Anyone have any good ideas on how to turn this around?

[Paolo F Cantoni]

Hi TrtnJohn,

Unfortunately this is an example of an aphorism I use all too often:

When everyone's responsible; No one is responsible.

Each project should have a designated Designer/Architect who can actually do the job.

From everyone's observations, some people aren't cut out to be designers (look at software all around you).

Too often, designers and architects seem to use the maxim:

"In titulo, ergo sum" (with apologies to Rene)
"I am thus entitled, therefore I must be..."

My job title says Architect, therefore I must be an Architect.

In your case, some of your team members aren't cut out to be designers - by your own admission.  So stop trying to get them to do things they can't do.  It has precious little to do with their C background.  They just don't get it.  As you implied, it's a paradigm shift.  The hardest thing of all to accomplish.

Architects and Designers (and I now distinguish between the two) are typically those who are those things "to their bones".

Agile development talks about multi-skilling and amorphous roles - which is fine, if you can actually fulfil those roles and have those skills. But...

My AU$00.02

Paolo

[jeshaw2]

TrtnJohn;

Sounds like you have a Change Management issue.

[random thoughts]

• Organizations are designed to be predictable.  When I order a toaster from a company, I want to receive a toaster, not a stove.
  
• Organizations are predictable to the degree that they resist change.  That is why they build in resistance to change via policies, procedures, and employee selection.
  
• Organizations select new employees for their resistance to change and desire to follow policy.
  
• To bring about change, one must do four things:  
  [1] Unlock the resistance to change; turn the old policy off.
  [2] Provide an incentive to change; reward the new behavior, do not reward the old behaviors.
  [3] Provide a process of making the change.  Training, tools, replacement, etc.
  [4] Lock in resistance to change with new policy.
  
• Power gravitates to those who assume it.
  [/random thoughts]
  
  Sounds like you need to:
  
• Assume the role of the Quality & Change Manager.  Since you defined the problem, you must now assume responsibility for it.
  
• Stop applauding procedural code.  That is no longer an optional best practice.
  
• Invalidate use of the C compiler except for maintenance programming.  Install it on the steam driven computer with the 30CPS teletype terminal.  Loving antiques, they'll think you are rewarding them.
  
• Redefine good quality on the basis of the Object Oriented paradigm.
  [plug for EA & this forum]
  
• Provide good OO training & tools
  [/plug for EA & this forum]
  
• Disenfranchise those unwilling to change. Reassign them to the procedural code maintenance team.  If there is no need for such maintenance, "Oh Well!"  It may be time for a redistribution of labor?
  
• Reward those who make the change; give them the choice assignments and rewards.
  
• Establish new policy that enforce OO concepts.
  
  Of course you could make the problem go away by personally embracing procedural code, but that is not an option, or is it?   :-/
  
  my US$.02  

[TrtnJohn]

Thanks for the great feedback Paolo and Jim.

Jim,

I've done most of what you have already said.  The next step should really be, as you put it,  a redistribution of labor.  Unfortunately I don't have backing from management for such a move.  We are a satellite office and they feel any resource lost will most likely not be replaced.  Another strategy I tried was to hire a "young gun" with some good OO experience to shake up the old guard.  Unfortunately, those types are hard to find in my area.  So far I haven't had much luck.  (Maybe I should be looking for a another job??)

I am not quite ready to give up yet and going back to the dark side of procedural coding isn't really an option.

Paolo,

Can you tell me a little more about how your role integrates into the development process.  I am beginning to think that this may be my best option.  How far do you need to take design before you hand it over to developers?  How do you avoid becoming the bottleneck on projects?  What kind of resource allocation works best.  (Architect/Designer/Developer resource ratios?).  I'd probably have to assume 2 roles Architect/Designer is that feasible?

I've had trouble in the past because I have been the "go to" guy in the company for all things related to technology.  This means I can get pulled for:  Trade Shows, Industry standards committees, customer meeting, outsourcing interviews, ...  (I need a raise!).  It seems impossible to be the key architect and have these types of interruptions.   But, it is becoming increasingly apparant that I don't have much choice.  I'll have to work with my management on this one...

[thomaskilian]

As long as you get payed for being the fool and you can live with that - go on. But (I've gone through that hell) it's likely time for a change. Without management backing it' a fight against windmills

My € 0.02

[KP]

Have a look here for some constructive advice: http://www.c2.com/cgi/wiki?ChangeYourOrganizationTactics

[mikewhit]

Another strategy I tried was to hire a "young gun" with some good OO experience to shake up the old guard

What makes you think that the young gun would have enough design and architecture experience (also implementing in different methodologies) to be of benefit ?

Surely an "old gun" who knew more than the existing staff and command respect, but could lead them onto the paths of righteousness would be better.

Even if they were ... a contractor.

[TrtnJohn]

What makes you think that the young gun would have enough design and architecture experience (also implementing in different methodologies) to be of benefit ?

Surely an "old gun" who knew more than the existing staff and command respect, but could lead them onto the paths of righteousness would be better.

Even if they were ... a contractor.

I agree.  That was the wrong term.  By young gun I meant someone with a lot of passion, energy, and experience.  Youth is relative after all.  

[TrtnJohn]

As long as you get payed for being the fool and you can live with that - go on. But (I've gone through that hell) it's likely time for a change. Without management backing it' a fight against windmills

My € 0.02

I do have backing.  I just haven't pushed it to the point of demanding a choice between me or them.  I probably would leave before it ever came to that anyway.