Mastering OO Modeling: An Industry Training & Mentoring Perspective

While the "Keynote Panel" was speaking, Helen Sharp kept track of the key thoughts and ideas expressed by the speakers. Here are the notes she made.

• Match Techniques to people (make it up as you go along)
• Different flavors of techniques
• CRC cards one of the best
• One or two week training course {Doesn’t work isn’t enough}
• Mentoring can work

• One week courses ‘Burn Out’ trainers too
• Reading* - discussion morning and afternoon
• Group work and presentation, non judgmental questions
• Use cases for word processor (separates requirements)
• People are different
• Some need concrete details
• The more precision, the less abstract can be seen

*Michael Jackson’s requirements
Dick Gabriel’s patterns

• Teaching abstraction is hard
• Mentoring ideal but expensive

+ Reverse model existing system

+ Drive towards executable software

+ Look at models of stuff that works

e.g. IBM San Francisco — positive example
Taligent — negative example

- You use models to solve problems so use them where it makes sense

• People change slowly — through repetition and hope
• Vision, persistence, confidence, optimism
• Modelling is problem-solving
• Look at teams
• Problem solving is connected to team work
• Lots of things; take account of all of them

Some Discusion and Questions from the floor, with the above participants, joined by David Delano:

RWB: Break up training for when it’s needed

MF: If you’ve got precision, can’t see whole picture…..so…..choose a subset (difficult)

NK: What’s important is what model doesn’t say be master of your own method adapt not adopt

GB: Reverse engineer ‘hello world’ — it’s complex conceptual models important

www.spmn.com

Best practices : 6 guidelines

MF: Study existing designs

Get communication going

Exposure to alternatives

RWB: Modelling a machine with buttons is easier than a ‘machine’ that processes information

NK: Is mentoring expensive or mentors or company?

GB: There are few good mentors

Introduce software designs first!

GB: Apathy us our greatest enemy

RWB: Models are flexible

DdL: Coding is schedule driven

NK: We’re living with the sins created in academia. Inverted curriculum — from a systems perspective

Failure comes from managers not knowing what & when, not technology

NK: everyone contributes to it: systems

GB: upper management sets framework

RWB: Difference between engineering & IT:

If you get funding for a year and ‘fail’ in engineering it’s serious but in IT, your consequences are less serious

MF: Successful teams are distrusted by other developers and are likely to be disbanded

If trying to get mentoring by good students to less good students, how separate the impact for assessing?

NK: Team with mixed experience

Why is mentoring not part of assessment?

Grades get in the way of good CS

RWB: Mentoring is not about showing off. They must transmit their knowledge to others.

If you were responsible for 15 teams, each 7-10 people, how handle mentoring?

GB: Pair team activities. Grow a culture put lots into mentoring & not ‘blaming’ review other models

RWB: Alistair Cockburn talks of ‘learning teams’ and ‘progress teams’. Don’t spread out the gurus.

GB: One group must be responsible for architecture

So ‘natural’ mentors

MF: Better to work with some and get success don’t spread too thin

Introducing OO in companies. Can’t do it quickly; It’s not green field (LEGACY) can’t carve out a small project because model is ‘mingled’

NK: Why are they looking to objects? They may not be ready for objects.

Try building hybrid system

MF: It’s ok to say it’s not ok for objects

RWB: If inter-twined then maybe some investment into building something small, then grow it.

Two forces: Integrating when knowledge into daily practices; pressure to produce

We’re not teaching culture of reuse, but creation

How facilitate building

What notation and what tool if any?

GB: UML. Architectural Mentoring.

Four plus 1