[ Content | Sidebar ]

doctor fun, r.i.p.

June 12th, 2006

Doctor Fun has ended its run. The last remnant on my bookmarks page of the early days of the web…

authority

June 11th, 2006

These sound to me like desirable characteristics for open source decision makers.

summer 2005 pictures

June 11th, 2006

I finally got around to putting up pictures of us (well, mostly pictures of Miranda) from last summer.

dbcdb: links!

June 10th, 2006

My dbcdb pages now can have a list of external links attached to them. This is a feature that I’d been wanting to add for a while – until now, the links from within these blog entries probably served as more of an annoyance to my readers than anything else, since the information on those pages was unlikely to be of interest to you. (Except maybe the hidden Amazon link, about which more later.) But now they can potentially serve as a way to make my blog a bit richer – if I refer to, say, a book from within a blog post, then they provide an easy way to find other blog posts where I talk about that book in more detail. (At least once I go and add more links into my dbcdb database.)

The issue of how to handle related posts is, I think, not an uncommon problem for bloggers to run against; c.f. Tim Bray on a variant of the problem.  There are lots of solutions, each suited for different manifestations of the problem, but I like this idea of adding an extra layer of indirection by sticking a mediating web page (my dbcdb pages) in the middle.

Once I decided to take that approach, though, there were two different implementation strategies: I could either add links manually to the database every time I posted about a book/game/whatever, or I could let a search engine find all blog entries that refer to that book/game/whatever. I decided that the latter wasn’t completely satisfactory: not all posts that refer to a given book are created equal. For example, half of my dbcdb blog entries link to the page for The Arcades Project not because they have anything to say about that book but because I’m using that as a default example. Also, one main argument for search, namely that manual indexing isn’t scalable, doesn’t apply here: manual indexing should scale just fine in this case.

Having said that, search also has its value for this: you might (or might not!) be interested in all blog entries where I, say, make an offhand mention of a certain video game, one that I might not choose to put in the index. So my next story will be to add an automatic “search my blog for references to this” link to all entities. With luck, that will give me the best of both worlds. Also, while I’m adding links, I’ll get rid of the ISBN/ASIN fields and replace them with an explicit Amazon link.

Before I started doing this, I realized that, if I didn’t first get rid of MemoryCollection in favor of SqlCollection, I’d have to do a tiny bit more useless typing to implement this. Since I’d been planning to do that soon anyways, I figured this was the time; it turned out to be quite pleasant, using (the classes that implement) the CLI tool’s interface. Yay. And, in doing so, it increased my appreciation for dynamic typing; I might go on about that later, but if nothing else it emphasized that I really do need to spend some time soon playing around with a dynamically typed language.

lean sales

June 8th, 2006

One thing I wanted to learn when I started reading about lean: given that Toyota is supposed to be so great at everything, why is it that, when I last shopped for a car, fully intending to buy one of their models, the experience was so bad that it (or rather they, I tried two dealerships) drove me to one of their competitors? (Saturn, in this case.) They could have made money off of me if they’d just acted like decent people, instead of making it clear that all they cared about was ripping me off. Admittedly, I did get a certain pleasure from one of the salespeople putting a lit cigarette into his shirt pocket, but I didn’t see any sort of exciting “lean sales” practice, any leveraging of their apparent ability to nimbly respond to conditions, any recognition that inventory should be considered waste. It seemed pretty much the same as standard practice in this country, maybe a bit worse.

It would seem, however, that sales practice in Japan really is quite different than in the US. Kind of creepy, actually – apparently, once you’ve bought a car, that sales person will then contact you quite frequently, even stopping by your house (most Japanese car sales don’t/didn’t take place in dealerships), checking in on how things are going, sizing up your future car-buying plans, or when you’re not about to buy a car at least improving their feel for the moods of the populace, to help Toyota’s strategic planning.

I wouldn’t like that, either. I want to talk to a dealer when I’m interested in buying a car, and I’m happy to continue in a relationship with a dealer after that (e.g. bringing it to them for maintenance), as long as I don’t feel they’re actively working against me. But I want to be the one in control of the relationship, not them. Still, it does seem a less actively adversarial relationship than a traditional American car sales relationship, which is certainly a plus.

Apparently they even take responsibility for fixing their cars whether or not they remain under warranty, in order to keep customers loyal. If only Saturn had done the same thing, we’d probably stay with them indefinitely; alas, our older car had to have its engine replaced because of a design flaw that (in our case) didn’t manifest itself until after the warranty expired. So if having to spend several thousand of our dollars because of their design flaws is what we have to expect from Saturn in the future, then no more Saturn. Maybe Honda will prove a nice mix of reliable cars plus a non-asshole sales force? (To be clear, we’re not shopping for a car now, nor are we planning to any time soon.)

Despite my misgivings about it (which are apparently growing more common in Japan, too: at-home car sales are declining, or at least were at the time the book was written), I can see how Toyota’s Japanese sales philosophy fits into their lean mindset. Lean likes to generate and feed off of high-quality information, so get that from your customers, too. An ability to easily customize means that you can encourage your sales force to meet with customers to pick the options on the car that best suits their needs and moods instead of forcing the customer to take whatever’s on the lot. As I already said, no lot means no inventory, which lean loves. Maybe the less adversarial sales/customer relationship is similar to their less adversarial manager/worker relationship. (About which I’ll write later; both relationships are uncomfortably constricting from my point of view, too.) And an ability to produce high-quality cars means that they can affort to fix defects that escape into the wild.

It does seem to be an aspect of lean that hasn’t made it to this country, though; and while I obviously don’t think that the standard American car sales model has much to recommend it, this sales model seems rather off as well. In an environment where customers have increasing access to choice and high-quality information, then treating them well will probably pay off more and more; acting like a (nice) stalker, not so much.

Maybe Toyota’s already changed their practices in Japan in the intervening decade and a half; I should look into that. The section in Lean Software Development on contracts might give some clues, too – after all, those are customer relationships, just of a slightly different nature.

dog diagnosis

June 6th, 2006

We got back the results of Yosha’s blood work; it would seem that his kidneys aren’t functioning at full capacity. Which might even explain the vision problems: kidney problems can lead to high blood pressure can lead to vision problems. We’ll see; we’ve gotten bags of special “easy on the kidneys” dog food, and hopefully various matters will improve.

Certainly he peed a lot less today than he had been doing in previous days. A good sign, though it’s rather too early to declare victory: there was poop all over the carpets, so probably not enough stuff was making it into his blood in the first place to really tax his kidneys. I’m not particularly worried about the poop; this sort of thing happens when changing from one kind of dog food to another. That should settle down in a few days, after which we’ll have a better idea of the new food’s affects.

aids

June 6th, 2006

Apparently there was only one AIDS death in Santa Clara county in 2004. A ways to go still, but that’s real progress.

We just finished watching the version of Angels in America that HBO did a couple of years ago; fabulous.

how buildings learn

June 6th, 2006

I wasn’t expecting to like How Buildings Learn nearly as much as I did. I learned about it from the XP book‘s bibliography, and certainly you wouldn’t have to look very far in the book to find inspiration for your programming. But I was surprised at how interested I was in the actual topic of the book. (Not too strange in restrospect – being a homeowner does change one’s views on such matters.)

Lots of groups of pictures of one house over the years: additions to the house, changes in the styling of the house, the occasional removal of a previous addition. We don’t have have any plans to add onto our house: we don’t have any plans even to remodel, though I can conceive of how we could, say, improve the kitchen. But looking around the house with addition eyes, I can imagine how we could this house could grow over time: enlarge the den by going out into the back yard, then add a similar addition to the guest room above it, then move out the kitchen next to it, and so forth. Though, to be sure, we couldn’t actually do that: we live in a townhouse complex, and there are rules against that sort of thing.

Even if there weren’t rules, we probably wouldn’t want to expand – there’s only so much space in our backyard, after all, and neighboring buildings are uncomfortably close. But a lot of standalone buildings these days are in developments with CCR’s of their own; I can’t see how that’s a good thing. I wouldn’t necessarily support giving up all housing-related rules, or even all non-safety-related rules, but enforcing a sterile uniformity for the putative reason of improving your neighbors’ property values seems pretty crazy to me. Much better to adapt your house to changing events, instead of being forced to change houses entirely.

There were also good thoughts on the idea that there shouldn’t be this sudden changeover when a building is finished: you only know how it will actually work when people are living in there, so the conversation with the architect/builder/whatever should continue at that point instead of end there. Some random tidbits from the book: drawings from a book on Malaysian house-building, showing various traditional expansion sequences for Malaysian dwellings. Discussion of some Japanese building firms that take responsibility for all of the design and construction, engaging with the resident throughout the whole process, continuing that engagement after the resident moves in. It’s hard to say what the future will bring, and I don’t particularly foresee ever having a house custom-built for us, but if we were to do so, that sounds like a good way to go.

And discussions of older architecture versus newer architecture. In lots of areas, I tend to reflexively support the new against the defenders of the old, but reading this book and Christopher Alexander have rather turned me the other way when it comes to architecture. A lot of screwed up ideas on that score in the last century. (Hmm, maybe my opinions shouldn’t surprise me so much: I’d already been convinced of that when it comes to urban planning.)

Among other things, modern houses apparently aren’t built to last so long. And one symptom of the lack of an ongoing conversation between builders and dwellers is the general lack of ongoing maintenance. Certainly I wish that I knew somebody whom I trusted whom I could talk to about the state of our house, what should be done about it in what order, and who could help arrange for stuff to get done. We’re managing to chip away at this somewhat (and actually the HOA / management company can be very helpful in this regard, for stuff that’s their responsibility to pay for / arrange), but not as quickly as I’d like, and there are definitely some areas where I could use some good, informed, unbiased advice. (E.g. about our floor.)

Of course, part of the issue there is scheduling – it’s the whole “important but not urgent” problem, made worse by the fact that I don’t in fact really know how important and/or urgent it is.

A problem I’ve been dealing with at work recently, too. I think we’re making some progress – my team in particular has been very helpful in informing me that, no, we shouldn’t put off fixing certain bugs, they’re causing problems now. XP and lean seem to have a good approach here: they have useful concrete criteria for telling whether or not something is important, and once they’ve decided it is important, they immediately elevate its urgency. (A defective part just went by – stop the whole assembly line until we can figure out what went wrong!) Not clear how to apply that to home maintenance, though, or even whether it’s a good idea to apply that to home maintenance. I guess there’s probably another way in which lean deals with important-but-not-urgent events – there must be periodic checkup sessions, which then lead to recommendations of fixes that are more urgent to implement. So the analogy here is to periodically give the house a check-up, and then to immediately fix the problems that you find. Assuming that I’m not just making up that last sentence about lean! Even if I am, the application to houses sounds like a good idea.

wordpress 2.0.3

June 3rd, 2006

I’ve just upgraded from WordPress 2.0.2 to WordPress 2.0.3. Let me know if you see any problems.

god of war

May 31st, 2006

God of War is a quite well done beat-em-up. Basically, you wander through a mostly linear, pseudo-ancient-Greek world, beating the crap out of tons of monsters that appear in your past, occasionally taking a break to either solve a bit of a puzzle or fight a boss monster.

I’m not sure that there are any stunning advances here, and I don’t understand the “game of the year” support that it’s gotten, but I had fun playing it. The difficulty level is well-balanced – I basically never got frustrated, and they’ve learned the recent lesson that, if a player is having trouble at a spot, maybe they should offer to make the game a bit easier for you instead of having you give up on the game. (Which I was happy to take advantage of in the final boss fight, or rather trio of fights – while I enjoyed the game, I didn’t feel like putting in hours to finish the very last part.) Good level design, nice texturing to the challenges, boss fights that I didn’t mind and even rather enjoyed at times.

The plot could have been decent (for the genre – this isn’t an RPG, after all) were it not for its blatant disregard of any actual Greek mythology. You play as a Spartan warrior who has been chosen by Ares but who has subsequently turned against him. So you end up trekking through a desert to find a Titan wandering around with a labyrinth chained on his back, hidden in the middle of which is Pandora’s box, which will give you superhuman powers. Sigh. If they’re going to do that, why not give up on the Greek theme entirely, and just invent a fictional ancient world to set it in?

Quite violent – you even have special finishing QTE-ish sequences to add to the gore of killing monsters. (And to provide an extra gameplay mechanic in boss fights.) Also, it’s the first video game that I can recall playing with bare breasts. I wonder why that is? I guess video game publishers are afraid that parents will freak out if their kids are playing games where you can see breasts, but in this game they figure the parents will freak out at the violence anyways, so they might as well go full-out for the slightly older male audience. The nudity disappears after the first third of the game or so, though; it was never very well-integrated into the plot, anyways. (Or maybe it’s that the plot attenuates after the first third or so, too.)

A slightly interesting leveling-up system: vaguely hidden (not really, any more than blocks in a Super Mario game are hidden) chests lying around. Many of these contain some amount of red orbs, which you can use to power up your spells and weapons. But some contain “Gorgon’s eyes” and “Phoenix feathers” to increase your health bar or magic bar. (I forget which does which.) Both of the latter max out after a certain point, however. And either I’m a stunningly good chest-finder or they’ve over-provisioned the eyes/feathers in chests, so if you find a chest that would have an eye or a feather after you’re already maxed out those bars, you get a lot of red orbs instead.

The result is that, if you’re at all inquisitive, you’ll have maxed out your bars by the end of the game. And the result of being extra inquisitive is that you’ll have maxed out every spell instead of most of them. It’s not at all important to max out every spell, while maxing out the bars is quite useful; the result is a system that gives you a linear world (so you can’t go back to earlier regions to search), and rewards you for doing extra searching, while not actually diminishing the gameplay for people who aren’t obsessive searchers (or who aren’t following a guide showing the location of every chest). A nice compromise.

Next in the “violent game” series: Halo. Which may or may not be too violent for Miranda to watch; I have no idea. I’m not sure, and it happens to be next on my list of games to play. One advantage – probably the only advantage, actually – of summer game doldrums is that it gives me time to play important games that I never got around to playing when they first came out. Speaking of which, if anybody has recommendations, I’m all ears – I don’t quite know what I’ll play after I’ve finished Halo or Guitar Hero.

thumper

May 31st, 2006

Hey, Jonathan’s blogging about Thumper. Neat.

no luck with music recommendations

May 30th, 2006

I am still looking for music recommendations. Several of the bloggers that I read occasionally recommend either individual artists or podcasts; since I seem to agree with said bloggers’ tastes in other matters, I usually give them a try. Alas, all such experiments have proved unsatisfactory. Fortunately, the artists that they recommend have sample songs available on their web pages, so I can discover that they are not to my taste before spending money on them. Progress, I suppose.

I’m somewhat embarrassed (or at least surprised) to find out that basically the only music podcast that I continue to listen to is Next Big Hit, which I found through the top 100 list on iTunes rather than more informal methods. A grab bag of pop, not particularly the sort of thing that I’m looking for, but I usually don’t mind most of it, and every week or two there’s a song that I rather like. And it’s in an AAC feed with chapter markings, so if there’s a song I particularly dislike, I can just hit the ‘next’ button.

Not a crisis, I suppose – I have enough music lying around the house that I don’t mind going through my CDs over and over again. (I’m just finishing a Mahler symphony run right now. Somewhat to my surprise, I’m finding that, though I basically like all of them, the first and second continue to stick in my head to a much greater extent than the others. Is that because of the symphonies themselves, or because I listened to those two over and over again before I bought recordings of the other ones? Maybe I should try, say, listening to just the sixth several times in a row.) And I have enough to listen to on my iPod; when I run low on my regular podcasts, I can always learn Japanese. Hmm – maybe I’m making a strategic error by looking for pop podcasts, and should try looking for classical music podcasts instead – judging from my non-podcast musical experiences, I’m probably more likely to find matches that way. Or if I’m going to branch out more, maybe jazz is a better place to go than pop. I shall experiment.

sbn

May 29th, 2006

I was just looking at the front material of a book and saw that its “SBN” was 671-21320-2. I didn’t know that there was a pre-international version of the ISBN.

And here’s some information if you’re curious about the 13-digit ISBNs that have been appearing recently.

i miss go

May 29th, 2006

I think I made the right decision to give up playing go: I just don’t want to spend one evening a week doing that. But I was just looking at a picture of a game in Hikaru No Go (nine moves into the Ota vs. Akira game), and memories came back. It can be a remarkably rich experience.

The next time I’m looking for a job, I should keep my eye out for one where I’ll be able to play go over lunch.

random links: may 29, 2006

May 29th, 2006

aging dog

May 29th, 2006

Our beloved Alyosha is fourteen years old. He’s been showing his age for a little while now – aside from slowing down in general, he started getting excessively grumpy three or four years ago. At a vet visit not too soon after that happened, the doctor said his thyroid levels were low; he went on thyroid meds, and his mood improved enormously.

He’s also started peeing a lot. Which may or may not be a side effect of the meds; we should get an answer to that soon. Recently, though, a couple of things have gotten worse. For a while, he’d had a hard time seeing the steps up into bed right after we turned off the light – it took his night vision a while to adjust. Recently, however, he’s been unable to get up into bed at all in the middle of the night – he seems to have very little night vision at all these days. Also, while it’s been a while since he wanted to take long walks, these days he’s loath to venture even as far as the end of the townhouse complex. I’m not entirely sure what’s going on there – he’s happy to shadow me when I walk around the house, including going up and down stairs, so I don’t think his legs can be aching too much. Hard to say. He’s gotten rather heavier, too, which may be a result of the decreased exercise.

Anyways, the other night we heard him falling down the stairs. I do hope that hadn’t been a regular feature of his nights; if so, it might be an explanation of why he doesn’t want to go on much of a walk in the morning, since he may be a bit bruised. So real night vision problems, and he hasn’t figured out quite where the stairs are. Once we realized he was doing that, we started leaving the stair lights on at night. Unfortunately, the stairs are near our bedroom, but we found that, if we unscrewed the light bulb at the top of the stairs, then we could still get to sleep just fine, and I think the light at the bottom is enough for him to see. Liesl was also talking about installing a dimmer switch; we might give that a try if the current solution doesn’t work.

Ultimately, though, we should take him to a doctor fairly soon. My tentative hypothesis is that he has cataracts: his eyes have been somewhat milky for years, so I hadn’t been worrying about that too much, but if it’s causing problems, we should do something about it. And googling suggests that cataracts can lead to poor night vision. Liesl’s parents had a dog who responded well to cataract surgery; maybe Yosha will get to go through that, too.

Or maybe it’s something else. Fortunately, the house is small and we have no plans to move any time soon (or any time not soon!), so if they can’t fix his vision, I’m sure he’ll adapt. But he is a sweet darling wonderful dog, so we’d like to make his remaining years as pleasant as possible.

books with more than two authors

May 29th, 2006

I can now handle books with more than two authors. Yay. Nice to be able to spend ten or fifteen minutes making a change that actually affects what books I can handle instead of spending months making a change whose effects nobody else can see.

Not that I’m done with the behind-the-scenes changes yet – I still have some amount of cleanup to do, getting rid of no-longer-necessary code, so I’m trying to combine each new feature with a bit of cleanup. And there was one unpleasant surprise when doing that: I was shuffling responsibilities between acceptance tests, when all of a sudden one of them stopped working. And stopped working in a quite strange way – it was updating a row in a database, and some of the columns got the new value while others had their old values. I don’t quite see how this could be any sort of obvious bug in my code – tests are pinning down the behavior pretty tightly, and if anything goes wrong an exception should be thrown that would make it up to the top. And my code should be pretty deterministic, yet the problem in question magically cured itself a few minutes later.

So I’m pretty disturbed. I have no idea if it’s related to my other current mystery, the random hangs I mentioned earlier. Just to be on the safe side, I read through the JDBC Javadoc a bit more, to look for places where I’m not releasing resources; I’m now calling close() on my java.lang.sql.Connection objects, just in case. (I was already calling it on my ResultSet objects, though that is one place where I could imagine there being gaps in my unit test coverage.) But this latest problem doesn’t feel like a resource leak to me…

Much of the future cleanups are pretty obvious, but there is one place where I have a question. Right now, I have an abstract interface Collection with two implementations, MemoryCollection and SqlCollection. The former is the original implementation, from the days when the list of books was represented by Java code; the latter is the implementation I’m using now. So I could delete the former, were it not for the fact that it’s being used in unit tests in a fair number of places.

So: do I keep it around, or do I retrofit the unit tests? It’s not clear to me that keeping it around is going to pose that much of a burden; and if it becomes a burden at some point, I can always retrofit the tests then. (Which will, admittedly, take a while, which is one reason to think about starting on it now.) So if keeping it around is the easiest way to write unit tests, then that’s what I’ll do.

One aspect of keeping it around is this: to create, say, a new Book object using MemoryCollection, I call a factory function, passing it the title and author, and then call various write accessor to update other attributes that I feel like setting. (E.g. the ISBN, or when I read it.) Which is an okay way to do things; it’s certainly better than creating an SQL row by hand. But now that I have this CLI tool to create and edit entities, I could use its interface instead, which is pretty easy to use: something like

add book author Fred title “This Book” isbn 1-234-56789-x

is easy enough to write, probably even easier than calling various write accessors.

There are a couple of issues with that. For one thing, I can’t just pass in a single string, I have to pass in an array of Strings, and it’s a little more verbose than I’d like to create that on the fly in Java. Maybe I could work around that by writing a little function to split the single string into an array, though – that would be easy enough to do, and might save me a fair amount of test-writing time. The other issue is that the above isn’t actually the syntax that I use for the current SQL interface – instead of passing in the name of the author, I have to pass in the entity ID of the author, something like “author 3” instead of “author Fred”. So there’s some fiddly counting to do, and I lose type safety, neither of which thrills me. (It’s a problem with the CLI tool as well.)

Another possible issue is that I was worrying about the tests being too incestuous, not being tied to the external realities of the database format enough. But, thinking about it more, I’m not worried about that any more: my tests for the Editor object (which writes out the SQL database) really do test the SQL that is generated. So it’s fine for me if my tests for Book, for example, whose main job is to generate HTML, aren’t so closely tied to the details of the SQL: as long as they accept whatever Editor outputs, it should be fine. In fact, it’s arguably superior to have that linkage be enforced in the unit tests. (This is all being enforced in the acceptance tests, too.)

I’ve got enough other cleanups to do that I don’t have to decide this one way or another for a few more weeks. I’m leaning towards getting rid of MemoryCollection and using SqlCollection exclusively, but I could still change my mind.

i’m hiring!

May 24th, 2006

I’m trying to fill an opening in my group. If you know any good programmers who live in the S.F. Bay Area, who are looking for jobs, and who think that it’s a good thing for code to come with tests, please point them at that link or send them my way.

wrote cli tool to edit sql

May 22nd, 2006

Up until a few months ago, the way I would, say, add a new book to the list of books I’d read was to edit a file (WriteDbc.java), compile it, and run its main, which would write out HTML pages directly from the Java data structures that it built up.

Then, a few months ago, I stuck in an SQL database as an intermediary: the main routine would write out the data structures into an SQL database (first wiping out the previous contents of the database!), and a separate program would go from the SQL to HTML. Which is ridiculous in the long term – the point of a database is to store data, not be a transient repository – but a useful step nonetheless.

But now I’ve finished a CLI tool to let me edit and add to the SQL database directly. So yesterday, I did svn rm WriteDbc.java after writing the data out one last time, and today I used the CLI tool for the first time in earnest (to reflect the fact that I just finished this excellent book and am about to start this one). And it works just fine.

Things that I learned while writing the CLI tool:

  • I might have fantasized that I had a traditional layered architecture for this, with at least hints of a persistence layer, an abstraction layer, a presentation layer. Well, I don’t. One manifestation of this is that the CLI tool and the SQL-to-HTML tool share essentially no code – my wrapper over java.lang.sql, a couple of simple data types (a date wrapper and a book title wrapper), and that’s it.

    The CLI tool is driven by a table mapping entity types (book, author, etc.) to SQL tables and, for each entity type, another table mapping keywords to columns; that’s it. Really simple to use, really simple to modify: after the first three entity types, adding each new one took less than five minutes. (With one special case exception.) And going from a CLI tool that could add a new entity (a book that I’d just bought, for example) to a CLI tool that could edit an existing entity (reflecting the fact that I’d finished the book, for example) took maybe 30 lines of code. It’s just not complicated enough to justify more architecture than that.

    One benefit of this is that, if I want to dabble in another language, I’ll be able to easily rewrite one part without having to touch the other. So if I want to, say, rewrite the CLI tool in Ruby, nothing’s stopping me (other than the fact that I don’t know Ruby yet) – I even have acceptance tests in place to back me up. Yay.

  • The one acceptance test surprise was that the acceptance tests went from taking a minute to taking two minutes; what’s worse, they would hang occasionally. The reason for the time increase was that, if an acceptance test wanted to test a scenario with 15 entities, it would have to run the CLI tool 15 times, starting up the JVM and connecting to the database 15 times. And, it turns out, doing so can turn a 3-second test into a 15-second test. So I modified the CLI tool to accept multiple commands in a single invocation; now the acceptance tests only take about 45 seconds.

    The sporadic hanging still bothers me. I can’t see how it could be some sort of infinite loop in my code, though I’ve been wrong before. I could imagine that I’m not freeing SQL resources appropriately – I have tests verifying that I’m releasing them in many circumstances, but it could well be that there’s some place where I don’t know that I’m supposed to release resources. (I would have naively assumed that resources would be freed when the process exits, so bugs like this wouldn’t matter, but maybe not.) Or maybe there’s a problem somewhere else.

I am glad that this is over with (there are a few loose ends to tidy up, but nothing major or urgent): it will be very nice to shift back to taking an hour to implement a feature that will make an actual visible change on the output, instead of taking rather longer than that to change the guts in a non-user-visible fashion. Especially since I have some features that really need to get implemented: I can’t add one of the books that I’m currently reading to the database, for example! Next weekend I will be able to, though, unless I’m too busy to be able to program at all.

lean software development

May 20th, 2006

Driven by my recent mania for all thing lean, I just finished Lean Software Development, by Mary and Tom Poppendieck; I wish I’d read it a few years ago. I’d been aware of it for some time, but I passed it over when doing my initial tour of the agile literature. I had assumed that the book was proposing a methodology; back then (and to a fairly large extent, even now) I had no desire to learn about more methodologies. Learning about one or two can be useful, to see concrete examples of how people but the basic ideas into practice, but beyond that, I didn’t see the point. (Especially since I have yet to hear about anybody other than their founders using any agile methodology other than XP or Scrum.)

It is, however, not a methodology: it’s instead a book with a range of suggestions for what software development might learn from lean manufacturing. (Both authors have quite a bit of software development experience; the first author also has quite a bit of lean manufacturing experience, from her time with 3M.) As they say right at the start, software development is not manufacturing: manufacturing is about producing identical (or similar) objects as quickly and reliably as possible over and over again, while software development is about producing a single or a few related evolving products. The authors’ take on this is that software development is more like product development than like manufacturing, so they use lean product development as their inspiration. (It turns out that lean manufacturing companies do product development differently from other companies: Toyota has been better at bringing new models quickly to market than US car companies, for example, and 3M has effective product development strategies as well.)

So, while some of their recommendations were very familiar to me from the little reading I’ve done in lean manufacturing (e.g. the first chapter is “Eliminate Waste”), others weren’t. “Set-Based Development” is a good example: they recommend that, when developing a product, you explore the solution space for your various constraints by constructing a large number of alternatives meeting each constraint, and then see if you can use those alternatives to come up with a design that meets all your constraints. This is in contrast to “point-based development”: there, you start with one target solution, and repeatedly alter it based on feedback until everybody is satisfied. The authors claim that this takes a lot longer to reach a solution than the set-based approach, despite the fact that many fewer options overall are considered.

There are some useful counterpoints (and, at times, counterweights) to XP. I should spend some time thinking about the relation, if any, between the set-based approach and XP spikes, for example. And XP depends on a (to me) almost mystical notion of a Customer making a certain class of decisions; this book spends more time looking at what goes into decision making. The “Empower the Team” section also provides a nice collection of tools (“Self-Determination”, “Motivation”, “Leadership”, and “Expertise”) which acknowledges certain dynamics more explicitly than XP does. Given the lean focus on quality, I was somewhat surprised that there wasn’t more of a focus on testing – I’m used to that being focused on (productively, I should add) to an almost obsessive extent in agile books. And this book spends much more of its time further away from the software developers than many agile books do, e.g. in the discussion of contracts. Or maybe that’s my selection bias coming into play – I have more software development context and responsibilities, so I focus my readings there.

I’m not sure what concrete effects it will have on my work in the short-term; for now, I’m going to continue reading about lean, waiting for concepts to sink in and crystallize. I imagine that I’ll return to this book in a couple of years and find specific inspirations in it, and indeed that it will have subconsciously inspired me in the interim.