malvasia bianca

Since I felt compelled to type out a long quote for use on a mailing list, I might as well stick it up here, too. This is from Deming’s Out of the Crisis, pp. 128–129, in its chapter on “Diseases and Obstacles”; the blockquote sections are indented in the original.

Search for Examples. Improvement of quality is a method, transferable to different problems and circumstances. It does not consist of cookbook procedures on file ready for specific application to this or that kind of product.

It is not unusual for a consultant to receive an enquiry for examples of success in a similar product line. One man enquired if the methods of this book had ever been used in the manufacture of wheelchairs. Another enquired about compressors for air conditioners: did I know of any application? Another man enquired about the management of a hospital: would the 14 points apply? Another wondered about application in a large accounting firm. Another man wondered if the principles taught in this book had ever been used in the manufacture of automobiles, as if he had never heard of Japan’s automobiles. A banker wondered about application in banks.

A man just called on the telephone from Johannesburg with the proposal that he come to this country and visit with me six companies that are doing well. He needed examples, he said.

My answer to such enquiries is that no number of examples of success or of failure in the improvement of quality and productivity would indicate to the enquirer what success his company would have. His success would depend totally on his knowledge of the 14 points and of the diseases and obstacles, and the efforts that he himself puts forth.

Too often this is the story. The management of a company, seized with a desire to improve quality and productivity, knowing not how to go about it, having not guidance from principles, seeking enlightenment, embark on excursions to other companies that are ostensibly doing well. They are received with open arms, and the exchange of ideas commences. They (visitors) learn what the host is doing, some of which may by accident be in accordance with the 14 points. Devoid of guiding principles, they are both adrift. Neither company knows whether or why any procedure is right, nor whether or why another is wrong. The question is not whether a business is successful, but why? and why it was not more successful? One can only hope that the visitors enjoy the ride. They are more to be pitied than censured.

It is a hazard to copy. It is necessary to understand the theory of what one wishes to do or to make. Americans are great copiers (QC-Circles, Kanban or just in time, for example). The fact is that the Japanese learn the theory of what they wish to make, then improve on it.

QC-Circles contribute vitally to industry in Japan. American management, without understanding management’s role in a QC-Circle, try to copy QC-Circles, only to find some time later that they have a dud. QC-Circles that enjoy cooperation and action by management will do well anywhere.

It was related to me during a seminar (source unfortunately unrecorded) that the management of a company that makes furniture, doing well, took it into their heads to expand their line into pianos. Why not make pianos? They bought a Steinway piano, took it apart, made or bought parts, and put a piano together exactly like the Steinway, only to discover that they could only get thuds out of their product. So they put the Steinway piano back together with the intention to get their money back on it, only to discover that it too would now only make thuds.

A bit video-heavy today.

• The power of continuous improvement.

• A cool-looking physics “game”:

  (Via BitWorking.)

• Zefrank on complicated stuff:

• Falco PA!

  (Via Game|Life, which also links to a Guitar Hero version.)

• An fun variant on presenting minigames.

• Time to add The Muppet Show to my Netflix queue.

  (Via Cosmic Variance.)

• Brian Dettmer book autopsies. (Via Signal vs. Noise.)

• Fun for your jailbroken iPhone:

  (Via Pink Tentacle.)

I finished reading The Art of Agile Development, by James Shore and Shane Warden a few weeks ago. It’s a quite good book: if you’re looking for a well-written, prescriptive guide for how to do XP, this is what I would recommend.

Though I won’t go into the book in general any more than that. But, a few thoughts that it triggered:

One thing I liked about the book’s discussion of “once and only once” (pp. 316–317) is that it spent some time on the first “once”. I’m used to thinking of the sentence in terms of eliminating duplication, which is great. But the first part of that sentence is important, too: as they say, “don’t just eliminate duplication; make sure that every important concept has an explicit representation in your design”. That way, you have a place to store behavior related to that concept: e.g. having a Dollar class may not seem like a big win over, say, just representing dollar values as integers, but it gives you a place to stash code for formatted output, or parsing, or conversions to related types.

I also really liked the discussion of levels, rhythms, and frequencies of refactoring in the “Incremental Design and Architecture” section. (pp. 321–330.) They distinguish between standard incremental improvements and “breakthrough” changes: the latter are “idea[s] for a new design approach, which will require a series of refactorings to support it. … Breakthroughs happen at all levels of the design from methods to architectures.”

After which they talk about how frequently you do various sorts of refactorings, and how to make time for them. At the method level, “Method refactorings happen every few minutes. Breakthroughs may happen several times per hour and can take 10 minutes or more to complete.” At the class level, “Class-level refactorings happen several times per day. Depending on your design, breakthroughs may happen a few times per week and can take several hours to complete.”

The latter raises the question: several hours is enough to make a noticeable blip in your team’s work for the week, so where do you find the time, if you see something that looks valuable but isn’t on the shortest path to completing a feature? Their answer: “Use your iteration slack to complete breakthrough refactorings.”

And then there are architectural breakthroughs; I’ll quote them at length on the subject (p. 325):

In my experience, breakthroughs in architecture happen every few months. (This estimate will vary widely depending on your team members and code quality.) Refactoring to support the breakthrough can take several weeks or longer because of the amount of duplication involved. Although changes to your architecture may be tedious, they usually aren’t difficult once you’ve identified the new architectural pattern. Start by trying out the new pattern in just one part of your design. Let it sit for a while—a week or two— to make sure the change works well in practice. Once you’re sure it does, bring the rest of the system into compliance with the new structure. Refactor each class you touch as you perform your everyday work, and use some of your slack in each iteration to fix other classes.

Keep delivering stories while you refactor. Although you could take a break from new development to refactor, that would disenfranchise your customers. Balance technical excellence with delivering value. Neither can take precedence over the other. This may lead to inconsistencies within the code during the changeover, but fortunately, that’s mostly an aesthetic problem—more annoying than problematic.

Definitely something to think about: over the last few years, my team has made some progress in terms of lessening the technical debt that we’re adding to the system, but we still haven’t done nearly as well on that as I’d like, and we’ve done a bad job in terms of actually eating away at the technical debt. (As you might suspect from my using the term “last few years”.) We’re just not good at maintaining a good refactoring rhythm at the various scales that are necessary; maybe the authors’ advice on the subject will help, by giving an idea of what our behavior would look like if we were successful.

Note also the importance of slack in carrying this out successfully.

In the spirit of “every long e-mail I send somewhere should be shamelessly recycled on my blog”, I present some random thoughts on testing.

Why do we release products with defects that we weren’t aware of? This is a sign of flaws in our testing; two possible causes are:

1. We don’t know what to test for.
2. We do know what to test for, but we’re not able to do enough testing before release.

For 1, how can we figure out where our blind spots are? Some tactics:

• Defect clusters.

If we can figure out in what areas we’ve historically had a large number of post-release bugs, then we can increase our testing in that area in future products. So if people can come up with useful suggestions for analyzing post-release data, that would be very useful.

• Different classes of tests.

One of the most interesting testing ideas I’ve seen over the last couple of years is the idea that you can analyze tests along two dimensions: are they business-facing or technology-facing, and are they intended to support engineering or to critique the product? (The idea comes from Brian Marick, I blather on about it elsewhere, and there’s also a section on it in Implementing Lean Software Development.)

This gives four quadrants. Technology facing tests designed to support engineering are unit tests, tests that narrowly focus on a specific internal interface. Business facing tests designed to support engineering are tests that are focused on a certain aspect of customer-visible behavior. Technology facing tests designed to critique the product are property testing, tests for “nonfunctional requirements”: load testing, security testing, combinatorial testing. And business facing tests designed to critique the product are various sorts of manual poking around: usability testing, exploratory testing, etc.

I know that, in the past, I’ve had huge blind spots in these quadrants. And we can gather data to figure out which quadrants we might be missing: if we’re either not implementing known basic requirements or taking too long for the product to stabilize its functionality in those basic requirements, then we might be missing tests in the two “support engineering” quandrants. If we’re running into lots of corner case bugs or stress bugs, we’re missing property testing. And if we’re producing products that behave according to spec, but isn’t what the customer wants, then we’re missing tests that are business facing and designed to critique the product.

The above assumes that we don’t know what to test for; what if we do know what to test for, we’re just not doing a good enough job? Here, testing is a bottleneck, and we want to speed it up. At least, it might be a bottleneck: it may also be the case that something else is a bottleneck, creating schedule pressure that isn’t caused by testing, and testing gets unfairly shrunk because it comes at the end of the development cycle. But, for now, let’s assume testing is a bottleneck.

There are certain obvious knobs we can turn here (hire more testers, build more machines to test on), and that may be what we have to do, but those knobs cost money. So we should also look at the testing value stream with lean eyes figure out where we can find waste, and eliminate as much as possible.

To that end, some questions:

• Are there manual tests that can be turned into automated tests?

Doing this would have three benefits:

1. If availability of human testers is a bottleneck, this helps alleviate that bottleneck.
2. Automated tests are generally faster than manual tests.
3. Engineers developing the product can run the tests more easily, which means that they can find defects sooner after introducing them, which has no end of benefits.

• Are there tests that can be sped up?

One technique that works really well on the software side is to directly test the smallest software interface relevant to the issue in question, instead of starting up the whole system: this can turn a 5 minute test into a 5 millisecond test. For example, every time I check in software, I first run a suite of 5000 or so automated tests; if I had to actually run the whole StreamStar system for each test, that would take weeks, but as it is it takes 15 minutes to run all 5000 tests. (And I wish they were faster than that!)

To be clear, we do have other tests that run the whole system. But, to return to the four quadrants above, try to move as many tests as possible to the “support engineering” side (by turning them into tests of clear functional requirements), and try to move as many of those as possible to the “technology-facing” quadrant (by shrinking the interfaces they test). You still need all four quadrants, but that’s the quadrant where you get the most bang for your time.

• Is the test analysis taking too long?

Maybe the problem isn’t with running the tests, it’s with making sense of the results of the tests. Do the tests give a clear pass/fail result? Failing tests take more time to analyze than passing tests (among many other problems, e.g. one bug can mask another); do we have too many failing tests? Do the tests not generate enough information in the failure case to make analysis easy (e.g. so you can tell different known bugs apart, or known bugs apart from unknown bugs)?

• Is the test writing taking too long?

If so, we should invest more time in test frameworks.

• Are people or machines idle inappropriately?

This is a dangerous issue to approach, because you don’t want to do makework for the sake of makework: for best utilization of a system, you should work your bottlenecks at as close to 100% as possible but explicitly allow slack in all other components. Having said that, sometimes waiting is just plain waste. For example, if you’re low on test machines, you want to separate running tests from analyzing tests as much as possible, so you can keep the machine busy running the next test while you’re still analyzing the previous one. (But if you’re not low on test machines, then if you can speed up the test writing/analyzing process by hogging the machine for a while longer, that’s a better choice. And still better is to make the writing and analyzing as easy as possible, so you don’t have to make that choice!)

• Do people have time to think about what they’re doing?

Overworked people make mistakes; even if they don’t make mistakes, it’s hard to devise a method to cut testing time in half in some area if your boss is harping on you to get dozens of things done today.

• Are good ideas spreading through the group?

We need a way to identify our best ideas and to get them adopted broadly.

About two and a half months ago, I had 89 saved items in my feed reader. I noted that I wasn’t shrinking that number as quickly as I expected, and predicted that, two months later, I’d have shrunk the list by a further 20 items. It’s a more than two later; how am I doing?

Going over to my starred list and scrolling to the end, it turns out that, in fact, my list has shrunk by a total of -9 items, bringing me to 98 saved items. Which makes my prediction off by 29; oops. What happened?

I’ve changed categories a bit in the interim: whether or not I got around to watching a video had a lot more to do with how long it was than anything else. So I decided to merge my old “read”, “video”, and “long” categories into two categories “short” and “long”, with “short” being items (written or video) that I expect to take 10 minutes or less and “long” being ones that I expect to take longer. With that caveat, and assuming that all the old video items now belong in “long” (mostly or entirely true), the new numbers for each category, with their change from the previous number from that category are:

• blog: 2 items (-2)
• book: 25 (+7)
• commented: 2 (-3)
• flash-game: 8 (0)
• long: 14 (-4)
• music: 7 (-2)
• podcast: 20 (+9)
• recommendation: 11 (+4)
• short: 0 (0)
• think: 9 (-1)

There’s some good news here. The long items have declined noticeably: I’ve taken the time to go through a few of those, and have generally been glad I did. I’m keeping the blog items under control, and “music” and “think” are doing okay. “recommendation” is growing a bit, but the real issues are “book” and “podcast”.

Actually, “podcast” is a weird case: I currently have 20 podcasts saved up that I’d like to listen to, but I tagged every single one this month. Basically, I’d been doing a quite good job of balancing free podcast-listening time with interesting podcasts that I noticed, but then a lot more podcasts caught my eye this month than last year. I’m not sure how that’s going to play out; check back next time.

The real killer is “book”: I simply run across interesting-looking books a lot faster than I make time to read them. It’s even worse than the numbers make it seem, since some people have the rude habit of recommending multiple books in a single blog post.

This isn’t a new phenomenon, of course: I have other long lists of books to read that I’ve saved elsewhere. At least the only book queue that I really worry about, the queue of books I’ve bought but haven’t read, isn’t doing too bad: it’s at three books, which is two books too large, but much much better than it used to be. Still, I should probably accept that I’m not going to read some of those books any time soon and get rid of them. Or should I? I read a little over a hundred books a year these days, so there’s no particular reason to believe I won’t eventually read most of the books on that list, even accepting that I take a lot of my reading suggestions from other sources.

There’s one other category which seems innocuous but isn’t: “flash-game”. A list of 8 items with a growth of 0 looks like a great example of a productive category: individual games take long enough that it’s not surprising that I might have a bit of a backlog, but clearly I’m making it through the backlog at an appropriate pace.

The truth is, though, that the 8 saved flash games are the exact same 8 flash games from last time, and that they’ve all been saved since July, 2007 or earlier. I have played a few shorter flash games in the interim, but the real lesson here is that I never get around to playing flash adventure games!

Overall, the oldest saved item (excluding possible items that I accidentally unstarred and then restarred, losing date information in the process) is Simon Phipps’s recommendation of Filoli, starred on June 18, 2006. Which looks like a pleasant place to spend a few hours some future day, I just don’t want to do it during the winter! We’ll go there this spring some time, though. The second oldest item is a mention that Getting Real is now available for free online. Which was in the “long” category for quite a while (or maybe the “book” category?), but I recently read it. (And am glad I did, and it’s actually not that long.) Now it’s in the “think” category, because I’m idly wondering if Backpack might be a useful tool.

I guess I need to make a prediction. I’ll report back in early April; I’ll predict that I’ll still be at a little under 100 items. I guess, to be concrete, I’ll predict that I’ll remain at 98 saved items.

I’m hiring again. If you live in the S.F. Bay Area, are a good programmer, and want to be the first kid on your block to stream out 320Gbps of video data, please let me know. (You can also submit a resume via the above link.)

Ken Robinson’s TED talk on “Do schools kill creativity?”

You can also watch it at its web page; I like the chapter markings on the full-screen version of the video player on their page. (Not the embedded one here.)

I heard about this talk via two separate routes: Presentation Zen and Evolving Excellence. Two blogs which don’t normally have much in common, but in retrospect it makes sense that you’d see this in both places: in particular, the lean folks know as much as anybody about the value of encouraging creativity at all levels of your organization.

Lots of good stuff in the talk; some ideas I particularly liked:

• Students who are in school now will still be working half a century from now, yet we have a hard time predicting what the world will be like half a decade from now; can we afford to do anything other than do anything other than encourage their creativity and capacities for innovation?
• To be creative, you need to make mistakes; yet schools punish you ruthlessly for making them. (They could take a lesson from Super Mario Galaxy: feedback doesn’t mean punishment. Or, for that matter, from more sandboxy games: you don’t need pervasive feedback, either.)
• Different people have different strengths, yet schools focus on an obscenely small portion of those. If somebody is fidgeting in your math class, perhaps discovering that they’re a dancer is a better idea than putting them on ADHD drugs.

As always, I’m very glad that we found PACT. It’s not perfect, but it’s worlds better than what I hear of schools elsewhere.

From 37 Signals’ Getting Real:

People often spend too much time up front trying to solve problems they don’t even have yet. Don’t. Heck, we launched Basecamp without the ability to bill customers! Since the product billed in monthly cycles, we knew we had a 30-day gap to figure it out. We used that time to solve more urgent problems and then, after launch, we tackled billing. It worked out fine (and it forced us into a simple solution without unnecessary bells and whistles).

Not sure I would have thought of that strategy myself. Or had the courage to follow through if I did…

From Kent Beck’s Implementation Patterns (p. 20):

Once a set of implementation patterns has become habitual, I program faster and with fewer distracting thoughts. When I began writing my first set of implementation patterns (The Smalltalk Best Practice Patterns, Prentice Hall 1996) I thought I was a proficient programmer. To encourage myself to focus on patterns, I refused to type a character of code unless I had first written down the pattern I was following. It was frustrating, like I was coding with my fingers glued together. For the first week every minute of coding was preceded by an hour of writing. The second week I found I had most of the basic patterns in place and most of the time I was following existing patterns. By the third week I was coding much faster than I had before, because I had carefully looked at my own style and I wasn’t nagged by doubts.

Some things that have passed through my earphones recently:

• In a recent lean blog podcast episode, Norman Bodek talked about how great mistakes are, because making a mistake is the best way to learn something.
• In an episode of The Cranky Middle Manager that I just listened to, Patrick Lencioni talked about how one of the signs of a bad job is that you can’t tell whether or not you’re doing a good job at it.

Everybody wants to do things right. But if you make a mistake, don’t freak out about it: notice that you made a mistake, figure out how to do things right the next time.

This has two hard parts: you have to notice that you made a mistake, and you have to not freak out about it. Which points at a problem with our educational system (among other aspects of our culture): it’s designed to get you to freak out about making mistakes, without giving you nearly enough tools to help you notice that you’ve done it. As math teachers all know, telling students to check their work isn’t sufficient support; helping students develop the skills to notice when they’ve made a mistake is hard, and I suspect that attacking them when they screw up probably isn’t the best way to go about it.

Of course, while making mistakes is all well and good from a learning perspective, we don’t want to go too far with that. Which is why, as Bodek continues, we should distinguish between mistakes and defects. Making mistakes is all well and good, but we don’t want other people to suffer from them. This is where poka yoke devices come in: they help improve quality by making it as easy as possible for people to notice when something is going wrong.

The big news around here for the last week has been the oil spill in San Francisco Bay. The news coverage has been all about whether or not it was the fault of the pilot or of a machinery malfunction: train wreck management, or at least train wreck news coverage, at its best. I have no idea what really happened there, but I hope the actual investigation is focusing more on learning about what went wrong and preventing this in the future than on figuring out whom to point fingers at.

(I can’t remember where I read this - Gerald Weinberg somewhere, maybe? - but if you really feel a need for a rule on how to point fingers, here’s one: if you aren’t authorized to sign off on a purchase for X dollars, then you’re not ultimately responsible for a mistake that costs your company X dollars. Again, I don’t want to excuse defects, but people higher up in the company should be growing an environment that minimizes the chance of defects happening at an unacceptable frequency.)

I would seem to be more confused than normal these days. Which, in the past, has frequently been a good sign; maybe my brain is figuring something out? Or maybe I’m just clueless. Anyways, I present to you a random collection of thoughts, which may or may not be related to each other in some way.

• At work, I think we’re doing a reasonable job of adding new features. Though I’m sure there’s room for improvement.
• I also think we’re doing a reasonable job of fixing bugs: acceptance test failures are way down, and we’re even successfully attacking sporadic bugs and old, thorny bugs.
• Not so sure about code maintainability: there’s even some evidence to suggest that our code maintainability has, in some areas, gotten worse recently.
• Code maintainability is harder to measure than features and bugs. And there’s less external pressure to get it right, so not surprising that it’s fallen by the wayside. Because of our successes in other areas, and because we’re doing a better job of planning this release than the last one, though, we have some time to attack it.
• I wish I were better at helping various teams that I’m part of improve our processes.
• One-on-ones are a good idea, even (especially?) if you don’t know what you’ll get out of them. And the more frequently you have them, the lower the pressure, which is a big help to everybody.
• The book I’m currently reading at work is Matthew May’s The Elegant Solution. Which is reminding me of some aspects of lean that I hadn’t been focusing on, especially on the “respect for people” side.
• Having the team all focused on the same, small-granularity tasks is wonderful in terms of making concrete progress in ways where our work reinforces each other and matches business value. Not necessarily so great in terms of letting people, say, focus on what they do best or define their own job.
• One thing that May talks about is the power of opposing goals (make a car faster and get better mileage and lighter and cheaper by these specific amounts), and the evils of satisficing. Simultaneous satisfying all your goals sounds wonderful if you can do it; I wish I knew how. I suspect that Toyota has some very useful techniques to this end.
• Alexia Bowers gave a good examples of meetin opposing goals, if I’m remembering the podcast correctly.
• The book before last that I read was a guide to the ToC thinking tools. (See also It’s Not Luck.) Do these actually work? My brain is strangely resistant to even giving them a try.
• I think I’m getting better at not talking in meetings, about chiming in and then letting other people argue for a while. Gratifying that, not infrequently, other people make the arguments that I would have made were I talking.
• I stayed home on Friday, because Miranda was sick, and called into two meetings. Both of which were very frustrating. I think part of it was that I missed some of the cues of the flow of the meeting, and part of it was that I wasn’t very good at explaining, or even seeing, how we were talking past each other. (I did think of an evaporating cloud to explain one of the conflicts after the fact, for better or for worse.)
• I wish I spent more time talking to people in other parts of Sun.
• What do I want to do when I grow up?
• After taking a break for a few years, I’ve gone to one conference each of the last two years, and gotten a lot out of each of them. I should continue this going forward. (And possibly even ramp it up a bit, since if there are further Agile Open Californias, I’m not going to stop going to them.) Where should I go next year?
• What communities do I want to be part of? What does it mean to be part of those communities?
• What teams am I currently part of? Do those teams behave how I think a team should behave? If not, how should I behave?

I could probably ramble on in this vein for quite some time; time to go to bed. Happy Armistice Day, all.

Warning: this post consists of discussion of management of queues that matter only to myself, and is therefore extremely unlikely to be interesting to anybody else. Despite which I insist on writing it, because of my excessive fascination with the effects of and management of queues.

Two months ago, when discussing my lists of saved items in Google Reader, I claimed that:

my bet is that I’ll be down to 50 items in another couple of months, and will be down to 10 items in half a year.

Which, two months later, turns out to be false. I’m down to 89 items, and the only reason why the number is under 100 is because I took a sick day today. (My brain is not up to programming, but blogging and blog reading are not so demanding.) The tags that I’m currently using are:

• blog: 4 items. (Would be longer were it not for my last post.)
• commented: 5 items. (A bit longer than normal.)
• flash-game: 8 items.
• long: 6 items.
• podcast: 11 items.
• read: 0 items. (That’s the imperative form of the verb, not the present or past tense.)
• recommendation: 33 items.
• think: 10 items.
• video: 12 items.

The numbers add up; as is normally the case, I don’t have anything double-tagged. (Other than numerical tags used for indexing purposes, which I’m not worrying about here.)

These lists have a different feel from each other. The simplest is “read”: that’s a temporary overflow area, nothing should stay in there for more than a day or so, it’s usually empty. The categories “blog” and “commented” are short-term queues for a specific purpose. (Well, they should be: all the current posts sitting in “blog” are from September. I should do something about that. Hmm, I’ll go and delete one of them right now!) Some of “podcast” fits into the specific, short-term category, too.

There are also queues of stuff that I want to get around to going through, but which is too long to fit into my normal rhythm: “flash-game”, “long”, “video”. (Some of “podcast” fits in here, too.) I’ve been making my way through that: these days, items that take 15 minutes or so to process don’t last in there for very long, but longer stuff can stay there for a while. Even so, the numbers in these categories are dwindling, but it wouldn’t surprise me if it takes a year to go through it all. (Hmm, does that add up? A net removing of one every two weeks? Seems plausible, but hopefully I can do a bit better than that.)

Looking at those three queues, it’s not clear to me that they’re the most useful choice anymore: am I getting anything out of segregating them based on content type? Maybe I should merge them all into “long”? Or maybe have “long” and “medium” categories, where “medium” means “about 15 minutes”? Or maybe I should put items of 15 minutes or less into “read”, and accept that occasionally items will stay in there for up to a week? Hard to say; the flip side is that I do like to have categories that don’t get much larger than about 10 items, so if I have reason to feel that way, then I shouldn’t merge them just yet. So I’ll leave them as-is for now, but I probably will merge them in a few months.

And then there’s “recommendation” and “think”. These, especially the former, are the big sinks. I use “recommendation” for blog posts that mention a book that I might want to read, a CD I might want to buy, etc., while “think” is for things that I’m considering doing: upgrading my WordPress installation, taking Alexander Technique lessons, learning a new way to tie a tie, various random stuff.

Those two queues don’t move very fast at all. My rate of reading books is dreadfully slow these days, for example, and I have other sources of book recommendations than blogs, so it’s a rare month when I knock off more than two or maybe three books of the recommendation list, while I can just as easily add two or three new recommendations back on. Similarly, I buy a new CD every week or two these days, but a lot of those are from artists that I’ve discovered elsewhere or artists that I already know I like and am working through the back catalog of. (Fortunately, or rather “fortunately”, I don’t subscribe to many blogs that give me good music recommendations.) To make things worse, some of the posts contain lists of recommendations where I’m interested in more than one item on the list.

Honestly, I’m not sure if the “recommendation” queue is growing or shrinking these days. And its size rather stands out. I should attack both of those problems by breaking it up into multiple categories; that makes since, after all, since I drain the different sorts of recommendations at different rates. Let me go and do that right now…

Okay, I’m back. It turns out that the oldest 8 saved items all fit into that category, which is further evidence that it was a bit out of control. (It would have been the oldest 10 if I hadn’t just shed a few.) The former “recommendation” category has turned into:

• book: 18 items.
• music: 9 items.
• recommendation: 7 items.

So now I’m left with three decent-sized categories instead of one large one; that’s better. And one of the remaining ones is still the largest category on the list! I should clearly spend more time reading books.

I guess I should make another prediction, if for no other reason than that it will let me continue saying false things. Over the last two months, the list has more than shrunk in half, but I don’t think I’m going to be able to keep that up. I’ll predict that, over the next two months, the list will shrink by 20 items, that I’ll eventually reach a steady state of 20 items in total, and that it will take me a year to reach that steady state.

And now to some actual content from Agile Open California. As I mentioned before, I hosted a session called I Don’t Like Pair Programming, since the topic had been on my mind after our team meeting the previous week.

The title isn’t really accurate: I usually enjoy pair programming when I’m doing it, but my brain nonetheless persists in not looking forward to it. Which is weird—I would like to think that my brain is generally more sensible than that—so I thought I should ask for help understanding myself.

My guess is that it was the single most sparsely attended session at the conference: there were about five of us there. But I really enjoyed it, and am quite grateful to the others who showed up. The main piece of psychological advice that I picked up was contributed by Rob Myers (who learned it from the AYE Conference): it’s not that introverts don’t like people, it’s that we need time alone to recharge. Which suggests that, perhaps, if I had, say, one or two hour-and-a-half pairing sessions a day, I’d be more likely to enjoy (or less likely to feel trepidation towards) pair programming than I do in my team now, where a pair typically sticks together until either the day ends or the card ends. This would require other changes in the way my team operates, but I suspect they’re all to the good: we hog cards too much as is.

Steve Bockman also gave us the following pairing mechanics suggestion: pass the keyboard every time you write a test, get a test to pass, or refactor. Which sounds like fun to try; I don’t think that I’m bothered by keyboard hogging, but other people probably are, and I’m certainly curious what the experiment would feel like.

The other thing I wanted to talk about from the conference: for whatever reason, some discussion that we had during a session that Rob hosted on “Maintaining a Collegial Environment in a Competitive World” got me thinking about teams transitioning to agile. (No idea how the topic led to this thought; which is a sign of the strengths of the conference.) Some people (e.g. Ron Jeffries) strongly suggest that, if you’re intrigued by XP but aren’t sure it’s all a good idea, you should just do it by the book for a while, and see how it works. (As opposed to starting with the parts that make sense to you, and then maybe adding in more stuff and maybe not.)

But we can juxtapose this against two other ideas from the agile and lean worlds:

• When dealing with legacy code, there’s a temptation to just rip it out wholesale. But that’s a good idea much less often than you’d think: it’s often much better to accept the code and gradually refactor and add tests as you need to touch it.
• Taiichi Ohno has suggested (I believe, I’m too lazy to dig up a reference) that you shouldn’t start with a standard work specification that’s too good: it’s better to start quickly with something mediocre, among other reasons that it will be easy to find ways to improve it!

I’m not going to take either of these as suggesting that, in general, Ron is wrong: for one thing, sometimes the right thing to do with legacy code is to throw it out, and I’ve read stories from the lean world about Japanese experts coming in, making drastic changes, and getting immediate results. But what they do suggest is that, rather than focusing on getting the details of the situation right immediately, better to focus on how to improve the situation in a disciplined matter. In other words, refactoring supported by testing in the code world, continuous improvement via formal experiments in the process world.

I spent Monday and Tuesday at the first Agile Open California. I learned several things there, which I hope I’ll find time to blog about over the next couple of days, but I want to start by talking about the format.

Actually before getting into the format, I want to talk about the setting. It was at Fort Mason, which is right on the northern edge of San Francisco, and took place during what must have been the two most delightful days of weather in S.F. that entire year: sunny and right around 80 degrees both days, either of which is a rather improbable event. The conference started with me sitting in a large room with half of my attention out the window looking at the sailboats in the marina and the Golden Gate bridge behind them. On the second day, I discovered the delights of spending free time on an outside stairs/fire escape on the northern side of the building: nice and warm, with a bit of a breeze, and while I couldn’t see the bridge and the marina from there, I could look straight across the bay to the northern shore.

So: hard to beat the setting. As to the format: it was the first time I’d gone to an all-open space conference. No talks prepared in advance: we spent the first thirty minutes or so coming up with the schedule, with people just writing a topic on a piece of paper, standing up and explaining it, and putting it on a schedule grid on the wall. Much to my surprise—I had zero plans of doing this going in—I turned out to be one of those people, because I had something on my mind after last week’s team meeting. (My topic being “I Don’t Like Pair Programming”; I’ll leave that to another blog post, other than to say that the title isn’t really accurate.) At the end of this, we had a schedule that averaged around three sessions at any given time, with me always at least somewhat interested in one of the sessions in any given slot and, as often as not, interested enough in two of them to wish I could be in two places at once. Basically, while hardly a stunning revelation, it was about as good a conference schedule as I’ve seen.

Which brings us to another aspect of open space: while you can’t actually be in two places at once, you are explicitly given your blessing to flit from session to session to follow your interest. I really didn’t do this, though: I stayed in a session from start to finish (except one time when I left early and went out to the aforementioned stairs to hang out and read a book), and pretty much everybody else seemed to do the same. (There may have been a contingent of people who didn’t really go to the sessions at all and just hung out and chatted; I’m not sure.) Part of this was that I was enjoying the sessions, part of this was that the sessions led to intricate enough conversations that I’m not sure I would have gotten a lot out of jumping into the middle of them, and part of this was that there weren’t any times where there were two sessions that both looked really interesting and where the one I went to first proved to be uninteresting.

So: the format doesn’t provide a miracle solution to the “be in two places at once” problem. Which is too bad, but what took me until the second day to realize was that it does provide a solution to another problem. Namely: at some point during grad school, I developed an allergy to lectures. I like learning about things by listening to other people, but I want a chance to talk back, to express all the thoughts that they spark, and to do this with more than one person at once. Which I got to do that for a couple of days, and it was great! Sure, some of the discussions were sort of meh, but some of them were completely fascinating, and I found myself having sudden revelations out of the blue, which I could express immediately, get feedback on, and refine in real time.

Honestly, I might now be spoiled for normal conferences. I won’t propose this as the miracle solution for everything: for one thing, not everybody is as allergic to lectures or likes talking as much as I do, and for another thing it probably works better in a setting where intermediate or advanced practitioners are trying to refine knowledge than, say, a setting where people novice practitioners are trying to acquire knowledge. (At least, that’s what I’d guess, but who knows.) And, while I generally prefer to get my canned knowledge in book or other written form, I’ve been to some wonderful talks in my time. But I tentatively think that this is now my new default best practice for running conferences, and any other format has to justify itself.

One other unusual thing about the conference: the makeup of the audience was rather different from what I’m used to in a setting discussing a technical topic. (Which makes sense, actually: agile focuses a lot on interpersonal matters, and open space probably draws more eccentrics than the norm.) In the closing session, I counted 17 men and 13 women; not all the attendees stayed through that session, but I don’t think the gender ration of the stragglers was particularly different from the rest of the conference. Also, I felt like a minority in either my role as a programmer or my role as a person manager: in particular, there were both more consultants and more product/project managers than I’m used to spending time with. Which is great: always good to be exposed to new viewpoints, they certainly had interesting things to say, and the consultants were people who clearly had a lot of valuable knowledge/experience and whom I would be happy to bring into a project that I was working on.

So: sign me up for next year! (Even if the conference can’t guarantee the same weather again.) Who knows, maybe I’ll even gather up a bit of foolhardiness and volunteer to help organize.

• Deterministic and probabilistic software product management.
• Pen tricks. I’ve been doing what he calls “the helicopter” for decades (though in a slightly different way); obviously I have more to learn.
• Beautiful movies. (Sorry about its non-embeddable nature, and for all the talking and the fact that it’s an ad; I couldn’t find anything else to use with high enough video quality.)
• I love the music, I love the way he lays down loops at the start. (Via 37signals.)
• Who wouldn’t like a song whose refrain is “You are likely to be eaten by a grue”? (Via GayGamer.)
• This is, perhaps, not news, but the music industry is truly fucked-up: apparently the people who have the power to license music want to keep that very fact secret.
• This hacked-up insanely difficult Mario is oddly amusing. (Via Game|Life.)
• Photos people are uploading to Blogger.
• The rice paddy art I referred to before has now gotten harvested. (Via How the World Works.)
• An interesting take on the (surprising lack of) value of time-boxed iterations.

I just listened to a great LeanBlog podcast episode on Dr. Sami Bahri, The World’s First Lean Dentist. Really amazing; this guy was unhappy with how his dental practice was going (e.g. very bad on-time performance, very long wait times), did some reading, and thought this lean stuff would help. Despite the fact, of course, that the vast majority of the lean literature is about manufacturing, which doesn’t have a whole lot to do with dentistry.

And he seems to have done a brilliant job of adapting lean concepts to his situation. He (and his employees) recast the concept of single piece flow as single patient flow, with a remarkably small amount of waste of the patients’ time. They’re shown into a chair within seconds of arriving, treatment begins almost immediately, the practice somehow manages to keep enough flexibility that they can do all the treatment necessary for a given patient in one shot instead of having to schedule further followup appointments for problems that are, say, identified during treatment.

It sounds like he’s got “respect for the individual” down pat, too: all the staff is involved in experimenting and improving, they do tons of crosstraining so people don’t get pigeonholed, and staff turnover is extremely low. And, of course, he hasn’t laid anybody off as a result of the increased efficiency: my favorite example was one of his employees who managed to transform verifying patients’ insurance from a full-time job into a job that takes three and a half hours a month. She was bored for a little while while they were figuring out how to best deploy her skills, after she’d basically transformed her own job out of existence through improved efficiency, but now she’s happily working in other areas of the practice.

Really fascinating.

• Ninja Town. I love the character names.
• A great video review. (Even though it’s of a demo of a game I’ve paid no attention to.)
• Tim Bray speaks sense on drugs. “Um, let’s see… the cost of pushing back a brutal ugly slow path to death is getting high from time to time. Yep, I could make that sacrifice.”
• An oldie which I just recently read: XML on the Web Has Failed.
• Mary Poppendieck on Train-Wreck Management. Ouch. (And ouch on my eyes, too, with that font size…)
• Love in the Age of Software: slides from what looks like it was a fascinating talk.
• Dave Nicollette’s analysis of how software development roles have been and will be changing.
• Linked to from the above was Scott Ambler on Generalizing Specialists. That is what I would like to be.

I’ve been on a bit of a Christopher Alexander kick for the last couple of years. At first, I started reading his most famous books, but those were good enough to leave me curious about what else he’d written. Not all of which is great, but enough is to keep me going.

Still, it’s taken me a while to get around to his book on carpets. For one thing, it’s out of print, and it took me a while to find a copy at a price that I’m willing to pay. For another thing, I don’t particularly care about carpets! But I finally found a copy, which I started reading earlier this week.

And I was completely blown away right from the start. Mainly because of the pictures: I was completely unprepared for the colors that are used in the carpets that he gives as early examples. But he also starts right off with a point that is really resonating with me right now:

What is often called the “detail” of the building—its fine structure—is not some kind of icing on the cake, but … the essence of what it is, and how it makes its impact upon us. (pp. 7–8)

The small stuff matters just as much as the big stuff; the power of the big stuff comes in large part out of the small stuff.

Translated into programming terms: keep your code clean, make every line as expressive as it can be. Which is something that I really enjoy doing, and I’m quite sure that I have a lot more to learn in that area. In particular, I’m fairly sure that there’s a lot more power to the notion that unexpected structure can arise somewhat spontaneously by determined refactoring than I’ve experienced so far. I don’t really believe that determined refactoring is all you need for good structure, but there too I have a lot to learn: where do you need more design, and what sort of extra design do you need?

(Side note: if I’m remembering correctly, Lisa Crawford told me once that Gustav Leonhardt spent a lot of time working with his students on how to best play short musical phrases. This sort of ability worked great for him, but apparently left some of his students able to play pieces in ways that sounded good at the small scale but didn’t work out so well in the large.)

But I’m not getting nearly enough practice at this. In my pet project at home, I’m trying to keep the code expressive and free from duplication, but there’s only so much you can learn from a thousand lines of code. I’ve had some interesting experiences at work, but there’s a lot of legacy code there, and I can’t responsibly spend large amounts of time cleaning it up.

Having the team as a whole spend small amounts of time cleaning it up is something that would be responsible for me to push on; I haven’t been very successful in balancing that against other activities with more immediate payoff so far, but I want to keep on trying. Even if that is successful, though, what I’ll get out of it will be different: I’ll learn a lot about balancing competing short-term and long-term demands, which is great, but I won’t have the experiences of uncovering structure myself.

What to do? One possibility is to try to work on a bigger project myself at home. I don’t feel like I have any big ideas bursting out right now, though. (Do any of my readers? I’m open to collaboration…) Another possibility would be to spend some time on evenings and weekends cleaning up the work code base. That sounds more reasonable; it still raises issues as to whether or not I’d be acting responsibly in doing so (since I’d be doing so for my own benefit, and I wouldn’t want that to hurt my team, e.g. by setting a bad example or depriving them of pleasure/learning opportunities), but in the balance I think that would be okay.

Or I could find a medium-sized open source project with an interesting code base to get involved in. That’s also an intriguing idea, and one that could have other benefits (and, to be sure, down sides); I have a few ideas in the back of my mind, but nothing concrete yet. I’m certainly open to suggestions on this front.

I’ll think it over for a few months: balancing the demands of existing programming projects, learning Japanese, reading blogs, blogging, playing video games, and of course reading books is quite a challenge as is. So, realistically, something has to give, which probably means that I have to wait until I’m done with my current personal programming project, and I already have another couple ones sketched out after it. But maybe in three or six months I’ll have managed to carve out a bit more time.

Back to the book. I’m not as in love with the rest of the first part of the book as I was with the beginning. He’s spending a lot of time talking about centers; I’d already seen those ideas in more refined form in The Phenomenon of Life. Still, it’s interesting enough, and I’m now pretty curious about the catalog of carpets that makes up most of the book.

I now have all of his earlier books except for The Linz Cafe: that one I have been unable to find at a price that I’m willing to pay. I just put in an interlibrary loan request for it, though. Once I’m done with it, I guess I’ll reread The Phenomenon of Life, and then move on to the rest of The Nature of Order.

I’m on the fourth chapter of my Japanese textbook now, enough for a new set of difficulties to surface. All of which ring vague bells from a decade ago; I’m trying to do things right this time, which means that I need better strategies for facing these difficulties than I had last time.

One problem: when I claim I know a vocabulary word, when I move it from the “review regularly” stack of flash cards to the “mastered” stack of flash cards, I want that to mean that I really do know the word! But, for an uncomfortable number of flash cards, what is really going on is that I can reliably, upon seeing the front of the flash card, recite what is on the back of the card. Which isn’t the same thing.

Some aspects of that problem show up no matter what language you’re learning. For example, I usually only do my cards in one direction, so I regularly drill going from megane to “glasses” but not in the other direction. Also, their are grammatical issues: to really know a verb, you should be able to conjugate it at will, and recognize it in any of its forms.

Those particular problems aren’t that big a deal for me yet. I haven’t learned too much grammar, and I’m doing a pretty good job so far in being able to go from English to Japanese even though I’m drilling Japanese to English.

What is a big deal is the presence of kanji. This increases complexity in a few different ways. For one thing, I have to go between three forms of the word (kanji, pronunciation, and English) instead of just two forms (Japanese and English). And, of course, a single kanji character can have multiple pronunciations, which may or may not have multiple readings, and which may or may not be signalled by adding some kana at the end. (After some experimentation, I’ve decided to exile all the extra kana to the back of the card, instead of leaving it on front.)

That’s the obvious problem, but there’s also a more subtle one. When I see a vocabulary card, I see something I wrote by hand, taken from a limited number of other vocabulary cards that I’ve written. So when I see, say, the kanji for bijutsukan, what I really see is a card with three kanji characters on the front, where in this case I happen to have written the kanji characters a little smaller than would be ideal, and a little bit off center. And, honestly, that enough is almost enough to allow me to uniquely identify the vocabulary card from among my current set, especially if one of the radicals in one of the kanji seems familiar for some reason.

But, of course, that doesn’t mean that I know the word at all: if I saw those same three characters in a Japanese book, I would have almost zero chance of recognizing them as bijutsukan, and for that matter I’d be equally likely to mistakenly think that some other sequence of three characters might represent bijutsukan. I now appreciate what kids learning to read and write English are going through when they see a sequence of letters and guess that it’s some other word that happens to start with the same letter or two and is more or less the same length: they don’t have any deeper grasp of the phonetics of written English than I do of the radicals that make up a kanji character, and in both cases we quickly get overwhelmed by the task of really understanding how a word is written.

So what do I do about this? Part of my solution is to simplify the problem. I can adopt a classic agile planning technique: recognize that there isn’t a strong correlation between the difficulty of a task and its business value, and that, when chosing between two equally tasks of equal business value, you’ll get the quickest bang for the buck by doing the easier one first. What that translates to in this case is that, all things being equal, I should try to memorize words made up of as few kanji characters as possible. So one is best, two might be okay, especially if I’ve seen one of them before, three is unlikely to be a good idea. And not all kanji characters are created equal: given a choice, I should choose characters made up of as few radicals as possible, to increase the chance that I’ll be able to really know the whole character. (As opposed to, say, having the left side of the character trigger a memory in me.)

That alone isn’t good enough, though: it doesn’t leave me with a strategy for dealing with important but more complicated characters/words, and doesn’t directly address the complexity of what it means to learn a character. To really learn a character, I should be able to write it out myself, and be able to reliably tell it apart from similar-looking characters, characters with, say, the same radical on the left and on the upper-right but a different one on the lower right.

The answer to both of these aspects of knowledge is, for me, the same: I need to learn to love radicals. Once I really know the radicals, I won’t have to, say, recognize and reproduce the thirteen strokes making up a complicated character, I’ll just have to recognize and reproduce the three radicals making it up. That’s not a simple problem, given that there are about 200 radicals to grapple with, but it’s at least a tractable problem. Especially since the radicals in a character aren’t chosen arbitrarily: radicals have meanings on their own, so you can frequently build up the meaning of a larger characters out of the meanings of its radicals, and radicals can at times lend their pronunciation to the pronunciation of the entire character. So there’s real structure to work with here; as I buff up my radical credentials, it should become easier and easier for me to learn more and more complex characters.

And, fortunately, I’ve recently acquired an excellent book on the subject. It does a great job of showing how the characters evolved (and is historically accurate, as far as I can tell), and of gradually introducing radicals and showing how they add meaning in more and more contexts. So I’m gradually adding characters from that book into my stack of cards to memorize, even if I haven’t run into those characters in my textbook, and trying to remember the evolution of those characters in the bargain. Should make learning characters more fun, and easier.

That’s the main problem; there are a couple of other problems that I’m running into as well, though. One is that there are too many new words in each chapter for me to be able to memorize. I was worried about this three weeks ago: it seemed like my stack of unmemorized cards was getting longer and longer. Since then, I’ve been doing a pretty good job of moving cards into the memorized stack, but I don’t want to ignore the problem. (Especially since I’m now adding vocabulary cards from a source other than my textbook!)

Part of the solution is to simply not memorize every new word in each chapter. Each chapter introduces maybe 80-100 new words; I’m pretty sure that I can get away with only learning 40 or 50 of them right then. So I’m picking the ones that seem particularly likely to be important, or particularly likely to be easy to learn, and I don’t sweat the other ones for now. And if, in subsequent chapters, I keep on encountering a word that I didn’t memorize when it first showed up, then I can always learn the word later. It’s not completely clear that this is a scalable strategy - maybe, once I get to chapter 15, I’ll have to memorize 5 new words from each of the previous 15 chapters along with an extra 50 words from that chapter, which would suck - but I think it’s worth giving a try.

The second part of the solution is basic queue management: the problem here is an unbounded queue. And if you don’t want to have an unbounded queue, then put a cap on it! So I could adopt a rule that I can never have more than, say, an inch of unmemorize vocab cards in the box. Once I reach an inch, I have to do something else until the stack goes down: some combination of memorizing a smaller proportion of words in each chapter, taking longer to go through each chapter, and learning to be more effective at memorizing words. I don’t have an exam schedule or anything that I’m working towards: I want to do this right, and to do this right I need to balance my capacities, my time, and the number of words that I’m attempting, instead of letting artificial pressures skew my attempts at the cost of a loss of effectiveness.

So far, all the problems I’ve talked about have been about memorizing words, but it’s also starting to get a little harder to put everything in the chapter together. In the fourth chapter, for the first time, I had a bit of trouble doing all the exercises in the chapter the first time through, because of a combination of not having all the grammatical details, the usage details, and the words at my fingertips. I think that, for now, the best approach is to acknowledge that this is a potential issue, and be alert for warning signs. So I’m planning to go through the exercises in this chapter until I can do them all easily; if that means it takes three weeks to get through the chapter instead of two, that’s fine.

I imagine that further non-vocabulary issues will crop up as I go along: needing to memorize conjugations, for example. It’s been a while (almost 15 years! Ouch) since I’ve had to deal with that sort of thing, but I was once adequate at memorizing grammar, so I assume I’ll be able to do it again, and I don’t think Japanese holds any particular horrors in that area. And further holistic issues will appear: getting practice in reading actual books (and finding a suitable gradual series of books to practice that), practicing spoken Japanese. I imagine that, once those become urgent problems, outside guidance will be essential; fortunately, outside guidance shouldn’t be hard to find around here.

Fun stuff.

I’m a fan of authors on construction whose works I can read in a programming context. On a related note, here’s a bit from Gerald Weinberg with a building/programming analogy that I like. (Quality Software Management, v. 4: Anticipating Change, pp. 216–217:

Imagine building a house by bringing all the parts to the lot, then having everybody run to the foundation and put their part in place, after which people walk around and see if the lights work or the floor collapses. There is no house test in house building to compare with the system test in system building. There are, instead, many incremental, intensive tests all throughout, especially when something is added that

• other people will depend on
• will be invisible (like wires and pipes in walls)

At every stage, the house must be stable. When it may not be, scaffolding is added so that the system of partially completed house plus scaffolding is stable. When the house becomes stable on its own, the scaffolding is taken away. Examples of scaffolding include concrete forms, extra framing, power brought to the site, and portable toilets.

Using the Stability Principle, we see that testing is not a stage, but a part of a control process embedded in everystage. What is often called system test is not a test at all, but another part of system construction, perhaps better named “system integration.” People are reworking errors in previous parts, and building the systems as they do.

Don’t get me wrong, all analogies are suspect, and I’m sure you would run into problems if you probed this one too far, but I liked it nonetheless. Incidentally, he uses “test” in a much broader sense than I normally do, including activities such as code and design reviews in the name.

I like the format of the book: it’s fairly free-form, but he frequently sprinkles in “Phrases to listen for” and “Actions to take”. The phrases in this example:

The following phrases warn a manager that the process of building while using stable phases has been or is about to be violated:

• Just wait till it’s all done, then you’ll be surprised.
• We’ll clean that up in system test.
• The testers will fix that.
• Of course we don’t have what we need, but get started anyway.
• They can clean up the design when they write the code.
• Ship it. The customers will tell us if anything is wrong.

My favorite of the phrases to listen for are those with a parenthetical note saying something like “(Warning: you may be saying this)”, as in this example from a section on fear:

• You will do this. It’s nonnegotiable. (Listen carefully: This may be coming out of your mouth.)

The point, or at least one point, of the phrases is that people’s actions are often incongruent with their beliefs and/or with stated plans and goals, and that people have a way of making statements designed to lull the listener into not realizing that. So what you should be alert to are frequently statements that are soothing on the surface, instead of statements that are alarming on the surface.

I won’t give the complete list of actions from this example; an excerpt:

DO NOT allow tests to be skipped or postponed to later stages. Whatever is pushed to the end of the cycle will be sacrificed to the schedule.

DO be aware that tests take many forms. …

In general, reasonable practical advice.