Alistair Cockburn

Agile Advanced Masterclass

The Center of Agile Advanced Masterclass with Alistair Cockburn

“Can I say on a personal note , since I came back from the AAD it has relit the fire in me , I can only thank you for providing the spark.” -Tony

An inspiring 2d w @TotherAlistair learning #AdvancedAgile from the 1 guy in the world capable of teaching it… Now time to repack my brain. – Tyson

“It was a great experience and definitly changed my mindset. Anyone doing scrum should take the class and get some “agile inspiration” :)” – Kosta

Move to the next stage by learning from one of the authors of the Agile Manifesto!
  • Level: Intermediate and Advanced :
    • This is the course for you if you have been doing agile development for 3-15 years, have read many of the books and are ready for a deep dive into what agile development is all about.
    • This is the course for you if you have been doing agile development for 1-5 years and want to amp up your capabilities to the next level.
    • This is not the course for you if you are a hot shot programmer or PM and want to strut your stuff.
    • This is not the course for you if you are looking for an introduction to agile, basic of Scrum, CSM, or project management (attend instead the Fundamentals of Agile Development public course (discussion: Re: Agile Development Class with Crystal and Certified ScrumMaster)).
    • This is a course for those who want to inquire and to get themselves ready for whatever comes next.

This is the advanced masterclass in agile development from industry guru Dr. Alistair Cockburn.

The Center of Agile Advanced Masterclass with Dr. Alistair Cockburn

Modern “expert” agile practitioners have mastered the practices – but not why they work, not how to adjust practices to situations, not how to approach new and surprising situations, not how to apply agile practices to non-software projects, not how to incorporate results from other fields back to their own projects, not how to tailor the practices to different organizational cultures. This advanced course from industry guru Dr. Alistair Cockburn addresses those areas.

  • In this discovery-filled course,
    • Learn why agile works, in software or outside of it,
    • Learn how to articulate and deal with the weaknesses in agile development,
    • Test yourself and your partners with the Test-Driven Carpaccio exercise.
    • Learn to reduce risk and maximize results by viewing design as a Knowledge Acquisition activity.
    • Practice backing up your recommendations with solid theory, not just an appeal to authority,
    • Learn how to plan and track larger, more complicated projects using Story Mapping or Blitz Planning (time permitting),
  • . . . and most of all
    • Come face-to-face with yourself, your strengths and your weaknesses, as you confront one situation after another with equally inquisitive classmates.

Bring along bring gnarly problems you have been challenged with and objections as to why agile can’t work in whatever context: We will work through those problems as a class, using the skills taught in the class.

This is not a course for the beginner or the faint of heart. Expect to do homework, expect to be put through your paces, expect to dialog and argue, have your beliefs challenged.

You need not prepare for the course, but you will get more from it if you have read Agile Software Development: The Cooperative Game and “The Seven Properties of Highly Successful Projects” from Crystal Clear: A Human-Powered Methodology for Small Teams prior to the start of class.

At the end of the course, walk away with a rich, robust set of tools for approaching your project and organizational situations.

Instructor:

Dr. Alistair Cockburn (pronounced Cō-burn) was voted one of the “All-Time Top 150 i-Technology Heroes” for his work in creating and steering Agile software development. He co-authored the Manifesto for Agile Software Development and the “Declaration of Interdependence,” created the first Agile Software Development Conference, co-founded the Agile Project Leadership Network, served on the board of the AgileAlliance, designed the Crystal family of agile methodologies, and co-founded the International Consortium for Agile. Three of his books have won Jolt awards and been listed in “The Top 100 Best Software Books of All Time”. He consistently receives high ratings for his presentations and courses. Much of his material is online at http://Alistair.Cockburn.us.

What Students Wrote After Attending One of Alistair’s Master Classes: “Huge emotional learning about self.” -@ksteffe “I’m breathless from drinking from the firehose.” – Resetley & Restarting Best part about the course. “Alistair’s mastery of the course/industry content and ability to respond and support any student requests.” – Scott Wolfe ”#AdvancedAgile with @TotherAlistair is like walking in as an agile Jedi then some dude with pointy horns pulls a double ended light sabre.” – Todd “Inspiring, I will be going back into the cooperative game with a refreshed strategy and some new moves” – Kelsey ” Best part of the course: Learning how to ask questions without jumping to a solution” ” It was interesting to see how we forget important known stuff when we face a crisis” – Pavel ” THE forum to test every theory and stalk even the sacred cows of agile practice ” – Kim “I don’t care what they say, being with you is a pleasure.” – CM “Really great master class with @TotherAlistair” “Mind exploding like crazy.” “Definitely inspired to up my game!” “Ego obliterated, mind expanded, much to ponder after the masterclass. Thanks” “I had to call in sick the next day.” “Huge emotional learning about self.” -@ksteffe “I feel a lot better this time around after coming out of Alistair’s class. Learned a lot and my mind is clear” “I’m breathless from drinking from the firehose.” – Resetley & Restarting Best part about the course. “Alistair’s mastery of the course/industry content and ability to respond and support any student requests.” – Scott Wolfe “Alistair is the Chuck Norris of Use Cases. Applying use cases to the project life cycle has re-instilled my faith in project management.” “Alistair provided a non-intimidating environment to allow for mind stretching. I feel like I’ve been put through a mental wringer but all in a way that can only improve my value for my team.” –Nicole Hopkins “The deep level of experience Alistair brings to the training adds significant insight to the domain.” –Dave Pugmire “Excellent course… well worth the investment of time and money. I especially appreciated Alistair’s depth of knowledge and breadth of experience. I will be watching for other courses offered by him.” –Chuck Stoner “Course goes well beyond novice level in terms of cognitive complexity. Pushes into analytical/critical thinking skills.” –Cristina “I want my boss, my boss’s boss and my boss’s boss’s boss to take this course.” “I would certainly agree with Alistair’s characterization of what he does being the height of voodoo witchery and other eldritch practices, at least to the untrained eye. Stretching the metaphor even further I’d also say that some of those that he coaches are left with a feeling much like what I would imagine a visit to the voodoo shaman would engender – glad that he was there to help, but equally glad that he has taken his rum and chickens elsewhere.” –Jonathan “In 20+ years of attending courses in software development this has been the best course. Great balance of theory and lab (hands on) work.” –John W. Cooley “Fantastic course for practitioners who want to think about what they do and improve their teams. Cuts through the Agile hype to communicate deep insights and truly useful techniques.” – Kay Johansen “This course was simply amazing! Dr. Alistair Cockburn has one of the best minds period. I have so much to learn. This course should be mandatory for all project managers.” – J. K. “Excellent job of imparting knowledge without creating dogma.” – J.S. “Your teaching style/positioning as a methodologist fit exactly what I was looking for, not dogma but the base/broad thinking behind the practices” – Anastasia “Alistair combines the theory with practical experiences and exercises that reveals the hows and whys of agile.” – Richard Thomson “It is great to be able to tap into Alistair’s years of experience!” – Sean Landis “It was great to take this course from one of the acknowledged leaders in the field.” – Jeff Romine “Very enjoyable course. More please.” “Exceeded my expectations! Great class; excellent presenter!” “Alistair is a wonderful instructor! Very knowledgeable, easy to listen to, and funny!” – Anne Marie Kimberling It was awesome! It broke my head! – Maria Fernanda “OMG @TotherAlistair u broke me!! I am seeing holes in everything that we are doing. Hugh improvement opportunities!!” – Supriya “I wanted to be challenged – and I was not disappointed – participants got kicked out of their comfort zone before morning tea on day one, by lunchtime you knew there is no going back.” http://www.betterprojects.net/2014/03/advanced-agile-review.html “He set out to challenge all of our preconceptions about agile, deconstruct them, and then help to rebuild our understanding using different lenses he’s crafted from his deep and extensive experience. The result being, that people walked away with more insight, understanding and approaches with which to advance their own agility and those of the people around them.” http://www.tabar.com.au/advanced-agile

Re: Waiting for Arrival

Lovely.

It seems to me that the text of this blog describes a more active engagement with a challenge than the title implies. More “Working towards arrival” than “Waiting for” it.

-by Seb Rose on 12/14/2014 at 11:35 PM


“I don’t know you in the distance. I only know you near me”
“I was shaking this morning as I was shaking now”

Are those yours?
They are beautiful

-by Gabriela Szulman on 12/15/2014 at 11:00 AM

Thank you, Gabriela. Those are special poems. They arrived at a unique moment, which I don’t expect to repeat.


An aspect of the “Release” concept the authors talk about in the book sounds a lot like Czikszentmihalyi’s “Flow.” Interesting book. Thanks for the tip.

-by Todd Webb on 12/16/2014 at 4:31 PM

Re: Poems

“I don ‘t know you in the distance, I only know you near me”
“I am shaking this morning as I am shaking now”

Are those yours?
So beautiful

-by Gabriela Szulman on 12/15/2014 at 10:20 AM

Yes, thank you. Those were unique moments. I might hope that someone else finds similar moments. Alistair

Waiting for Arrival

“Usually we try a scene or a moment so many different ways that the right choice makes itself known. And everybody in the room know what that right choice is. We work until we find that”.
— (Abigail Adams, director of People’s Light and Theatre Company, “Artful Making” p. 19)

That moment, I call Arrival.


http://www.paulbondart.com/paintings/thumbnails/cropped/In-Between-Here-And-Not-Here.jpg
(What a great title for what this blog post is about!)

“Failure isn’t the right idea. In rehearsal, the iterations all interact with each other. The current run-through provides the main material for the next run-through. Each trial is a necessary step on the way to what’s good and essential to the final success. To call an essential step toward success a failure merely tortures language. What’s more, the word “failure” applied to routine work could poison the growth of Ensemble, a quality of group work essential to rehearsal, and to artful making.” — (p xxviii “Artful Making” Rob Austin & Lee Devin)

What is Arrival?

“When Stella burst into tears … even the director had to get a grip. Something big was happening. Something beyond work came into the room. The stage manager called, “And, lights.” There followed a moment of hush, a deep and happy silence of accomplishment. Then, from someone in a far corner of the room came … the flat, empty drawl of NASAspeak: “Ahhh, Houston? We have play.” ” (“Artful Making”, p.13)

Arrival: Not Experiment, Not Discovery

“Not Quite Experiment, Not Quite Discovery” _(“Artful Making”, p.22) :

“Scientific experiments look for causal relationships … ‘Discover’ suggests there is a right choice waiting to be found.”

so what is it, then?

“the importance of individuals’ efforts to release themselves from restraining preconceptions and inhibiting circumstances; the intensity and interdependency of these collaborations; the understanding of “wrong” choices as advances rather than setbacks; the sense of the emerging product as something better and more interesting than anything a single person could have preconceived, greater than the sum of it’s parts; an unpredictable result that in retrospect seems investable.” (“Artful Making”, p.14)

“Touch a hot stove and burn your hand… touch it again and burn your hand again… same injury, no new information. ... you may need to make the same mistake many times on the way to an innovative leap. Burning your hand is a small price to pay for a good idea.” (“Artful Making”, p. xxiii)

“every choice an actor makes enters the play and, in some form other, remains there. ... experience becomes the material that future choices are made of. ... People are people, and they don’t have Delete keys. ... Inclusion of past actions into the materials of creation is the force that drives emergence” (“Artful Making”, p. 21)

What he calls “emergence” there, I call Arrival here.

Communication is touching into shared experience

There is a little fake being inside us who demands too much attention: the little ‘i’, the little voice from our prefrontal cortex, commandeering our vocal cords to make sounds to our heads that sound like they are our voices speaking. Except the little ‘i’, utilizing only the vocal apparatus, denies external access to the many parts of our brain and bodies that also are looking for expression. Our minds are full of ideas we can’t know about as long as we listen to ourselves.

We have to act.

As we act, interact, act by accident (tripping over a bump), act in accidents (different modalities of expression take differing lengths of time to reach the outside world, creating accidents of timing between different parts of our bodies), we do things the little ‘i’ inside our minds did not have any idea existed. We create new realities, new moments of experience. Shared experiences, if we are with a group.

Each act, action, enters our shared experience, becomes a building block for future actions.

“by running-through many times with variations and accidents, we build new shared experiences, new building blocks for action and for communication.” (“Artful Making”)

If one of us burns his/her hand on a stove several times in a row and does not learn, that by itself becomes a ‘meme’ for the person, for the group. Thus, “the current run-through provides the main material for the next run-through.”

The moment of arrival is when something shows up that we recognize as being an advance.

And so we wait for it. We act, we experiment, we stumble, we shout, we make nonsense, we do the same dumb thing 10 times in a row. We are waiting.

And it arrives.

Arrival

I am using the word ”arrival” to name that thing that was never there in the first place, but which we suspect can be there, but we can’t find it, we can’t hunt for it, we can’t discover it, we can’t invent it. We have to wait for it.

Arrival happens to poets, to musicians, to comedy writing groups, to theater groups, to programmers and designers discussing an idea together.

Constructing an Arrival

“Artful Making” (Austin & Devin) describes constructing an arrival as well as I have ever seen (the description of working on the play Streetcar Named Desire.) They describe theater as a process that generates arrival moments reliably, although no one knows when the arrival will arrive.

The only way to get the arrival to arrive is to play, to experiment, to push things past their boundaries. To do dumb things, crazy things, the same thing over and over; and wait for some hitherto quiet part of someone’s being to express itself in some way that has not been seen before.

As a person in a design group, I watched as one person mis-wrote what someone said, and someone mis-read what was written, and what he said was just what the group needed to hear. It was the winning idea. I have often seen designers discuss an idea at a whiteboard, and every time one person made a comment or drew, another person said, “But in that case…” and made a new, great observation. In minutes, the group designed something that none of them could have designed alone.

You don’t say Sorry in hackey sack

Hard for me to not say “sorry” when I drop the hackey sack. But I had to learn it. It’s part of hackey sack to drop the hacky sack. You can’t have a group saying “sorry” every time they drop the sack.

You don’t say “sorry” when making a fault in an improvisational dance. You might restart, or you might continue, but “sorry” isn’t in the game.

Similarly, in constructing an arrival, you don’t say “sorry” for each version that doesn’t produce an arrival. You just add to the stack of available material and keep going.

You can say Thanks and High-Five

I wish to thank Diego Fontdevila, who pushed “Artful Making” under my nose years after I had first seen it, but just at the moment when I could read certain sentences in it. Thanks, Lee Devin, for pushing Rob Austin about the topic of “failure”, and to the two of them for getting the book published. Just these pages alone changed my life.

For my part, I immediately put this new knowledge of Arrival to use. I dance a lot, but am terrified of making mistakes with a partner on the dance floor. Just after reading this book, I went to a free-improvisation tango class, and although still sweating, stopped saying “sorry” and only froze once on the dance floor, viewing now each faulty move as just a brick in my construction of an Arrival for better tango dancing. My partner, too, (since we were taking turns leading in this free-form tango class), had to learn to not say “sorry” with faulty moves, but to replay or just continue after each one. We do, however, high-five after great accidents and arrivals.

cheers,

The Center of Agile Advanced Masterclass

The Center of Agile Advanced Masterclass with Alistair Cockburn

An inspiring 2d w @TotherAlistair learning #AdvancedAgile from the 1 guy in the world capable of teaching it… Now time to repack my brain. – Tyson

“Can I say on a personal note , since I came back from the AAD it has relit the fire in me , I can only thank you for providing the spark.” -Tony

“It was a great experience and definitly changed my mindset. Anyone doing scrum should take the class and get some “agile inspiration” :)” – Kosta

Move to the next stage by learning from one of the authors of the Agile Manifesto!
  • Level: Intermediate and Advanced :
    • This is the course for you if you have been doing agile development for 3-15 years, have read many of the books and are ready for a deep dive into what agile development is all about.
    • This is the course for you if you have been doing agile development for 1-5 years and want to amp up your capabilities to the next level.
    • This is not the course for you if you are a hot shot programmer or PM and want to strut your stuff.
    • This is not the course for you if you are looking for an introduction to agile, basic of Scrum, CSM, or project management (attend instead the Fundamentals of Agile Development public course (discussion: Re: Agile Development Class with Crystal and Certified ScrumMaster)).
    • This is a course for those who want to inquire and to get themselves ready for whatever comes next.

This is the advanced masterclass in agile development from industry guru Dr. Alistair Cockburn.

The Center of Agile Advanced Masterclass with Dr. Alistair Cockburn

Modern “expert” agile practitioners have mastered the practices – but not why they work, not how to adjust practices to situations, not how to approach new and surprising situations, not how to apply agile practices to non-software projects, not how to incorporate results from other fields back to their own projects, not how to tailor the practices to different organizational cultures. This advanced course from industry guru Dr. Alistair Cockburn addresses those areas.

  • In this discovery-filled course,
    • Learn why agile works, in software or outside of it,
    • Learn how to articulate and deal with the weaknesses in agile development,
    • Test yourself and your partners with the Test-Driven Carpaccio exercise.
    • Learn to reduce risk and maximize results by viewing design as a Knowledge Acquisition activity.
    • Practice backing up your recommendations with solid theory, not just an appeal to authority,
    • Learn how to plan and track larger, more complicated projects using Story Mapping or Blitz Planning (time permitting),
  • . . . and most of all
    • Come face-to-face with yourself, your strengths and your weaknesses, as you confront one situation after another with equally inquisitive classmates.

Bring along bring gnarly problems you have been challenged with and objections as to why agile can’t work in whatever context: We will work through those problems as a class, using the skills taught in the class.

This is not a course for the beginner or the faint of heart. Expect to do homework, expect to be put through your paces, expect to dialog and argue, have your beliefs challenged.

You need not prepare for the course, but you will get more from it if you have read Agile Software Development: The Cooperative Game and “The Seven Properties of Highly Successful Projects” from Crystal Clear: A Human-Powered Methodology for Small Teams prior to the start of class.

At the end of the course, walk away with a rich, robust set of tools for approaching your project and organizational situations.

Instructor:

Dr. Alistair Cockburn (pronounced Cō-burn) was voted one of the “All-Time Top 150 i-Technology Heroes” for his work in creating and steering Agile software development. He co-authored the Manifesto for Agile Software Development and the “Declaration of Interdependence,” created the first Agile Software Development Conference, co-founded the Agile Project Leadership Network, served on the board of the AgileAlliance, designed the Crystal family of agile methodologies, and co-founded the International Consortium for Agile. Three of his books have won Jolt awards and been listed in “The Top 100 Best Software Books of All Time”. He consistently receives high ratings for his presentations and courses. Much of his material is online at http://Alistair.Cockburn.us.

What Students Wrote After Attending One of Alistair’s Master Classes: “Huge emotional learning about self.” -@ksteffe “I’m breathless from drinking from the firehose.” – Resetley & Restarting Best part about the course. “Alistair’s mastery of the course/industry content and ability to respond and support any student requests.” – Scott Wolfe ”#AdvancedAgile with @TotherAlistair is like walking in as an agile Jedi then some dude with pointy horns pulls a double ended light sabre.” – Todd “Inspiring, I will be going back into the cooperative game with a refreshed strategy and some new moves” – Kelsey ” Best part of the course: Learning how to ask questions without jumping to a solution” ” It was interesting to see how we forget important known stuff when we face a crisis” – Pavel ” THE forum to test every theory and stalk even the sacred cows of agile practice ” – Kim “I don’t care what they say, being with you is a pleasure.” – CM “Really great master class with @TotherAlistair” “Mind exploding like crazy.” “Definitely inspired to up my game!” “Ego obliterated, mind expanded, much to ponder after the masterclass. Thanks” “I had to call in sick the next day.” “Huge emotional learning about self.” -@ksteffe “I feel a lot better this time around after coming out of Alistair’s class. Learned a lot and my mind is clear” “I’m breathless from drinking from the firehose.” – Resetley & Restarting Best part about the course. “Alistair’s mastery of the course/industry content and ability to respond and support any student requests.” – Scott Wolfe “Alistair is the Chuck Norris of Use Cases. Applying use cases to the project life cycle has re-instilled my faith in project management.” “Alistair provided a non-intimidating environment to allow for mind stretching. I feel like I’ve been put through a mental wringer but all in a way that can only improve my value for my team.” –Nicole Hopkins “The deep level of experience Alistair brings to the training adds significant insight to the domain.” –Dave Pugmire “Excellent course… well worth the investment of time and money. I especially appreciated Alistair’s depth of knowledge and breadth of experience. I will be watching for other courses offered by him.” –Chuck Stoner “Course goes well beyond novice level in terms of cognitive complexity. Pushes into analytical/critical thinking skills.” –Cristina “I want my boss, my boss’s boss and my boss’s boss’s boss to take this course.” “I would certainly agree with Alistair’s characterization of what he does being the height of voodoo witchery and other eldritch practices, at least to the untrained eye. Stretching the metaphor even further I’d also say that some of those that he coaches are left with a feeling much like what I would imagine a visit to the voodoo shaman would engender – glad that he was there to help, but equally glad that he has taken his rum and chickens elsewhere.” –Jonathan “In 20+ years of attending courses in software development this has been the best course. Great balance of theory and lab (hands on) work.” –John W. Cooley “Fantastic course for practitioners who want to think about what they do and improve their teams. Cuts through the Agile hype to communicate deep insights and truly useful techniques.” – Kay Johansen “This course was simply amazing! Dr. Alistair Cockburn has one of the best minds period. I have so much to learn. This course should be mandatory for all project managers.” – J. K. “Excellent job of imparting knowledge without creating dogma.” – J.S. “Your teaching style/positioning as a methodologist fit exactly what I was looking for, not dogma but the base/broad thinking behind the practices” – Anastasia “Alistair combines the theory with practical experiences and exercises that reveals the hows and whys of agile.” – Richard Thomson “It is great to be able to tap into Alistair’s years of experience!” – Sean Landis “It was great to take this course from one of the acknowledged leaders in the field.” – Jeff Romine “Very enjoyable course. More please.” “Exceeded my expectations! Great class; excellent presenter!” “Alistair is a wonderful instructor! Very knowledgeable, easy to listen to, and funny!” – Anne Marie Kimberling “OMG @TotherAlistair u broke me!! I am seeing holes in everything that we are doing. Hugh improvement opportunities!!” – Supriya “I wanted to be challenged – and I was not disappointed – participants got kicked out of their comfort zone before morning tea on day one, by lunchtime you knew there is no going back.” http://www.betterprojects.net/2014/03/advanced-agile-review.html “He set out to challenge all of our preconceptions about agile, deconstruct them, and then help to rebuild our understanding using different lenses he’s crafted from his deep and extensive experience. The result being, that people walked away with more insight, understanding and approaches with which to advance their own agility and those of the people around them.” http://www.tabar.com.au/advanced-agile

The Center of Agile Workshop

An exciting, informative day for all roles and at all levels, learning the Center of Agile from one of the founders of the Agile movement.

  • An opening lecture to catch you up on the state of product and software development right now.
  • Two fast-moving activities, cooperating, developing, drawing, sharing, in short, being agile.
  • A facilitated small-group discussion to work out what to do with all the insights from the day.

Set your organization’s expectations for agile adoption, create a shared experience for everyone to refer back to, ask difficult questions of one of the founders of the agile movement.

Duration: One or two days, as desired. The one-day version is level-setting; the two-day version contains specific techniques.

Level: Beginner.

This is an excellent day for an entire organization, from execs to receptionists, business to technical people, novices to experts (yes, even the experts will learn!). Use it to level-set vocabulary and expectations for agile, to create a shared experience to refer back to, and create new small improvement initiatives within the organization. General comment heard during this workshop is, “I wish my boss were here!”

Location: Taught on location, by request

Class Size: Any (class sizes have varied from 20 to 150 people)

Course statement: What we call agile is an attitude giving priority to efficiency in the process, and maneuverability with respect to changing requirements, technology and team. Having the agile attitude does not yet make for a successful project. The team needs a certain understanding of core practices: incremental scheduling and staging, reflecting on its working style every few weeks, concurrent development, paying attention to the strong points of humans without building on their weaknesses, among others.

Course Description:

This workshop, based on the award-winning book, Agile Software Development, and on Crystal Clear: A Human-Powered Methodology for Small Teams, consists of a mixture of lecture, exercises, and discussions. These are constructed to give attendees a sense for how it feels to be doing some of the key practices as well as what how it feels not to do them. The techniques reviewed are valuable in carrying out any kind of project, not only agile ones.

The workshop is non-technical in the sense that it is non-programming; it is technical in that it contains material that is core to the modern life of professional developers, project managers, and business managers. Because the issues cover all aspects and stakeholders in the development process, this workshop is recommended for business executives, project managers, business analysts and developers alike.

Lecture:

The opening lecture introduces key concepts and ideas needed to make use of modern agile development:

  • Decisions flowing through an organization,
  • Cooperative games of invention and communication,
  • Disciplined learning,
  • Craft,
  • Trimming the tail on product development.

Communication Exercise:

In this 90-minute activity, the room is broken into teams of 5-7 people, each with specifiers and artists. The specifiers are given a drawing to have the artists reproduce, but they can only use simple-text messages to communicate. The teams go through this activity three times to learn how to reflect and improve during a project, how to spot impediments to communication and collaboration. This is a high-energy, highly enlightening activity.

Carpaccio (Programming) Exercise:

In this 120-minute activity, people work in pairs (or trios) on a computer with either a programming environment or a spreadsheet. Programming is best, spreadsheet usage also works. Any development language and environment is OK, whether JavaScript, .NET or Java, whatever. The spreadsheet version is used when there are not enough programmers present.

The purpose of the exercise is to show business people how to slice their business requests thinly enough to fit into any size of iteration or sprint, and to show programmers how the best programmers currently work, working in 15- to 45-minutes episodes that result in fully functional, end-user-visible, tested code ready to be checked in and used.

This is an intense exercise that shows business-side and development-side people, both, how to work in the fine-grained style needed for modern agile development.

Facilitation Discussion:

In this final activity, discussion groups are formed, to discuss what parts of the agile concepts learned during the day will be easy to adopt, and which will be difficult. This section of the day serves so that every person can discuss how to take the day’s learnings home.

Some learnings you might take away:

  • What software development consists of, and how considering software development as a “cooperative game of invention and communication” sheds light on common project failure and winning strategies.
  • The characteristics of human cooperation and communication, and how those shed light on program documentation, UML and offshore development.
  • The role of trust, amicability and goal alignment in a project team.
  • The role of individual talents and personalities; how to adjust for them.
  • The speed of the project is the speed at which ideas move between team members; harness this idea with office layout and information radiators; avoid or handle offshore development.
  • How to adjust different projects for their specific characteristics.
  • How and when to reflect on what is happening to the project while it is in motion.
  • How to understand incremental development and keep it under control.
  • What concurrent development looks like in practice and how to think about it.
  • Named agile methodologies: XP, Scrum, Crystal – how they take advantage of the core properties of the cooperative game principles, how they differ from each other and how to extract and combine them.

The day is very full. Depending on where the group gets more deeply focussed, some of the topics may get more or less emphasis

Alistair Cockburn

The Instructor: Dr. Alistair Cockburn.

One of the original authors of the Agile Manifesto. Voted in “The All-Time Top 150 i-Technology Heroes” for his work in Use Cases and Agile Software Development

Internationally renowned strategist, author of the Jolt award-winning Agile Software Development and Writing Effective Use Cases, he co-created the Agile Manifesto, the Declaration of Interdepen-dence, the Agile Project Leadership Network and the International Consortium for Agile. Dr. Cockburn is an expert on agile development, project management, process design, use cases, and object-oriented development.

Contact:
Alistair Cockburn, totherAlistair@aol.com, +1.801.824.1211

What engineering has in common with manufacturing and why it matters

Alistair Cockburn, Humans and Technology

Humans and Technology Technical Report HaT TR 2006.04, Sept 6, 2006.

Abstract

Engineering – software engineering in our case – is remarkably like manufacturing, once we shift to view the unvalidated decision as the unit of internal inventory. The parallels with manufacturing allow us to borrow from results in manufacturing theory to understand how to better structure our software processes, and the teams involved.

Preface

It is generally considered frivolous to compare software engineering with manufacturing. Manufacturing consists (so the argument goes) of making the same thing over and over, while engineering is about making something different each time. In software engineering, the design is the hard part, production is the easy part, often as easy as pressing CDs or publishing onto the internet.

Once we shift to considering decisions as the items being handed from person to person, gathered into larger and larger assemblies, then suddenly, there is a very real parallel between design and manufacturing. This is useful to us because manufacturing has been heavily studied over the last hundred years, and we can learn from their lessons.

In what follows, I shall talk about software development, but it should be clear that the same argument applies to every team design activity, including theatre, publishing, engineering, and much of business.

Waiting for Decisions

We start by recognizing that in team design activities, people wait on each other for decisions.

Figure 1 shows a simplified view of the dependencies between people in software development – it is missing the feedback loops, in particular (which are shown in Figure 2).


Figure 1: People wait on other people for decisions

In Figure 1, the dependency of one person on another is shown with a large gray arrow. The person at the head of the arrow is waiting for or being handed decisions from the person at the tail of the arrow. A small pyramid represents the actual decision being passed from one person to another.

In Figure 1, we see

  • business analysts and user interface (UI) designers waiting for users and sponsors to decide what functions and design styles they want,
  • programmers waiting for business analysts to work out the business rules, and UI designers to allocate behavior to different pieces of the user interface,
  • testers waiting for programmers to finish their coding.
    A nice thing about considering individual decisions as connecting people is that we can move away from stereotypes about how a company’s process or decision-making activities ought to look like, and instead focus on what it actually looks like – what decisions actually get made by which people, who is really waiting for whom.

There is no ideal software process any more than there is any ideal manufacturing process. Each company has its own strong-minded people, who make a disproportionate number of decisions that might, in other companies, be made by people in other roles. Each company has its own shortage of UI designers, programmers, testers, or even sponsors, which causes its process to have a certain characteristic shape – people working overtime, or perhaps sitting idle because other people can’t get their work done fast enough. Each company has its own reasons to have a large, external test department, or perhaps no test department at all.

Figure 2 shows the feedback loops in a common sort of organization. The feedback loops complicate the math, but don’t change the basic results we’ll be discussing.


:Figure 2: The decision-dependency network showing feedback loops

Different Bottlenecks, Different Processes

In any organization, we can find a backlog of decisions stacking up at some particular work group. The presence of that stack indicates a bottleneck, a place limiting the speed of the overall team.

Bottlenecks are of great concern in manufacturing, and have received much study. The obvious thing to do is to increase the capacity of the bottleneck group – hire more people, or better people, or get better tools, and so on.
Sooner or later, however, the organization hits its limit as to what it can do to improve the speed of the bottleneck group. At that point, what comes into play is the process definition itself.

Figure 3 shows three different, but fairly typical organizations.

  • In the first (top) organization, there are not enough user interface and database designers to keep up with the work. We see decisions stacked up at their work centers.
  • In the second (middle) organization, there are not enough experienced programmers, and work requests stack up in front of them.
  • In the third (bottom) organization, the users and sponsors are notably missing from the discussion. What happens in these organizations is that the business analysts and UI designers end up making the business decisions, and then sending those decisions (or running products) back to the users and sponsors for comment. The picture shows those requests for review stacking up in front of the users and sponsors.
  • The third (bottom) picture also shows the programmers and database designers sending decisions back and forth to each other. Both groups need to come to agreement on the domain model and how that will be represented in the code and in the database.


Figure 3: The optimal process varies with the decision-dependency network

There are two points to draw from these pictures:

  • First, they should be using different processes;
  • Second, these drawings help us to see how those processes should be different.
    The organization at the top, assuming that they can’t or won’t hire more UI and database designers, should look at ways to have programmers and business analysts pick up sections of the UI designer’s and database designer’s work. Even assuming that UI design work is specialized, parts of that work can be automated, carried out by assistants, or handled by programmers.

In the second organization, the reverse is more the case. The programmers, being few and probably inexperienced, might need to have much of the problem “digested” for them as much as possible.

In a case that I participated in, we recommended that the business analysts write quite detailed use cases (not containing the user interface, but containing the business rules more explicitly than we otherwise might), and also the layouts of the data needs, plus discussions of different business scenarios. The business analysts then sat with their respective programmers as they started on each use case, and discussed the use case, the scenarios, and the data. They left the paperwork with the programmers, and made themselves available for discussions and tutorials as needed.

The process in this second organization was aimed at minimizing the trouble the programmers had to undergo to understand the problem at hand. This is quite different from the process in the first organization.

In the third organization, the process might call for prototypes and early samples to be produced and put in front of the users and sponsors. Since those people have the least availability, the material should be as fully prepared as possible. Also, since close collaboration between the programmers and database designers is required, those teams should be seated together, or at least have frequent meetings and joint design reviews.

The purpose of this article is not to make these recommendations, which any good manager or consultant would be likely to spot, but to show how they come from mapping and considering the bottlenecks in the flow of decisions through the organization.

Lessons from Manufacturing

To complete the mapping to manufacturing, we use the unvalidated decision as our unit of internal inventory, or “work in progress” (WIP). Each decision that has been made but has not yet been validated by someone (the sponsors, the testers, the marketplace) is still “pending”, still waiting to show its quality.

Move Inventory Out

The first lesson that we draw from experiences in manufacturing is to keep work-in-progress (WIP) down. This is as important in software development as it is in manufacturing, since every decision that is pending costs the organization money.

The value of decisions decays over time:

  • Each “requirement” is a decision based on a business climate; when the business climate changes, the decision may become incorrect. If the software isn’t yet earning value for the company, the requirement is waste.
  • An “architecture” is a decision based on technology and business. If the technology changes before the software is earning value for the company, those decisions are waste.
  • Each line of code is a decision based on requirements, domain, technology and aesthetics. If anything causes it to become obsolete before the software is earning value for the company, it is waste.

To the extent that it is not earning value in the business, each decision loses value and quality with time. The more decisions stuck inside the pipeline, the more decaying “inventory” the organization is carrying.

Inventory stacks up quickly, even exponentially. Assume for reference an organization that is so fast that when a new requirment arrives, they can implement and deploy it by the next morning:

  • The company with a 1-day turnaround has about 1 day’s worth of inventory lying around the office.
  • The company with a one- to two-week turnaround has about 10 days worth of inventory lying around the office.
  • The company with a quarterly delivery system (assuming they deploy from fresh requirements every quarter) has about 100 days of inventory lying around.
  • The company delivering a 3-year project has 1,000 days of inventory (decaying) around them.
    The message, in software as much as in manufacturing, is: get the inventory out the door and earning value! Find ways to shorten the pipe.

Move Small Amounts, Continuously

The second lesson to draw from manufacturing is to reduce the size of the transfer batch between working groups. That is, move small amounts, continuously.
Figure 4 shows two ways of transfering work from the programmers to the testers.

In the first case, the programmers hand over 100 lines of code (each week, let’s suppose). The testers get a regular weekly arrival rate of about 100 lines of code, and have to integrate and test them against the rest of the system and against the known defect log.


Figure 4: Feed systems run more smoothly with small transfer sizes

The actual size handed over will vary, of course, and the actual length of time needed to work through the new code will also vary. That variance is very important.

The lower part of Figure 4 shows the programmers handing about 1,000 lines of code to the testers (each quarter, that would be, to keep the rate of production about the same as in the upper picture).

The problem with the lower picture is that all 1,000 lines of code show up at one time. The responsiveness of the testing group suddenly becomes much more variable, with the large arrival of an unknown number of bugs of varying sizes.

Equally bad, when they start handing over bug reports back to the programmers, the programmers suddenly see a large spike on requests on their input queue coming from the testers (see the arrow in Figure 2, from the testers back to the programmers). The programmers are now juggling two input queues, requests for new features and requests for bug fixes.

Manufacturing lines have experienced and studied all the above, and concluded that these sorts of feed systems run best when small amounts of work get handed from one group to the next. The ultimate goal is to hand over just one part from one group or person to the next.

Toyota pioneered this idea in its lean or just-in-time manufacturing lines. They aim for continuous flow, the flow of just one piece of material from one person to another (what to do when a queue backs up is the subject of another lesson we’ll see).

It is not clear exactly what continuous flow might mean in software development. Some decisions affect large parts of the system, and some decisions can’t be validated for a long time. However, the experiences in manufacturing are backed up by both mathematical models and experiences in agile software development.

It is rare to find development teams able to deploy fresh requirements every week, but I have been able to find a few teams who both deploy weekly and have a low enough defect rate that they get only one or a few requests a day. On one team I talked with, a person was assigned each day, on a rotation, to handle any incoming requests, whether bug reports or requests for small enhancements. That person would stop other work, do the work and redeploy the system before rejoining the main group. The average time to redeployment was half a day. With such a small, steady flow of requests on the feedback queue, the team was able keep from being diverted from their main assignment.

Cross-Train People

The lean and agile manufacturing literature contains the recommendation to cross-train people at adjacent stations. The idea is that when a small bubble of inventory grows at someone’s input, the neighboring person having a spare moment steps over and works it down. In this manner, small variances in work flow can be evened out and not disturb the organization’s overall flow.

We see this in software development, when programmers help testers, user interface designers and business analysts, or when business analysts help testers. Unfortunately, programming is a technical enough activity that UI designers, testers and business analysts are unlikely to be able to help the programmers. Programmers can help other programmers, though. We see front-end developers, middleware developers and back-end developers helping each other in some companies when one of the groups has a sudden bump in work.

Extend the Network

All of the above ideas are good – so good, in fact, that a company using them soon finds that their bottleneck lies somewhere in their supply chain, whether their sponsors, their subcontractors, or their distributors. These companies start to draw the queuing or decision-dependency network for the larger system in which they sit, and start including their supply chain partners in their discussions.

Toyota is well known for working with its suppliers. Less well known are cases of software development groups doing it. The same team I referred to earlier, having the the daily programmer rotation for fixes and enhancements, also wrote automated acceptance tests for their subcontractor’s parts of the system. They reasoned that their time was better spent writing automated acceptance tests and catching bugs on arrival than debugging and finding those same faults in the integrated system when their supplier’s code broke it. The supplier was, of course, surprised but delighted to find they didn’t have to write the automated acceptance tests.

The lesson from Toyota and the other companies who are streamlining the wider network is: the wider the network of ‘we’, the faster we all go..

Who’s Writing About This?

Once you see the mapping between manufacturing and team design activities, suddenly a lot of literature becomes available.

Toyota’s production system, also called The Toyota Way, Toyota Production System, and lean manufacturing, is widely documented. The Toyota Way Fieldbook [1] is a good place to start.

The application of lean manufacturing principles to design work is described in Managing the Design Factory [2]. The Poppendiecks have appled lean manufacturing principles to software development [3, 4]. Agile Software Development [5] contains an experience report from a software product company (Tomax) that is including its customers directly in it dependency network.

Goldratt wrote about bottleneck stations in manufacturing [6] and then widened the disussion to constraints in general (theory of constraints) [7]. David Anderson applied the theory of constraints and queue size to software projects [8]. I have written about strategies for dealing with bottlenecks that have reached their capacities [9].

Summary

It is not immmediately obvious that software development teams can learn from manufacturing. However, once we map the network of dependencies between people in a software development organization and make the shift to think of unvalidated decisions as comprising the “inventory”, then the parallels become startlingly clear.

We learn 6 lessons from the parallels:

  • Drawing the decision-dependency network helps us see the bottleneck stations, where decisions-to-be-made are piling up.
  • From the different decision-dependency networks in various organizations, and their varying bottlenecks, we can see how the optimal process varies from organization to organization.
  • Move inventory out: Decisions decay over time, so it is important to find ways to shorten the pipeline from arrival of a request or decision to the deploymnet of the system.
  • Move small amounts, continuously: Transferring large batches of inventory (decisions in our case) between workers causes unpredictable variations in the organization’s output. It is better to move small numbers of decisions more often. This reinforces the idea of incremental development, with the smallest increment size possible.
  • Cross-train people: When people can help each other across specialties, they can move quickly to eliminate small bubbles in each others’ input queue, thus smoothing the organization’s output.
  • Extend the network: By widening the network included in the dependency analysis and queue-size reduction, a company can smooth its own input stream and simplify its working.
    h2. References

  1. Liker, J., Meier, D. The Toyota Way Fieldbook, McGraw-Hill, 2005.
  2. Reinertsen. D., Managing the Design Factory, Free Press, 1997.
  3. Poppendieck, M., Poppendieck, T., Implementing Lean Software Development: From Concept to Cash, Addison-Wesley, 2006.
  4. http://www.poppendieck.com/publications.htm
  5. Cockburn, A., Agile Software Development: The Cooperative Game, 2nd Edition, Addison-Wesley, 2006.
  6. Goldratt, E., The Goal,
  7. Goldratt, E., What is This Thing Called the Theory of Constraints?,
  8. Anderson, D., “Managing Lean Software Development with Cumulative Flow Diagrams,” May 2004, BorCon 2004 (online at <).” target=”_blank”>http://bdn1.borland.com/borcon2004/article/paper/0,1963,32096,00.html>).
  9. Cockburn, A., “Two Case Studies Motivating Efficiency as a "Spendable" Quantity”, Humans and Technology Technical Report HaT TR 2005.00..

What is Sprint Zero?

Rumor has it that Sprint One delivers software, in just two weeks. Some teams prefix this with Sprint Zero, also two weeks long, in which a starting architecture is created. I have even seen talk of Sprint Minus-One, where something else happens.

Where did Sprint Zero come from, and what is it, really?

I have an apocryphal story to offer for the origin of Sprint Zero, which a Senior Source tells me is very close to the what actually happened.

There was a village of earnest Sprinters, who shunned any form of advance thinking. Code! Code! Code! was their byword.

A senior designer fell afoul of the villagers, because he was caught spending time working out what his team should do, looking at the technology and the choices for architectural decisions, trying out some ideas.

The villagers gathered at his door one day, carrying pitchforks and flaming torches, to carry him off, burn him at the stake, tar- and feather him, and run him out of town on a rail (all of those, of course, one after the other).

The designer, thinking quickly, said, “But this is, don’t you see, ah, the necessary part of Sprint Zero! That’s when we get things lined up for Sprint One!”

And the villagers turned to each other and said, “Sprint Zero! Why of course! Of course there is a Sprint Zero.”

And they went off and instituted Sprint Zero on all of their projects.

.

Postscript: Some time later, there was another designer, who also wanted to do some investigation that was longer than two weeks long, something he felt had to be done before Sprint Zero. When the villagers gathered at his door with pitchforks and flaming torches, he said, “This is Sprint Minus-One, don’t you see?”. And they carried him off, burned him at the stake, tore out his heart, tarred and feathered him, and ran him out of town on a rail, in that order.

.

Scrum is a tool for running a project. Sometimes investigation precedes a “project”, because having a project already implies having made certain decisions. Those decisions are made before the project is running. Or, possibly, the project is funded, but there is investigation about aspects of the project that are good to do before development starts.

Like:

  • Who are the stakeholders in this project, and what do they care about?
  • Who are the users we care about, and what do they care about?
  • Who are our competitors, and how do we get around them?
  • What is the narrow market segment we should address first, before we take over the world? And what does that segment care about the most?
  • Is there technology suitable to our purpose? What might it look like?
  • Can we get good enough people to build this?
  • Where is the funding going to come from?
  • What should we be trying to build at this point?

This is “The Swamp”. The sticky, gooey period where sometimes nothing happens, and sometimes everything happens too fast and you have to sort it out. Answering all that may not be a two-week sprint.

In Programming as learning too late, and dialoguing with the design and Disciplined Learning (discussion: Re: Disciplined Learning), I describe how having an idea of what to build and how to build it, grows over time. During the Swamp Period, the team still has a bad idea of what to build, who to build it for, how to build it. In this period, they are are building up understanding and sorting out ideas. There can be a lot of staring at each other and saying, “What do you think?” “I don’t know, what do you think?”

There are a number of good exercises for how to get out of the swamp: a Exploratory 360, user surveys, stakeholder analysis, user trailing, and others; and some of those can and should be put on a schedule. However, to be honest, I don’t think I’ve seen a single case where it either all fell into a two-week period, or even a neatly predictable period. That’s why it’s called a Swamp.

Once you get out of the swamp, then there is information and direction, and you can put things on periodic time boundaries with code coming out. An architectural spike or a Walking skeleton (discussion: Re: Walking skeleton) makes good sense in the first such period; getting the integration and delivery systems in place, having the team complete an assignment together so they learn how to talk together.

I don’t particularly know that it needs a special name like “Sprint Zero”; it’s just work, as usual. Making incremental progress toward knowledge and toward deliveries. But if there is a sprint zero, that’s probably what’s in it.

Exploratory 360

Strategy: Exploratory 360°

At the start of a new project, usually during the chartering activity, the team needs to establish that the project is both meaningful and they can deliver it using the intended technology. They look around them in all directions, sampling the project in all ways to test for viability and meaningfulness.

The entire Exploratory 360°for a Crystal Clear project takes a few days up to a week or two if some new and peculiar technology is to be used. Based on what they learn, they decide whether it makes sense to proceed or not.


http://3.bp.blogspot.com/-JgLdIONG8js/U9klrHBPKTI/AAAAAAARoEU/mAbX1hs6MH0/s1600/Mercedes-360-0.jpg

Extract from Crystal Clear: A Human-Powered Methodology for Small Teams
Alistair Cockburn, 2004

Strategy 1.Exploratory 360°

At the start of a new project, usually during the chartering activity, the team needs to establish that the project is both meaningful and they can deliver it using the intended technology. They look around them in all directions, sampling the project’s

  • business value,
  • requirements,
  • domain model,
  • technology plans,
  • project plan,
  • team makeup,
  • process or methodology (or working conventions).

(They may check other aspects of the project, but these are the usual.)

The entire Exploratory 360°for a Crystal Clear project takes a few days up to a week or two if some new and peculiar technology is to be used. Based on what they learn, they decide whether it makes sense to proceed or not.

Business-value sampling consists of capturing, with key stakeholders, what the system should do for its users and their organization(s). This should result in the names of the key use cases for the system, along with the focal roles the system should serve, the personalities and functions it should present to the world.

Requirements sampling consists of low-precision use cases that show what the system must do, and with what other people and systems it will have to interact. Often that drafting exercise turns up interfaces between organizations or technology systems that had not formerly been identified.

Concurrently or from the use case drafts, the developers sample the domain-model. This sample serves to highlight the key concepts they will be working with, the core of the business, the programming and discursive vocabulary. It also helps the team to estimate the size and difficulty of the problem at hand.

The developers create a technology sampling, running a few experiments with the technology. Ward Cunningham and Kent Beck call these Spikes (see http://c2.com/cgi/wiki?SpikeSolution). The assignment is to ask: Can we really connect these technologies? Will they withstand the intended loads? Can our developers master the technologies in time? The programmers perform the smallest programming assignment needed to make it clear the project is not running down a blind alley. The experiments establish the technical plausibility of the project.

The team creates a coarse-grained project plan, possibly from the project map or a set of stories and releases. It might be done using the blitz-planning technique described later in this chapter, or XP’s planning game. This plan is reviewed by the Lead Designer, the Executive Sponsor and the Ambassador User to make sure the project is delivering suitable business value for suitable expense in a suitable time period.

Finally, the developers discuss their process, either in a Reflection Workshop or a Process Miniature.

***
Here is the story of one project that failed three elements of the Exploratory 360°:

During the technology sample, the developers found, much to their surprise, that they could not connect the organization’s email system to their intranet and browser system. It was not clear how they could actually deliver the software services they had envisioned.
The project planning sample showed the cost to be about three times higher than the Executive Sponsor was interested in spending.
The business value sample showed that the organization should not allocate very many developer resources to this problem; it would be better outsourced (or simply bought), and the development team allocated to a more significant business problem.

You would think that canceling or outsourcing such a project would be obvious to all involved. However, the developers were keen to experiment with the new technology, and therefore kept the project alive, under the guise that this project would serve as a good learning vehicle. Fortunately, the executive sponsors paid attention to the Exploratory 360° results, stopped the programmers, outsourced the project, and put these key developers on a project of much greater value to the organization (which, I am happy to add, they enjoyed much more).

Agile in tables

©2011 Alistair Cockburn

Humans and Technology Technical Report HaT.TR.2011.01.

I’m not much of one for running a project in tables, but other people are, and we are now at a point where some of the tables are looking interesting and useful. Here are a few I would consider using:

Risk-Value-Tail table

The RVT table shows a set of projects, features, or user stories against their risk or knowledge-acquisition aspect, their value aspect and their tail or gloss aspect (see Trim the tail (discussion: Re: Trim the Tail)).

Figure 1. Three stages of developing a feature: risk, value, gloss.

Project/feature/story Risk (knowledge) Value Tail (gloss) P1 Whatever it might be Whatever it might be Whatever it might be P2 Etc. Etc. Etc. P3

The purpose of the RVT table is to expose the 3 schedule aspects of each project, feature or story, thus allowing the team to tackle them in any order they might prefer – column-first, row-first, or some funny diagonal.

The good thing about this table is that it permits all possible implementation schemes, and maps to the trim the tail (discussion: Re: Trim the Tail) curve.

Knowledge acquisition table

As I’ve been exploring the front section of the knowledge-acquisition or Trim the tail (discussion: Re: Trim the Tail) curve, four risk or knowledge acquisition areas keep showing up:

  • Business risk: Are we building the right thing?
  • Social risk: Can these people build it?
  • Technical risk: Will all the parts of our idea work together?
  • Cost/schedule risk: Do we understand the size and difficulty?

These can be gathered and framed as a single question: “What are we trying to learn right now?”, which is quickly followed by, “What is the cheapest, fastest way to get that information?”

We can put these into an extension of the RVT table just for the risk/knowledge question, the Knowledge Acquisition table:

Project /feature /story How can we learn what we should really be building? How can our people learn how to work better together? How can we learn where the design isn’t working? How can we learn how much money, time it will take to get done? F1 experiment experiment experiment experiment F2 etc etc etc etc F3 F4 Feature Grade table

This table is due to Jeff Patton and his grades of quality idea (link?), turned into a table by Gery Derbier.

Grade each feature or story separately as F (not acceptable), D (minimally acceptable but not something you would want to ship), C (minimally usable), B (quite nice), and A (top quality).

One strategy for using this idea is to get every mandatory feature to a C level first, before trying to get any of them to a B or A level. Then use the time available to get the important features up to B or A as desired. In principle, this delivers the highest “perceived” quality of the final product.

Feature Grade F1 D F2 C F3 F F4 C Micro-incremental development (“hexagonal architecture”) table

This table comes from the Hexagonal architecture (discussion: Re: Hexagonal architecture) description, particularly the “barn door” image.


Figure 2. Hexagonal architecture “barn door” sequence.

This picture suggests developing features in three stages:

A Test harness functionality loopback in lieu of database
B Real UI functionality loopback in lieu of database
C Real UI functionality real database

(where the UI and the real database can be added in either order)

I first came up with this table when contemplating a serious piece of multi-site development on a large portfolio of projects, being shipped to multiple countries, where we were not sure what the quality of the programmers might be.

In order to regulate the development and keep track of the quality, we proposed setting into place the following rules:

1. Every developer must first check in A, with tests. The build manager or iteration manager or customer or product owner would reject any feature checked in without it being (a) free from the UI and (b) with automated tests

2. Then the UI and the database are added in any order at any time, with the caveat that the A version must still run at all times.

This yields, as with the Risk-Value-Tail table, a rich set of possibilities for sequences in which the feature set might be implemented: all A sections, then B, then C, or some of each, as long as the two rules are followed. It also allows the UI and database work to proceed somewhat disconnected from the feature set, allowing them to go slower or faster, as needed.

Here is the resulting HA table:

Feature Test-app-loopback +UI +database F1 Due/done date Due/done date Due/done date F2 Due/done date Due/done date Etc F3 Etc etc etc

Four tables is a lot of tables – I’m not sure how to use them together… However, one of them might do your project some good, perhaps even a couple of them. Write me and tell me if you use them.

Alistair

Re: Foundations for Software Engineering

I like very much your point that large or new “true” engineering projects are as likely, or more so, to fail spectaculary (such as the Boston “Big Dig”). There seem to be two classes of classic engineering – the new, large and risky projects, that require new or adapted methods, untried materials, or unprecedented scale. These seem as subject to delays and cost overruns as software projects (the Boeing Dreamliner a latest and dramatic example). Then there are the more prosaic engineering/construction projects. One example is a friend of mine who many years ago left chem engineering school for a job as a chem engineer, and complained to me that all he did was look up values in tables, type the numbers into a computer, and document the results. All the experimentation had been done, he was working on known procesess, and was not asked to invent or improve. His work was on time, but not creative. Another example is my home remodel – the designer chose materials based on his knowledge, put the pieces together, and a computer program told him if it would stand up, its ovearll R-value, and if it met code. He did not invent any materials or processes – he used what was available and already tested, and he was on time.

Is software development like either type of these projects? Certainly more like the former, though many want it to be more like the latter. But to do that would require an inventory of tested components and local codes. It seems to me that I’ve been hearing about this since objects were invented.

Capers Jones makes a different, very interesting comparison – to medicine, not engineering. He wonders if the progression of medicine from a craft to a profession is the better model for creating software “engineering”. Of course, no one considers physicians engineers. And, indeed, although medicine is vastly more professional than it was 100 years ago, can anyone deny that it is still way too costly, not always driven by science (witness the struggles for “evidence based medicine”), often still dangerous (hospitals can be a very unsafe place to be) and subject to enormous litigation costs due to alleged and real malpractice? Perhaps medicine is indeed the better comparison, which offers us some hope (medicine has developed practices and is somewhat based on science), and we can learn from medicine’s continued efforts to create more evidence based practice and to encourage practioners to practice already known working methods (like washing one’s hands!).

-by Jerry Kickenson on 1/12/2010 at 10:05 AM


Hi Alistair,

In case you’re interested, I’ve just posted a real-life example of one of the “conversations with the situation” that Schon talks about. It’s my “stream of consciousness” as I was doing some coding. http://www.agilekiwi.com/other/news/conversation-with-the-situation-a-software-example/

I’d be interested to know if you’ve seen any other software examples. (I have found them hard to Google for, with no success so far.)

-by John Rusk on 2/24/2011 at 6:43 PM


Nice, John! good thoughts, good outcome, happy the customer was also happy :). cheers – I might be back in Oz in June, Alistair

-by Alistair on 2/27/2011 at 9:49 PM


Again :o) GREAT thanks for your knowledge

-by Arquitectura DSN_XP on 4/25/2012 at 10:19 PM


Thanks for the intriguing article, had to download Pelle Ehn’s doctoral thesis (link below, should anybody else be interested).

Just a minor note, it is not surprising at all that “Schön’s account meshes perfectly with Pelle Ehn’s description of software design as a language game [...]”. Ehn is discussing Schön in the very paragraph the citation comes from.

http://urn.kb.se/resolve?urn=urn%3Anbn%3Ase%3Aumu%3Adiva-62913
http://umu.diva-portal.org/smash/record.jsf?pid=diva2%3A580037&dswid=-7493

-by Florian on 12/4/2014 at 11:52 AM

Thank you, Florian. Alistair

Re: What engineering has in common with manufacturing and why it matters

There are no images in the places where they are indicated to be as Figures 1 through 4. Can this be corrected?

-by Dean on 4/27/2011 at 2:44 PM


This is brilliant, thank you. I spent some time at Eastman Kodak, who pretty much wrote the book on 20th century manufacturing. They tried to leverage this hard won knowledge in software development and quality assurance with, in my opinion, limited success. They, along with everybody else, missed the idea of a decision being the “consumable” in the software engineering processes.

I think this article contains an excellent basis for actual doingness in improving software development. At the same time, I feel a little uneasy with the idea that we necessarily want to follow the example of modern manufacturing too far. After all, don’t the products of this technology include mountains of dead cell phones, plastic bottles, computers, and cars?

The idea of software craftsmanship, for example, seems to owe something to 18th century manufacturing model with its journeymen, masters and novices. I am not sure this is the best approach in every case, nor do I think that the “good enough for version 1” approach used by the big software manufacturers works all the time either.

In any case, I think the idea of a decision bottlenecks is important, and may transcend the question of mass production vs craftsmanship. Thanks again.

-by Andrew Cowenhoven on 4/28/2011 at 11:00 AM


hi, Andrew … Trim the Tail (discussion: Re: Trim the Tail) or Design as Knowledge acquisition (discussion: Re: Trim the Tail) fits nicely in here with your objections… the decisions thing helps us borrow from a vastly different field; Design as Knowledge acquisition (discussion: Re: Trim the Tail) should help reduce the mountain of unused cell phones. Talk not given at TEDxUoU 018.ppt shows all 5 sections. cheers, Alistair

-by Alistair on 4/28/2011 at 6:52 PM


I have gone back and read Alistair’s work on comparing engineering and manufacturing many times over the last few years and each time I re-read it I become more convinced that this is the way organizations need to be constantly thinking if they want to continuously improve their performance. Keep the unvalidated decisions to a minimum. The value of a decision decays over time. These are powerful ideas that organizations need to keep reminding themselves of. If I make an architecture decision, but I can’t get value out of this decision through the pipeline fast enough it will turn from potential value to technical debt. The trick is to find that right balance of just enough architecture decisions so we don’t start patching bad code, but not so many architecture decisions that we can’t get value to the customer fast enough. Right now in February, 2013 many organizations that do business with the US DoD are struggling with this question given the certain future defense budget cuts.

-by Paul E. McMahon on 2/17/2013 at 10:03 AM

superthanks, Paul. Highest compliment possible. Alistair

While decisions and unvalidated decisions is somewhat useful, we do not need to utilize them directly as a means of measurement-and-control (e.g. you cannot manage what you do not measure). There are other useful structures that indirectly control the size and flow of decisions.

The issue is scope.

1. Build small-useful: Useful to the user means faster less stale deliverables: Big is buggy and buggy takes time
2. Build in layers: Must-have, Need-to-have, Nice-to-have—work in priority order: Less layers is more bugs
3. Build what you know: Do NOT build what you have to invent if you can avoid it: Unknown-unknowns produce bugs
4. Document well: Relearning what you already designed and worked out details wastes time: Unknown-unknowns produce bugs
5. Design-by-Narrative: What you write is real and what is only in your head is open to change and change is one source of bugs
6. Appropriate flexibility: Flexible is complex; complex is open to bugs
7. Build for efficiency: Slow code is usually violating some point above and probably has bugs as well, which is not Cheaper or Better
8. Build for independence: Dependent code defies reuse, so decouple where it makes sense and organize decoupled code in libraries for easy discovery—and DOCUMENT!

By going after small and agile steps one is rewarded with less complex, more known-known, and easier to test, easier to debug, less to refactor, and more deliverables, which means happy client.

There are other matters which are born of the technologies we choose to use and write with. The choice of technology matters.

For example: Our system is written in a language called Eiffel, which has a technology called: Design-by-Contract™ (or DbC for short). DbC is a form of testing brought in from the code of the external testing paradigm, where testing lives in the code, under the awareness of the compiler, and means that code is tested by rules applied in-situ and in-context rather than external. As such, programmers are encouraged to heavily write contracts that protect the integrity of the code and then write just enough external testing to touch the code-and-contracts together. DbC has the innate quality of ensconcing business and technical specification logic (rules) right into the code, where it is does its validation-through-testing job continually and NOT just when external tests are executed, even though external tests are written for regression purposes.

Finally, we have found that specialized code generation is well worth the effort! Our rule is this: If you write the same code pattern more than 3 times, it is time to: A) Refactor or B) Generate. The first and best response is to use the tools of OOA/D to get good abstractions. Yet, there are times when code generation just makes so much sense. We have found that our code generators take tedious jobs of weeks and reduce them to a day or even hours. With more than 500,000 LOC and 4,500 classes in our system to-date, the notion of Code Generation is a God-send!

So—let’s circle back and talk about manufacturing lessons brought into a software project paradigm. Yes—decisions and unvalidated decisions are the consumables that go into the product, but they are not the product. Managing decisions well, does not put a lock on “project-success”. However, keeping these consumables in mind and limiting them by designing, building, and testing smaller software wigits—with an eye on useful deliverables—is the key to keeping choices and decisions being made as small as the thing being built.

The lessons above have been hard won by thoughtful examination of my own project management over the last 24 years. I hope something in what I have written helps!

-by Larry Rix on 12/2/2014 at 10:22 PM

Re: Thinking before programming

Hi Alistair,

RE “In the mid-1990s, there was a minor movement called “Design from the client’s perspective”, I see a similarity, if not an equivalence, with SICP’s (http://mitpress.mit.edu/sicp/) programming by ‘wishful thinking’: see first three paragraphs of _sec_2.1.1" target="_blank">http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html#_sec_2.1.1 and bottom of http://c2.com/cgi/wiki?WishfulThinking

Philip

-by Philip Schwarz on 11/30/2014 at 12:57 PM


Alistair,

in the previous comment I left, how annoying having to drop the p from http to get round the fact that hyperlinks are disallowed!

Philip

-by Philip Schwarz on 11/30/2014 at 12:59 PM

Philip, you have no idea how much that has saved this site from spam, porn and hacking, just disallowing links by casual visitors. Well worth the annoyance, from the perspective of the site manager!. Alistair. For future URLs, just leave off the http:// part and put the rest in. I can add the http:// back in for you.


I also see a similarity between “Design from the client’s perspective” and what Alan Shalloway calls “Programming by Intention”: http://www.netobjectives.co/system/files/essential-skills-programming-by-intention.pdf.

-by Philip Schwarz on 11/30/2014 at 1:22 PM


Thank you, Philip. ... Am researching those links now, thanks. Alistair

-by Alistair on 11/30/2014 at 2:56 PM


Interestingly, there even is a much more elegant solution than those you came up with.

I played with this problem together with Jon Jagger about 3 years back. After solving a few times in pretty much the same way, we discovered a much simpler and yet more expressive solution while taking a break with Indian food.

I think your observation about the role of thinking is reinforced by this story, but maybe even more so: What about collaborative thinking and about IFDD (Indian food-driven development)?

(Let me know if you want a hint for the most elegant solution I’ve found on many many tries)

-by Johannes Brodwall on 12/1/2014 at 2:54 PM


Hi, Johannes – Please DON”T tell me the solution!!. This is such a cute problem, with so many super approaches possible, I don’t at all want to know any of the other ways of solving it! I look forward to years of fiddling with it :).

. Alistair

-by Alistair on 12/2/2014 at 12:06 PM

Programming as learning too late, and dialoguing with the design

Peter Naur neatly observed that programming involves building a theory of how the world works, and another about how the solution work. Some years later, Don Reinertsen and Phil Armour wrote that one of the outputs of design is the knowledge of how to do the design. (Ref to pages DAKA and DAKA2)

In 1994, Ward Cunningham said (as we were driving down the mountain from Snowbird after the WOOD workshop there (Hi, Ward!)), that he would not criticize a programmer’s code, because the code represents the knowledge of the person at that moment, and of course that knowledge changes over time.

The problem that comes along with this neat truth is that it is AFTER we have programmed and shipped the code that we finally have the whole picture in our heads and can go, “Duh! That’s how we should have built it.”

A few days ago, I opted to try mixing Thinking Before Programming with TDD (discussion: Re: Thinking before programming). It was a satisfying experiment.

Then this morning I woke up and said, “No! There’s such a much simpler way to do this! It has a 2-way mirror symmetry! I’ll just code the top right quadrant, which is just letters along a diagonal, and then mirror it left and mirror it down, and be done. Much simpler than the tray nonsense! ”

So I jumped up (after eggs and coffee, of course, and a shower, and some Facebook, and some email, but in principle), and started programming.

The new code is not bad. It seems to me simpler than the first one. That is, “of course” (thanks Naur / Reinertsen / Armour). And I didn’t even bother with TDD, since this was not a TDD exercise, but just printed the output to screen, as I often do; still doing nano-incremental development, but using my eyes instead of test cases. I just kept on typing into the same test case, adding a few lines as I went, so you can see the whole program development as you read. To save you a click it is right here:

def test_kind_of_actually_everything p __method__ s = '_'*0 s[0] = 'A' p s p '--------------------' puts # "A" x = 0 s = '_'*x s[x] = 'A' p s p '--------------------' puts # "A" c = 'B' alphabet = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' x = alphabet.index c p x s = '_'*x s[x] = c p s p '--------------------' puts # 1 # "_B" (0..x).each { |r| s = '_'*x s[r] = alphabet[r] p s } p '--------------------' puts # "A" # "_B" x=2 (0..x).each { |r| right = '_'*(x+1) right[r] = alphabet[r] left = right.reverse p left + right } p '--------------------' puts # "__AA__" # "_B__B_" # "C____C" x=2 (0..x).each { |r| right = '_'*(x+1) right[r] = alphabet[r] left = right.reverse left = left[0, x] p left + right } p '--------------------' puts # "__A__" # "_B_B_" # "C___C" x=2 (0..x).each { |r| right = '_'*(x+1) right[r] = alphabet[r] left = right.reverse[0, x] p left + right } (0..x).each { |r| right = '_'*(x+1) right[x-r] = alphabet[x-r] left = right.reverse left = left[0, x] p left + right } p '--------------------' puts # "__A__" # "_B_B_" # "C___C" # "C___C" # "_B_B_" # "__A__" p 'and now, finally, char in, chars out' puts def diamond c alphabet = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' x = alphabet.index c (0..x).each { |r| right = ' '*(x+1) right[r] = alphabet[r] left = right.reverse[0, x] p left + right } if x>0 (0..x).each { |r| right = ' '*(x+1) right[x-r] = alphabet[x-r] left = right.reverse[0, x] p left + right } end puts end diamond 'A' diamond 'B' diamond 'C' diamond 'D' # "and now, finally, char in, chars out" # # "A" # # " A " # "B B" # "B B" # " A " # # " A " # " B B " # "C C" # "C C" # " B B " # " A " # # " A " # " B B " # " C C " # "D D" # "D D" # " C C " # " B B " # " A " # end end Dialoguing with the code

Figuring out that the beautiful code you just shipped is actually rather baroque-roccoco ornate and belongs in a dust-bin is pretty depressing. Thanks to Ward for saving us with his kind observation that the code is a reflection of our knowledge at that moment.

But this blog post is about 2 things, not just one. What comes next isn’t necessarily bad, it’s just “different”.

Reference here Donald Schön’s book The Reflective Practioner, in which he talks about how designers “dialogue with their design” to improve it. He gives many examples. These days it is not uncommon to hear programmers talk about how they dialogue with their code (Ron Jeffries, for example, says this in his unfolding of the same diamond puzzle).

And it happened to me in this case, so clearly that I could name it at the moment it happened.

At the 2nd to the last step in the programming, I had the top half of the diamond, and my key insight of the morning had been to reflect it downwards.

But at that particular moment in programming, i was feeling lazy. I had not been storing, but rather had been printing the diamond parts as I went along, so there was nothing to flip. I would have to go back and do something to the already running code to store stuff so I could flip it over. I didn’t feel like doing that.

Looking at my code, I could see that all I really needed to do was to copy the code for the top half:
(0..x).each { |r| right = '_'*(x+1) right[r] = alphabet[r] left = right.reverse[0, x] p left + right }

and use it for the bottom half exactly, only needing to invert the array index:

(0..x).each { |r| right = '_'*(x+1) right[x-r] = alphabet[x-r] left = right.reverse[0, x] p left + right }

From the standpoint of thinking and typing, this was less work. And it seemed about the same clarity as whatever else I might do.

So I switched designs at that moment. What Donald Schön said.

Learning too late; and dialoguing with the design. Q.E.D.

cheers

Thinking before programming

A long time ago, in a university far away, a few professors had the idea that they might teach programmers to think a bit before hitting the keycaps. Nearly a lost cause, of course, even though Edsger Dijkstra and David Gries championed the movement, but the progress they made was astonishing. They showed how to create programs (of a certain category) without error, by thinking about the properties of the problem and deriving the program as a small exercise in simple logic.

I was a latecomer to their work, I studied it in the 1980s, and used the method on live code only twice, but both times in circumstances where debugging would have been a nightmare (writing in assembler, setting bits in words, unrolling the loop, jumping into and out of the loop). The code produced by the Dijkstra-Gries approach is tight, fast and clear, about as good as you can get, for those types of problems.

Fast forward to XP and TDD, which, when practiced well, involve a different kind of thinking – not about the problem, but about the code. TDD has become a pablum to avoid thinking. Programmers using TDD are so often invincibly convinced that developing a program using TDD will produce the best code the fastest.

I have been wondering about combining the two for some time.

The advantage of the Dijkstra-Gries approach is the simplicity of the solutions produced.
The advantage of TDD is modern fine-grained incremental development. In the 1980s, we derived the program, typed it in, and it worked. If it didn’t, as in, we made typos and stuff, there was the usual debugging.

What happens if instead of typing the whole thing in at once, we “grow” the program using the TDD introspection about the code, the benefits of adding only a few lines at a time (to catch typos) and the automated-tests?

I ran across Seb Rose’s blog post http://claysnow.co.uk/recycling-tests-in-tdd and thought that problem would make a good trial.

  • Given a letter, say, ‘C’, produce a diamond of letters and spacers like this

What struck me in Seb’s recounting of people’s approach to the problem is they first get the ‘A’ case working:

‘A’

Then they shuffle around a bit to get the ‘B’ case working:

. A .
B . B
. A .

And then all the work that they did so far is of no use to them whatsoever when they hit ‘C’, because that’s where all the complexity is. In essence, they have to solve the entire problem, and throw away masses of code, when they hit ‘C’.

It reminds me of the story of incremental development and jumping to the moon:

Step 1: Go out and buy really good sneakers.
Step 2: Do warmup exercises.
Step 3: Jump really really really high, like, to the moon.

So, this is not the interesting form of incremental development. What would Drs. Dijkstra and Gries have to contribute?

Stage 0: Reflecting about the problem.

Let’s look at the problem for a moment and see what we can learn. To simplify things, let’s use numbers instead of letters. (Letters are just base 26 numbers anyway, and neither I nor my compiler are good at base 26). We’ll start from 0.

  • For a request for letter/number x, the end result is a table with 2x+1 rows and 2x+1 columns. (x about the centerline, x below, and the centerline itself).
  • How many spacers are needed between the starting and ending letters on a row?
row # spacers 0 0 1 1 2 3 3 5

Aside from that pesky zero case, there are (2x-1) spacers. Actually, in a funny sort of way, for row 0, there are (2*row-1) = -1 spacers!
huh. Maybe we can get that A to backspace or something and just print on itself twice. That would be good.
I’ll make use of this, I’m sure. I’m pretty determined to get rid of that nasty aberration on the first and last row.

  • How many leading and training spacers are needed?

Let’s look at the letter ‘C’ or the number 2 (we started at zero, right?)

row # spacers 0 2 1 1 2 0

ok. (x-row) spacers are needed per row.

That’s about the math there is. Drs. Dijkstra and Gries would probably do some iterator-toward-zero thing at this point, but I want to pause and look at some possible structures that could be useful.

Looking for structures.

I keep thinking the inner letters are the “interesting” part (to the viewer). I am thinking that there is some sort of a tray that holds the key phrase ‘B…B’ or ‘2…2’ for example, and the tray has the payload letter/number on the outside and the spacers in the middle

Then this tray is placed between two bumpers that keep it in place.

This little metaphor is looking useful. To fill the tray, I need to put the payload at the first and last positions of the tray, and just leave the rest empty.

And here is where some nice little magic happens: “first and last positions” of a tray with only one slot in it (think ‘A’), are the same slot!

So if I put the ‘0’ or the ‘A’ into the first and last positions of the tray that is 1-wide, then that is the same instruction but getting a different-looking result as when doing the same on a tray that is, say, 5-wide, as for ‘C’ or ‘2’: ‘C…C’ or ‘2…2’.

cool. By the way, the tray is of size (2* row)+1, cuz we have the two payload characters to put in. (and in the case of the zero row, the two characters just happen to land on each other, no problem, the math keeps working out :).

This now suggests a different incremental approach to this problem than Seb’s experiences describe, one in which the increments each produce something interesting, without having to just start over each time.

Starting development.

So the very first test, the very first code, the very first increment will be to fill a tray with that symmetry, but regardless of how big the tray is! It will pick up all the cases, 0..N, without having to make some separate, false start with the zero thing.

The code will be something like

tray[0] = tray[tray.size-1] = r

Of course you didn’t see that, because this is TDD, and you’re not allowed to type any code ahead of a failing test, but yes, it will look something like that.

More interesting is that while our first test is the fairly obvious:

def test_01_fills_first_and_last_slot_in_tray fill_tray( [nil], 0).should == [0] end

our second test comes without changing any code, just “recycling the test”, as Seb calls it (sorry, it’s a mystery this should need a name), and just making slowly sure the formula actually works as advertised:

def test_01_fills_first_and_last_slot_in_tray fill_tray( [nil], 0).should == [0] fill_tray( [nil, nil], 1).should == [1,1] end

and so on just to make sure our little tray works as intended:

def test_01_fills_first_and_last_slot_in_tray fill_tray( [nil], 0).should == [0] fill_tray( [nil, nil], 1).should == [1,1] fill_tray( Array.new(3), 2).should == [2, nil, 2] r = 3 fill_tray( Array.new(r+1),r).should == [3, nil, nil, 3] end

So this was the heart of the mystery, and it’s solved in one line, without IF statements, in our first test. Big smile.

Next tiny increment, create and fill a tray of any size correctly:

def test_02_makes_and_fills_tray_of_any_size make_and_fill_tray(0).should == [0] make_and_fill_tray(1).should == [1,nil, 1] make_and_fill_tray(2).should == [2, nil, nil, nil, 2] make_and_fill_tray(3).should == [3, nil, nil, nil, nil, nil, 3] end

Next are the bumpers. They need to be (x-r) big, that’s easy. And gluing them onto the tray is also easy, nothing big going on here. At this point we actually have a full row in the diamond, row r in diamond of size x.

So here are the next tests:
def test_04_glues_bumpers_to_tray_making_complete_row_in_diamond make_row_in_diamond(0,0).should == [0] make_row_in_diamond(1,0).should == [nil, 0, nil] make_row_in_diamond(1,1).should == [1, nil, 1] make_row_in_diamond(2,0).should == [nil, nil, 0, nil, nil] make_row_in_diamond(2,1).should == [nil, 1, nil, 1, nil] make_row_in_diamond(2,2).should == [2, nil, nil, nil, 2] end

The lower half of the diamond

We’re making screaming progress here, but deferring some nastiness about the bottom half of the diamond.

It turns out we can use the same trick vertically as horizontally, and simply write the row twice, starting from the top and the bottom of the table. This neatly picks up both the case of only 1 row, and the center row which appears only once.

The key code is

d[ r ] = d[ 2*x-r ] = row_contents

and the tests are simply that everything works.

def test_07_digit_diamond_fills_correctly p __method__ digit_diamond(0).should == [ [0] ] digit_diamond(1).should == [ [nil, 0, nil], [1, nil, 1], [nil, 0, nil] ] digit_diamond(2).should == [ [nil, nil, 0, nil, nil], [nil, 1, nil, 1, nil], [2, nil, nil, nil, 2], [nil, 1, nil, 1, nil], [nil, nil, 0, nil, nil], ] end

And that’s basically the end of the story. Coding in slices, it took me 7 slices to get the diamond, with no backtracking or unraveling, and no funny IF statements and special cases.

Number are easy. How about letters?

It took me another 7 slices to go from number-in-numbers-out to letter-in-letters-out, but none of that is really interesting or different.

You can look at the code and how I wrote each run separately at https://github.com/totheralistair/LetterDiamond1

Pages