Ultimo reportage da OOSPLA, con un po’ di ritardo per non pesare troppo sui lettori.
Collaboration and Telecollaboration in Design

Frederick P. Brooks, Jr. (University of North Carolina at Chapel Hill)
Qualcuno osa chìedere chi è Fred Brooks? Questa volta vi accontento.

Brooks distilled the successes and failures of the development of Operating System/360 in The Mythical Man-Month: Essays in Software Engineering, (1975, 20th Anniversary Edition, 1995). He further examined software engineering in a 1986 paper, No Silver Bullet. He is a member of the National Academy of Engineering, the National Academy of Science, and the American Academy of Arts and Sciences. He has received the ACM A.M. Turing Award, the IEEE John von Neumann Medal, the IEEE Computer Society’s McDowell and Computer Pioneer Awards, the ACM Allen Newell and Distinguished Service Awards, the AFIPS Harry Goode Award, and an honorary Doctor of Technical Science from the Swiss Federal Institute of Technology

Il design engineering, a differenza dell’arte, è un lavoro di team. Perché? Ci sono aspetti sempre più sofisticati anche nei prodotti più semplici. Tuttavia i grandi progetti di ingegneria sono ancora oggi il lavoro di una, al più due menti. Si ha così l’integrità concettuale.
Brooks mostra una tabella con a sinistra linguaggi e sistemi disegnati da una sola persona e a destra quelli disegnati da un processo di gruppo. Solo i primi hanno il loro fan club.
Il problema è: come ottenere integrità concettuale con il team design. Il design non può essere il prodotto di una negoziazione. Ci vuole un chief designer e per grandi sistemi un chief architect. Anche l’interfaccia utente richiede un solo user-interface designer (es. Google). Per preservare l’integrità concettuale le assunzioni devono essere documentate:

“better to be wrong than silent or vague”

Brooks cita The Cathedral and the Bazaar con Unix costruito da gruppi diversi e l’early bug detection come risultato dell’enorme scala del testing. La posizione di Brooks è che il modello del bazaar è basato sul gift e funziona quando gli sviluppatori sono i clienti stessi: conoscono così i requisiti in base alla loro esperienza personale. Costruireste mai un sistema di controllo del traffico aereo? Attenzione alle generalizzazioni errate, quindi.
Ma quando la collaborazione aiuta? Aiuta nel caso dell’esplorazione concettuale (alternative radicali, brainstorming) ma non nel conceptual design né nel detailed design. E il pair programming? E nei design review? I review sono collettivi, il design no. Il design è un processo prevalentemente per il singolo individiuo mentre il review è un processo di gruppo condotto in modo iterativo.
Il messaggio che Brooks vuole trasmettere è:

Low tech often suffice

I documenti condivisi sono il fattore più importante. Poi la voce. Quando unsare la videoconference?

  • When issues vital to one or more players
  • When people are insecure
  • When interviewing strangers
  • When organization or national cultures are very different

Freb Brooks conclude dicendo che cI sono pochi studi di telecollaboration in design.

Frederick Brooks, Jr. at OOPSLA 2007
Tagged on:

Leave a Reply

Your email address will not be published. Required fields are marked *