Stuff To Do
Stuff To DoDouble-check the pictures (like the Newschwanstein Castle). Do we want them all in, and are there copyright concerns? (One of them was kind of big.)
It might be nice to have a list of the top five patterns early in the book, maybe with a discussion of how they relate to core principles (triple-loop stuff...)
ResponsibilitiesEngage needs a picture -- I would prefer a different one from the one in ProducersInTheMiddle, but it's not bad...
BuildPrototypes refers to some patterns that are untethered: MicroCosm and EarlyAndRegularDelivery. I think these are Alistair's and we need to put in BibRef? citations for them and treat them as external references.
WorkSplit: Interesting structural ramifications. Write it up (or rewrite it), and see about working it into the language. (neil?) Hmm. Looks like it's already in there, and is written up. Has a reference to ComparableWork, which is in the graph, but not in the BookOutline. It does not seem structural to me; I think we should not include it in the book (ComparableWork). So we either fix the reference to it, or maybe include patlets for such patterns.
MultipleCompetingDesigns?: Also has interesting structure. Also write it, and see about working it in.
ParserBuilder, HierarchyOfFactories both appear to have broken links to somewhere.
PrivateVersioning vs. PrivateWorld: they should reference each other.
SubclassPerTeam: we had wondered whether this is covered by CodeOwnership, ConwaysLaw, and others. Should we pull it out? (Any more, I think it stays. But maybe add cross-refs.)
Check on this possible pattern: 1. A role which serves as a bridge among people, to convey information and make sure that people stay on the same page. It helps maintain UnityOfPurpose. (Steve)
Check on WiseFool, to make sure it covers this: 2. Agitator role: someone who stirs up things to make sure, for example, that the problems in the architecture bubble to the surface. This person might ask the dumb questions, or the questions nobody else dares ask. (Steve)
Dangling reference (need bib-ref) in DayCare, near end. Fixed it.
DeveloperControlsProcess has a sentence at the end noting a page with concerns that should be addressed inside ProcessServesProduct. I think I have now addressed this with the paragraph at the very end. Looks fine -- Neil
ProducersInTheMiddle needs a picture (I added one -- Neil, does it look O.K.? -- Yes); so does ResponsibilitiesEngage (same one? -- see new item above)
I think we still need to explain to the reader why there are four pattern languages, and how to use them together (I think this is done -- in OrganizationalPatternLanguages). (I agree -- Neil)
Next Meeting: 7/24, 9:00/10:00. Neil will call Cope (at home, right?).
Agenda:
Review ParkingLot, especially CrisisManagement and Schismogenesis (where to put them).
Check out new candidate pattern: CommunityOfTrust
Also added to book: ProducersInTheMiddle
Review previous items.
We will do the PiecemealGrowthPatternLanguage in the order in the BookOutline.
Notes from 6/12
We need external input beyond Gus' "It's awfully dry" on the book itself. So let's ask Alan to look at the book as it stands, and then have him join one of our calls, to decide about getting it into the hands of some reviewers. (mail to Alan: cope)
Things to think about to make the book more readable: Pictures, diagrams, individual war stories, and running stories.
Reviewed the AlmanacCandidates. Had the following action, and work:
Don Olson's patterns: We already got feedback from Don about using them; still need to decide which to use or reference.
Todd Coram's Demo Prep patterns: None seem to fit.
WorkQueueReport: Not structural; refer to it in other patterns, especially StandUpMeeting. (cope)
WorkSplit: Interesting structural ramifications. Write it up (or rewrite it), and see about working it into the language. (neil?) Hmm. Looks like it's already in there, and is written up. Has a reference to ComparableWork, which is in the graph, but not in the BookOutline. It does not seem structural to me; I think we should not include it in the book (ComparableWork). So we either fix the reference to it, or maybe include patlets for such patterns.
MultipleCompetingDesigns?: Also has interesting structure. Also write it, and see about working it in. (Note: we need to ping Charles Weir about using it.) (neil)
GenericsAndSpecifics: Probably add it. (neil)
The five patterns at the bottom: Add references to them (neil done).
Still need to clean and probably refactor the code ownership glob (cope).
Notes from 5/22
FunctionOwnerAndComponentOwner, OwnerPerDeliverable:
Are these the same? How do they differ? Cope to ask Alistair about them. We may want to refactor these together with CodeOwnership; maybe we get two patterns out of it. But Component vs. Function ownership (the need for both) must be understood. This whole area of code ownership needs to be carefully written to get it right. (cope, initially, but neil will get involved after KoalaPLoP?.)
ParserBuilder, FactoryMethod, and HierarchyOfFactories:
Are all of these instances/implementations of VariationBehindInterface, or do they stand on their own? Cope fixed the links in the language, now what to do with them?
Note on FactoryMethod: We can use this to show the value of this pattern WRT to the GOF patterns, and how it bridges code, people, and organization. It shows how proper code structure can help the organization be more effective; making Conway's law happen, etc. But it's still part of VariationBehindInterface...
Look at making this a part of PrivateWorld, which needs to explicitly talk about the role of the individual and supporting individuals. Also, mail to Steve telling him of our intention to merge the two. Get his reaction. (neil)
Cope to review, and add into the language and book outline. Remove ReviewTheArchitecture. (done)
Cope to ping Alistair. (probably leave it in the language)
Cope to send it to BetsyHanesPerry. (done; awaiting comments)
Notes from 5/8
Fold the review into GroupValidation, and write ScrumMeeting as a pattern. Note in ConwaysLaw of effect of reviewing architecture or the business on the other. Maybe add a note in ArchitectControlsProduct as well. (done)
(check this out: DailyMeeting -- neil)
Add a bunch of stuff, including how it differs from OwnerPerDeliverable. (neil --- done)
Appears to be covered by CodeOwnership, ConwaysLaw, and others. Pull this one out? (cope -- see above)
Maybe put a note in about the "crisis" nature of locking em up together. The team comes closer together, outside influences are cut off, there is a change in the world. Thus the meeting becomes a learning meeting. (neil, cope maybe to add references elsewhere. done)
Neil to send mail to Brian about presupposing the solution. (done)
Needs a lot of work. Needs to be clear to apply this or orgs. (cope - ask Alistair to rewrite.)
Needs to be rewritten. (cope - ask Alistair to rewrite)
no changes.
Notes from 5/1
Add it to the language; fit it in. And clean up PublicCharacter to refer to it, and maybe pull out a sentence or two. (cope. neil to add patlet done)
Cleaned up. (done)
Neil to update. done
minor cleanup - cope - what was this?
try to fix it - neil done
cleanup before reviewing - neil done
Think about it, and come back to it. Also, explore link to GroupValidation. Should ReviewTheArchitecture be folded into it? neil added stuff to think about. (done)
We aren't overly thrilled with it, but it's ok as it stands.
Notes from 4/24:
Cleaned up HubSpokeAndRim. (done, I think)
Worked on MoveResponsibilities (neil to fix problem statement done -- with more surrounding stuff, the problem statement works.)
UnconventionalTeamStructure? changed to UpsideDownMatrixManagement (neil to do content cleanup, cope to do administrative cleanup (administrative cleanup done, content cleanup done))
JesterRole (aka WiseFool) may be a separate pattern from PublicCharacter. (neil to write up candidate. done)
Cope mentioned that when he used TeamPerTask in the WhatArePatterns section, it became apparent that it didn't fit where it is in the language. (cope to figure out where it goes -- sometime) (done)
(neil to clean up last sentence of DissonancePrecedesResolution.)
Previous notes:
Patterns to discuss:
New Candidates:
Others:
Meeting 2/27:
Needs clarification about roles vs. people, and mapping between people and roles. Also, how to identify roles, and maybe examples of roles, perhaps roles vs. tasks within roles (i.e. responsibilities of roles). (Neil done)
"Some roles are simply pipelines for information..." Rephrase this to make it clear what is meant. (Neil done)
We discusssed two possible new patterns:
1. A role which serves as a bridge among people, to convey information and make sure that people stay on the same page. It helps maintain UnityOfPurpose. (Steve)
2. Agitator role: someone who stirs up things to make sure, for example, that the problems in the architecture bubble to the surface. This person might ask the dumb questions, or the questions nobody else dares ask. (Steve)
Steve will write these up as skeletons (and will come up with a name for the first one.), and we will discuss them next meeting (whether they should be included in the language.)
It needs something more to make it really convincing; maybe an example of what roles might come out of this. (Cope -- have a look to see if this is better)
No comments.
"Handoffs...should take place via well-defined interfaces" Note somewhere that one must avoid going too far: Extreme formalism of interfaces/handoffs results in cumbersome and ornerous development processes (a la ISO 9000) (Cope -- done)
No comments.
Note that there is a tradeoff: If teams are too close, they can become isolated from other functions, and you get marketing/development/test/etc. ghettos. You need interaction outside your team. Check out Allen's type 1 and type 2 communication. (Neil done)