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.
*Michael Jacksons requirements
Dick Gabriels patterns
+ 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
Some Discusion and Questions from the floor, with the above participants, joined by David Delano:
RWB: Break up training for when its needed
MF: If youve got precision, cant see whole picture ..so ..choose a subset (difficult)
NK: Whats important is what model doesnt say be master of your own method adapt not adopt
GB: Reverse engineer hello world its complex conceptual models important
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: Were 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 its 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. Dont spread out the gurus.
GB: One group must be responsible for architecture
So natural mentors
MF: Better to work with some and get success dont spread too thin
Introducing OO in companies. Cant do it quickly; Its not green field (LEGACY) cant 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: Its ok to say its 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
Were not teaching culture of reuse, but creation
How facilitate building
What notation and what tool if any?
GB: UML. Architectural Mentoring.
Four plus 1