Written by Jamie Monday, 25 October 2010 13:02

There is nothing to writing [code]. All you do is sit down at a typewriter and bleed.
Hemingway.
If we start with the premise that engineering is ‘the strategy for causing the best change in a poorly understood situation within the available resources’ (Koen) then it becomes easy to see why pedagogy matters to the software community.
In 2000 I worked for a company called Razorfish where I met a guy called Bobby Montalvo. A couple of years earlier, in about 1998, when I was still a student, I had messed about with a test-driver using reflection. Basically, I looped through a test class and executed all the methods beginning with ‘test’. Therefore, when I stumbled across JUnit I knew what it was doing (and via its architecture, I saw what was wrong with my own). Bobby had given me the gang-of-four book and we used that and JUnit to guide our designs. When I got to Covast, in about 2002, I hooked up with my second mentor, Andre Ruiter. Two years older, a touch wiser, and I am sure a pain in the ass, Andre helped me with the design of my little web-server (not doing much more than dealing with images in the body and supporting only put and get, the design reflected the protocol: stateless and simple). He also gave me the white book, XP Explained, which I dismissed outright as rubbish. The ideas did not fit my mental model and therefore they were crap. I was unconsciously incompetent, living in a state of oblivion. At about the same time, I was going back over the gang-of-four book and coding up one pattern per week.
I left Covast and went to Accenture via one more start up. I graduated to XP and Scrum, perfected what I knew about RUP, and was well on track with my career. In 2005 I went to SPA, a conference in England. Nat Pryce and Steve Freeman were there with their earlier version of JMock. My world shifted again. This summer Gerald Weinberg helped me with an essay. Over on Linked In, Gene Bellinger and co. hold together a good systems thinking group.
Why do we do it? Do we know that all our situations are poorly understood and therefore it can be as wise to read as to code? We learn when we teach, and so are we selfish? Or does the community react to itself? Are we all scratching itches?
All of the above, Corey Haines would say. I met Corey on Saturday at his Code Retreat over at Amsterdam’s Hogeschool. I was late, just a touch, and arrived to one small room absolutely rammed with developers and machines (more Macs than Dells). Backpacks and winter jackets were strewn everywhere. I was wet, and hot, and outside, up fourteen stories, black clouds swirled across Amsterdam dwarfing her like pieces of lego under a king size duvet.
Corey’s retreat was simple enough. Conway’s game of life has four rules for cellular survival, death and birth. Corey wanted the group, in pairs, test first, to implement the rules. He asked the group to mind the tenets of the code retreat: 1) The tests must all pass; 2) the names must be good; 3) the code should be small, a couple of lines per method; 4) there must be no duplication. Conway’s rules were projected onto the wall, and whoosh! everyone was off coding and arguing like mad. After the first iteration, just 45 minutes, the group debriefed in the hall. They chatted, talked about lessons learnt, pairs separated and reformed with a new partner, all code was deleted and the exercise began again.
There were some unconscious grumblings. (‘This problem can’t be solved in a day!’/‘This example doesn’t lend itself to learning TDD.’) At work, our earliest attempts at TDD will involve discussions and compromises and design decisions. So, the simulation gets the participants used to that. The problem can be solved in a day, but at 10 in the morning because of the rank lack of progress made it was hard to see.... we don’t know what we don’t know.
We moved on. Tests got smaller... one group hit on the business rules for a cell’s life. That pair split up and the meme travelled around the group like a flea in a pack of dogs. As that meme went in one direction, the idea that you don’t need a grid of coordinates came in the other. Just as evolution does not work constantly but in leaps, so too did the group’s understanding of the problem. They were coding to discover and those discoveries came in bursts. What they say is that design tends towards stability if there are intermediate steps. It was these steps that the group were finding.
Corey claimed to be teaching us about test-driven-development, pairing, and what I call the ‘Field of Dreams’ principle: if you refactor it, reuse will come. And, indeed, he did teach that. But, he did something else, something on the side and on the quiet. He showed the dangers of analysis paralysis and, via an exploration of the design space, how to get around it. He showed how ideas cross pollinate within in a group and that you don’t creep up on a solution but pull it out of the ether in fits and starts. He showed that faith is a necessary component of design (and therefore, to master design you must master yourself and the anxiety that lack of closure lends itself to).
The final thing Corey - and Andre, and Bobby, and all the other engineerings who dedicate themselves to the growth of others - taught us was this: somebody’s got to step up. Somebody’s got to run the workshops, teach the juniors, to buck the trend from simplicity to idiocy that we are seeing now. Somebody’s got to raise and hold the bar in its new position. Somebody has to remind the community what it forgot: software development is hard.
Why do we do it? Maybe we do it because we can and because we should. Because we are responsible for the growth of our own generation and the one coming after us. Conway’s cells survive because of their rules but we live and die, rise and fall, by our own hand. That is a choice we can make.
Acknowledgements
Thanks to Corey for organising and then giving his time away like he did. The day was thought provoking, fun, and clearly beneficial to the group. Youngsters also look to be inspired, so let’s not forget how important it was for them to see a senior member of the community functioning.
The next retreat is in Ghent, Belgium, on the 6th of November. After that, Corey will be in Brisbane and Melbourne.
Finally, thanks to all those who went to the retreat and paired with me. So, Frank, Patrick and Bram from Kabisa, Bas and Rachid. I enjoyed the Ruby coaching and I learnt something... that’s one ugly language you’ve got there. And thanks to everyone in the pub. Gee, can you guys booze.
Further Reading
Koen, B. V. (2003) Discussion of the Method. Oxford University Press.
| < Prev | Next > |
|---|
Comments
I particularly liked you calling out & praising the many people who stood up to organize the event.
J
RSS feed for comments to this post