maximize each iteration

This post by Ron Jeffries caught my eye a few days ago: maximize each iteration. Over the last six months, my team has released a build to a customer at least once every two weeks, often more frequently. When I first started in this world, I was told, frequent checkins are good. At Brown, I would make a little tiny change, check it in, repeat over and over. Yes, I broke the build frequently, and my colleagues and I did not understand eachother's code at all. Here at Laszlo Systems, every checkin requires a peer code review. This is fantastic for code quality, but as usual there's a quality for time trade-off. In choosing the granularity at which to do checkins, I am starting to consider some of the hidden costs:

• The author needs to synchronize their tree, resolve any conflicts, and do some version of a fly-through/smoke-test.


• The author and the reviewer have to do the review at the same time, which means the author will some small-chunk time waiting for an available reviewer.


• After the review, the reviewer and the author will both have to re-establish their cognitive state.


• The other members of the team will have to update to get each checkin, and pay their integration tax. Each integration has a flat fee in addition to the per-line-of-code-change cost.

It's worth it. An ivy league education is essentially a long series of having really smart, experienced, knowledgeable people review one's work and suggest how to improve it. Even if it didn't improve software quality, the code reviews would be worth the time for the sheer educational value.
Ideas for how to improve the value of each code review:

• Do reviews in coordinated pairs. If we both wait until we're ready for a review, we only pay the stop/start cost once for two reviews.


• Take the right size bites. The XP metric is something like a day of work or less, I think; right now I'm feeling like two or three days would be better for my team's process. I need to stray farther from the trunk to maximize the value of each of my reviews. I think XP calls this courage.


• A lot of my checkins are (just) changing assets and constants. I should combine many low-risk changes into a single checkin.

Any other suggestions on how to maximize each iteration?

Here's a live demo of the OpenLaszlo Rich Text Editor, which is part of the Laszlo Mail application. (If this were an academic paper, I'd have been thinking for weeks about the order of author names. In this case, I'll just let the team lead do the talking.) A specification of the user interface and api is available on the wiki.
The platform version of the editor supports a more stable subset of the formatting operations available in Laszlo Mail. Paragraph formatting in the flash runtime is challenging; character formatting is simpler.

better at starting than finishing

I'm better at starting things than finishing them. This week has provided another round of interesting ideas from the fascinating people I work with, but now it's time for me to be a mature programmer, and finish one of my side projects. I want to be like Oliver Steele, who created packagemapper.com over Thanksgiving. Or Don Hopkins, whose site has a ton of little projects that work. Or, heck, Wil Shipley, the creator of Delicious Library and a major contributor to the incredible Omni Group products. (Sorry, Wil, I don't know exactly how to describe your role at Omni; hope I'm not selling you short.)

My last few years of working on software has all been very isolated and obscure. If I wanted to show anyone anything, they had to either come to my lab, or for some projects I could bring my demo machine with me and demo it live. The projects have been either demo-ware or essentialy theatre. With the Open Laszlo platform, I can finally make rich smooth tasty applications that other people can use from the comfort of their own homes. Now I need to add the fit-and-finish step to my process. One standalone rich text editor, coming right up...

no programming after 9 pm

I have a rule which I've been forgetting lately: no programming after 9 pm. This is my equivalent of the extreme programming 40 hours a week rule. I'm old enough and secure enough to admit that I'm useless as a coder after seven pm. I can still do decent pixel tweaking and whatnot for a bunch of hours after that, but if I haven't found a bug by seven pm, I'm not going to find it that night.
Some of my co-workers at Laszlo work insane amounts (fer instance, Scott Evans' domain name is antisleep.com) and I've been trying to be like them... even turning up at work before 9 am a few times! but no. I need eight hours of sleep a night; I really truly do. Stopping programming by 9 pm is one of the best ways for me to maintain my happiness and well-being, not to mention my code quality.
In my world, schedules matter on the order of days and weeks, not hours and minutes. If our process is running at light-speed, it takes minimum a day for a code change to go from "it works on my machine" to "it's live." At a more normal speed, we do weekly or semi-weekly builds. So, reminder to self: go to sleep! Now! And eat a sandwich!

over-caffeinated, or, the hazards of being friendly with java juice employees

Today I went on an afternoon fructose run, and treated myself to a matcha shot. That's powdered green tea in one or two ounces of fresh orange juice. One shot is supposed to be 75 mg, two shots is 150. I am a caffeine lightweight, so I usually get just one shot and drink half of it. I think this is one of the tastiest low-sugar ways to self-medicate with caffeine; I can't stand the sucralose/aspartame/red #5/natural and artificial flavors "energy drinks." I've indulged in this treat enough to make friends with one of the employees at the Jamba near the office, and today I think she must have given me a free double, or triple, or something, because it's seven hours later and I'm still rather caffeinated. Er, thank you? I think?