April 30, 2003

A Japanese Best-Seller

According to a friend of a friend, the Japanese edition of Lessons Learned in Software Testing just published and is currently the second-best selling Japanese-language book at Amazon.co.jp. Many thanks go to the volunteer translators at the Testing Engineers' Forum and team leader Kenji Onishi of SQC.
Posted by bret at 09:59 PM | Comments (0)

April 23, 2003

Requirements and Inspections

We passed our final inspection on my new office today. The work was principally complete on Friday, i moved in over the weekend, and i've really enjoyed working in it this week. Its spacious, quiet, and has lots of desk space for my work and shelves for my books.

The other day i discussed how certain kinds of changes weren't much trouble for my builder, that like XP programmers, he expected certain kinds of changes and indeed sometimes suggested them. It was important to him that i had a nice looking building that i was happy with.

Today i thought i'd talk about another aspect of technical projects that i saw from the customer side: bug reports. We had an city inspector who came out at various points in the project. Unlike a lot of software testers who think they should be treated as the quality police, this guy really was the quality police. They couldn't proceed until they got his say-so. Actually he hasn't been the quality police. What he is code police: making sure that the building conforms to the city building codes. This was often a matter of safety, energy efficiency and reliability.

One of his bug reports concerned the stairs. In the front of the building is a square staircase: it rises in four short flights of stairs. Some of the bathroom plumbing, placed before the foundation was poured, wasn't in exactly the right location. So the builder put in a wall using 2x6's instead of 2x4's. This stole two inches from the stairwell and another was lost due to some other inexact measurements. These three inches put the original stair out of compliance with the code. There is one page of nearly incomprehensible rules regarding the required dimensions of stairs. After we came up with a design that worked, he had to rebuild the stairs.

I suspect that few people would notice the difference between the original and the rebuilt stairs, we moved an inch here and an inch there to make it conform. Presumably the rationale for the stair rules was safety. If they are too steep, someone could fall. I've also lived in older places with narrow or winding stairs. These can cause a lot of trouble when moving furniture or appliances. But in this case, i don't think it really made this kind of difference.

The architect knew the stair code and his original plans would have worked. But the plans didn't indicate how tight the tolerances were here. In theory all the builders are supposed to know the code, but it's very fat and constantly changing, and it varies from town to town. And the stair code was written in terms that were not easy to understand. For example, one term used was "nosing." Understanding what it was and the rules regarding turned out to be key to solving our stair problem. But if the inspector hadn't explained it to me, i wouldn't have been able to figure it out from reading the code.

In software, testers often complain about not having detailed requirements. But here we had a detailed set of requirements -- the code. The problem was that different inspectors applied and interpreted it differently. When i was a tax programmer and tester, we were in a similar situation. We had detailed spec's on how taxes should be computed. We had the IRS tax forms and instructions, plus the multi volume annotated CCH edition of the intenal revenue code and treasury regulations. The problem was that no one could be expected to read it all. Even knowing how to look things up in it itself was a specialized task. At the time, i think i was one of very few programmers (or testers) who dared try. Mostly we relied on "tax specialists" -- accountants, usually CPAs, who had been trained to do this.

And the rules take on a life of their own. Major changes to tax law are sometimes referred to accountant full employment acts, because you have to hire one to tell you what the rules are. I started in the tax business right after one of the largest tax law changes in US history. It introduced one of the most mind-numbing questions ever to appear on an income tax form: "Do you have active participation in a passive activity?" (See Form 8582).

Posted by bret at 10:51 PM

April 08, 2003


I'm building an office as a separate building in my backyard. The exterior is complete and there is a pretty good chance that it will be ready for me to move into by the end of the week. Actually, i'm just paying for it: i have a contractor who is doing the construction.

We hired an architect over a year ago and our contractor broke ground in August. We never thought it would take this long. This is but one way that it has been like a software project. I've often taken exception to the common metaphor of software as a construction project, but i'm realizing that the use of this metaphor suffers as much from an inapt analogy as it does to an idealization of how construction projects develop. I say this, of course, with the knowledge of but one project.

My new office has a number of built-in desks and shelves. I worked this out with my architect. I remember it being pretty difficult to imagine how i was going to lay out my furniture in a building that didn't even exist yet. But he assured me that i really did need to plan everything in advance, otherwise i'd be subject to onerous change fees. The idea is that rework costs money. He assured me that any contractor would take advantage of any changes of mind that i had as a way to boost his profits.

I've changed my mind plenty of times, and it hasn't cost me a cent. My contractor assumes that changes will be made. My architect, and many software people who are keen to make analogies, presume that it is cheap to make changes on paper, but expensive to make them with the physical structure. Several times i would be talking to my contractor about maybe making a change to something that i was still unsure about. I was keen to try and make a decision before the work was done, but my contractor often advised me to see how it looked and decide then. There was a short wall that my architect had added to the plan late and i was still unsure if it was better with it or not. When they were framing the room, i figured i had to decide, but my contractor said you can always add it later if you want. He said that you often don't know until you see it. He advised me to wait until after it was sheetrocked because that would give me a better sense of the room.

Actually, i have been charged one change fee. I moved the bath room after the plans had been drafted and my architect charged me to redraft them.

We moved several window openings vertically during the framing. In some cases, the framers had put them in the wrong place -- other than specified by the blueprints. In other cases the blueprints didn't specify, and they chose an elevation that didn't make sense to me. And in one case the window dimentions for the same window were specified differently in two different diagrams -- conflicting requirements (and the followed the diagram that didn't capture my intentions). A big thing is often made of such differences by software methodologists. Is it a defect in the requirements or the design or the implementation? But my contractor didn't seem to care. He wanted to make a building that i was happy with and that looked good and would sometimes suggest changes himself.

During framing, it was very easy to move things around. The modern construction methods using 2x4 studs and nail guns and reciprocal saws is like tinkertoys. Rework is no big deal. I'm sure if i asked to move a window right now, there would be a change fee. And a significant delay. But back then it didn't take much time at all. And they work under the assumption that changes will need to be made: they'll misread the plan, or the architect will have made a drafing error or the owner will change his mind, or things will be left unspecified and they'll make an illogical guess. All of these things have happened. But as long as they are caught before the next layer of materials is put on, it's no big deal to fix it.

"Rework" is one of these words that CMM methodologists use to criticize "low maturity" practices. "You should do it right the first time." A couple weeks ago i was giving a talk about XP to a meeting of the Silicon Valley chapter of the American Society of Quality (Software Division). I was asked a question about XP and rework by someone who mentioned that he had liked my book: didn't XP encourage rework? I thanked him for the kind words about my book, and i informed him that it was the result of a lot of rework. Many of the sections had been written and rewritten many times. Some saw as many as five or six complete rewrites. One thing i learned in writing that book was that if i was going to make minor edits to most of the sentences in a section, it was easier to just retype it. Easier -- and better too, because in retyping it, i'd invariably find other words that could be dropped or otherwise improve the cadence.

The hard part about writing is throwing your writing away. I think the same is true for coding or construction. You can't get too attached to your work, when a better idea comes along.

My kindergarten teacher gave me a pencil without an eraser. All the kids got them. Her intention was that it would force us to get it right the first time and think ahead. Instead, i learned to scribble out my errors, a habit that stuck with me throughout elementary school, long after i'd been allowed to use pencils with erasers on their ends -- scribbling was faster than erasing. I learned not to worry about letting others see that i'd made (and corrected) mistakes. This wasn't her intention, but it may have been a valuable lesson nonetheless.

These different attitudes about rework seem to arise in construction, writing, and programming. Some people want to avoid it; others realize that finding a way to embrace rework, as emotionally difficult as it can be, is what you need to do to achieve great work.

Ward Cunningham likes to talk about working the code, as if code were something like clay that needed to be worked before it could reach its final form.

Posted by bret at 03:03 AM