malvasia bianca

Guitar Hero is a music game that comes with a guitar-shaped controller. There are five “fret buttons” on the neck, and a strum button on the body. (It’s somewhat inconsistent on the model it uses – sometimes it pretends to be a guitar with a single string and five frets, and sometimes it pretends to be a guitar with five one-fretted strings.) Pretty standard game mechanics: a song plays, “notes” come down the screen, you have to strum when they hit the bottom while holding down the appropriate fret keys. (With a few minor twists that I won’t go into here.)

The songs are various sorts of rock music; I was only vaguely familiar with most of them, but that doubtless has more to do with my musical background than anything else. Pleasant enough, at any rate. (Miranda particularly likes singing along to “I Want to Be Sedated”.) I hadn’t played any of the songs on a real guitar (other than a few notes of that Deep Purple song); they unaccountably neglected to include “Alice’s Restaurant” as one of the choices.

Four difficulty levels; in the easiest, you only use three fret keys, in the next one, you use four, and in the last two, you use all five. I started on the easiest level, and was pretty unimpressed. A standard button-pressing game; less fun than DDR, and I didn’t like the music as much. (Not that the music was bad, just that DDR’s music is better.) Also ridiculously easy, so I thought I should give the other difficulty levels a try.

The four-fret version was a noticeable improvement. With only three buttons to press, the link between the notes that were playing and the fret buttons was somewhat tenuous. With four fret buttons, however, there weren’t so many glaring mismatches: runs of more than four notes in a single direction are a good deal rarer than runs of more than three notes, for example.

And, actually, playing the game started feeling like playing a musical instrument. To the extent that some of my musical bad habit came back to me: on difficult bits, I was gripping the neck rather too tightly, which is one reason why I could never produce a good vibrato on a violin. The five fret versions (especially the toughest level) felt even more realistic; playing five frets with only four fingers obviously presents certain difficulties, but, with a bit of practice, my fingers were sliding up and down the neck with grace. Quite a lot of fun, really.

Having said that, there were parts of the higher difficulty levels that I didn’t like nearly as much. I really enjoyed richly textured sections. Sections where the notes came faster than the rate at which I was comfortable were not so much fun. There are some techniques that relieve the need to strum all the time, but it’s not so easy (for me, at least) to do those reliably in long fast runs.

And this is where the comparison to a real musical instrument showed problems with the game. If I’m playing a piece on the piano with a tricky fast bit, I’ll concentrate for a while on that part, playing it slowly until the notes are in my fingers, after which I’ll speed up gradually. With the game, however, I didn’t have that option: I had to restart the song from the beginning, at full speed, and hope that I’d do better next time. Which is something I’ve been trained to accept in other sorts of games (albeit not without resentment – see multiple forms in final boss fights without a save point), but here, I just gave up and moved on to songs without such passages, knowing that a better world is possible.

Quite good game. I’m not planning to buy the sequel, and DDR is better, but a lot of fun none the less. Of course, maybe the lesson is that I should spend more time playing piano and less time playing video games…

Now that I’ve finished this and all the sudoku puzzles in Brain Age (good puzzles on the intermediate and advanced levels), I’m back down to only playing two games at a time. Which is much better. That should be enough until Okami comes out in early September; if I’m really lucky, the rumors of a Wii launch on October 2 will pan out. If not, I guess I’ll put more memory in the mac and get Civ 4.

When I first saw Brian Marick’s complaint about the prevalence of the term “leadership” at Agile 2006, my first reaction was “hmm, that doesn’t sound so good, and here I am being part of the problem.” After thinking about it a bit more, though, the Christopher Avery talk that I blogged about doesn’t sound like the sort of thing Brian Marick is bothered by – that was really about responsibility, a concept which is equally applicable to all levels of the organization.

Still, I was pretty sure he was onto something. (Side note – where did I read an article recently complaining (intelligently) about bossism?) But then, a couple of days later, I saw Brian Marick on a stage helping present the Gordon Pask award. So it would seem that my understanding of the “Great Man theory” and his understanding are somewhat different. I guess he’s more focusing on the ills of executive leadership than on other forms of leadership? The team leads the Scrum Master but the organizer leads the XP day participants? Seems a bit odd to me.

This seems to be the focus of his post:

We know how to do software better. It’s the executive’s job to support us in doing that—to clear obstacles out of the way of our practice—and not to lead us. We already know where to go. We know how to do our job. We need to be assisted, not led.

On the one hand, I sympathize with that a lot. I’ve had one notable experience with an executive pushing his pet theories on a development team, and it’s one that I hope not to repeat. I’m a fan of the notion that you should move decisions to the lowest responsible level. And it’s unquestionably the case that people who are doing something out of internal motiviation will work at it much more effectively than people who are doing it out of external motivation.

On the other hand, I can’t uncritically accept the statement “We know how to do software better”. Another past experience that I’d like to avoid in the future involved a project where decisions were supposed to be made relatively communally, yet where dysfunctions seemed to me to hurt the effectiveness of the team’s operation; while I can imagine other solutions to that problem, I’m sure that an effective executive would have stepped in and resolved the issues much more quickly. To be sure, an ineffective executive could well have exacerbated the problem, but I won’t argue that that group as a whole “[knew] how to do software better.”

And just what is the better way that we allegedly know how to do software, anyways? Given the context, I assume it’s agile in some form; my experience is that many/most programmers aren’t particularly well steeped in agile ways of thought, and that, when exposed to those ways of thought, most programmers find some areas they agree with, some areas they are suspicious of, and have good reasons for their suspicions. Also, if we know how to do software better, did we also know how to do software better 10 years ago? Were our answers the same then? Will our answers be the same 10 years from now? Are we sure that teams will always come to those new insights before executives? I’m not. This stuff is hard; I can use all the help I can get.

On the third hand, just who is the “we” who know how to do software better? Agile practices bring in a large number of stakeholders. In particular, even if we want to move decisions to the stakeholders most directly affected by those decisions, a key stakeholder is the gold owner, who is likely an executive. I can understand arguments that, say, the gold owner shouldn’t have much to say about the details of your refactoring strategies. But I think the gold owner might well have a lot to say about the composition, frequency, and quality of your deliverables, or about the reliability of your estimates, and hence has every right to feel strongly about, say, the planning game, frequent releases, and the quality of your test plan.

The most interesting examples I know of of companies that have productively moved decisions to lower levels are Toyota and Semco. My understanding is that, in both cases, executive leadership played a strong role. I won’t say that it was the only factor, but surely we can learn a lesson from that? One of the key agile tenets is the importance of communication; we should embrace productive communication with executives, accept them as potential active resources for change, not limit our vision of their job to simply be “to clear obstacles out of the way of our practice”.

 

After writing the above, now I’m starting to understand why some people say that retrospectives are the single most important agile practice. Communication is key, getting people at all levels to think about how we could best do our work is crucial. And I can imagine how increasing the openness of conversations could potentially have helped greatly with some areas where we’ve functioned at less than peak effectiveness over the last few years. I’m looking forward to our team retrospective on Monday.

I just read Zen and the Art of Motorcycle Maintenance for the first time in more than a decade. I confess to some amount of trepidation: I used to really like the book, and I was afraid it hadn’t aged well.

In fact, the book continues to be awesome. Most novels could not pull off extended expositions/meditations on philosophy or aesthetics; no problem here. Not so much Zen in the book (at least not overtly; I will have to think about how much is there covertly, but I’m not convinced there’s much covert Zen, either), but that’s okay: there are lots of (relatively) popular books touching on Zen out there, but not so many delving into, say, sophists. And the use of motorcycle maintenance is well done. (Not that I know anything about motorcycle maintenance, but I did at least do a fair amount of bike maintenance when I was in high school.)

I’d completely forgotten the “grades are bad” theme from the book. That is an idea that has been embedded into my brain for quite some time now; I’d assumed I’d gotten it from Alfie Kohn (reinforced, of course, by John Holt, but I read him later), but it’s here in all of its glory.

The initial discussions of Quality reminded me of Christopher Alexander on Life, but they developed rather differently. Honestly, Alexander’s idea of Life seems rather more productive than Phaedrus’s idea of Quality, but that’s okay: that’s only one of the many strands that makes up the book, and the strength of the book in no way depends on our agreement with Phaedrus on particulars of philosophy.

I suppose I should read Lila next. I don’t have high hopes for that one: I didn’t like it when it came out, and it seems unlikely that my feeling will have changed in the interim. Still, it deserves one more shot before I give away my copy.

I’ve made a couple of dbcdb changes. Now every page contains a link to let you search for all blog posts mentioning it. Which required a bit of WordPress futzing: it turns out that WordPress doesn’t let you search for double quotes by default. Also, I replaced the ISBN and ASIN fields that were really Amazon links by an explicit Amazon link – it’s not like anybody needs to know ISBNs these days, after all.

There are a few more issues I want to deal with. A while back, I noted that the pages looked like crap in Internet Explorer due to a bug in their CSS handling. That didn’t really bother me too much, but now I realize that pages for, say, books with long titles don’t get wrapped in the way I’d prefer. Since the same fix should handle both issues (stop using definition lists), I’ll take care of that.

The other issue that I want to fix is the handling of books by multiple authors. When I first started this, I had an author class, with a compound author subclass; each of those generated a web page. So you could, for example, see for all books by Christopher Alexander, Howard Davis, Julio Martinez, and Don Corner. When I started using SQL, though, the resulting SQL got a bit messy; Per pointed out a more natural table structure, which would (as a side effect) make it rather harder to generate those multiple-author pages.

So: do I go with the pages suggested by the original class hierarchy, the pages suggested by the SQL structure, or neither? (I certainly shouldn’t let implementation details unduly hijack my page layout.) After thinking about it for a bit, I think that the current compound author pages are hurting more often than they’re helping. I basically never want to see all books by a given set of authors, while it’s not infrequently the case that, when presented with a book by multiple authors, I want to see all the other books in the database that one of the authors has written. So the multiple author pages aren’t helping, and are actually forcing an unnecessary level of clicks.

So I’ll probably deprecate the multiple author pages. (And eventually make the corresponding SQL change, though that’s not particularly urgent.)

Also, I’ll probably get rid of the ‘Own’ link (who cares what books I own?) and reduce my ratings by one. After all, while I would probably rate most books in the world as 1’s (= gave up in disgust), the truth is that I’m quite good at avoiding such books, and the world really doesn’t need to know which books I actively disliked versus which books I didn’t particularly care for.

After which I have further plans, about which more later.

I’ve upgraded to WordPress 2.0.4; let me know if there are any problems.

I can report that Animaniacs holds up quite well. Miranda approves, too.

Miranda’s daycare occasionally goes on bowling trips, and the local bowling alley also handed out cards entitling kids to one free game a day (plus free shoe rental) over the summer, so she’s been asking me if I could take her bowling some time. Which I finally got around to doing today.

Fun. First time I’d been bowling in a while; I was in a league (and even bought my own ball) in, I think, 1999, but basically haven’t bowled since. And I’m still not entirely comfortable with a 15 pound ball; this all meant that, basically, I had no idea where the ball would go and what it would feel like the first few frames.

And I did actually slip and fall a bit releasing the ball; oops. Where the ball would go, however, proved not to be a particular problem. I still seem to be capable of sending the ball straight down the lane to within a half-pin of accuracy most of the time, and to within a pin of accuracy the rest of the time; hurray for muscle memory. Or hurray for turning my arm into a pendulum with a big weight at the end of it. Or something. Not enough to turn me into a really good bowler, but enough to produce 135 and 148 games.

After the end of which my fingers ached, I was a bit sweaty, and I imagine my play would have gone rather downhill if I’d tried a third game.

Nice to do every once in a while; I’ll be happy to go bowling as frequently as Miranda wants. On the other hand, my skill has been at a plateau of around 130 for almost two decades, and (unless my free time drastically increases somehow) I can’t see myself either taking the time to improve that or wanting to play in a league without improving that.

As previously threatened, I asked my team members if any of them would like to take charge of retrospectives. To which I got the response “but that’s not the way to do things: we try to share knowledge and skills wherever possible.” Oh, right – I’m glad somebody remembers that sort of thing, since obviously I’m not up to the task!

Anyways, after a bit of discussion, we decided that it didn’t make sense for us all to go off and read the book right now. So one of us volunteered to read the book, run one retrospective, and rope the rest of us into running subsequent retrospectives, while sharing an overview of the ideas from the book and being available to suggest techniques from the book. In other words, taking ownership of the task without unduly linking that to carrying out the work (or hogging the knowledge). Yay.

I spent this morning hanging out in open space. The first discussion was a followup to last year’s talk by Arlo Belshee on promiscuous pairing. It turns out that a couple of experience reports were presented here on teams’ experiments with the practice. The good news: both teams saw similar productivity/quality/etc. boosts to the team from the original experiment. The bad news: both teams gave up the practice in spite of those boosts, one after about a month and the other after about three months. (The original team had been doing it for 18 months, with no plans to stop, by the way.)

I don’t remember the details of why one team stopped after one month; something about thinking that it’s too hard, or not enjoying it. So it would seem that the practice can, for some groups, bump up against Sustainable Pace. (I got the impression that the original team had a higher tolerance on that front than the norm.)

The story behind the team that gave up after three months is apparently that they’d run into a few team issues after a month or so, which they’d solved, and some bigger team issues after three months, which they might have been able to resolve but were hindered from doing so by management shuffles. Arlo said that his team had also seen big issues surface at around that time, as well; they’d managed to deal with them successfully, and doing so improved their performance.

This is a phenomenon that shows up more generally in lean discussions: once you reduce buffers / cycle times in various ways, problems start to turn up that you hadn’t seen before. It’s not that the problems weren’t there before: they were always there, hindering your progress, but you just hadn’t been forced to deal with them. Which manifests itself in other ways in agile processes, of course – e.g. continuous integration makes breaking the build a much more serious problem than it would be in other environments, but that’s not a problem with continuous integration, it’s a problem with breaking the build! This particular manifestation of the problem does seem scarier, though: in particular, it suggests that a team that wants to try it should probably be comfortable with introspection and retrospection.

After that, I participated in a discussion on what agile might have to learn from open source. About which I don’t have much to report.

I spent the afternoon at a tutorial on retrospectives, run by Esther Derby and Diana Larsen. Retrospectives are one of my current sore spots: I’m bad at running them, but I hear over and over again how important they are. And I believe that, too – I very much want my team to continue improving, and to do so in a collective fashion.

And I’m glad I attended the tutorial: we got some hands-on practice, we got some ideas of other things we could try, and I picked up a copy of their book to get more ideas. So I’m rather more confident now that I can get this to work – if nothing else, I can try format after format and topic after topic to shuffle things around, and I’m pretty sure that something will click with us. (And will then get stale after a few months, after which we’ll be able to shuffle again.)

On the other hand, I still don’t feel that it’s an area where I’m particularly skilled. So now I’m thinking that I should ask my team members if any of them wants to volunteer to design and run retrospectives. If none of them do, fine, I’ll do it myself; if one of them does, that will move more decisions down and there’s a good chance that one of them is more talented in this area than I am. And I’ve got a book full of suggestions for whoever volunteers for that.

Back to work tomorrow. I’m glad I came; certainly useful for me, and I hope it will prove useful for my employer. No revelations, nothing that’s going to have a huge concrete effect on my work, but I learned about and got practice with some useful techniques, and learned a few things about myself. And if, for example, higher-quality retrospectives can cause my team to gain just one extra week’s worth of work over the next year, then that will pay for the conference a couple of times over. Also, being at a conference made it much easier for me to concentrate on the subject: I left the hotel a grand total of twice during the conference, and spent the vast majority of time during the five days thinking about what I wanted to learn, going to talks, thinking about what I’d learned at those talks, and blogging here to get some of those thoughts out. I’ve spent some time keeping up with other tasks or doing reading on other topics, but it has allowed me to be much more focused than I normally am. I wouldn’t want to spend all my time doing this sort of thing (Sustainable Pace again), but doing it occasionally is refreshing.

Thanks to Mark and Marissa, I can report that the warehouse district seems rather more interesting than the blocks of downtown Minneapolis between the light rail stop and my hotel. Certainly more places where I’d want to eat.

I spent this morning at a talk by Mary Poppendieck on lean. It was billed as a tutorial, but there were too many people for that, so it ended up as just a talk. As far as I can tell, the main thing that I missed from its not being hands-on was a chance to do my own value stream mapping; too bad, because I think that’s a useful tool and I’ve never tried it out, but I don’t see it as being directly applicable to my situation.

Pleasant enough talk, but pretty familiar, given that I’d read the Poppendiecks’ excellent book. One thought that it did bring to mind: she brought up the fact that 3M and Google both encourage their engineers to spend a fair amount of time exploring whatever suits their fancy, and gave a queuing-theory justification for this. So: should we institute such a policy at work? What would be the effects, both positive and negative? Does the queuing theory justification really hold up; if so, does it hold up for reasons that are applicable to us?

One concrete situation where I think we might benefit is that one of my coworkers recently posted a list of gripes about our house coding practices on our wiki. I think there’s a lot to most of his points, but it’s hard to find time fixing them; if we had a bit of slack, though, perhaps both he and I would spend a bit of time tackling the issues that bugged us the most, which might help our morale and increase general productivity going forward. Hard to say, though, and I don’t think that’s the sort of benefit that Google and 3M get.

The afternoon talk was a workshop by Ron Jeffries and Chet Hendrickson on “Crushing Fear under the Iron Heel of Action”. The first time they’d given the workshop; an interesting experiment. The core of the workshop involved breaking up into groups where we each talked about some sort of fear we had, and dug deeper into it and talked about specific actions we could take to address the fear. Then we talked about what each of the groups had produced, and talked about common tactics (and, to be honest, had a bit of a therapy session): fail early and often, test your fears, hold retrospectives to address your fears, some people skills issues, many other things that I’m forgetting.

Fears are certainly a bit of a theme for me during this conference; I hope that I’m starting to get better about acknowledging and confronting them in productive ways (though I feel a bit too lazy / other to talk about details of that right now), but it was heartening to see all of us come together, address fears, and come up with concrete productive actions to deal with them. It gives me hope that I’ll be able to do so in the future.

(Don’t get me wrong: there aren’t any crushing worries that I’m laboring under or anything.)

The first session I went to this morning was on systems thinking / causal loop diagrams. They had us go through an exercise throwing balls around, talked about states of the system, and showed diagrams that explained the different states (why performance increased, then leveled off, then went down).

Pretty good; I’d seen the ideas before in Quality Software Management, but never put them to use. And I suppose that talk will increase the chance that I’ll give them a try. The problem is finding the right time – like other forms of root cause analysis (e.g. five whys), I’m afraid that I’ll be too clouded by my biases, so I’ll end up just uncovering what I already “knew” was the problem instead of really figuring out what’s going on. So I should give them a try in a situation where I’m genuinely confused, I suppose.

Then I went to the open space to talk about lessons from waterfall. Nobody came other than Arlo Belshee (the convener) and myself, but I enjoyed spending an hour chatting with him. He talked a little about what lessons he thought we could learn from waterfall (risk management, configuration management, one or two other things I’ve forgotten), I talked a little bit about pain points in my current project that could probably be mitigated by these techniques; a pleasant way to spend an hour.

I spent all afternoon in a tutorial on coaching; really good, and I really wish I’d attended such a training a year or two ago. Actually, to be honest, I wish I’d managed to pull in an external coach a year or two ago, because I neither had sufficient agile skills nor coaching skills to bring off a successful transition. Or, for that matter, skills in retrospectives, which is still an issue and which I’m hoping to remedy on Thursday; and I made several mistakes related to not having the courage of my convictions (most noticeably my not pairing enough, which I think had strong concrete negative effects on the team), which perhaps yesterday’s leadership talk will help with in the future. So there does seem to be a coherent theme to my choice of sessions to attend – it would be nice if it were fighting the next war instead of fighting the last war, but there are worse themes than the latter.

The core of the tutorial involved going through four role-playing coach/other sessions (where “other” was sometimes a (project) manager type and sometimes a developer). We did this in groups of four (two of whom were roleplaying and two of whom were observing at any given time), plus somebody with coaching experience. We went through each scenario once, then talked about it, then went through it again. Very helpful hands-on experience, and I learned a lot each time, whether role-playing either side or just watching. (I apologize to the coach roleplayer for my excessive recalcitrance when roleplaying a PM.)

One nice thing was the way it reinforced some of the stuff I’d gotten out of manager training at Sun: let the other people speak, empathize, don’t try to solve problems directly, don’t even approach the idea of solving problems until they’ve had time to vent first. The more they can recognize problems and suggest solutions, the better. I felt a lot more comfortable role playing this time than I did during manager training; I guess I should spend more time putting these techniques into use.

The guest coach at our table was James Shore, who was very pleasant to talk to, had many useful comments, and did a nice job modeling acting as a coach on a meta level. If people are looking for coaches to bring into their organization for training, I suspect he’d be a very good choice.

I also drew my first mind map today. The presenters from the first session I attended yesterday were trying to get the notion of mind maps to spread virally – handing us out stickers, and encouraging us to teach mind maps to other people, who would then get a sticker on their badge, plus some stickers to give to other people as they in turn spread the teaching. Which mostly annoyed me – I don’t particularly care if some people can successfully spread a concept virally throughout a conference – but I actually did want to learn how to do a mind map. (The fact that the presenters didn’t actually teach us how to draw mind maps was actually the one aspect of the viral spread that I did like.) James had a sticker, so I asked him to show me how to draw a mind map, and he got me to draw one; yay. I’m still not sure how widely useful I’ll find them, but I’ll give them a try a few more tries.

I believe there’s supposed to be a get-together tonight for people who participate in the various mailing lists; it will be nice to put faces to names.

A follow-up to my zombie sighting from Saturday evening: it turns out that the price they paid for livening up downtown was to spend two nights in jail. The police should be ashamed of themselves: any claims of “simulated weapons of mass destruction” or “intimidat[ing] passersby” are ridiculous.

And now day 2 is over. Better than day 1: I enjoyed all four talks that I went to, and hopefully got something out of them.

One of the problems that I have is figuring out which talks to go to. I have enough agile experience that I’ve been avoiding the beginners’ tutorials. The main basic practice where I feel lacking is in customer (or Customer) interaction; I’m not sure that my problems in that regard would be best solved by going to a tutorial on the subject. On the other hand, I’m hardly a grizzled veteran – maybe I don’t know my own ignorance, so maybe there’s really important stuff that I would learn from tutorials (on that or other subjects) if ony I went to them.

Still, that’s one way to narrow down the options, which is important given the large number of sessions to choose from. (And then there’s the open space stuff which is getting organized ad hoc, and which past attendees say can be the most rewarding part of the conference.) But it would be nice if I had a more positive approach toward selection: is there something that I really feel that I’m missing, and need to learn about? I don’t have a great answer there, either.

So, in retrospect, I should have approached the planning in a bit more TDD-ish fashion, with some idea of acceptance tests before starting the conference. Oops. Most of the sessions look interesting; if several all look approximately equally most interesting, my first coin flip is how easily I could imagine using it at Sun – they’re sending me here, so they should benefit. But if something is much more interesting but less directly applicable, I’ll go to it instead – I know from experience that I’m much more productive when working on things I’m interested on, and that it’s hard for me to predict what actually will end up being useful in my future life.

If any of my coworkers are reading this while the conference is going on, feel free to go to the conference web site and suggest sessions that I should attend. Or any of my other loyal readers, for that matter.

Anyways, enough blathering. In general, the theme for sessions that I attended today was bringing about change. I don’t think I have too much concrete to talk about what I learned, but it was interesting hearing reports on the subject from several fronts. And I got some good book recommendations out of it. Not clear directly how this will apply at work – it’s not even clear to me in what circumstances at work it’s appropriate for me to be an advocate for change – but I hope it’s not completely irrelevant.

The talk by Christopher Avery on leadership was worth mentioning, if for no other reason than that it was an interesting counterpoint to an earlier blog post. Like Holt, Avery makes the point that responsibility is important and doesn’t mean wallowing in guilt and blame. And like many consultants, he has a list of stages; his is “Denial, Lay Blame, Justify, Shame, Obligation, Responsibility”. In any given situation you typically proceed through these steps, frequently getting stuck at one; you may also go to a special stage “Quit” at any step of the process.

The interesting thing here is the stages “Shame” and “Obligation”. Saying “yes, I screwed up, that’s my fault” would frequently be called taking responsibility; and, indeed, it’s much more responsible than the earlier stages of blaming other people or explaning away the results. But it’s ultimately lacking: it’s all well and good to accept blame for something, but if you just leave it at that, you haven’t done anything to improve the situation, so it’s still a way of avoiding responsibility. Similarly, doing something because you feel obligated to even though you really don’t want to do it is better than flaking out; but it still isn’t a way to constructively move forward, because there’s probably a problem somewhere that should be dealt with but isn’t.

Not entirely clear what I’ll do tomorrow. There’s a tutorial on systems thinking; I could learn something from that. I think I’ll go to an open space discussion lead by the promiscuous pairing guy on lessons we could learn from waterfall. That will cover the morning; the afternoon is less clear to me. Also, somebody is giving a tutorial on C++ unit testing in the morning; I don’t want to attend, but I should probably track down the speaker after the talk to pick his brain.

The first day of Agile 2006 is now more or less over. It was just a half-day, really: only afternoon talks, and I don’t think quite everybody is here.

I went to a couple of presentations. The first wasn’t too good: it was billed as talking about how agile had changed since the manifesto, but ended up having people talk/fill out cards about various aspects of their experience, with minimal analysis/insight, and overrunning its time box to boot. (I though agilists were supposed to be good about that?) The second was rather better: Scott Ambler talking about data he’d gathered about the penetration and effects of agile practices. Nice that somebody’s trying to gather data, and apparently doing a decent job (though it wouldn’t be too hard to find places to doubt the methodology); also nice that almost nobody thinks they’ve been hurt by adopting agile practices and most people think they’ve been helped.

There was an icebreaker. With some DDR pads; you’d think that, in a room full of geeks, some people would be drawn to video games, but that turns out to be the case. I don’t know how much of that is fear of dancing and how much of that is age. I also talked to Mary Poppendieck for half an hour or so, pumping her for information about lean. Most kind of her to spend the time; that’s the high part of my day.

The wifi in the areas where the conference is actually taking place is free; I’m using that now.

I also finally got around to making tar files of my unit test framework; the latest version should now always be available at http://unittest.red-bean.com/tar/unittest-latest.tar.gz. Yay.

I wasn’t sure what to expect from Whisper of the Heart. It’s a Studio Ghibli film, which is obviously a big plus. On the other hand, it’s not by Miyazaki or Takahata, and it somehow sort of shares a character or two with The Cat Returns, which isn’t the biggest recommendation. All in all, I didn’t have high hopes.

And for the first twenty or thirty minutes, the low hopes seemed on track. Middle school girls confused about boys and life; whee. It could be worse – they were treated humanely enough – but it could be a lot better, too. But then it started pushing my buttons; I’ve always been a big bildungsroman fan, and I like kids who start figuring out what they want to do and pursue that instead of more conventional paths. (Somewhat ironic, given that I’m thirty-five years old and don’t know what I want to do with my life, but I suppose that’s a topic for another blog post.) And I rather choked up during the chamber music scene.

So a quite pleasant movie, when all is said and done. And with it, I’ve seen all the Studio Ghibli movies except for Only Yesterday (which Disney apparently has no plans to release, grr) and Tales from Earthsea (which only just came out in Japan; actually, apparently it’s not coming out until a week from now). Amazing studio, that, and I don’t think it’s just my pro-animation and pro-Japanese bias showing. (Let’s test the latter – would I like, say, animated movies about self-directed girls as much if Disney made them? It’s hard to tell, isn’t it, given the almost complete lack of such movies! But Beauty and the Beast is fantastic.)

While Miyazaki gets more press in this country, I’m not at all sure that I don’t like Takahata’s movies just as much. Don’t get me wrong, Miyazaki’s movies are wonderful. But the visionary intensity of his environmentalist movies can be a bit much for me, Porco Rosso is decent but not great, I don’t like Totoro as much as some (sorry, Jim), and Howl didn’t do a lot for me. They are all rather better than your average fare, and I really like Kiki and think I probably really like Spirited Away (I haven’t seen it enough), but I like Pom Poko a good deal more than most of Miyazaki’s movies (and in particular I prefer its less mystical treatment of environmentalist themes). I’ve only seen Grave of the Fireflies once, maybe three years ago; I should really watch it again, if I think I’m up for it, but my recollection is that it was quite good. And I’ve also only seen My Neighbors the Yamadas once, but it was rather charming. Hard to say; I guess the next thing to do is to track down a Japanese copy of Only Yesterday (the Japanese DVD apparently does come with English subtitles).

I’m here now. Getting on the light rail and taking it to the Nicollet Mall stop was easy enough. Then I got off, looked around for my hotel, and didn’t see it. Or any useful street signs, or anything like that. Most people were walking in one direction, so I followed them; after a bit, I discovered that the street that I was walking along was, in fact, Nicollet Mall. (Until then, it hadn’t been clear to me that Nicollet Mall was, in fact a street name; maybe next time I travel to an unknown city, I should bring along a map?) And that my hotel was about 10 blocks away.

A bit depressing, really – this is a city downtown at around 7pm, yet the streets are relatively empty and the stores are closed? The one bright sign was a group of people carrying some sort of boombox, with a banner of some sort; when I got closer, it turned out that the banner read “Brains”, and as far as I could tell they were wearing some sort of zombie makeup. Pleasantly bizarre. As I got closer to the hotel, things picked up a bit, and in fact there were quite a bit of people in some areas (and restaurants with reasonably full outdoor seating). Still, I remain unimpressed – so far, downtown Mountain View wins over downtown Minneapolis hands-down. But doubtless other areas of the city are more interesting.

Aftter a bit (short blocks, yay), I made it to the hotel. Whose exterior is pretty ugly. Got to my room reasonably promptly; looked pleasant enough. Having my priorities in order, I look for the promised “high-speed internet”. No jacks apparent, so I turn on the computer: a “Hyatt” wi-fi connection appears. Yay. So I try to ssh home, which seems to take a while. While that’s going on, I open up my web browser and click on a link; up pops a screen asking me to pay ten bucks. Gee, guys, maybe you should have mentioned that aspect on your website? Or am I just naive? (Rhetorical question, I know the answer.)

On my way out, I notice something with a description of their services. And it does mention “Wireless high-speed internet service”, at $10/day, followed by “This is not your typical hotel story. This is the Hyatt Touch.” Personally, I would just as soon not have hotels touch me in that particular way. Next to it were one-liter bottles of water for four dollars; another aspect of the Hyatt Touch, I suppose. (The tap water tastes fine to me; I trust they won’t bill me for drinking that.)

I did give in and pay; adding insult to injury, the connection speeds are crap. Oh well; at least it exists. When I was in Stratford last month, the bed and breakfast didn’t have an internet connection at all. But they were a ton friendlier, and I spent a lot less than ten bucks at the local coffee shop which did have one. Which may end up being the solution I ultimately adopt here; we shall see.

I’m off to Agile 2006 tomorrow. Should be interesting; many thanks to the powers that be at work for sending me there.

I wasn’t sure what I thought about this article on removing warning signs when I first saw it, and I’m equally confused by this one. On a basic level: does this really work? I’ve never driven in Europe, I’ve never been to Italy at all, so I don’t have much context for many of the examples. If it does work there, would it work in an American city? (Doubtless better in some than in others.) Would it work in the more suburban area where I currently live? It’s hard for me to imagine techniques that would naturally cause cars to want to travel under 20mph here. And then there’s Green Streets…

The second mentioned article is the one I’ve been thinking about more, because of my current lean obsession. I’ve been on a bit of a slow driving kick for a couple of years, so I actually do frequently come to a complete stop at stop signs, but I would tend to agree that doing so doesn’t make my driving any safer – it just slows me (and potentially other people) down. (And wastes gas, too.) To be sure, my slow driving has flow benefits as well – if I see a red light ahead of me, I just coast, which has the benefit that I’m more likely not to have to come to a complete stop at the light, giving me a speed advantage. (And saving gas in two ways.) Go production leveling! Of course, you have to be a bit careful: if you cut the timing on the light too close, you can get killed by somebody running a red light. But in general asking the question “is holding down the gas pedal going to improve my total time, or is something else the bottleneck?” has had pleasing affects on my driving.

But what I’m really confused about is this: on the one hand, we have the idea that adding explicit safety (or quality) warnings is actually less safe than encouraging people to pay attention to natural environmental signals. Which I think I’ve seen in other lean sources, though I’m not completely sure that it’s canon; I’m also not completely sure I believe it, but it’s plausible enough. On the other hand, lean also heavily promotes certain kinds of quality signals, so you can tell when something has gone wrong as quickly and as immediately as possible. So: how do I tell the good sorts of quality warnings from the bad sorts?

I would like to say that I know it when I see it, but a bit of testing shows that that isn’t the case. Is pair programming a good sort of quality signal, encouraging a constant flow of dialogue about the process and hence heightening awareness? Or is it a bad, rigid, rule that’s a detriment to flow and encourages people not to pay attention to what’s going on because surely their partner will catch the problems? Or is it orthogonal to the issues raised by these traffic articles? I tend to think that pairing is more good than bad, but it’s not at all clear to me how to derive that from general principles. (And maybe this is a sign that we’re doing the right thing at work by not pairing all the time.) TDD raises similar questions to me – good, bad, excessively rigid, creating an informative environment, something else entirely? Again, hard for me to analyze, though here I’m rather more confident that it’s almost universally a good idea – you’ll pry my unit tests out of my cold, dead hands, and red, green, refactor is a wonderful way to work. (But perhaps those wonders, especially the design benefits, are orthogonal to these issues.)

Always more to learn.

The previous owner of our house was quite a gardener. One of the things I liked about the place: out the back door, there’s a patio with a table and chairs, covered by a sort of trellis with jasmine growing over it (creating a nice, cool space). In the yard proper, many flowers, large, colorful and (to my eye) frequently exotic. And various little knicknacks (including colorful fishes and a mirror on one of the fences).

Unfortunately, we are not gardeners. The result has been that half the plants have died in the intervening two and a half years, and the other half of the plants are hugely overgrown. Perhaps attacking the house in the process, almost certainly attacking the fences in the process, with the result that on one side a section of the fence has fallen down while the fence on the opposite side is sagging. We really should talk to our neighbors and do something on it; it’s probably second on the list of house priority stuff.

As you can probably guess from the above, we haven’t spent much time in the garden. Miranda heads out there every once in a while to pick flowers. Liesl’s done a little bit of hacking at the worst of the climbing vines. The dogs do their business (and Zippy actually wanders around some); some opposums in the neighborhood have been seen there. I mostly ignore it.

We’ve talked a bit about improving it. Probably getting rid of some of the stuff there, and adding a bit of a vegetable garden. But nothing concrete has come of that, and nothing concrete will come of it this year.

Right now, the townhouse complex is in the process of painting and repairing the trim in all of the units. Part of this includes the trellis in the back. So they sent us a letter: either clear plants off of the trellis or they’ll leave it alone and we’ll sign a waiver saying that the trellis is our responsibility to look after, not the HOA’s.

So: what to do? On the one hand, I like the effect the jasmine on the lattice creates on the space beneath it. On the other hand, we’re not sure what’s going to ultimately happen in the yard, and if the jasmine turns out not to be part of the solution, we’ll want the HOA to be responsible for that part of the maintenance, not us.

This is a situation I’ve seen before. Speculative implementation of a feature, causing a maintenance burden, with no plan to use the feature any time soon. Seen in that light, I know my answer: remove the offending code to improve maintenance.

So I spent three or four hours today hacking away at the honeysuckle climbing up the side of the house and the jasmine that was all over the lattice. The honeysuckle was easy to deal with: snip through vines at the ground, and pull, and two stories of honeysuckle come tumbling down. The jasmine, however, was another story: many of the vines were more like branches, and they’d been growing on the trellis for years with no interference. (I was impressed by the way it had integrated itself with a neighboring tree, too.) So I was hacking away largely at random for the first hour and a half. By the end of two hours, I’d cleared off the trellis near the area where the vine originated, so I could see that the end was in sight; after lunch, though, it took another hour and a half before the rest was cleared off. And I was filthy, with leaves and flowers all over my hair and beard (quite the dryad look, actually, or whatever the male equivalent is), with hands starting to feel raw.

The results were as my software experience would lead me to expect. Once I’d removed the mess, there was more of a mess underneath: if the HOA is really going to repair the trellis, they’ll probably have to end up replacing it entirely. And I feel much more in control of the backyard – previously, for example, I’d been happy to let Liesl go out every year or so to hack at the worst of it, but now I’d be happy to go out for ten minutes every month or two to fight the honeysuckle. (And the jasmine, if it comes back every month or two; I really don’t know what to expect there.) I don’t like the area under the trellis quite as much as I did before, but it’s not as bad as I’d feared. I understand the effects of plants on fences much better than I did before.

Of course, now I have jasmine debris covering the back yard, and I’d feel guilty filling the dumpster with it. I guess I’ll go out every Tuesday night for the next couple of months and see how much room there is in the dumpsters, and add some more of the jasmine. (Trash pickup is on Wednesdays.) It’ll get taken care of eventually, and having an excuse to think about the garden every week is probably a good thing.