malvasia bianca

I just finished another one of Eliyahu Goldratt’s business novels on the Theory of Constraints. I didn’t lose sleep over it the way I did with The Goal, but it was quite good. And useful to see ToC applied to product development situations, instead of just manufacturing situations.

One thing that caught my eye: not only does it speak somewhat ill of Just in Time, it lumps the latter together with assembly lines. Only somewhat ill, to be sure: assembly lines and JIT are both successful in limiting the amount of inventory that can accumulate between stages, limiting the waste of overproduction. TOC agrees that that’s a good idea in general; but it’s really focused on alleviating the ill effects of bottlenecks, which means that while it’s happy to have production stages that aren’t involved in bottlenecks be idle when not needed (as JIT supports, but perhaps assembly lines have a harder time with?), it wants to make sure that there’s material ready to allow bottleneck production stages to be active whenever possible. Mind you, TOC doesn’t want pre-bottleneck stages to produce for the sake of production, but they definitely shouldn’t run the risk of letting the bottlenecks be idle.

So: who’s right? TOC or lean (of which JIT is a component)? I’m pretty sure I’ve run across favorable mentions of The Goal in lean discussions, so I doubt they’re too strongly opposed. (It would, of course, be inconceivable that both are wrong: I couldn’t possibly be obsessed with two areas of thought that are both mistaken.)

Of course, lean isn’t just JIT: there are other tools in there. And doubtless part of the answer is that, because of the increased predictability that lean’s high quality gives you (via its other tools), the need for TOC-style production buffers is lessened. And kanban, the technique by which JIT is maintained, could probably be used to get TOC-style buffers. Kanban is the pull-style mechanism where each step requests new material from its predecessor by handing it containers to fill. The simplest example is one-bucket kanban: if you have a sequence of steps where each step requires one item from its predecessor, then this is the situation where each step keeps one piece of inventory on hand. That way, if a request comes in from its successor, it will be able to quickly build what is required. (While, at the same time, putting in a similar request to its predecessor, to make sure its one feeding bucket remains full.)

This works great if all steps take the same time, but sometimes different steps take diferent times. In those situations, you can add buckets as necessary. Or, I suppose, remove buckets – for example, when buying books, Amazon normally ships books to me a little faster than I want to buy them, so while I normally use one bucket, I don’t always worry about keeping the bucket full.

If we wanted to adapt this to the TOC concerns, then, I suppose they might recommend that your bottleneck should have more buckets preceding it than would otherwise be strictly necessary to fill that step’s demands: you’re trading off excess inventory before the bottleneck for the risk of having your bottleneck not working at full capacity if something goes wrong. Given TOC’s focus on bottlenecks, that seems like a reasonable tradeoff.

I’m not sure that lean would agree, though – they would probably see this as a failure, and focus instead on improving the predictibility of the bottleneck’s predecessors. Given the apparent effectiveness of lean’s tools for improving predictibility of manufacturing, that sounds like a reasonable response to me. Non-lean shops might want to focus more on the bottleneck’s buffer, though. (Don’t get me wrong, buffers in TOC situations are much letter than buffers that other methods find acceptable.) Also, lean covers more than just manufacturing; maybe it takes more of a TOC-style approach in, say, product development? Honestly, I have no idea.

So: what does this mean about my situation at work? Again, I have no idea: I’m having a hard time finding the sequence of steps that will enable me to even ask the question of what the bottleneck is. For now, probably the best thing is for me to watch and figure out where something inventory-like is piling up, because it will naturally appear before bottlenecks. If the bottleneck is under my control, though, then probably the right thing to do isn’t to focus on the chains leading up to the bottleneck, though: the right thing to do is instead to eliminate the bottleneck by, say, increasing the number of people who can work on that area of code. (If it is an area of code.) So lean over TOC for me.

Kanban calculations have started to appear. For example, one of the questions that my team had been recently asking in its previous incarnation is how large a task backlog we needed from my boss. We’d been doing a monthly planning cycle with my boss, combined with internal weekly planning cycles; it’s not clear that’s a great mix, though. If we really only had a month of cards then, at the end of the month, we’d be mostly done with them, and might be unnecessarily idle because we wouldn’t have quite have enough to work on. So, at any given time, it’s useful to have, say, an extra week of backup cards built up. There’s also a problem at the start of a month: we have a whole month of backlog then, and that can actually be a bit much – sometimes, for example, we had a hard time accurately predicting how long it would take for us to do a card a few weeks off, because we needed to get our hands dirty with the preparatory work first.

So the lesson seemed to be that two or three weeks was about the right size for our kanban bucket: that’s best for production leveling, keeping us working at our maximum productive pace. And, actually, I suspect that that size is actually a bit too large – we need a bit of a buffer in case we’re more productive than expected over the course of a week, but lean suggests that you don’t want buffer for the purpose of making sure that people can’t still work on something if, for whatever reason, they’re not suitable for working on tasks that would otherwise be higher priority. You should instead see the latter as a bug, figure out its root cause, and try to eliminate it.

Lots and lots of stuff for me to learn. Lean concepts are starting to fit together for me, but I’m also becoming increasingly aware of just how little I really understand lean. And how little I really understand several other things…

I used to like first-person shooters – in the distant past, I seem to recall having enjoyed Doom, Marathon, System Shock, Dark Forces, and GoldenEye, for example. The last few times I’ve played FPS’s, though, they really haven’t done much for me. I’m not sure why the big change – part is probably that I have other ways to get my graphics fix, and part is probably that I have access to a much wider range of gameplay styles these days, so have a better idea what my tastes are. (Most of those I played before I became a console gamer.) Or maybe those games were just better, or at least had ideas that were new at the time, which isn’t the case for more recent FPS’s that I’ve played – Doom and System Shock certainly qualify on that score, and Marathon and GoldenEye probably do as well.

At least that’s how I feel about the single-player mode. The last time I tried out an FPS in multiplayer mode, I really enjoyed it, and I have no reason to believe that wouldn’t still be the case. My fave was the scripted multiplayer scenarios for Perfect Dark; have more recent FPS’s adopted that as well? As you might guess from that last sentence, however, I unfortunately almost never have a chance to play multiplayer video games these days – I just don’t have that many videogame-playing friends, and for various reasons I don’t play video games online.

Anyways, during the summer game lull I was looking for something to play. And everybody’s been talking about the Halo series for the last five years, so I felt somewhat uncultured at not having played either of them. So I decided to give the first game a try.

I started off on the Normal difficulty setting. (As opposed to Easy, Hard, or Legendary, if I’m remembering correctly.) Which seemed like a reasonable choice for the first couple of levels – I had to take a little care, but really it wasn’t very hard getting past any of the sections.

When I got to the third level, though, my brain gave me its first warning sign. You start off the level with a sniper level; rather than thinking “how nice for them to be varying the game play like this”, my reaction was “crap, that means that I have to spend time moving slowly through the level and sneaking around”. Still, I more or less enjoyed the first part of that level.

The later part of the level had some large areas with a fair number of waves of enemies for you to kill, dodging in and out behind pillars and boxes and such. By the time I got to the largest such room, I was a little low on health, and didn’t manage to make it through the room before I had to go to bed. I hadn’t saved, fortunately, so I wasn’t in a big hole, but it did mean that, the next time I played, I had to replay a fair amount of the level, and be rather more careful.

Which I didn’t want to do; the level was well enough designed, but I just wasn’t enjoying it. I thought about stopping right then, but I remembered the easy setting, so I decided to give that a try.

They made me restart the level from the beginning (why?), which was a bit of a bummer, but my disappointment was quickly erased by the fact that they really weren’t joking when they called that setting “easy”. There were still a few places where you had to take a bit of care, but, most of the time, you can just blithely gun your way through without taking a scratch. Which turned the game into pleasant enough light entertainment, and let me see all the plot points. Honestly, I sometimes wondered if it made the game too easy – maybe there was to much of a gap between Easy and Normal – but later levels brought the difficulty back up to a better level.

Speaking of plot points: people talk about how great the plot is, but I just don’t see it. The plot does exist – we’re not talking about Doom here – but any decent RPG would have ten times as many twists and turns, and FPS’s I played a decade ago had at least as strong a plot as Halo. To me, the single-player game feels like it’s largely an add-on to the multiplayer game – there are rooms all over the place that are filled with platforms and levels and hiding spots that make no plot sense, that don’t make much sense in the single-person game, but would probably be a lot of fun in multiplayer.

The game mechanics are solid. The vehicles are a nice addition. Restricting you to two weapons is a surprisingly good idea. Your suit has a regenerating energy field which means that you can recover from small amounts of damage, so you don’t have to be too much of a perfectionist when dealing with small numbers of enemies at a time. Not many different kinds of weapons, but they’re well-chosen, so that’s a plus instead of a minus.

All in all, I’m happy I finished the game, but I’m certainly not rushing out to play Halo 2. Maybe I’ll reconsider when Halo 3 comes out. Now I’m down to just being in the middle of one game, and I’m almost done with that. Which is good timing – Okami will come out in just over a week, the Wii will launch in approximately two months with at least one must-play game (the next Zelda), and if that proves not to be enough, Civ 4 is now out for the Mac.

• Project X: Cup Noodle clearly has to go on today’s one-click list.
• Jackson Pollock.
• I would seem to be getting into interactive flash sites.
• House of dominoes.
• The Foundation replacement saga.
• Quite a storefront.
• Our money is badly designed (and getting worse). Nice manhole cover, too.
• A much longer talk than I usually tolerate on the net, but good economic animations.

I seem to be in a quiet mood these days. But I did like this video from my CEO’s blog. Andy is an excellent geek.

I suppose I could even try joining the modern world and embed it.

Gee, that was easy. Go web 2.0, or something.

One of my fellow managers has resigned, and rather than hiring another manager, we’re merging his team with mine. So my team has more than doubled in size. It’ll be interesting to see how things play out, and to see if I’ve learned anything about managing over the last couple of years; I’m looking forward to it. Too bad it will reduce the amount of time I spend programming, though. (It shouldn’t eliminate it entirely, fortunately.)

My, the design for the new digs for the American Institute of Mathematics look posh – quite a change from the Palo Alto Fry’s building. Here are renderings from one side, another side, and a rendered flyover video. I will definitely have to wander over the first time Jordan goes to an event there after it’s been built.

This page, though, confuses me – the writeup mentions a “large building” and “octagonal building” with pictures of buildings that seem, while nice enough, much less dramatic. And, in the pictures, those buildings seem to actually exist, but I thought AIM was still running workshops at Fry’s? And the writeup doesn’t talk explicitly about the castle-style building, even though it shows pictures of it. (I suppose it’s possible that the large building could even be remodeled into the castle; it looks unlikely but not inconceivable.) So I don’t understand how many buildings are envisioned, when they’ll be built, and whether all of them really will be used by the institute. (As opposed to the other projects that Fry has at the site – maybe the castle will turn out to be a really big clubhouse for the golf course…)

I’ve finished the last important code cleanups from my dbcdb code: I removed some proxy objects that had been used for lazy loading. I was really surprised to see how much that cleaned up certain aspects of the code: my Entity objects’ constructors got a lot cleaner, useless attribute setters/getters were removed, and in general responsibilities were greatly clarified: the Entities’ only job is to convert from SQL to HTML.

Which brings me to a pause point. I’ve met some of my objectives: gotten a little more practice with Java and HTML, learned a little about SQL and CSS, and provided an alternate linking structure to use in the blog. Nothing earthshattering, but it’s been of some modest use to myself. And there aren’t any obvious gaping holes to be filled.

So it’s time to take stock and figure out what to do next. For a while, actually, I was considering taking the time I’d been spending on this and using it to learn Japanese instead. (Which would actually take rather more time, but never mind that.) With some regrets, though, I’ve decided that isn’t the best course of action right now. My best guess is that I’ll be looking for another job in about two years from now. (With a huge margin of uncertainty, of course.) And, while I’m not sure what I’ll target in my search, I would like my options to be as many as possible; to that end, spending more time broadening my skills could be of some use. Exactly how much use isn’t clear – having been on the other end of the resumes, I realize how easy it is to reject candidates whose professional experience isn’t exactly what you’re looking for – but it’s worth a shot. So I’ll want to keep this up for another year or so. (After which, I hope to have enough time to take a break and learn Japanese. But who knows what the future will bring.)

So, given that I’m not going to stop now, what next? Rewrite it in Ruby, for one. I’m starting to chafe at Java more and more: just today I ran into a few places where I could use lambda, a few places where static typing was being mildly annoying. So I’ll start by rewriting the CLI tool in Ruby, then rewrite the HTML conversion part in Ruby. After that, I’ll generate the web pages on the fly instead of statically, using mod_ruby. (I don’t plan to learn Rails for now: I don’t have any good applications for that in mind.) After which, who knows; maybe I’ll stop there, maybe I’ll convert the editing tool from a CLI application to a web application. Maybe I’ll play around with web services, scraping book information from Amazon. Hard to say.

The immediate next step isn’t entirely clear. I’ve read/skimmed the Ruby book, but it hasn’t all sunk in; clearly I need to get my hands dirty. And I need to learn how to use Ruby to interface with a database. (Maybe the book talked about that; I skimmed the library section.) It’ll probably take a few months to have anything to show there; I also have a bit of unit-test library cleanup that I’ve been putting off. So don’t be surprised if I go quiet on the programming front for a little while.

I’ve deprecated the old compound author pages – they’re still there, but now nobody links to them. Instead, pages for books written by multiple authors link directly to the individual authors’ pages.

A matter of a change of a couple of lines of code. (Though all of my acceptance tests passed unchanged after that – oops. That has now been fixed.) I’ll probably eventually improve the database design as a result of this, but doing so is hardly urgent.

One thing that I never got around to blogging about when I first became lean-obsessed: Toyota never fires anybody. Or something like that; at any rate, one thing that lean bloggers claim is that, for lean manufacturers, employees are a fixed cost instead of a variable cost.

Which has interesting ramifications. In general, it’s a good deal more humane, which I certainly approve of. And it fits in well with constantly asking your employees how to improve matters: if both parties are committed to each other, then it’s natural to see your employees as resources whose insights are to be valued. (Similar to the way they treat their suppliers.) All to the good.

Having said that, there are a few things that I wonder about. In the first place, what if your business isn’t constantly growing like gangbusters? I know, I know, that’s a sign that you can’t possibly be doing lean right, but it still strikes me as conceivable that even the leanest of businesses might have efficiency improvements that aren’t linked to sales increases, or might be hit by an economic downturn that it can’t ride out solely by lowering prices enough to maintain market share. So what do you do? In the former case, you could simply give your employees the excess profits by paying them the same for working fewer hours. The latter case is harder.

At the very least, this suggests that there’s more to this production leveling idea than is obvious at first glance. Even if you have a surprise hit on your hands, a lean company may decide not to provide enough of their product to meet demand, because that could lead to a rate of expansion that would lead to overstaffing in less sucessful times.

That’s one problem; the other is rather darker. I don’t know what matters are like now, but if Womack and Jones are to be believed, not only will Toyota not kick you out, but you won’t be able to leave if you want: salaries are set based on service time with Toyota, not overall skill or experience. So if you change companies, you start again at the bottom of the salary level, which few people are willing to do. And that sucks.

So I’ll go with the Semco model in this regard. You get the same respect for employees, the same benefits of treating them as resources, but without the gilded cage aspects. And they get advantages from an entrepreneurial spirit, where employees not infrequently leave to form companies that turn out to be valued suppliers for Semco; victory all around. They don’t seem to manage their ups and downs quite as smoothly as Toyota does; that’s okay with me (makes them feel more human, at least), and they’re certainly leery about excessive expansion as well. And, I suspect, the highs and lows in Brazil were more extreme than they were in Japan, once the worst of the WWII effects wore off there.

If one is so eccentric as to use a Dvorak keyboard layout, it is easy to accidentally hit clover-Q with one’s thumb. Good thing Emacs has auto-save files; I should get in the habit of saving long e-mails while in the middle of drafting them, though…

I’ve read a couple of business novels recently, and I confess that I hadn’t properly appreciated the genre before. I’m not going to stop reading nonfiction or anything, but it seems like a quite decent way to learn something about an area that I don’t want to currently pursue in depth. Which is the case for most business topics – I want to figure out what I can do to help increase the chance that the product I’m working on will succeed, and there are doubtless skills I don’t have that I should be thinking about, ways of looking at situations that I could productively be informed about. But that doesn’t mean that I want to delve into these areas in depth: for now, I’m just browsing for ideas. So the lack of depth in these novels doesn’t bother me (and, for all I know, these topics might be situational enough that learning more theory wouldn’t have a huge payoff, though that’s probably my bias showing), while I’m surprised to find how much having a bit of a plot to follow helps keep my interest.

I’m currently in the middle of The Five Dysfunctions of a Team, by Pactrick Lencioni. (Almost done with, actually, even though I started it yesterday and have done several other things in the intervening time; admittedly, it’s a quite short book, a little over 200 pages with very little text on them.) Don’t get me wrong, I don’t see any of the various teams I’m a part of being particularly dysfunctional; the book was actually a little comforting in that regard. Having said that, there are certainly scenes described here that are pretty familiar, and if I were more at ease with conflict, I could doubtless do a better job of helping us get productively aligned. A fun, fast read; I’ll probably check more of the author’s books out of Sun’s library.

The Goal, by Eliyahu Goldratt, however, was completely and utterly absorbing: I brought it home and spent more than one night reading it rather later than I normally consider wise and then lying awake for way too long after turning off the light trying to figure out what, if any, concrete actions I could take. It’s about queue theory, or the theory of constraints, or leanish ideas, or something; basically, taking a manufacturing plant, figuring out what results are actually important to the plant, and figuring out how to alter the behavior on the floor (and elsewhere) to dramatically increase the quality of those results. With some quite surprising twists, if you haven’t seen this sort of thing before; I really should dig up a link to a Theory of Constraints simulator that I found somewhere and try playing with some variables.

Which is all pretty interesting, but what kept me up at night was: what does this mean to me? One of the basic principles, for example, is that, when considering the productivity of a system, the bottlenecks are almost all that matters. So, for example, keeping people working on non-bottleneck tasks just for the sake of looking busy probably isn’t doing you any good and may in fact be actively counterproductive. Which is pretty interesting, and I can imagine trying to apply that on a manufacturing floor. Does it apply to a software team, though? I’m pretty sure the answer is “yes”; how do I then go about identifying the bottlenecks that determine my team’s effectiveness?

There are probably several lessons to be learned here: my difficulty in even starting to figure out how to identify the bottlenecks is a warning sign in itself, for example. (There are other related warning signs, e.g. the fact that I have no clue in how to draw a value stream map for our situation.) But of course that’s the wrong place to start: following the title of the book, the first question I should ask is: what is the goal? Which my boss and I had a talk about recently, and it turns out that we came up with the same answers: that alignment is certainly a good sign, and it’s greatly clarified some decisions that we’ve had to make this month.

So what are other interesting novels out there on topics that would normally be covered in nonfiction? What other nonfiction genres does this work with? (I have a hard time imagining learning, say, algebraic geometry by reading a novel.) I am curious.

Today’s dbcdb projects:

• Improve the appearance of pages with long fields: now the long field doesn’t get forced to start on the next line. I’d hoped this would fix the Internet Explorer problem, but it doesn’t (though it improves it): for reasons that I haven’t yet investigated, I have to have the key float: left to get its width to stick, which triggers the IE bug.
• I removed the ‘own’ field. Which was my first bit of database tweaking; yay.
• I downgraded all ratings by one. Which was my second bit of database tweaking; yay. (Though I didn’t tweak the database in the most stylish way possible.) Definitely a good idea: it turned out that I hadn’t rated any books as 1, and I’d only rated one game as 1.

No particular lessons that I learned; it was all pretty straightforward.

So what’s the deal behind this story? 37signals is notable for, among other things, being minimalist (in many ways) and profitable. Like they say, they don’t need money (at least to do what they’re doing now); and, in the past, they have apparently been happy with (quite) small teams. (Indeed, DHH reinforces the latter in this interview, talking about how they’re happy that they don’t have to worry about, say, managing people.) On the other hand, they say they have big plans, where by “big” they mean becoming one of “the great companies of the next 20 years”. I don’t know offhand of any other small company that I’d listen to when they say that; from these guys, I wonder.

Some compelling (to me, at least) articles/etc. on the excellence of Ruby:

• Martin Fower says people he works with are significantly more productive in Ruby.
• Tim Bray says: “Ruby is remarkably, perhaps irresistibly, attractive. Over the last week I’ve got an unreasonable amount of work done in a ridiculously short period of time, with lots of interruptions, in a language I previously didn’t know.”
• A remarkable interview with David Heinemeier Hanson. His first program in Ruby was Basecamp, the programming part of which took a grand total of two and a half programmer-months.

And it’s not just productivity: just listen to DHH talk about the sheer enjoyment of programming in Ruby; he’s clearly not the only person who feels that way.

I won’t claim that everything is perfect in Ruby land – Sam Ruby complains about the libraries, for example. (Incidentally, I saw a similar complaint about C++ recently, and it’s really true. When I started learning the language, I saw the glorious example that is the STL, and there are other nice examples out there (e.g. the Boost smart pointers), but there’s a lot of disorganization out there, and a lot of libraries that just aren’t good examples of how to use the language. Where the latter issue is, of course, compounded by the wealth of paradigms that the language supports.) That, however, I can deal with, in the face of an apparently excellent language and one dominating library example.

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.