I met up with Daniel from GT At Charing Cross this evening and we wandered over to the IEE building for this years Turing Lecture. I heard of the event on Louise Fergusons event list only a few weeks ago, and was instantly attracted by the presence of the godlike Fred Brooks. His book The Mythical Man Month became a favourite after a project-related disaster back at GT kicked off an interest in project management and software development processes.

I wasn't disappointed. Whilst the title of Professor Brooks' lecture was "Collaboration & telecollaboration in design", he covered an awful lot of process-related stuff. Another one of those occasions where pearls of wisdom mutate into the bloody obvious on contact with my brain.

Notes follow:

1. Intro

Process of design is similar, independent of media: e.g. for software and buildings. How can young media (e.g. IT) learn from old (e.g. architecture)?
19th century engineers were builders; today there's a divide between designers and builders. "Can anyone here take a pile of sand and build a computer?"

2. To understand telecollaboration

There's an assumption that the more collaboration we have, the better. This isn't necessarily true.

3. Conceptual integrity: how do we get this with team design?

4. Most products today are team designed. This wasn't always the case.

5. Most works of art are by individuals - or occasionally a team of 2 (being a magic number)

6. Why use teams? Increasing complexity and specialisation in what we do - compare the original iron bridges to modern suspension bridge. "There are no naive technologies left in the west.": a digression on computational fluid dynamics and how they relate to something as throwaway as shampoo. Nothing is simple any more, but we're often solving a common industrial problem: taking wide variance of inputs to produce a consistent output.

7. Hurry to get to market: "first to market gets 40%" (is this true?). There's another assumption that team design means fast design.

8. Many hands can make *more* work: task partitioning, interface definition, interpretation and reconciliation are all additional burdens. Standardisation. Common style definition. Integration & testing have a cost which might only be realised at integration time: the shipbuilders mantra - "cut to measure; bang to fit"

9. Conceptual integrity: Cray's computers, Menn's bridges, etc. have this thanks to single-mindedness of design. St. Pauls is an example of this too.

10. Fan clubs vs no fan clubs: mac vs pc, linux vs nt, fortran vs cobol etc. Products which have fan clubs were usually produced outside normal corporate processes. Normal corporate processes don't inspire devotion in their end-products: they're good for incremental improvements, but not innovation.

A counterpoint to this view is the book "Multiple authorship & the myth of solitary genius" by Jack Stillinger

11. Design as interdisciplinary negotiation? NO! Chief-programmer in Brooks' ideal team is effectively a supported designer.

12. Architect as separate from team leader: team leader handles resourcing, scheduling and delivery. Architect delivers the conceptual integrity and is an advocate for the user. Large projects are broken into chunks with individual architects. ONE user interface designer, no matter how complex the product.

He talked of a project where no one person understood the overall system: "Well it had the smell of death". How do you expect 1 user to understand it, if no one technical expert can? Likewise with UIs - you need conceptual integrity here.

Single UI designer serves as surrogate for single user.

13. Document assumptions at the start of the process: population characteristics, application future use. Better to be wrong than silent or vague! Users will put successful applications to new use and therefore make demands on their future development. Each member of a team makes a different set of assumptions, leading to inconsistencies - unless these assumptions are documented.

14. Style sheet: consistent styling of details is the hallmark of conceptual integrity. It's like pornography: "you know it when you see it"

15. Eric Raymonds "brilliant paper": marketplace determines which pieces of a product survive. Individual pieces of Linux have conceptual integrity and fit together thanks to the initial conceptual design of UNIX.

16. BUT this is based on a prestige/gift culture where your status is determined by what you've contributed. It's a culture whose members are fed anyway, and whose clients are its members. You wouldn't design an air traffic control system like this.

17. Collaboration helps when determining user needs (more people = more questions = more viewpoints = more information). Brainstorming conceptual alternatives. Not conceptual or detailed design. Using XP 2 developers take 1.4 days to do a piece of work... but order-of-magnitude better quality. Design reviews bring in different expertise.

18. Real design is more complex than textbook design and demands change control.

19. Telecollaboration: needed thanks to specialisation of modern design, geographic dispersal of talent (in different time zones, etc.).

Airbus 380 as an example of telecollaboration. System/360 was very dispersed. Face time is crucial. Best collaborations are built on this "face time".

20. Most telecollaboration R&D is done for tool builders, not tool owners

Some questions and points made in answer:

1. We know how to avoid troubles that plague software projects: do best practice stuff and don't cut corners!

2. Torvalds is effectively the conceptual design.

3. Point from a graphic designer that visual design is very subjective and it's only when you get down to pen and paper than people can get their view of things consistent and address assumptions and inconsistencies.

4. Interfaces should occur at the points where the least amount of information needs to be transferred. There's no process at large software companies for growing designers in the way that there is for growing designers.

5. Does reuse bring problems? "We've seen so little design for reuse that we don't have enough experience of it". There are no incentives to invest in reuse either: it's political, rather than technical, issues that prevent it.

6. "The waterfall model is a disastrous way to build software".

7. Professional humility is a way to deal with turnover of system architecture staff.