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.


Martin Fowler
Rebecca Wirks-Brock

 

*Michael Jackson’s requirements
Dick Gabriel’s patterns


Grady Booch

+ 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


Norman Kerth

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

 


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