jbrains.ca: Can't stop the learning

Three Steps to a Useful Minimal Feature

me@jbrains.ca (J. B. Rainsberger) — Fri, 16 Jul 2010 08:00:00 GMT

Recently, in the mailing for Steve Freeman and Nat Pryce’s book Growing Object-Oriented Systems Guided by Tests, I followed a discussion that included this comment:

I guess the skill is knowing in what makes as small as possible but valid slice (as you say in the book)

Even though I’ve written before about splitting stories, I have refined my ideas about how to deliver a useful, significant, but small slice of software. I use a simple technique which I describe this way:

Write out any, and I mean any, meaningful end-to-end scenario in detail with concrete values at every step.
Now that you’ve chosen one real scenario, go to each step in that scenario and ask the question, “What would I need to assume to eliminate this step?” If you find those assumptions make for a reasonable scenario, then use that assumption to simplify the scenario.
Repeat step 2 until exhausted or unable to come up with a simplifying assumption with five minutes’ thought.

I’ve used the example of online bill payment in many of my classes and applied this algorithm. You’d be surprised how simple, but useful a bill payments system one can build.

In fact, let’s look at this example in a bit more detail.

What does a typical bill payments system look like? I imagine that TD Canada Trust has a fairly representative system, so I’ll use that as my example.

First, select the “Pay Bills” option.

Next, select the account to use to pay the bill.

Next, select the bills you’d like to pay. Once in a while, I want to pay multiple bills at once, such as when my business has to pay the property taxes on a handful of rental properties.

Next, enter the amount you want to pay, the date on which to pay it, the account from which to pay it (why again?) and whether you want to repeat this payment automatically.

Verify the payment details: the amount, the account, the creditor, the date, and the system schedules the payment.

From this, I can describe the scenario in a form that looks like an executable example:

Pay a bill online

Given that Joe has already logged in
Joe says "I want to pay a bill"
Joe selects chequing account 12345 from which to pay the bill
Joe selects Visa bill with account ending in 2222 as the bill to pay
Joe says "I want to pay $5,000"
Joe selects a date 14 days from now as the date on which to pay the bill
Joe selects "only once" as the frequency with which to pay the bill
After Joe sees a summary of the bill payment he has asked to schedule, he says "I confirm that I want to pay this bill"
Now the system schedules to pay the bill as requested and sends Joe an email to confirm the transaction with a link to cancel or change the scheduled payment

Apart from the numbers, this scenario perfectly accurately reflects how I pay my bills online, although I only wish TD Canada Trust would send me the confirmation email I threw in as the system’s response. We have completed step 1 of the algorithm: we have specified a complete scenario with concrete values at every step.

You'll notice that we didn't specify Joe's username and password. We don't intend to re-test logging in here, so we don't bother with those details. We will have tested that elsewhere.

Now we move to step 2 of the algorithm: looking for assumptions we could make about paying a bill online that would eliminate steps in the process. To do this, we have to be prepared to sacrifice any semblance of a decent user experience. Don’t worry: once the Walking Skeleton runs, you’ll be able to add all the bells and whistles that will make this feature a pleasure to use. For now, we want to eliminate any detail that distracts us from connecting our feature to the key interfaces it must deal with. In this example, I know I want to expose an HTTP interface to clients (eventually the web) and that I need to connect to the Big Ugly Banking System, but beyond that, I don’t know that anything else matters. Within this context, then, we can start making our simplifying assumptions.

That is, until someone remembers that, being a bank, we need to keep a strictly accurate record of all transactions. That means we should add a final step to the scenario: the system records the transaction in its log. While some might consider this a superfluous detail, banking regulators would call it quite essential, and so I find it hard to ignore. This means that we have a third essential interface to which to connect: the transaction logging facility. For our purposes, I’ll assume that we have one and that it has the usual properties: transaction posting date, description, and debit or credit amount, who performed the transaction and when.

This itself makes me ask whether we need to log the transaction yet, because in our scenario we’ve scheduled a payment, and not made one. Scheduling a transaction leads to issues of canceling, editing, and building a process that completes the transaction on the day the customer scheduled it. This leads to our first simplifying assumption: Joe pays the bill immediately.

This simplifies the scenario because we no longer need Joe to tell the system when to pay the bill: the system always pays the bill immediately. Our revised scenario looks like this:

Pay a bill online

Given that Joe has already logged in
Joe says "I want to pay a bill"
Joe selects chequing account 12345 from which to pay the bill
Joe selects Visa bill with account ending in 2222 as the bill to pay
Joe says "I want to pay $5,000"
Joe selects "only once" as the frequency with which to pay the bill
After Joe sees a summary of the bill payment he has asked to schedule, he says "I confirm that I want to pay this bill"
Now the system schedules pays the bill as requested and sends Joe and email to let him know that the bill was paid

I like to start at the top and look for simplifying assumptions. First, I see that Joe has to select the account from which to pay the bill, which implies that the system presents a list of accounts to Joe, which we recognize we need to do, but not in the Walking Skeleton. Ultimately, Joe simply needs to specify the account number to debit to pay the bill, so for now we’ll make him type that in. Our revised scenario looks like this:

Pay a bill online

Given that Joe has already logged in
Given that Joe has already logged in
Joe says "I want to pay a bill"
Joe says "I want to pay from account 12345"
Joe selects Visa bill with account ending in 2222 as the bill to pay
Joe says "I want to pay $5,000"
Joe selects "only once" as the frequency with which to pay the bill
After Joe sees a summary of the bill payment he has asked to schedule, he says "I confirm that I want to pay this bill"
Now the system schedules pays the bill as requested and sends Joe and email to let him know that the bill was paid

Next, I see that Joe again has to select the bill to pay, which implies that the system presents a list of bills to pay. We could simplify this by requiring Joe to enter the payee identification number and the account number, even though this means saddling Joe with knowledge of payee identification numbers. In particular, the system neither has to store nor present a list of bill payees, and Joe doesn’t need to register a creditor before paying them.

I'm making up this notion of payee identification numbers because I don't know how banks really implement this. I imagine whatever they do, it boils down to companies registering as payees for bill payments, which results in issuing them some kind of identification number. If some kind soul wants to educate me on how this really works, I'd gladly edit the article to bring it closer to the banking industry's real implementation.

Our revised scenario looks like this:

Pay a bill online

Given that Joe has already logged in
Given that Joe has already logged in
Joe says "I want to pay a bill"
Joe says "I want to pay from account 12345"
Joe says "I want to pay to payee number 66666"
Joe says "I want to pay to account number 2222"
Joe says "I want to pay $5,000"
Joe selects "only once" as the frequency with which to pay the bill
After Joe sees a summary of the bill payment he has asked to schedule, he says "I confirm that I want to pay this bill"
Now the system schedules pays the bill as requested and sends Joe and email to let him know that the bill was paid

Next, I notice that Joe has to specify the amount to pay, and I can’t think of how to eliminate that detail without complicating matters. It does make me think about potential future features, such as “pay balance off in full” and “pay minimum payment required”, which I note down before returning to this scenario. Joe will simply have to tell us exactly how much to pay towards the bill.

Next, I notice that Joe has to confirm that he only wants a one-time payment. We can eliminate this detail by assuming that Joe can only pay the bill once. We know that customers want recurring payments, but that only distracts us from implementing the Walking Skeleton. We can eliminate this step, and our revised scenario looks like this:

Pay a bill online

Given that Joe has already logged in
Joe says "I want to pay a bill"
Joe says "I want to pay from account 12345"
Joe says "I want to pay to payee number 66666"
Joe says "I want to pay to account number 2222"
Joe says "I want to pay $5,000"
After Joe sees a summary of the bill payment he has asked to schedule, he says "I confirm that I want to pay this bill"
Now the system schedules pays the bill as requested and sends Joe and email to let him know that the bill was paid

Next, I notice that Joe has to confirm the bill payment before the system will process the payment. While this step might seem essential for security reasons, remember that we don’t necessarily have a graphical web interface for our Walking Skeleton implementation, and so we might not even have the opportunity to ask for confirmation of the bill payment. On this basis, we eliminate this step by assuming that Joe has looked over the details before pressing the button to pay the bill. Our revised scenario looks like this:

Pay a bill online

Given that Joe has already logged in
Joe says "I want to pay a bill"
Joe says "I want to pay from account 12345"
Joe says "I want to pay to payee number 66666"
Joe says "I want to pay to account number 2222"
Joe says "I want to pay $5,000"
Now the system schedules pays the bill as requested and sends Joe and email to let him know that the bill was paid

I can’t see any further simplifications, so I choose to stop here. I suspect this constitutes a close-to-minimal protocol for the “pay a bill online” feature. The programmer in me sees this as a single message, which pleases me, because of the simplicity of the interaction. The customer in me can see clearly all the extra stories we need to complete to make this feature available for public use, which makes planning easier. It feels like a win for everyone, except perhaps for Joe, who has a crappy interface to work with.

Now that we have a Walking Skeleton bill payment feature, we can identify the stories we want to deliver beyond the simplest case, and can decide which ones we need to roll this feature out to paying customers.

Let Joe choose from a list of available payees which company to pay
Remember the payees that Joe has previously paid and present them as “favorites” so he doesn’t have to search for them
Remember the payee accounts that Joe has previously paid so that he doesn’t have to enter them each time
Let Joe delete accounts he no longer needs to pay
Give Joe the option of paying the minimum payment required by the payee
Give Joe the option of paying the full balance owing
Let Joe schedule his payment in the future
Let Joe cancel pending payments
Let Joe change pending payments
Send a reminder to Joe to pay a bill he has paid at least three of the past six months (try to detect a recurring payment)
Let Joe schedule a payment to recur every month (same day each month)
Notify Joe in advance of automatically detected recurring payments and ask him if he wants us to pay the bill for him
When emailing Joe about a bill payment, include links to review the scheduled payment, change it, or cancel it, if appropriate

I imagine we could come up with more together, but I find one common thread with all these stories: once we implement the Walking Skeletion, we can implement most of these stories independently of the others. We know that more independent stories means greater opportunities to change priorities as needed as well as greater opportunities to drop features in favor of other more lucrative options. Once again, everyone wins.

Would you like to work with J. B. Rainsberger to realize revenue sooner and lower costs from delivering software? Schedule a workshop with J. B. today.

July 16, 2010 08:00 stories, planning, design, article

Design your own TDD learning experience

me@jbrains.ca (J. B. Rainsberger) — Thu, 15 Jul 2010 03:00:00 GMT

Join me in Chicago in September to learn whether test-driven development will work for you. In this course, you will learn the secrets of modular design from one of test-driven development’s master practitioners. Bring your laptop and be prepared to change the way you write software.

July 15, 2010 03:00 junit, refactoring, design, extreme programming, TDD From the Beginning

Best of... June 15, 2010

me@jbrains.ca (J. B. Rainsberger) — Thu, 17 Jun 2010 08:00:00 GMT

The tweets I found most interesting or useful in the past week.

@mfeathers: You don’t get abstraction until you’ve squeezed every bit of duplication from a piece of code walked away and found some more.

“There are no simple tricks for eliminating blame. You simply must stop doing it.” –Juran Institute, Inc.

Back to Basics: Efficiency v. Effectiveness by Matt Heusser

@ByronKatie: Stress is an alarm clock that lets you know you’re attached to something not true for you.

June 17, 2010 08:00

Some examples of programming in pairs

me@jbrains.ca (J. B. Rainsberger) — Tue, 15 Jun 2010 08:00:00 GMT

I had the pleasure of pairing with Naresh Jain during Agile India 2010 in Bengaluru and Mumbai in January 2010. Naresh recently uploaded some video that I’d like to share with you.

This is how we sometimes end up pairing:

This is how we like to think we pair:

June 15, 2010 08:00 agile, people, communicating effectively

Video: Education and Software Craftsmanship

me@jbrains.ca (J. B. Rainsberger) — Sat, 03 Apr 2010 08:00:00 GMT

In February 2010, MosaicWorks of Bucuresti, Romania, hosted Corey Haines and me to teach the world’s best introduction to Test-Driven Development. After the class ended, they interviewed us on the topics of software development education and the craftsmanship movement. Please enjoy.

Part 1:

Part 2:

Part 3:

April 03, 2010 08:00

Making decisions doesn't have to be so hard

me@jbrains.ca (J. B. Rainsberger) — Wed, 10 Mar 2010 08:00:00 GMT

I enjoy collaborating on decisions, but only with groups that agree to use a technique I refer to as consent-based decision making. I might not use that term exactly as the coiners intended, so let me explain what I mean. I characterize consent-based decision making by putting forth a proposal, then looking for reasoned objections. When no-one raises such an objection, we accept the proposal. I find this style of decision making quicker, easier, and better for team unity than typical approaches.

Consent-based decision making contrasts sharply with a typical decision-making exercise, which tends to follow these steps:

Present a need or problem.
Present options.
Solicit more options from the group.
Discuss the merits of each option in detail.
Propose solutions.
Combine the proposed solutions into a kind of hybrid solution to which everyone can assent.
Ask for any last-minute objections.
Decide.

I feel tired trying to make decisions this way, and it seems that the fatigue rises with at least the square of the number of people involved. Not only do I find it difficult to make decisions this way, but that difficulty encourages me to exclude people who might otherwise have valuable input. It puts me in a place of wanting to prune ideas, rather than generate them. You can understand why I’d want to avoid this kind of consensus building.

Some objections

When I have taught consent-based decision making to my clients, some of them have pointed out that it leads to a particularly negative culture: “Don’t bring me problems; bring me solutions.” I agree that, practised mindlessly, that could happen, but because I insist we practise mindfully, I think we can avoid this problem. Still others have pointed out that this style of decision-making stifles creativity because it intimidates people who want to point out a flaw in a proposal without necessarily having a better proposal. Again I agree, but we can mitigate this risk by looking at one of consent-based decision making’s greatest strengths: separating generating ideas from selecting a solution.

I remember dozens of meetings in which I participated in making decisions by building consensus, specifically how inconsistently engaged I felt. I would enter some of these meetings with a desire to generate ideas, brainstorm, and explore solutions; and I would entry other of these meetings tired of sifting through ideas, craving to decide on a course of action. I can’t tell you why I felt the way I felt, but rather just that it varied, and that I felt it strongly. Sometimes I wanted to expand the solution space, and other times I wanted desperately to contract it. So far, I don’t see a problem with that, but there are, of course, other people.

When you and I enter a decision-making meeting with different goals, we create problems for each other. When you want to generate ideas and I want to select a solution, we fight for air time, for space, and indeed for life… at least, it feels that way to me. I struggle to bring us to a sensible solution, and as my wish comes close to coming true, you trample on it with yet another pie-in-the-sky idea. Worse, your idea might fit perfectly, but I simply won’t see it that way. I will interpret your every new idea as an attempt to prolong the agony, whereas you will interpret my every attempt to choose a solution as an attempt to shut you down. Result? War. Root cause? Cross purposes. Remedy? Alignment. (Surprised?)

Two goals, two meetings

Consider, instead, having two separate meetings: one to generate proposals, and one to select a proposal. You might find that that helps.

In the first meeting, we generate ideas, brainstorm, solicit opinions, run impact studies… whatever we need to do to generate proposals. The people who come to this meeting might or might not care about making the decision. Whatever happens, we can feel certain that whoever shows up wants to lend their ideas to the group, and most importantly, we ignore any attempt at choosing a solution. We agree in advance to ignore them, because we have a different goal in this meeting. We agree not to chastise people for attempting to choose a solution because they form part of our natural impulse to jump to a conclusion. We agree to recognize each other’s humanity by allowing each other to compare or rank solutions, but we generally ignore those attempts in a quiet, friendly manner. (See Ask Why, But Don’t Answer for an explanation.)

The second meeting starts with a proposal. The group may ask clarifying questions, but by now we shouldn’t need to ask too many. The Proposer than asks the group to vote, which the group does by signaling thumb up, sideways, or down. A thumb up means “I accept the proposal”. A thumb sideways means “I will go with the rest of the group”. I thumb down means “I reject the proposal”. Of course, if you reject the proposal, then you must make a counter-proposal right away, otherwise the group feels free to ignore your vote. The group repeats this process until either it makes a decision or reaches a deadlock. If it reaches a deadlock, then we immediately adjourn the meeting and schedule another one to explore the competing proposals in depth. Why schedule another meeting? In part, to discourage people from rejecting a proposal just for the sake of rejecting it, and to give those people an opportunity to sleep on it before beginning another round of brainstorming.

No silver bullet

Naturally, people could abuse this system. And yes, when we have to make particular tough decisions, this system could take longer than the consensus-building approach. Even so, for more routine decisions, consent-based decision making works more quickly and easily, and I’d rather make easy things easy and hard things possible than optimize for the hard decisions.

March 10, 2010 08:00 people, article, coaching

Ask why, but never answer

me@jbrains.ca (J. B. Rainsberger) — Sun, 07 Mar 2010 01:12:30 GMT

Sometimes I go on project archeological digs with my clients through their projects, often focusing on their code bases. We sometimes run a “code bazaar”, where we set up a half-dozen machines with code to dig through, then walk in pairs from machine to machine, digging and taking notes. During these digs, I institute a key rule:

Ask “why”, but never answer.

What kind of “why” question? Why, the most perplexing one: Why the $%@# did we do this?! We feel free to ask the question, but we don’t answer it. If someone feels the impulse to answer it, someone says, “We don’t go there.”

This rule serves a dual purpose. By never answering “why”, we avoid the exercise devolving into wallowing and blaming. We avoid counter-productive actions like justifying, going on the defensive, and shifting the blame. This allows us to have an open, frank discussion of the project in a safe environment. Why, then, do we permit people to ask “why”? Simply put, we don’t deny human impulse.

You’ve experienced it. You’ve reviewed code, screamed “What the fuck?!” and shook your head. I recently read code that made me angry enough that I had to stand and walk around to calm down. (It assigned a field to itself. Don’t ask.) I understand the power of the impulse to recoil, then demand of the universe how it could allow such a thing to happen. For this reason, we permit each other to ask “why”, and even to do so in a loud, obnoxious, pained tone of voice. We simply don’t answer that question, and if someone tries, we remind them that “we don’t go there.”

Try it the next time you have to rummage through code, documents, or some other project artifacts as a group. Ask the group to agree on one rule: you can ask “why”, but you can’t answer it.

March 07, 2010 01:12

You're probably sabotaging your people's training

me@jbrains.ca (J. B. Rainsberger) — Thu, 04 Mar 2010 08:00:00 GMT

You want to make a good investment in your people, and you know they need training, but when you invest thousands of dollars in courses without giving your people the slack they need to apply what they learn, you’re just being cruel.

Now granted, you don’t mean to act cruelly, but you have to take responsibility for the fact that when you give someone a chance to learn, but not to practise, you not only waste their time, but you tear down morale. Some of your people will even interpret your move as shallow, transparent appeasement. I’ve seen it, and I’ve felt it.

Let me explain.

First, let me start with a diagram that you absolutely need to know. I didn’t invent it, and I have definitely simplified it, but I believe I’ve kept its essence intact. This diagram graphs productivity against time as we learn a new skill.

When you provide your people training, you start them off at the beginning of this graph, with whatever productivity level they have in that area. If you wanted to train your people in design techniques, or a new programming language, or a new programming platform, then you could interpret the productivity level in terms of features delivered per week. If you wanted to train your people in negotiation techniques and interpersonal communication, then you could interpret the productivity level in terms of complaints about others, fights, or the general quality of discourse you perceive in meetings and during daily work. However you choose to interpret this graph, it works out the same for just about any measure of productivity. Before training, your people find themselves at the far left, at some baseline level of productivity.

After training, your people start to incorporate what they learned into their work. As they practise, they learn to execute the new techniques correctly, with uneven results. Once they become comfortable with the basics, they exhibit some improvement, but over weeks or months, they reach the first plateau. At this point, they have learned most of what they will learn from the first set of ideas and techniques they try.

Next, they incorporate some more of what they learned into their work. This time, their productivity decreases for a while as the new techniques they try clash with what they already know. During this time, they don’t know which techniques work best in which situations, so sometimes they choose well, and other times they choose poorly. They generally struggle integrating the new ideas and techniques into their work. Eventually they reach a point where the new techniques begin to mesh well with what they know, they see new benefits that they didn’t see before, their confidence improves, and their productivity resumes its increase, past their previous highest level, on to higher levels than they’d experienced before. This continues until they reach the next plateau, then the cycle begins again: struggle, bottom out, improve, plateau. This cycle continues indefinitely… unless you get in their way.

Saboteur? You?

I’ve seen two major categories of errors that managers make when they encourage their people to develop new skills: giving them no slack to learn, and panicking when they bottom out the first time. You might not realize you do these things, so watch for them, because I routinely see otherwise thoughtful, intelligent managers ruin potentially game-changing improvement programs by doing one of these two things. Let me clarify what I mean.

I’m going to tell you a story

I remember when I first tried to use the Getting Things Done system to manage my own work. I spent dozens of hours creating projects, contexts, and next actions. I think my first task review took an entire day, as I questioned at every step how to review tasks “correctly”. I also remember spending plenty of time learning to use first iGTD, then later OmniFocus, struggling with how to synchronize tasks with my calendar, and generally feeling my way around the system. I remember mechanically clipping parts of email into an OmniFocus task, creating a project for it, then responding to the email and marking the OmniFocus project as “completed”. I remember thinking that this couldn’t possibly improve my effectiveness, as it now takes a handful of steps simply to reply to an email, when it used to take only one. Still, I knew that unless I practised the steps, I’d never manage to execute them deftly, so I invested the time I needed to practise. For that, I needed to build some slack into my schedule.

Building slack into my schedule meant disappointing some people. It meant letting some revenue-realizing activities slip. I invoiced clients later, I paid bills slightly after they came due, and I turned down some opportunities to market myself that would surely have resulted in an increase in sales. I knew I had to do this, because if I didn’t improve how well I executed the work I needed to do, I would never clear the ever-lengthening backlog I had to complete. (Before you comment, I did consider throwing away the bottom 80% of my backlog, and could manage to throw away only about 20%. This helps you understand how far behind I fell in completing this work.) Even in a desperate situation, with wolves knocking at the door, I invested the time I needed to learn how to work more effectively, because if I hadn’t, then I would have continued struggling while even bigger, more ferocious wolves found me and knocked longer and louder.

Turning the first corner

Over several weeks, I noticed the first hint of what Getting Things Done promises: the feeling of having a trusted system that helps you ensure you do whatever you need to do. I started to see tasks show up a week after I’d added them, because they started to come due. Unfortunately, while I saw some early wins, I feel into a deeper trap: due dates. Knowing the urgency of my backlog items, I’d set tentative due dates for the vast majority of the tasks that I felt I needed to complete within two months. Naturally, since I had a blind spot for identifying all the tasks I needed to complete a project, that meant I had hundreds of tasks with due dates, averaging about fifteen per day. Every day when I looked at that list, I felt defeated, but I tried to soldier on. I fell into a rut of completing about five tasks, while deferring five more to “three days from now” (or worse, Friday) and, at the end of the day, pushing the last five to the next day. Within two weeks I went back to bed, feeling depressed about having over 40 “urgent” tasks to complete in a single day. It seemed hopeless.

At this point, I could have filed for temporal bankruptcy, abandoned Getting Things Done, thrown away the task list I’d spent dozens of hours crafting, and wallowed in my own inability to make progress on my backlog. I had some serious deadlines looming, which then passed, and I began to suffer so much from the stress of the wolves at my door that I reach my wit’s end. I could have simply quit, and for a while, I did.

Summoning the courage to try again

After a few weeks of fighting fire after fire, interspersed with hours spent in a mild vegetative state in front of the TV, I resolved to try again. I had read a great article about why high achievers procrastinate, and it resonated with me. At the same time, I ended up spending a week at my wife’s family cottage, re-reading Getting Things Done, then reading The Four Hour Work Week. Armed with more information, more ideas, and renewed enthusiasm, I cracked open OmniFocus, performed a thorough task review, threw away 90% of my due dates, and moved most of the projects into “Someday” and “Maybe” folders. This took over six hours spread over two days. After I got back to the office and resumed completing tasks, I noticed how much more I felt in control of my work. Within a month I had made more progress on my backlog than I had in at least two years. I felt better, but noticed a new problem: due dates started sneaking up on me.

Into the abyss once more

Since I had stopped setting due dates for most tasks, I found that some due dates began sneaking up on me. Some deadlines blew right past me. I felt a momentary and mild depressive state as I wondered whether I had chosen incorrectly in removing all the due dates. I read some more, thought some more, and performed another very thorough task review. After a week I decided to experiment with adding due dates only when I absolutely knew the date on which a task came due, then measure the results. I would occasionally agonize during a task review about whether I needed to put a due date on a certain task. Sometimes I decided in a few seconds, and sometimes it took me fifteen minutes, because I didn’t want to do this mindlessly. I needed to avoid falling back into the old habit of deferring tasks that had due dates, but didn’t really need doing by that date. I needed not to see 40 tasks due on a Friday ever again. I persisted and, since then, I gladly report that I get good results from my use of Getting Things Done: I still have the occasional hiccup with a due date sneaking up on me, but it happens once every couple of months. For the most part, I do what needs doing and aggressively look for ways to delegate what others could capably do for me. Services like Your Man in India and elance.com help me with that. I still have things to learn, but I’ve reached a pretty comfortable plateau where my productivity level appears to have matched my current workload.

And then…?

So why did I tell you that story? I hope to demonstrate the power of having slack to apply what you learn when you learn it, and the power of not panicking when things start to go wrong. Specifically, I have this advice for you:

If you plan to provide training to your people, you need also to provide about 20% slack time for them to practise what they learn.
If you cannot provide your people with 20% slack time, then do not schedule any training yet. Instead, figure out how to get them the slack time they need.
If you have currently scheduled training for your people and they won’t have the slack time they need to practise what they will learn, then balance the cost of canceling the training against the cost of getting them that slack time between now and when the training will begin.
After your people complete their training, work with them to build a charter related to the way they will use what they learn. This consists of a time-boxed experiment with a single measure of progress and a single goal related to that measure.
When you choose the length of time for your time-boxed experiment, make sure make it long enough to get past the first bottoming-out phase working towards the second plateau.
When your people show that they continue to struggle even half-way through the experiment, don’t panic! Trust the system, and maintain your commitment to invest in the entire experiment. Continue to measure progress, and make sure to check in with your people frequently and regularly, but whatever you do, don’t panic.

If you’d like to learn how to help your team adopt new practices effectively, schedule a private course with J. B. During your initial conversations with him, he will walk you through chartering how your people will use what he teaches them, help you figure out how to give them the slack time they need, and even give you tips on how not to panic.

March 04, 2010 08:00 people, training, coaching

"Integration Tests Are A Scam" Is A Scam

me@jbrains.ca (J. B. Rainsberger) — Sun, 14 Feb 2010 13:53:20 GMT

I made this announcement at a TDD course in Bucuresti this week, and I wanted to make it here: I now fully and freely admit that when I use the term “integration tests” I confuse people unnecessarily, and so I will stop.

As a result, you will notice me change from “integration tests” to “integrated tests”, because I believe the latter term better fits the meaning I intend to convey as well as avoids confusion with what everyone else means by “integration tests”. I agree to reserve the term “integration tests” for tests that focus on checking the integration points between subsystems, systems, or any nontrivial client/supplier relationship. Integration tests might be integrated tests, and might be collaboration tests. Your choice.

I apologize for the confusion I created, and appreciate you for hanging in there while I refactor my considerable library of legacy articles. That will take time and I can’t make it my full-time job.

February 14, 2010 13:53 integrated tests are a scam

What sessions do you want to see at Agile 2010?

me@jbrains.ca (J. B. Rainsberger) — Thu, 04 Feb 2010 13:56:41 GMT

I have already submitted one session to Agile 2010, and I don’t know what else to submit for the year. I’d like to leave one slot open for a potential collaboration (hint, hint), but as for a solo session, what do you think I could present or facilitate that you’d spend 90 minutes of your precious time attending? I’d prefer to do something new, which means no “Integration Tests Are A Scam” and no “XP: My Greatest Misses”, but that doesn’t mean that I couldn’t run a session on this topics.

You could help me by outlining what you might see in a session description in the Agile 2010 program that would attract you over the other sessions. Perhaps I can deliver that very session!

Thanks for your help.

February 04, 2010 13:56 speaking, agile 2010

Using integration tests mindfully: a case study

me@jbrains.ca (J. B. Rainsberger) — Sun, 31 Jan 2010 08:00:00 GMT

Gus Power commented about the way he uses integration tests in his work.

Interesting series of articles & comments. I also read Steve Freeman’s article in response to the same topic. It’s got me thinking about how we work and I thought I’d take the time to describe it here.

You define an integration test as “… any test whose result (pass or fail) depends on the correctness of the implementation of more than one piece of non-trivial behavior.” We have many such components that exhibit such non-trivial behaviour in the products we create, many of which are not developed by us. And we have integration tests to verify they work. I’m not just talking about 3rd party libraries and frameworks here, I’m referring to the whole system: caching layers. load balancers, DNS servers, CDNs, virtualization etc. When we build software it only becomes a product or service for our users when it has been deployed into a suitable environment; an environment that typically contains more than just the software we have written and packaged. Since our users’ experience and perception of quality result from their interaction with a deployed instance of the whole system, not just their interaction with the software at a unit level, we have come to value end-to-end integration testing. I believe there’s merit in testing these components in symphony and will attempt to clarify what kind of integration testing I’m talking about.

For a given piece of functionality we write an executable acceptance test in human readable form (for web projects we typically use some domain-specific extensions to selenium, for services we have used FIT and it’s ilk, sometimes we roll our own if there’s nothing expressive enough available). We run it against a deployed version of the application (usually local though not always) which typically has a running web/application server and database. The test fails. We determine what endpoint needs to be created/enhanced and then we switch context down into unit-test land. A typical scenario would involve enhancing a unit test for the url mappings, adding one for the controller, then one for any additional service, domain object etc. When we’re happy and have tested and designed each of the required units we jump back up a level and get our acceptance test to progress further. The customer steers the development effort as he sees vertical ‘slices’ of functionality emerge. The acceptance test is added to a suite for that functional area. The continuous build system will then execute that test against a fully deployed (but scaled down) replica of the production environment, with hardware load balancer, vlans, multiple nodes (session affinity) and so forth. Any additional environmental monitoring (e.g. nagios alerting) is also done as part of this development effort and is deployed into the test environment along with the updated code.

Setting up the infrastructure to do this kind of testing takes investment, both initial and ongoing. The continuous build needs to be highly ‘parallelized’ so you get feedback from a checkin in 10 mins or less (we’re heavy users of virtualization, usually VMWare or OpenVZ). The individual acceptance test suites need to be kept small enough to run quickly before check-in.

Benefits of this approach
* The continuous context-switch between acceptance test and unit test is key to our staying focused on delivering what the customer actually wants.
* The customer has multiple feedback points that he can learn from and use to steer the development effort.
* It confirms that the whole system works together – networking, DNS, load balancing, automated deployment, session handling, database replication etc.
* We create additional ‘non-functional’ acceptance tests that automatically exercise other aspects of the system such as fail-over and recovery.
* Upgrades to parts of the system (switches, load balancers, web caches, library versions, database server versions etc.) can be tested in a known and controlled way.

We’ve caught a number of integration-related issues using this approach (a few examples: broken database failover due to missing primary keys, captcha validation not working due to a web cache not behaving correctly, data not persisting because one database server had the wrong locale) and stopped them before they have reached our users. We have used the feedback as a basis for improving our products and their delivery at a system level.

OK this reply has now become far too long :-/ It would of course be good to discuss this in person sometime :)

—Gus Power

Thanks for the substantial comment, Gus. For those who don’t know Gus, he is one of the joint recipients of the 2009 Gordon Pask Award for contribution to Agile practice. I invite you to follow his work and learn from his example. On to the substance of Gus’ comment.

Gus, it appears you do not use integration tests to check basic behavior exhaustively. While I try not to use integration tests to check basic behavior at all, I mostly hope to stop programmers from attempting to write exhaustive integration tests that check basic correctness conditions. I wrote in Not Just Slow: Integration Tests are a Vortex of Doom about the vicious cycle I see when teams rely on integration tests to check basic correctness. I encourage them to stop that particular insanity. I would hesitate to use integration tests as even smoke tests for basic correctness, but if I found myself in a situation where I needed to write such tests, I’d do it, then look for ways to render them obsolete.

Also, you mention writing “human-readable acceptance tests”, and I certainly use such tests in my work. When I counsel against using integration tests, I advise it within the context of programmer tests only. While I strongly encourage teams to allow even some of their acceptance tests to check policy or business rule behavior directly and in isolation, I understand and agree that one generally needs to write some acceptance tests as integration tests.

In general, you describe using integration tests quite purposefully, mindfully, and responsibly. I expect no less from a practitioner of your caliber. I would truly enjoy working with you on a project.

Finally, you mention that your integration tests catch system-level issues, such as a broken database schema, mistaken cache integration, and so on. I expect integration tests to find only, or at least mostly, these problems. None of these sound like basic correctness problems.

So Gus, I appreciate you for writing a great description of using integration tests well. I wish we had more examples like this. I truly wish I saw more examples like this. Sadly, I don’t: I see teams trying to check basic correctness issues with plodding, brittle, misleading tests. For those, I stress the need to eliminate integration tests.

January 31, 2010 08:00 testing, agile, design, integrated tests are a scam

Not Just Slow: Integration Tests are a Vortex of Doom

me@jbrains.ca (J. B. Rainsberger) — Thu, 28 Jan 2010 08:00:00 GMT

“Aha! So @jbrains is really against the integration tests just because they are too slow for hourly use”

It reminds me about the Ferrari IT story (XP team, dozens of deployments a year on many continents) that started from getting a big visible counter of a total number of tests and wrote just big amount of any tests first. You need to start somewhere and getting large integration tests is definitely better than nothing. As long as you are prepared to improve the testing practices later. —Artem Marchenko

I agree with this sentiment. I tell the story of my very first attempt at test-first programming¹, how I wrote about 125 tests, many of which fit my definition of “integration test”, and which took 12 minutes to execute. This meant that, on average, I only made 8-12 edits per hour when writing that code. I recognized then, and I still recognize now, that even making only 8-12 edits per hour—4-6 edits per hour towards the end—that I produced better software than I did when I would write code almost continuously for several hours at a time. As much as I disparage those integration tests today, I appreciated them a great deal at the time I wrote them. I find integration tests useful for finding system-level problems, as the first step in fixing a mistake, and if I genuinely can’t write a focused object test, then I will usually write an integration test.

As you say, Artem, I simply don’t stop there.

When I label integration tests a scam, I mean to emphasize the self-replicating nature of integration tests. It starts simply enough: you write a handful of integration tests, which give you a lot of freedom to implement your design in a way that introduces unfortunate dependencies, which makes focused object testing quite difficult. As a result, you will probably resign yourself to writing more integration tests, which do nothing to improve your dependency problems, and the cycle begins again.

Integration tests help cause pain, even though they appear to help reduce pain. Therein lies the scam.

I must acknowledge this: if you started writing tests this week, or this month, or even this year, then you will probably benefit more from writing integration tests than trying to write perfectly focused object tests. I have said and written elsewhere that I believe a programmer needs to write about 1500 to burn into her brain the basic patterns of good tests. Even so, as you write those tests, I want you to remain aware of the cost. Even if you don’t know how to write a good, focused object test, if you want to write more such tests, and especially if you try to write more such tests, then I will have completed the first phase of my mission to eradicate programmer reliance on integration tests to show the basic correctness of their code.

Join us! Turn one integration test into a small suite of focused object tests today. If you don’t yet see how to replace an entire integration test with equivalent focused object tests, then write at least one or two focused object tests along side the integration test. Try it. I promise, you’ll like it.

¹ I use the term test-first programming to refer to test-driven design without the evolutionary design part. With test-first programming, I develop a specific design, then I use tests to help me type it in correctly.

One last comment to my good friend Artem: please don’t put me to sleep with the word “just”!

January 28, 2010 08:00 testing, agile, refactoring, design, integrated tests are a scam

The importance of aligning authority with responsibility

me@jbrains.ca (J. B. Rainsberger) — Mon, 25 Jan 2010 08:00:00 GMT

Some ideas simply click with you. I remember reading about “the alignment of authority and responsibility” for the first time and feeling how much that idea resonated with me.¹ I worked at IBM at the time, on the (then) Net.Commerce project, and after about a year, I began to feel some responsibility for delivering on a project plan without any authority to negotiate scope, priorities, or timing with a stakeholder. I remember clearly staring at a whiteboard that waited for me to put work estimates next to a long list of tasks. I refused to do it.

“I don’t know long it will take,” I told my manager.

“Forget about getting the numbers right. Just give me something to put in the plan.” I knew he supported me, but he needed me to understand the difficulty in his position. He felt a similar powerlessness and asked me to help him work through it. I felt quite sad about it. While his response didn’t help me in the short term, but it opened my eyes to what I now know to call Schedule Chicken. I felt truly powerless in having to make a commitment to a schedule in which I did not believe.

I had had project managers hold me to rough estimates in the past. I had read about the “best practice” called No Hallway Estimates. I felt that Management (that nebulous machine that doesn’t really exist) foisted responsibility on me without the authority I needed to accept and deliver on that responsibility.

I had had enough. I started walking up and down the halls, asking, “Why do you make me guess? I always guess wrong.” Within two years, I left IBM with serious Authority Deficit Disorder. If you find yourself in a position of having to manage people with low authority and high responsibility, then you need to know the Law of Conservation of Authority and Responsibility.

People will correct an imbalance of authority and responsibility, whether you want them to or not, and on their schedule, not yours.

Consider the case of Jane, who has spent two years suffering from Authority Deficit Disorder. If you don’t give her more authority, then she will reach her breaking point, disrupt your organization, and eventually leave. Unfortunately, if you decide to give her more authority, then she will spend about two years demanding authority without responsibility, just to compensate for her two years of Authority Deficit Disorder. She will demand it. Either way, Jane will disrupt your organization, your plans, and probably your life. You will suffer, whether you deserve it or don’t.

So the Law of Conservation of Authority and Responsibility has a corollary.

When a person suffering from Authority Deficit Disorder has reached his breaking point, nothing you do can remedy the situation, except to wait.

Jane spent two years suffering, so she probably needs two years to recover. I understand how powerless and unfair that is, but I don’t find it any less unfair than the treatment Jane endured. This leads me to conclude

When you withhold authority, but insist on responsible behavior, everyone loses.

I don’t know how to solve that problem without simply balancing authority and responsibility better.

¹ I haven’t read it, but found at least one reference to this idea in Harry Chambers and Robert Craft’s No Fear Management.

January 25, 2010 08:00 people, coaching, consulting

Lend your voice and face to Agile India 2010

me@jbrains.ca (J. B. Rainsberger) — Sun, 10 Jan 2010 08:00:00 GMT

I will have the opportunity to address the Agile India 2010 events in Mumbai and Bangalore this month on a simple topic:

What silly thing do you want people on software projects to stop doing in 2010?

I’d love your help. A number of people have already responded on Twitter with the hashtag #StopIt2010, but I invite you to go one step further. Voice your opinion, with video if you can, and audio if you don’t have a camera handy, answering the question I’ve asked above.

Please introduce yourself, say “Hello” to our audience, and give the 20-second version of your rant. You can practise by writing your rant out in 140 characters first, then reading it.

If you can record video, then please simply upload the video somewhere (youtube.com, vimeo.com, dropio.com), add a comment to this entry, and tweet your link with the hashtag #StopIt2010.

If you can only record audio, then please package the audio and a nice, big picture of you, and upload it somewhere, like dropio.com, add a comment to this entry, and tweet your link with the hashtag #StopIt2010.

I’ll pick my favorites and include them in my keynote.

So please… go for it. Rant away. Submit more than one, if you like. You can use this template, if it helps you:

Hello to everyone at Agile India! My name is J. B. Rainsberger and I want programmers to stop insisting that writing the tests after the code is just as good as writing the tests first. Stop it!

Thanks!

January 10, 2010 08:00 agile

Introduction to Agile and the Theory of Constraints

me@jbrains.ca (J. B. Rainsberger) — Sun, 20 Dec 2009 08:00:00 GMT

J. B. Rainsberger, “Theory of Constraints”, Agileee conference, 2009 from Alexey Krivitsky on Vimeo.

I would like to find people willing to add subtitles to this video in any language, including transcribing it in English. If you’d like to do this, then please do it! I only ask that you email me with a link to the resulting video so I can add a link from here. Thanks.

December 20, 2009 08:00 agile, people, coaching

Healthy Eating for the Road Warrior... in Toronto

me@jbrains.ca (J. B. Rainsberger) — Fri, 23 Oct 2009 08:00:00 GMT

Alistair McKinnell recently exposed me to a great vegan restaurant in Toronto, and I’d like to pass the information on to my fellow road warriors looking for healthy eating while on the road. If you have a gig coming up in downtown Toronto, then I highly recommend Fressen at 478 Queen St W. I ate there with a few associates and new friends after Agile Tour Toronto this week and thoroughly enjoyed it.

They have a tapas menu, larger appetizers, main meals, soup and dessert. Like most good tapas/meze/maza, I can feel as sated sharing a half-dozen small dishes as I would with a standard, North-American-sized main dish. I especially enjoyed the sweet potato soup, tomato and cucumber salad, marinated olives, beet salad (that surprised me) and, jicama/mango salad and, of course, the chocolate terrine dessert they served Tuesday night.

Sadly, their online menu shows dinner from summer 2006, so you’ll just have to go to see the most recent menu. For a party of four, I recommend 7 to 9 tapas dishes, soup, and the four of you can probably share the dessert. I am 5’10"/235 and love to eat, so take it from me that 1/4 of that dessert satisfies!

I see from their site an address for “Urban Herbivore”, but no link, so try going there at your own risk. I’d love to try it.

A place like Fressen simply cements my new-found love affair with the Queen/Spadina area of Toronto, which we’ve got to know better as business travelers than we ever got to know as residents of Toronto. I can design an ideal business traveler’s day in the area:

Morning espresso at Dark Horse Espresso Bar around Spadina/Sullivan
Lunch at Fressen
Take-back-to-the-hotel dinner at Fresh on Spadina

I could do that every day, easily.

October 23, 2009 08:00 business travel

"One of the high points of the whole conference for me"

me@jbrains.ca (J. B. Rainsberger) — Tue, 06 Oct 2009 12:11:39 GMT

I’d like to share one very positive bit of feedback from my Agile 2009 sessions:

XP: My Greatest Misses 2000-2009… was actually one of the high-points of the whole conference for me. Amongst other things, you talked about the soft skills you need as a consultant which was deeply fascinating. I still remember your “recommendation” to accept that everything you say will be given the harshest interpretation, and to give what other people say the most generous interpretation. That was an “epiphany” moment for me which has already made a positive change in my life (on many occasions). –Keith Erskine

October 06, 2009 12:11 agile 2009

How test-driven development works (and more!)

me@jbrains.ca (J. B. Rainsberger) — Fri, 02 Oct 2009 08:00:00 GMT

It surprises me, from time to time, how much I still need to justify test-driven development to prospects and would-be course attendees. Many feel that TDD has crossed the chasm, while others still see TDD as a cultish practice worth marginalizing. I take some blame for those who find TDD cultish, because until now I haven’t had a strong, sensible, theoretical basis to justify TDD as an idea. I could do no better than “it works for me” or “my friends like it”. That has changed since I’ve started giving my talk “Introduction to Agile with the Theory of Constraints” in which I use concepts from Theory of Constraints to motivate the practices of agile software development, notably those of extreme programming. If you buy in to ideas from Theory of Constraints or Lean Manufacturing, then I think I now have a stronger argument to justify the core programming practices in extreme programming in particular and agile software development in general. I don’t even need all of the Theory of Constraints but rather a simple appeal to fundamental concepts in Queuing Theory.

Queuing Theory?

Yes, Queueing Theory. (And I don’t plan to capitalize that any longer.) I don’t proclaim to have any particular expertise in this area, but I have already seen how to use queuing theory ideas in optimizing network-based systems, and I see no reason we couldn’t extend that to software delivery systems. Better, I only need to appeal to a single idea from queuing theory to make my point.

Given a process B, which follows a process A, sometimes in performing B we need to perform some of A again. We can remove the need to rework by taking some portion of process B and performing it before process A¹.

This merits a diagram. If we have this problem

then we can solve it by doing this

and the resulting system will work more efficiently by removing wasteful rework. I assume here that we derive no significant benefit from the rework itself, which I suppose I must justify, but let’s not ruin a good story with the truth. Here I’ve described the general problem, and by applying it to software development, I can… well, I find it more effective if I save the punchline for the end.

Winston Royce, 1970, revisited

I imagine you know this diagram

and appreciate that Royce wrote in his now infamous paper that this single-phase waterfall is risky and invites failure. If you don’t appreciate that, then I cannot strongly recommend enough your reading the original paper in its entirety, rather than stopping after page 2 as most people have done².

We can apply the queuing theory result I’ve just cited to this diagram and generate some interesting conclusions. I’ll start by focusing in on this portion of the system

We write code, then we test it. Sadly, we occasionally find a bug³ which makes us change the code we wrote after we thought we’d finished it. That makes a loop of the type we can unravel with our queueing theory result.

Since “coding” is process A and “testing” is process B, we need to do some testing before we start coding.

It doesn’t take long for this to become a virtuous loop where we writing only the code we need to write in order to pass the tests we write.

I use the term test-first programming to describe this cycle⁴. When we practise test-first programming, we design as much detail as we can before writing the first test, then use the tests to help us type in our implementation correctly. Most teams most of the time can use test-first programming to reduce their ~~defect~~ mistake count to near zero, which increases their productivity and improves their ability to deliver, by helping them waste less time agonizing over whether to fix mistakes late in a release. I started this way in 2000 when I first discovered JUnit and stopped making silly mistakes in the code I wrote, which I found significantly beneficial in helping me code more confidently. I still designed most of what I built mostly up front.

After a while, though, I recognized a new process loop: I found some parts of my design difficult to test, or I found some parts of my design didn’t fit together when I tried to type them in.

Returning to our queuing theory result, since “designing” is process A and “doing test-first programming” is process B, we need to do some test-first programming before we start designing.

It doesn’t take long for this to become a virtuous loop where we check our design ideas as we think of them and implement only the parts of the design we can justify needing. When we include refactoring in our practice, we can confidently “under-design” compared to the level of design we expect to need by the end of a task, which I believe amounts to designing appropriately for the code we need to implement right now. This virtuous loop combines test-first programming and evolutionary design, including guiding principles like “you aren’t gonna need it” and the four elements of simple design into test-driven development, where we check our implementation by running tests and we check our design ideas by writing tests.

Where test-first programming helps most teams most of the time reduce their mistake count to near zero, test-driven development helps them reduce their design inventory—mostly code that gets in our way because it doesn’t actively help us deliver a feature—to near zero. This further increases productivity and improves their ability to deliver by helping them waste less time agonizing over design problems they find costly to fix. I waited until I’d spent an entire release practising test-first programming before doing more test-driven development. My transition consisted of trying to do less and less up-front design for each task, letting myself feel comfortable with each new step. Within two years I estimate I designed about 5% as much up front as I did before I started practising test-first programming. I can’t measure the corresponding improvement in my design, but I look back at projects that took 3 months before I practised test-driven development that I now feel confident I could complete—truly complete—in one week. Of course, we can’t stop here!

Enter our friend analysis. To simplify the discussion, I will treat analysis as “discovering the features we want in our software” without forcing myself to state too precisely how that happens⁵. Once again, we have our familiar situation.

Once again, we face the situation where in the process of implementing features we discover new features we need, current features we don’t need, and learn new things about features we know we need to build. This adds to our analysis, meaning that we should try test-driving some features before we try to implement others.

It doesn’t take long for this to become a virtuous loop in which our desire to implement (and deliver!) features drives them ever smaller, as we extract more concentrated value out of each one⁶. When we implement feature 12 we learn something about features 23, 30 and 52. We might decide not to deliver feature 30 any more. We might decide to expand feature 23 to encompass a few more key cases. We might decide to rush feature 52 to the top of the pile. Most teams most of the time find that this cycle helps them reduce the number of rarely- or infrequently-used features in their system⁷. This yet again increases productivity and improves their ability to deliver meaningful software to their stakeholders by eliminating the time wasted on delivering too much of a feature too soon, the time wasted on entire features we thought we needed but realized we don’t, and the time wasted arguing about what a feature means, rather than writing examples together: business-oriented tests that describe how a feature works in enough detail for the business and technical project community to agree on the conditions of satisfaction for delivering the feature.

I call this behavior-driven development, and refuse to spell it with the u that provides as much value to the word as your appendix does to your body⁸.

Once again, I didn’t coin the phrase, and some might argue against the way I use it, but I find it apt. This cycle include practices like business and technical people writing examples together, feature injection, feature splitting, and value-based (rather than cost-based) planning.

At this point, I think I’ve done my job. I believe I’ve justified not only test-first programming or test-driven development, but full-on behavior-driven development, using only a single result from fundamental queuing theory. I’ve made only a single assumption—that we agree on the appropriateness of applying queuing theory to a software development system. I’ve tried to add as little as possible to my reasoning in order to keep it as context-free as possible. As a result I claim that most teams most of the time will benefit from moving along the path from code-and-fix to test-first programming to test-driven development to behavior-driven development.

Now, for homework, what happens when we consider these processes?

Surely at least one you’ve needed to deliver more features for software you’d already deployed. How well does that work? What problems do you encounter? What if you applied our new favorite queuing theory result to that rework loop?

¹ I really need a citation for this, and when I find it, I will place it here.

² I digress, but I really can’t help myself on that one.

³ Also known as defect or, for the truly congruent, mistake.

⁴ Clearly I didn’t coin the phrase, but I know many people who treat “test-driven development” as a simple renaming of “test-first programming”, and I believe making a stronger distinction adds real value to the conversation.

⁵ I don’t think “gathering requirements”, as though we could pick them like berries, fits as a metaphor. I like “trawling for requirements”, which I believe I first read in Mike Cohn’s User Stories Applied.

⁶ We can easily apply the “Pareto Distribution” here in that we can deliver 80% of the value from implementing 20% of the feature.

⁷ You recall that Jim Johnson of the Standish Group reported in 1994 that 45% of developed features are “never used”. As I recall, only 7% of features were used very frequently.

⁸ My Canadian and British brethren and sistren be damned. I assert my right as a Canadian to choose the British spelling when I prefer it and the American spelling when it saves me time.

October 02, 2009 08:00 junit, testing, agile, stories, refactoring, design, article, extreme programming, consulting

Questions about feedback from Agile 2009

me@jbrains.ca (J. B. Rainsberger) — Tue, 29 Sep 2009 08:00:00 GMT

I presented three 90-minute sessions at Agile 2009 with varying degrees of success. Most notably, in two of my sessions, where I expected to use a flipchart and draw diagrams as I spoke, I found myself in long, narrow rooms with in excess of 100 people. That meant that few people could see the flipchart, which proved a sizable disadvantage for them. To you who attended my sessions, but couldn’t see what I wrote on the flipchart, I apologize and have corrected the problem. Frankly, I feel good about having audiences large enough to have this problem!

While I felt quite good about the majority of attendee feedback, I did receive some feedback that puzzled me. I wanted to post that material here in hopes that if you gave me some of this feedback that you’d email me and help me understand either what you meant to say or how you intended me to use the information you gave me. I really do not want to lay your feedback to waste, but if I don’t understand it and can’t use it, then I simply won’t change anything related to it.

So if you gave any of this feedback, then please answer my questions by sending me email at the address you can see on every page.

Introduction to Agile with the Theory of Constraints

It’s boring to listen for 90 minutes; get the audience involved too.

I think this could work well, but I don’t know how to do that with this session in particular. Can you suggest one or two ways I could have got you involved in the session that you would have liked?

Room too big for just flipchart.

I gave this talk at AgileEE with a tablet PC as an e-flipchart and that appeared to work much better. I think I’ve solved this problem.

It may have been a little bit more organized and focused.

I appreciate this perspective. I have changed the session to include a 20-minute introduction of all the key Theory of Constraints topics: throughput accounting, bottlenecks, and even production/production capacity. I think this helps give the session a more focused feel. I like to keep the talk quite fluid, because I don’t know how to cover everything important in only 90 minutes. To talk about all the common agile practices, I think, would require a half day. I also don’t want to give exactly the same talk every time.

References to studies, concepts could use prepared diagrams, references so the flow isn’t interrupted.

I like this idea. As I give this talk more frequently, I will start identifying common bits that I use in every talk, and can start preparing some material like that. I recently gave this talk privately to a client and included some prepared, but handwritten, slides. I think it worked well, so I rather appreciate the suggestion.

Make sure to emphasize importance of bottleneck, provide facts and background [instead of ‘some study I read’], inventory == all work in progress

I appreciate these suggestions. I know I forgot bottlenecks, and have introduced a first-pass to the talk that ensures I talk about the key Theory of Constraints concepts, including throughput accountings, bottlenecks, and production/production capacity. When I gave the talk at AgileEE and again privately to a client, I made sure to highlight all these areas in the first 15 minutes.

I understand the desire to make the references more meaningful by using less handwaving. I admit that I simply don’t care that much about these references for such a session, and recognize that others care more about that. I suppose I have the attitude that I don’t intend my talk to fit into the academic style, even though I see how one could consider that a cop-out.

Puzzle: you present solutions, can you also include the problem-solving part?

I don’t quite understand this request. Can you tell me more about what you mean? Can you give me an example of what you’d expect?

It would have been nice to hear some positive arguments about the ‘softer side’ (team work, etc.)…

I can’t interpret this comment meaningfully, because I don’t know at all how it relates to this talk. Can you give me an example of a positive argument about teamwork that you think I could have included?

…and tips for selling agile to customers (the point of view was a bit business-restricted).

I simply don’t understand this comment. What do you mean by “business-restricted”?

Regarding selling agile to customers, I discuss this issue in detail in a different talk entitled “Strategic Selling and Agile”, which I perform with Niraj Khanna.

I would have liked a hand-out to help me know the outline/main points of the talk….

I agree that that would help, and as I give any talk more frequently, an outline emerges. In the most recent version of this talk, I gave an outline that I believe helped the audience better anticipate the content of the talk.

Also, references to books mentioned would be helpful on hand-out.

I will include a reference to a librarything.com list in future versions of the talk.

I found it difficult to take notes on everything because he talked quickly.

I appreciate the difficulty in taking notes when someone speaks quickly. I do try to speak at a more reasonable pace, but frankly I don’t know how easily nor how quickly I’ll manage to make a lasting change there. I will try.

Created slides would have been easier to follow, but you’d still want flip charts.

Thank you for acknowledging the value of both prepared material and spontaneous material. I will include some prepared material in future versions of this talk.

Have more expertise in ToC.

I suppose you mean that I should learn more about ToC. I agree that that could help, but I don’t yet see how more expertise in ToC would improve this talk in particular. Can you give me an example of how that would have helped?

In more recent versions of this talk I make a point of asking the audience whether anyone considers themselves an expert in Theory of Constraints. I then acknowledge my relatively broad and shallow knowledge of the topic and ask them to forgive any mistakes I make or correct me gently.

Show some real examples of actual changes and how they helped change those critical parameters [meaning, I think, throughput, inventory, and operating expenses.

I really like this idea and have begun to think about how to include this in the 90-minute version of this talk, even though I find the short version already overflowing with material that I don’t usually get to talk about. In a longer version of the talk I’d find it easier to include such information.

Good, informative but heavy of XP practices, so less interesting to me.

I started learning about agile with XP, so I find it natural to use mostly XP examples. Which non-XP practices would you like me to have addressed? Perhaps I can do that some other way for you.

Slides would be helpful.

I had two talks with the same issue. I didn’t expect an audience of over 100 people in each one. Would you have preferred slides because you prefer them as reading material, or because you couldn’t see the flipchart, or for some other specific reason? I prefer not to assume to know the significance of your interest in slides. -

Shorter.

Understood. What would you suggest I cut?

Some facts wrong. Some sources quoted wrong.

Please believe me when I say that I made any such mistake unintentionally. Can you remember any facts or sources that I got wrong? I’d like to correct myself in future versions of the talk.

Wanted a bit more rigor around ToC, based on [the] title.

Can you give me an example of how I could have increased rigor around ToC for future versions of this talk?

Integration Tests Are A Scam

Not testable prior to presentation to customer

What do you mean by “testable prior to presentation by customer”?

Didn’t address some of the bigger problems we have like how to test integration + DB (unintelligible) quickly

I couldn’t read one key word in this comment. I would appreciate the commenter clarifying what he or she wrote.

Made a meal of explaining something quite simple

I think ideas derive power from simplicity, so I don’t necessarily view this as a negative. Moreover, if these concepts are so simple, then why isn’t everyone doing it?

Should have prepared charts

I don’t quite agree with the “should” party, but I do plan to use e-flipcharts for future presentations. I did this at AgileEE 2009 and it looks like it will work well and can leave attendees with something to which they can later refer.

Good presentation, more for developers only, which I was unaware by the description

I re-read the description and I can’t decide how to interpret it other than for programmers. Please tell me how you interpreted the description that didn’t strongly suggest the audience would consist of programmers.

Would be nice to have some tips of how to keep the tests in agreement. It’s not automatable, so humans need to keep track.

I thought I did this, but in case I didn’t, please read this example where, near the end, I describe the algorithm I use to match up collaboration tests and contracts tests. I believe one could automate some of this, either in the style of lint or in the style of Cucumber and its “here’s what you need to write to implement that step” feature.

Talk was on unit tests rather than ‘integration’ tests; felt session was mislabeled.

I understand this a little, but I don’t understand how the talk was not on integration tests. I talked about them all the way through. Moreover, since I titled it “integration tests are a scam”, I assume that would suggest that I wasn’t going to praise or recommend using integration tests.

You make the case integration tests are a waste of time and effort in almost all cases. You should outline where they do add value.

I really like this comment, and I will do that in this space sometime soon. Briefly, they add value when they check for system-level problems and unintended emergent behaviors that focused tests can’t find.

Too fast; too auditory – hard to integrate this way

I apologize for this. I do sometimes talk too quickly because the topic excites me. As I perform this presentation more, I can more easily create long-lasting artifacts that will help people remember what I described.

Took too long to get to interesting ‘contract tests’. Seemed somewhat disorganized.

I can appreciate this sentiment. I suppose that in every audience at least one person will feel this way. I think that for most people, most of the time, I need the introductory material before I describe contract tests.

As for feeling disorganized, what could I have done to make it feel more organized for you? An outline? Something you could see to keep track of my position in the talk?

I’m not sure half the room could read the easel.

Agreed. I didn’t expect so many people, and it makes me happy to know that my audience has started growing. I have started using a tablet as an e-flipchart. I hope that helps.

If the speaker’s argument that we need more unit and story-level tests on component modules, I buy that and he could have said so. If he said that integration tests are not a complete test regime for development, I agree. But integration tests are a scam → get real HIS TITLE is a scam.

I think I did say that we need more unit and story-level tests on component modules. I think I did say that integration tests are not a complete test regime for development. I still stand by the title: I believe there is more to the problem than that: integration tests sucker programmers into writing more integration tests, and that’s the scam.

35 minutes to get to mock objects and strategies for using mocks… yuck.

I can appreciate that perspective. What did you expect? I can try to give more of that next time.

I’d like to see some code, especially to see how this technique provides confidence through multiple levels of collaboration.

I agree that that would help. I don’t know how to do that well in a 90-minute session.

Would have loved to see some real example contract tests on a large system.

I appreciate this comment, and would love to have included some, but my clients don’t let me show their code. Also, I find it hard to include examples like that in a 90-minute session. In a half-day session I’d find it easy to do, if any of my clients would let me show their code.

I was looking for how to fix integration/BDD tests… Description of session should have made it clearer that it was programmer tests not standard integration/BDD tests.

I will look at how to improve the description to make that clearer.

Turned out to be a lot more basic than I thought — seemed to be ‘why use mock objects’ but handwaved over the difficulty of using them.

I wish you had got more of what you wanted from the session. I think this session includes more than just ‘why use mock objects’, but I can see why you might have that impression. As for ‘handwaving over the difficulty of using mock objects’, can you share some of the difficulties you would have liked me to discuss?

Handwriting so poor—can’t read the flip chart—use PPT. I found his swearing offensive.

I apologize for the quality of my handwriting. I know I need to raise my awareness of this issue, and I think I have started to do that. I prefer not to use PowerPoint in general, so I have started using a tablet PC as an electronic flipchart so that more people can easily read what I’ve written.

Regarding the swearing, I apologize for having offended you. I know that I take that risk and I understand that swearing represents lazy speaking.

Straightforward but a bit boring.

I wish you had been able to get more out of the session that you did. I find it surprising that you’d stay the entire time in a session that you found boring, but I appreciate your determination. What would you like me to do with this information? What might I have done to excite you more?

XP: My Greatest Misses 2000-2009

I wasn’t sure where we were in the list of misses. What I needed was a list, maybe on the flipchart.

I take full responsibility for this. I have written the misses as an article, which you can easily find online with google. I didn’t ask Agile 2009 to print this list as a handout because I wanted to save paper.

Also, as the talk evolves, my perspective about my misses evolves, and I don’t give this talk the same way I did in 2007 when I did it for the first time, so I worry that any list would become out of date and useless. Perhaps I underestimate the value of that list.

Over-labored one problem of mis-interpretations of one’s communications.

I suppose I find this problem so important that it merits emphasis. Also, thinking back to the talk, I saw links from other mistakes to miscommunication that I hadn’t seen before, and I wanted to share those new connections with you as they happened. I see how that would appear as over-laboring the point.

I expected more examples of things you can do wrong with XP rather than a discourse of (J. B.’s) personal mistakes.

I don’t quite know how to react to this comment. I think that both the title and the description make it clear that I will talk about my mistakes, and not about mistakes one might make. I even put “My” in the title to suggest that point. I don’t know how to make that clearer in the future, but if you can suggest something, then I’d like to know about it.

Good storyteller, but would have preferred a bit more focus.

I understand and agree. I like my talks to proceed somewhat in a stream-of-consciousness style, and I understand the risk I assume by doing this. When I give talks with a narrower technical focus, I tend to do a better job of following a clearer structure. I suppose I don’t see this talk as fitting into that category.

I find it surprising though, that you’d rate my presentation skills with the worst possible rating, but you only offer the comment “would have preferred more focus”. Your innocuous comment doesn’t appear to match your extremely low rating. Can you tell me more about what you feel I did wrong?

Too much talkative, too sleepy.

I don’t know what to do with this comment. It’s a talk. There will be talking. It’s a talk about my mistakes, and you can’t tell the audience my mistakes—only I can. What do you suggest that I could have done differently?

Personal info is good, helpful and helps develop rapport, but a few examples went a little too far (example: your wife crying).

I appreciate this sentiment, and I apologize for making you feel uncomfortable. I have a trusting nature, so I find myself more comfortable making myself more vulnerable than others do. I wanted to emphasize the significance of what I’d learned, showing that it goes far beyond my work as a consultant.

Don’t know that we actually got through 10 misses.

I understand. I don’t remember promising to get through 10 misses. :) To read all 10, please google “rainsberger greatest misses” and you’ll find the article with a similar title that provides a summary of 10 specific misses. I apologize if you didn’t get as much variety in the talk as you’d have liked. As I was talking, I felt things becoming a bit monotonous, but I didn’t know what to do about it at the moment. I suppose I could have just paused, admitted that I needed to move on to another idea, then done so. I can remember that for future versions of this talk.

Maybe I did not understand the topic description. I thought it would be examples from the industry.

I think I included plenty of examples of my work in the industry, although I did also include more personal examples that occurred outside my work as a consultant. As for misunderstanding the topic description, what did you expect from the session given the way you interpreted the description?

This talk is valuable to experienced coaches, but not too much would be evident to a novice coach. It might be hard for them to identify a big idea or theme. [Best idea was saved for last.]

I had hoped that novice coaches would find my mistakes useful in that they could watch out for making those same mistakes themselves. Some other coaches and practitioners have told me directly that they notice themselves making similar mistakes and now have some ideas how to stop themselves before they do too much damage. So it seems at least some novice coaches managed to get from the talk what I intended to convey. Of course, I have no way to know how many other novice coaches left the room reeling and confused, because none of them have told me as much.

As for saving the best idea for last, I assure you that I didn’t do that intentionally. Sometimes it takes that long for the best idea to come out.

Go Leafs

You are bastard.

Editor’s note: I know who left the “Go Leafs” comment. We are friends and I am joking with him. Please hold your cards and letters.

Joe, I hope you feel better! You’re smart enough, you’re good enough, and by golly, I like you!

I appreciate the sentiment, and I further appreciate you letting me know who you are in your comments, but then I don’t understand why you rated the session so poorly. That doesn’t match your comment, which appeared humorously supportive in nature. I don’t want to interpret your comment as sarcasm and condescension, but given your ratings, I find it hard to interpret it otherwise.

I wish there was more time for Q&A.

I apologize. I wish there were clocks in the room so that I could have managed my time better. I think I simply need to stop after 2/3 of the time available, even mid-sentence, just to ensure we have enough time for Q&A.

I thought Joe’s insights and ideas were great, really valuable. It just didn’t match description. Should de-couple the XP in the title.

I don’t understand why the content didn’t match the description. I would like to know more about the mismatch you perceived. I use XP as my primary toolset when I consult, so most of, if not all, my misses come from XP or XP-leaning projects. What could I have said or done that would have made that connection clearer for you?

September 29, 2009 08:00 agile 2009

Click On Macs saved Apple a customer today

me@jbrains.ca (J. B. Rainsberger) — Fri, 25 Sep 2009 08:00:00 GMT

It took several years, but Apple had me thinking about switching back today, until Sarah and ClickOnMacs in Toronto teamed up to saved the day.

The internal hard disk on my MacBook Pro began failing in the past few days. I suspected bad sectors based on random pauses while the machine appeared to write temporary data out to disk. Booting to my trusty backup drive made the problem disappear, which reminds me to recognize Hitachi for their fine 500 GB SimpleDrive Mini and Shirt Pocket’s reliable SuperDuper! backup system for allowing me to keep working in spite of a wonky internal disk. Sadly, when I tried to fix the internal disk by software means, I ran out of rocks pretty quickly.¹

I managed to learn that the “Write all zeros” feature of Disk Utility identifies bad sectors and pushes them out of the way. I tried that and my drive’s capacity fell by only 300 MB. I could live with that minor loss, but after restoring my backup, Verify Disk failed. At this point, I gave up on the disk and Apple decided to let me down.

Sarah made Genius Bar appointments at all three Toronto locations, but couldn’t get anything before Thursday, when we had to fly to Istanbul. Of those three locations, one claimed to be too short staffed to deal with us. Neither of the other two were willing to tell us whether they had the necessary service parts available to fix my machine before we had to fly. We even asked them merely to make sure they weren’t already out of stock, so we could avoid a wasted two-hour trip on the day we need to fly seven time zones east. They didn’t care, preferring instead to play poor disempowered employees. Sad.

Next, when I remembered I had a ProCare membership, I thought I’d get quick service that way. No dice. First, my membership expired without any notification. Next, I asked about renewing my membership to jump the service line, and they said they’d only let me drop the machine off with no estimate of whether they could repair it in time to fly. Sad.

Finally, Sarah remembered Click On Macs downtown in Toronto. I called them, gave them my computer at 1:30 PM and they invited me to return by 5:30 PM to pick the machine up. I authorized them to install a new hard disk if they couldn’t fix the existing one. All that for less than $200. Nice.

So Apple, I won’t switch quite yet, but be aware that I priced out buying two disposable Dell laptops to avoid this nonsense. If Click On Macs hadn’t done what you flatly refused to do, I’d have bought a Dell today.

But wait, there’s more!

When I picked up my machine, I asked about the lead time on a RAM upgrade from 4 GB to 8 GB, expecting it to take a few days. They answered “we can do it now” and offered me a much more reasonable price than Apple did. I walked out of there with 8 GB RAM and a new, 7200-RPM, 320-GB internal hard disk which, thanks to SuperDuper!, will boot to my OS by the time we come back from the Blue Jays game, and I’ll manage to return my dealings with my computer back to normal.

¹ A curling reference. Try Wikipedia.

September 25, 2009 08:00 mac

The World's Shortest Article on Behavior-Driven Development, revisited

me@jbrains.ca (J. B. Rainsberger) — Sat, 19 Sep 2009 08:00:00 GMT

I added more to this article on September 18, 2009.

On May 21, 2006, I wrote the world’s shortest article on Behavior-Driven Development. Although the title links to the entire article, it is so short that I can reproduce it here.

What is Behavior-Driven Development (BDD)?

It is Test-Driven Development (TDD) practiced correctly; nothing more.

At the time, I wrote this in anger, for reasons that I’m too tired to get in to just now (it is 4:30 AM on the last day of Agile 2006), but I wanted to share with you that my anger is changing to some more positive emotion regarding this topic.

The fact that BDD and TDD are equivalent—isomorphic, even—has its good points and bad points. I am unclear at the present moment whether the good outweigh the bad or the other way around.

What I dislike about the existence of two (perhaps three or more) different names for the same thing is that it can confuse people and divide them. Think of a single language written in two alphabets: while the speakers understand one another, they cannot read one another’s literature. I would hate to see that happen.

What I like about it is that we have two (perhaps three or more) standard approaches to explaining the technique that suit different audiences. To some, the word “test” resonates well, and to others, the words “behavior” or “example” resonate well. Rather than haphazardly sprinkling the word “behavior” into conversations about TDD, we can use an entire, cohesive vocabulary to explain TDD to someone who prefers to talk about behaviors over tests. I imagine this would help.

I would like to thank the people in room 2411 of the Hyatt Regency in Minneapolis for their willingness to participate in a spirited debate on this topic. It was tiring, and it was late, but I found it worth the effort.

Times have changed

In the time since I first wrote this article, BDD has evolved and my opinion of it has evolved as well. I now see how BDD ideas map well to the way I deliver features, complete with Feature Injection and the inner BDD design cycle. The BDD community have described how they set up a pull system for features, which I’ve been doing for years. As always seems the case, we had much more in common with one another than we originally thought!

Thanks to all the BDDers who have patiently worked with me on this unification, even when they didn’t know they were doing it: Dan North, Chris Matts, Olav Maassen, Aslak Hellesøy and Liz Keough.

September 19, 2009 08:00 testing, agile, people, agile 2006, article

jbrains Classic: Null as a method parameter

me@jbrains.ca (J. B. Rainsberger) — Fri, 18 Sep 2009 15:54:20 GMT

I originally published this on March 2, 2005.

Unless I’m publishing an API for general use, I don’t worry about testing method parameters against null. It’s too much code and too many duplicate tests. Besides, I would be testing the wrong thing.

When a method receives null as a parameter, the invoker—and not the receiver—is missing a test.

September 18, 2009 15:54 coding standards, design

Comments on "Integration Tests Are A Scam" at Agile 2009

me@jbrains.ca (J. B. Rainsberger) — Fri, 18 Sep 2009 15:45:46 GMT

You managed to get me rethinking my ideas about testing. That’s great! That’s what I came for. — Nick Southwell

September 18, 2009 15:45

jbrains Classic: Contract Tests

me@jbrains.ca (J. B. Rainsberger) — Fri, 18 Sep 2009 15:42:11 GMT

I originally published this on March 2, 2005.

Contract Tests explain how a class should extend a superclass or implement and interface, so that I don’t have to read a bunch of prose to figure out how to do that. Typically, a contract test case class is abstract, then I extend it and implement a creation method or two to return instances of my own implementation of the given interface. That gives me a standard battery of tests I can run to drive my implementation. It might not be perfect (I’ll have n failing tests to start) but I prefer it to documentation written in prose.

So if you’re delivering something you want me to extend and I need to follow more than three rules, please deliver me some contract tests.

September 18, 2009 15:42 design

When to fake; when to mock

me@jbrains.ca (J. B. Rainsberger) — Fri, 18 Sep 2009 15:02:15 GMT

I originally published this on January 3, 2005. One of my other postings links to this article, so I wanted to bring it back to life. Thanks to James Breen for pointing out the broken link to me.

In working with Pat Welsh I had occasion to describe in a rather pithy way when to fake and when to mock, so I thought I’d share that with you.

To be clear, I mean “mock” in the sense of interaction-based testing with mock objects, and I mean “fake” in the sense of state-based testing with fakes or stubs. Google if you need a stronger definition of those terms, but they suit me for now.

Note that I use the term “stub” when I used to say “fake”.

So then, I want to test some object in isolation from the rest of the system. In broad terms, I need to write tests to answer two essential questions:

Am I using the objects around me correctly? Am I invoking the right methods at the right times with the right parameters?
Am I reacting to the objects around me correctly? Do I handle errors reasonably? Do I respond well to the answers they send me?

For the first kind of test, I generally mock; and for the second kind of test, I generally fake.

Put another way, I lean on interaction-based testing to verify how my object talks to its collaborators; but I lean on state-based testing to verify how well that object listens.

September 18, 2009 15:02 testing, agile, coding standards, design, extreme programming

Increase your sphere of influence by focusing on people one at a time

me@jbrains.ca (J. B. Rainsberger) — Tue, 15 Sep 2009 08:00:00 GMT

I’ve spent the better part of the last five years helping a variety of organizations with some form of agile transition. In the process, I have experienced the symptoms that Patrick Lencioni described in his enjoyable The Three Signs of a Miserable Job. After a couple of years, it really dawned on me that I suffered from the kind of delusions of grandeur one sometimes associates with consultants: I thought I could fix the company, and worse, that doing so represented my mandate. Looking back, I find the result predictable: limited reach and ultimate failure. I needed to change my approach.

I let go of the notion that I had a mandate to fix the organization. As my good friend Patrick Wilson-Welsh taught me, I had to release the outcome. Instead, I relinquished responsibility for fixing the organization and accepted responsibility for having positive impact on individual people. As I did this, I noticed my results changed. (Surprise!)

I spent less time talking to teams and more time working with individuals. I designed with the programmers, I worked through stories with the business analysts, and I helped the build team simplify some parts of the build. I exchanged my good habits for their domain knowledge. I genuinely wanted to help, and I think I did.

The more I focused on individuals, the more I noticed those individuals sharing what I’d taught them with their peers. I’d created little consultants-in-training, but those with a definite goal of improving circumstances for their peers, their managers, and their organization. I created a little von Neumann machine out of the tidbits I shared. Months later I found that my message had reached dozens of people, many of whom actually gave it the time of day. I hadn’t seen that two years earlier.

Based on this experience, then, I focus my work on individuals, and I find my work has more impact. I enjoy it more, too. Everyone wins.

September 15, 2009 08:00 emotional health, consulting

Part 4: Surely we need integration tests for the Mars rover!

me@jbrains.ca (J. B. Rainsberger) — Sat, 12 Sep 2009 08:00:00 GMT

Recently, “Guest” commented about my Agile 2009 tutorial, Integration Tests Are A Scam. “Guest” wrote this:

A Mars rover mission failed because of a lack of integration tests. The parachute system was successfully tested. The system that detaches the parachute after the landing was successfully – but independently – tested. On Mars when the parachute successfully opened the deceleration “jerked” the lander, then the detachment system interpreted the jerking as a landing and successfully detached the parachute. Oops. Integration tests may be costly but they are absolutely necessary.

I don’t doubt the necessity of integration tests. I depend on them to solve difficult system-level problems. By contrast, I routinely see teams using them to detect unexpected consequences, and I don’t think we need them for that purpose. I prefer to use them to confirm an uneasy feeling that an unintended consequence lurks.

Let’s consider a clean implementation of the situation my commenter describes. I see this design, comprising the lander, the parachute, the detachment system, an accelerometer and an altimeter. A controller connects all these things together. Let’s look at the “code”, which I’ve written in a fantasy language that looks a little like Java/C# and a little like Ruby.

Ashley Moran has posted a working Ruby version of this example. If you speak Ruby, then I highly recommend looking at that example after you’ve read this.}

Controller.initialize() {               
  parachute = Parachute.new(lander)
  detachment_system = DetachmentSystem.new(parachute)
  accelerometer = Accelerometer.new()
  lander = Lander.new(accelerometer, Altimeter.new())
  accelerometer.add_observer(detachment_system)
}  
          
Parachute {
  needs a lander
  
  open() {
    lander.decelerate()
  }             
  
  detach() {
    if (lander.has_landed == false)
      raise "You broke the lander, idiot."
  }
}      
                        
AccelerationObserver is a role {
  handle_acceleration_report(acceleration) {
    raise "Subclass responsibility"
  }
}
                        
DetachmentSystem acts as AccelerationObserver {
  needs a parachute
  
  handle_acceleration_report(acceleration) {}
    if (acceleration <= -50.ms2) {
      parachute.detach()
    }
  }
}               
 
Accelerometer acts as Observable {
  manages many acceleration_observers
                                    
  report_acceleration(acceleration) {
    acceleration_observers.each() {
      each.handle_acceleration_report(acceleration)
    }
  }
}
 
Lander {
  needs an accelerometer  
  needs an altimeter
  
  decelerate() {
    // I know how much to decelerate by
    accelerometer.report_acceleration(how_much)
  }
}
 

view raw This Gist brought to you by GitHub.

I need to test what happens when I open the parachute. The lander should decelerate.

testOpenParachute() { 
  parachute = Parachute.new(lander = mock(Lander))
  lander.expects().decelerate() 
  
  parachute.open() 
}
 

view raw This Gist brought to you by GitHub.

Since this test expects the lander to decelerate, I have to test that. When the lander decelerates, the accelerometer should report its deceleration.

testLanderDecelerates() {                  
  accelerometer = mock(Accelerometer)
  lander = Lander.new(accelerometer)
  accelerometer.expects().report_acceleration(-50.ms2)
  
  lander.decelerate()
}
 

view raw This Gist brought to you by GitHub.

Since this test shows that the accelerometer can report acceleration of -50 m/s², I have to test that.

testAccelerometerCanReportRapidAcceleration() {
  accelerometer = Accelerometer.new()
  accelerometer.add_observer(observer = mock(AccelerationObserver))
  observer.expects().handle_acceleration_report(-50.ms2)
  
  accelerometer.report_acceleration(-50.ms2)
}                                          
 

view raw This Gist brought to you by GitHub.

Since this test shows that any acceleration observer must be prepared to handle an acceleration report of -50 m/s², I have to test that.

First, the general test for the contract of the interface:

AccelerationObserverTest {
  testAccelerationObserverCanHandleRapidAcceleration() {
    observer = create_acceleration_observer() // subclass responsibility
    this_block {
      observer.handle_acceleration_report(-50.ms2)
    }.should execute_without_incident
  }                                                      
}
 

view raw This Gist brought to you by GitHub.

Now the test for DetachmentSystem, which acts as an AccelerationObserver. What should it do if it detects such sudden deceleration? It should detach the parachute.

DetachmentSystemTest extends AccelerationObserverTest {
  // I inherit  testAccelerationObserverCanHandleRapidAcceleration()
  
  create_acceleration_observer() {
    DetachmentSystem.new(parachute = mock(Parachute))
    parachute.expects().detach()
  }
}
 

view raw This Gist brought to you by GitHub.

You might find that easier to read this way, by inlining the method create_acceleration_observer():

DetachmentSystemTest {
  testRespondsToRapidAcceleration() {
    detachment_system = DetachmentSystem.new(parachute = mock(Parachute))
    parachute.expects().detach()
    this_block {
      detachment_system.handle_acceleration_report(-50.ms2)
    }.should execute_without_incident
  }
}                              
 

view raw This Gist brought to you by GitHub.

Since this test expects the parachute to be able to detach, I have to test that. Now, detaching only works if we’ve landed. (I’ve simplified on purpose. Suppose the parachute can’t survive a drop from any height. It’s easy to add that detail in later.)

ParachuteTest {
  testDetachingWhileLanded() {
    parachute = Parachute.new(lander = mock(Lander))
    lander.stubs().has_landed().to_return(true)    
    this_block {
      parachute.detach()
    }.should execute_without_incident
  }
  
  testDetachingWhileNotLanded() {
    parachute = Parachute.new(lander = mock(Lander))
    lander.stubs().has_landed().to_return(false)
    this_block {
      parachute.detach()
    }.should raise("You broke the lander, idiot.")
  }
}
 

view raw This Gist brought to you by GitHub.

Hm. I notice that parachute.detach() might fail. But I just wrote a test that uses parachute.detach() and doesn’t yet show how it handles that method failing. I have to test that.

DetachmentSystemTest {
  testRespondsToDetachFailing() {
    detachment_system = DetachmentSystem.new(parachute = mock(Parachute))
    parachute.stubs().detach().to_raise(AnyException)
 
    this_block {
      detachment_system.handle_acceleration_report(-50.ms2)
    }.should raise(AnyException)
  }
}
 

view raw This Gist brought to you by GitHub.

Hm. So handling an acceleration report of -50 m/s² can fail. Who might issue such a right? The accelerometer. Since the detach system doesn’t handle this failure, I have to test what the accelerometer does when issuing an acceleration report might fail.

testAccelerometerCanRespondToFailureWhenReportingAcceleration() {
  accelerometer = Accelerometer.new()
  accelerometer.add_observer(observer = mock(AccelerationObserver))
  observer.stubs().handle_acceleration_report().to_raise(AnyException)
 
  this_block {
    accelerometer.report_acceleration(-50.ms2)
  }.should raise(AnyException)
}
 

view raw This Gist brought to you by GitHub.

It turns out that the accelerometer might fail when reporting acceleration of -50 m/s². When might it do that? When the lander decelerates. What happens then?

testLanderDeceleratesRespondsToFailure() {                  
  accelerometer = mock(Accelerometer)
  lander = Lander.new(accelerometer)
  accelerometer.stubs().report_acceleration().to_raise(AnyException)
 
  this_block {
    lander.decelerate()
  }.should raise(AnyException)
}
 

view raw This Gist brought to you by GitHub.

Hm. So decelerating could fail! All right, who causes the lander to decelerate? That code might fail. Oh yes… the parachute opening!

testOpenParachuteRespondsToFailure() { 
  parachute = Parachute.new(lander = mock(Lander))
  lander.stubs().decelerate().to_raise(AnyException)
  
  this_block {
    parachute.open() 
  }.should raise(AnyException)
}  
 

view raw This Gist brought to you by GitHub.

So opening the parachute could fail! We probably want to nail down when that happens. We have a test that shows us when:

testDetachingWhileNotLanded() {
  parachute = Parachute.new(lander = mock(Lander))
  lander.stubs().has_landed().to_return(false)
  this_block {
    parachute.detach()
  }.should raise("You broke the lander, idiot.")
}
 

view raw This Gist brought to you by GitHub.

So the parachute opening could cause it to detach because the lander hasn’t landed yet. I don’t know about you, but I think the parachute provides the most value when its helps the lander land, and not once it has landed. That tells me that someone, somewhere needs to handle the exception that detach() would raise, or at least prevent detach() from happening while the altimeter reads above a few meters off the ground.

testDoNotDetachWhenTheLanderIsTooHighUp() {
  altimeter = mock(Altimeter)
  altimeter.stubs().altitude().to_return(5.m)
  
  DetachmentSystem.new(parachute = mock(Parachute))
  parachute.expects(no_invocations_of).detach()
  
  detachment_system.handle_acceleration_report(-50.ms2)
  
  // ???
}
 

view raw This Gist brought to you by GitHub.

In writing this test, I see that in order to stop the detachment system from telling the parachute to detach, it needs access to the altimeter.

Integration problem detected. When I wire the detachment system up to the altimeter, even the collaboration test shows how to ensure that the parachute doesn’t detach in this kind of dangerous situation.

testDoNotDetachWhenTheLanderIsTooHighUp() {
  DetachmentSystem.new(parachute = mock(Parachute), altimeter = mock(Altimeter))
  altimeter.stubs().altitude().to_return(5.m)
  parachute.expects(no_invocations_of).detach()
  
  detachment_system.handle_acceleration_report(-50.ms2)
}
 

view raw This Gist brought to you by GitHub.

This means I have to add the following production behavior.

DetachmentSystem acts as AccelerationObserver {
  needs a parachute
  needs an altimeter // NEW!
  
  handle_acceleration_report(acceleration) {}
    if (acceleration <= -50.ms2 and altimeter.altitude() < 5.m) {
      parachute.detach()
    }
  }
}               
 

view raw This Gist brought to you by GitHub.

Integration problem solved with no integration tests. Instead, I have a bunch of collaboration tests, one important contract test, and ~~the ability to notice things~~ a systematic approach to choosing the next test, which I describe in the comments below. Any questions?

Dan Fabulich rightly jumped on me for using the phrase “an ability to notice things” just a little earlier in this article. I choose that phrase lazily because I didn’t want to patronize you by writing, “an ability to perform basic reasoning”. Oops. I thought about how I choose the next test, and I decided to take the time to include that here. Enjoy.

In this example, I used no magic to choose the next test; but rather some fundamental reasoning.

Every time I say “I need a thing to do X” I introduce an interface. In my current test, I end up stubbing or mocking one of those tests.

(See A sign you’re mocking too much for more about when I avoid interfaces and when I routinely create them.)

Every time I stub a method, I make an assumption about what values that method can return. To check that assumption, I have to write a test that expects the return value I’ve just stubbed. I use only basic logic there: if A depends on B returning x, then I have to know that B can return x, so I have to write a test for that.

Every time I mock a method, I make an assumption about a service the interface provides. To check that assumption, I have to write a test that tries to invoke that method with the parameters I just expected. Again, I use only basic logic there: if A causes B to invoke c(d, e, f) then I have to know that I’ve tested what happens when B invokes c(d, e, f), so I have to write a test for that.

Every time I introduce a method on an interface, I make a decision about its behavior, which forms the contract of that method. To justify that decision, I have to write tests that help me implement that behavior correctly whenever I implement that interface. I write contract tests for that. Once again, I use only basic logic there: if A claims to be able to do c(d, e, f) with outcomes x, y, and z, then when B implements A, it must be able to do c(d, e, f) with outcomes x, y, and z (and possibly other non-destructive outcomes).

I simply kept applying these points over and over again until I stopped needing tests. Along the way, I found a problem and fixed it before it left my hands.

If I can describe the steps well enough for others to follow – and I posit I’ve just done that here – then I don’t agree to labeling it “magic”.

September 12, 2009 08:00 java, junit, ruby, testing, agile, coding standards, refactoring, design, article, extreme programming, integrated tests are a scam

The Four Elements of Simple Design

me@jbrains.ca (J. B. Rainsberger) — Thu, 10 Sep 2009 08:00:00 GMT

I realize that I’ve never really written this down before, and I say it so frequently in my work as a trainer and mentor, that I think it bears repeating.

I have reduced everything I’ve ever learned about effective object-oriented design to the four elements of simple design that I first learned from Kent Beck’s work. Maybe you can, too.

I define simple design this way. A design is simple to the extent that it:

Passes its tests
Minimizes duplication
Maximizes clarity
Has fewer elements

Note that I put these properties in priority order. I’m willing to copy-and-paste to get a test passing, but once the test passes, I can usually remove the duplication quickly. I’m willing to extract code into a method and call it foo() in order to get rid of duplicate code, although that name foo() rarely survives more than 15 minutes. Finally, I will gladly introduce interfaces, classes, methods and variables to clarify the intent of a piece of code, although generally speaking once I make things more clear, I can find things to cut.

Some people put “minimize duplication” and “maximize clarity” in a tie for second place. I don’t. My experience has led me to conclude that removing duplication helps more than fixing bad names does. Moreover, removing duplication tends to allow a suitable structure to emerge, whereas bad names highlight an inappropriate distribution of responsibilities. I use this observation as a key element of my demonstration, “Architecture Without Trying”.

Now I should point out that, as a test-driven development (and now also a behavior-driven development) practitioner, I write tests as I draw breath, so I don’t really need to emphasize that part.

~~Passes its tests~~
Minimizes duplication
Maximizes clarity
Has fewer elements

I should also point out that I’ve yet to see a codebase with low duplication and high clarity that, nonetheless, had considerably more design elements than it needed, so I don’t really need to emphasize that part, either.

~~Passes its tests~~
Minimizes duplication
Maximizes clarity
~~Has fewer elements~~

That leaves me with two key elements of simple design: remove duplication and fix bad names. When I remove duplication, I tend to see an appropriate structure emerge, and when I fix bad names, I tend to see responsibilities slide into appropriate parts of the design.

I claim these to be axioms of modular design, with a “parallel postulate” of whether you use objects or not. If you use objects, you get object-oriented design, and if you don’t, you get structured design. (I don’t know how functional design fits into this yet, because I haven’t done enough of it.)

I claim that developing strong skills of detecting duplication, removing duplication, identifying naming problems, and fixing naming problems equates to learning everything ever written about object-oriented design.

Put more simply, if you master removing duplication and fixing bad names, then I claim you master object-oriented design.

Now I wouldn’t bother burning your old OOD/OOP books, but I will tell you that if you have an interested buyer, then feel free to sell them.

September 10, 2009 08:00 agile, coding standards, refactoring, design, extreme programming

The Code Whisperer: Detecting anemic class hierarchies

me@jbrains.ca (J. B. Rainsberger) — Thu, 10 Sep 2009 08:00:00 GMT

When I remove duplication from the siblings in a class hierarchy, I extract some code out to collaborators and pull some code up into the superclass. This often results in a kind of degenerate class hierarchy where the subclasses only override methods that return values or constants. They look like this:

class FindAllUsersRequest extends GetRequest {
    public FindAllUsersRequest(parameters) {
        super(parameters);
    }
 
    public URL getRequestUrl() {
        return URL.create("http://www.jbrains.ca/users/all");
    }
}
 

view raw This Gist brought to you by GitHub.

Here we could replace class FindAllUsersRequest with a method on a GetRequestFactory—an instance where I find a factory appropriate.

class GetRequestFactory {
    static GetRequest findAllUsers(parameters) {
        return new GetRequest(requestUrl: URL.create("http://www.jbrains.ca/users/all"), parameters);
    }
}

view raw This Gist brought to you by GitHub.

In this case, we go from a class hierarchy with high duplication in the methods to a class hierarchy with duplication in which methods they override and that they override them to return simple values we could store (and memoize!). From here, we remove the subclasses, as they don’t pull their weight.

So the next you refactor a class hierarchy, watch to see whether your hierarchy wants to become a degenerate one like the example here. If so, I recommend you consider collapsing it.

September 10, 2009 08:00 java, ruby, agile, coding standards, refactoring, design, extreme programming

Interlude: The Tutorial

me@jbrains.ca (J. B. Rainsberger) — Wed, 02 Sep 2009 08:00:00 GMT

I presented Integration Tests Are A Scam as a tutorial at Agile 2009. Since I haven’t managed to summarize more of my ideas on the subject, let me lean on Gabino Roche, Jr. to do that for me. He refers to my earlier work describing contract tests.

I hope this helps the ones of you who’ve anticipated my writing more on the topic.

September 02, 2009 08:00 integrated tests are a scam

Ask first; conclude later

me@jbrains.ca (J. B. Rainsberger) — Mon, 31 Aug 2009 08:00:00 GMT

I became embroiled in a melee over the Gordon Pask Award yesterday in Twitterland. People suggested I write about those conversations here to clarify the award’s purpose, but instead, I decided to write about an incident emblematic of the root cause of the Pask Award confusion.

My wife, Sarah, pointed me to this article, intriguingly titled I’m done with GMail complaining that GMail doesn’t have folders, so he can’t get to Inbox Zero.

Sigh.

I wanted to reply with the following, but ZDNet waited until I pressed “Add Your Opinion” to tell me I must register to post replies. Since I’ve read Influence I don’t fall for the Consistency principle much any more. That means I had to post my response here. Enjoy.

Hello, there.

As you know by now, labels act like folders, and if you use IMAP for sharing mail between GMail online and an offline mail client, labels become folders. I’m not here just to repeat those two points.

I’d like to offer this advice: next time when something /really/ doesn’t act the way you’d expect it to, ask a question. I recommend this question:

I’ve used Yahoo! mail and GMail, and it shocks me that GMail doesn’t have folders. I know the people at Google use email, so they can’t have all decided that folders have no value. That just doesn’t compute to me. There must be a way to have folders in GMail that I can’t see. Will someone please tell me what’s going on here?

Maybe if you’d done this instead of accusing GMail of ruthlessly taking a feature away from you, then you wouldn’t have looked like such an idiot or dick for posting this.

Don’t worry: we all learn this lesson eventually.

August 31, 2009 08:00 communicating effectively

Awesome virtual personal assistant/research needs work

me@jbrains.ca (J. B. Rainsberger) — Wed, 19 Aug 2009 08:00:00 GMT

I have worked with Rebecca Slominsky (annaonthemoon79 at gmail dot com) a few times and she has done thorough, quick, and professional research for me. If you need an affordable, excellent virtual personal assistant, I highly recommend her. If you’ve thought about outsourcing some annoying task that anyone anywhere in the world could do, then do please hire Rebecca to do it. Reasonable rates, excellent work, excellent service.

August 19, 2009 08:00

libxml2: Can't upgrade it; can't downgrade it

me@jbrains.ca (J. B. Rainsberger) — Thu, 13 Aug 2009 08:00:00 GMT

It started simply enough: I wanted to use webrat to write view specs with its Matchers to add some specs to this very weblog. I swear, that’s all I wanted to do.

When I managed to run those specs properly, I’d get this message:

HI. You’re using libxml2 version 2.6.16 which is over 4 years old and has plenty of bugs. We suggest that for maximum HTML/XML parsing pleasure, you upgrade your version of libxml2 and re-install nokogiri. If you like using libxml2 version 2.6.16, but don’t like this warning, please define the constant I_KNOW_I_AM_USING_AN_OLD_AND_BUGGY_VERSION_OF_LIBXML2 before requring nokogiri.

Very well: let me upgrade libxml2. Big mistake.

I tried downloading libxml2 version 2.7, then I went through the usual motions: configure, make, sudo make install.

Then I couldn’t run anything. Sometimes I couldn’t even boot. I kept seeing the wrong architecture message when I tried to run various programs on my MacBook.

I tried deleting libxml from /usr/lib and rebuilding, but then I couldn’t even sudo. I didn’t know what the hell was going on.

Finally, I booted from my backup disk (thank you, SuperDuper!) and copied /usr/lib/libxml* back onto my internal hard disk. I booted from my internal disk and all returned to normal, including the annoying nokogiri message. I suppose I’ll have to live with the message for now.

Still… has anyone successfully upgraded libxml to version 2.7 on Mac OS 10.5.7? I’d like to know.

August 13, 2009 08:00 rails, ruby, mac, adventures in RSpec

Design your own TDD course!

me@jbrains.ca (J. B. Rainsberger) — Thu, 30 Jul 2009 15:22:00 GMT

Do you know someone who needs a strong, in-depth introduction to test-driven development and modular design? How about someone who wants to take the next step in their evolution as a TDD practitioner? How about someone stuck on the merry-go-round of too many defects, a long backlog of feature requests, too many times designing themselves into a corner?

…or is that someone you?

Obtiva and I would like to present an uncommon opportunity for would-be TDD practitioners: a chance to design your own TDD course with me over three days. You get to learn what you want to learn, practise what you want to practise, do what you want to do. All you need to do is register now.

Now I know what one of you is thinking: this sounds like a trainer who’s too lazy to design a course and wants me to do his work for him.

Not at all. I have already designed a great introductory TDD course, and I’ll teach that to whoever wants it, but I want to teach you what you want to learn, and I’m ready to do that August 31 to September 2, 2009 at Obtiva in Chicago, Illinois, USA.

You can look through this site for the courses I’ve taught and for the services I provide for ideas on what we might practise together. I only ask you to keep the topics in the area of test-driven development and modular design. (I treat object-oriented design as modular design with objects, so consider that your free sample.)

If you’re planning to attend Agile 2009, then stay an extra few days to solidify your understanding of test-driven development and modular design.

I hope to see you there.

July 30, 2009 15:22 agile, design, extreme programming, training

An open call to Agile 2010 submitters

me@jbrains.ca (J. B. Rainsberger) — Wed, 29 Jul 2009 16:12:00 GMT

I finally read Mark Levison’s thoughtful weblog entry about his experiences reviewing and selecting session proposals for Agile 2009. He makes a number of suggestions, which I reproduce here:

Authors need to know that proposals are being reviewed/commented and that replies/updates are a critical part of the acceptance process.
Authors need to be notified when a comment/review is added.
People who write comments/reviews need to know when replies are made
RSS is not the the only notification system some of use still prefer email.
The difference between comments and reviews needs to be made more clear.
“Browse session proposals” page needs to display the length of the sessions. It makes it easier to make decisions if we know their length.
Proposal database should exportable to spreadsheet. A web page is handy but once the hard work begins it would be alot easier if I could just work in Excel or even Google Docs.
I don’t want recommendations visible to the proposal author. These are often friends and colleagues who I want to work with again. This maybe true today but I can’t tell.

Whether you agree with all Mark’s suggestions, I think that unless a number of us volunteer to own some feature requests, nothing will change for Agile 2010. I volunteer to own the feature requests related to notifying submitters about comments and reviews. I will send Jim Newkirk, the Agile 2010 chair, an email asking him how I can make myself a customer of the submission system.

Which feature request do you volunteer to own?

July 29, 2009 16:12 agile 2010

Interlude: Basic Correctness

me@jbrains.ca (J. B. Rainsberger) — Wed, 22 Jul 2009 02:43:00 GMT

I tried to respond to a comment from James Bach, but surpassed the 3000-character limit, so I’ve decided to add this long comment as a short article.

James Bach: I don’t understand the point of calling a failure discovered by running a test “unjustifiable.” Let me offer you a justification: I WANT TO FIND BUGS. :)

J. B. Rainsberger: Now now, changing the definition of a term on me constitutes dirty pool. Stop that! :)

James Bach: When you say ‘Presumably, we have tests that intend to test step 2, which justifiably fail’ I would say that sounds like a dangerous presumption. Just because we write a test, and that test has a purpose, does not mean the test achieves its purpose. In fact, as far as we know a test NEVER achieves its deeper purpose of finding all possible interesting bugs in the thing it is testing. Of course, when I test, I want to find all interesting bugs, and of course, I will never know that I have found all of them worth finding.

J. B. Rainsberger: I think you’ve taken my specific definition of “justifiable failure” and extended it past how I chose to use the term. When I write a test that fails because of a defect in the code that test intends to focus on, then I call that failure justifiable. All other failures are not justifiable. As a result, the statement you zeroed in on appears tautological to me… except my sloppy use of “presumably”. Let me clarify what I left unexpressed. Let’s assume that we have used integration tests to test the five-step process minimally broadly (in other words, we have written tests to find at least all basic correctness defects). That means that we’ve written some tests specifically to check step 2. Suppose now the existence of a defect in only step 2. When our test for step 4 fails because of the defect in step 2, the tests for step 2 fail justifiably, while the tests for step 4 fail unjustifiably. I haven’t yet turned my attention to latent and lurking defects, for the reason I provide at the end of this comment.

James Bach: … That’s why I use a diversified test strategy. It seems to me that complicated integration tests that cover ground also covered in other tests is a reasonable strategy— as long as it is not too expenses to produce or maintain. There is a cost/benefit that must be weighed against an opportunity cost, of course.

J. B. Rainsberger: I agree; however, I see too many programmers (in particular) using integration tests to help them find or avoid defects that much less expensive isolated object tests would better help them find or avoid. I center my entire argument on the thesis that too many programmers use these tests in a way that leads to considerable wasted effort in maintenance.

James Bach: So, perhaps you are talking about a restricted context where its not worth the effort of testing a particular function indirectly. Maybe not, but I bet it’s worth considering that sort of testing. Personally, I like automation that touches a lot of things in a lot of places, as long as I can create and maintain it without too much disruption of my sapient testing.

J. B. Rainsberger: Indeed so! I have wanted to reveal these points gradually so as to avoid writing 20,000 words at once, but I limit the arguments in this series to a specific context: programmers writing tests to show the basic correctness of their code. By basic correctness I refer to the myth of perfect technology: if I ran the system on perfect technology, would it (eventually) compute the right answer every time? I would call such a system entirely basically correct. While integration tests offer value in other contexts, too many programmers use them to show basic correctness, and when they do that they waste a tremendous amount of time and effort.

July 22, 2009 02:43 testing, agile, design, article, extreme programming, integrated tests are a scam

Interpreting inaccurate estimates

me@jbrains.ca (J. B. Rainsberger) — Tue, 21 Jul 2009 18:48:00 GMT

I ran across this today and thought I’d comment briefly about it. How can you interpret inaccurate estimates? What might it mean when you estimate incorrectly?

I know individuals that beat themselves up over inaccurate estimates. I know teams that beat each other up. I know managers that beat up their teams. I even know a company that awards bonus compensation based on the accurate of their programmers’ estimates. In those environments, inaccurate estimates hurt, so although I don’t like cost estimates in general for most teams most of the time, I recognize that some people must play the game to keep their job. That said, I return to something Ward Cunningham said in the early days about Fit: when we look at test results in a spreadsheet, we can look at patterns of red cells to learn something about our patterns of failure. He drew our attention to two kinds of patterns: systematic failure and sporadic failure.

In the early XP literature, books like Planning XP told us that by measuring velocity we gracefully handle systematic estimate inaccuracy as the “value” of our story points fluctuates over time. Think of it like a floating currency: its value in hours changes slowly over time as our ability to complete points improves. If you prefer to estimate in hours, then after several months, you might notice a bunch of stories whose actual costs were close to some constant multiplier of the estimate. In that case, you would consider multiplying all remaining estimates by that constant until you internalized it and began estimating in the “new scale” out of habit. Even when I cared deeply about cost estimates, I worried little about systematic inaccuracies.

Sporadic inaccuracy hurts more. Since we provide cost estimates to that others might plan, we owe it to them to lower the variance of the actual cost of our work, in order to make planning more useful. I have developed a conjecture over the last few years that changes the question of sporadic estimate inaccuracy:

The actual cost of a story depends on (among other things) the complexity of the story and the current state of the design. The higher our technical debt, the more that cost dominates the cost of the story.

I have noticed various people floating the definition of “technical debt” to suit their needs, so I want to clarify what I mean by “technical debt”:

By technical debt I refer to the latent cost of the amount of rot in the design. I think of technical debt as the cost of the design improvements we need to make in order to feel comfortable adding features or fixing defects in that part of the system.

You can think of technical debt as financial debt: interest-bearing principal owed to another party. In this case, the other party is the system or the project, the principal is the current design and the interest is the extra cost associated with either rescuing or working around the current design. With these definitions established, I can state my conjecture this way:

In systems with high technical debt, the cost of repaying that technical debt dominates the cost of a story.

Since not all stories affects all parts of the design uniformly, we can do a little better:

The cost of a story depends on the complexity of the story and the amount of technical debt in the areas of the design we need to change or extend to deliver the story. Working in areas with high technical debt causes the cost of repaying that debt to dominate the cost of the story.

I think you get the point. From this it follows that in systems with generally high technical debt, the distribution of technical debt effectively determines the variance in the cost of the stories. Sporadic estimate inaccuracy, then, likely has a clear root cause: high technical debt distributed decidedly non-uniformly. This follows logically, because if the system distributed technical debt uniformly, then our estimates would show systematic inaccuracy.

This allows me to make two broad claims:

In general, if a system has high and sporadic technical debt, we’ll tend to estimate with sporadic inaccuracy even if we estimate the relative complexity of those stories with perfect accuracy.
In general, we should estimate with at most systematic inaccuracy when delivering stories for a greenfield system or component.

I can interpret these claims more pithily:

If your estimates suck when adding features to a legacy system, blame the shittiness of the codebase.
If your estimates such when adding features to mostly clean code, blame the shittiness of the programmers.

In particular, if you feel bad because your estimates suck when adding features to a legacy system, you can relax. As you attempt to build those features with high discipline, the resulting volatility in your actual costs will come from the current state of the design. The design will actually try to convince you to cut corners. Cutting corners can only improve the accuracy of your estimate for the current story at the expense of the remaining stories. Cutting corners can only get your project manager off your back for a day or two. You will eventually need to stop cutting corners.

July 21, 2009 18:48 agile, stories, people, coding standards, refactoring, design, antipatterns, article, extreme programming

Part 3: The risks associated with lengthy tests

me@jbrains.ca (J. B. Rainsberger) — Mon, 20 Jul 2009 21:17:00 GMT

I just read a tweet from Dale Emery that turned my attention back to the topic of integration tests and their scamminess.

View dhemery’s tweet

Since practitioners tend to write acceptance tests as end-to-end (or integration) tests, I think I can safely substitute the phrase “integration tests” here for “acceptance tests” and retain the essence of Dale’s meaning. I do this because I don’t want you to conclude from what I plan to write that I treat acceptance tests with the same disdain as I treat integration tests. I already went through that when Eric Lefevre-Ardant introduced us to David, Agile Developer, one of the personas that the Agile 200x conference has developed to help people choose sessions at the conference. While I felt flattered that he chose my session as one to attend, he accidentally misnamed it “Acceptance Tests Are A Scam”, which set off a miniature firestorm in Twitterland. In short: I like acceptance tests when we write them to confirm the presence of a feature; and I dislike them when programmers write integration tests, checking the design and behavior of large parts of the system, and call them “acceptance tests” to justify their existence.

Back to Dale’s question, which I paraphrase: how often do we write faulty integration tests, meaning that the test failure points to an error in the test, rather than in the production code? Rather than attempt to answer that question, I prefer to write about a strongly related idea: integration tests necessarily fail more frequently and in a more costly manner than isolated object tests, even when the underlying production code behaves as expected. To simplify the discourse a bit, let me introduce the term unjustifiable test failure to mean a test failure without a corresponding defect in the production code. When an incorrect test fails, I will call that failure unjustifiable.

The cost of unjustifiable test failures

An unjustifiable failure has both a clear cost an a hidden cost. We know the immediate, clear cost: an unjustifiable failure causes me to do root cause analysis on a nonexistent failure, which costs me something and gains me nothing. More insidious, though, persistent false failures erode my confidence in the tests. I tend to value the tests less. I run them less frequently, reducing the actual value I get from the resulting feedback. With less feedback comes less confidence in the code, and more conservative behavior. I change the code less frequently; I avoid extensive changes, even when they seem appropriate; I entertain fewer ideas because I can’t as easily predict the cost of the corresponding changes. I start designing not to lose, rather than designing to win. I can’t quantify that cost on a given project, but I know it in my heart and we could measure it over time. I think one should eliminate unjustifiable test failures where possible, or at least where easy, and integration tests simply cause an avoidably large number of unjustifiable failures.

Integration tests fail unjustifiably more frequently

Let me support this conjecture with two key arguments.

First, integration tests tend to require more lines of code than isolated object tests. Perhaps more formally, as we write more integration tests and more isolated object tests in a system, the average length of the integration tests becomes considerably larger—at least double—than the average length of the corresponding isolated object test. If we accept this premise, then combine it with the well-accepted premise that more code means more defects in general, then it follows directly that integration tests tend to have more defects than isolated object tests. This means that integration tests fail unjustifiably more frequently than isolated object tests.

Next, because integration tests rely on the correctness of more than one object, it follows directly that a defect in an object results in more integration test failures as compared to the number of failures in corresponding isolated object tests. That production defect, then, results in two classes of test failures: justifiable ones in tests designed to verify the defective behavior, and unjustifiable ones in tests design to verify another behavior, but that happen to execute the defective code.

You can envision an example of the latter case by thinking of an integration test that verifies a specific alternate path in step 4 of a 5-step process. This test must execute steps 1 through 3 of the process in order to execute step 4, so if we have a defect in step 2 of the process, then this test fails unjustifiably, because it does not actively try to verify step 2. While the test failure can be justified by a defect in step 2, I call the failure unjustifiable with respect to the behavior under test, because this test does not deliberately attempt to test step 2. Presumably, we have tests that intend to test step 2, which justifiably fail.

Integration tests, then, result in unjustifiable failures by executing some potentially defective behavior without intending to verify it. While I wouldn’t call this a defect in the test, the test nevertheless fails unjustifiably.

I have tried here to describe the problem of unjustifiable test failures and to explain how integration tests necessarily result in more unjustifiable test failures than isolated object tests. I admit that I have not compared the cost of these unjustifiable test failures to the corresponding costs of writing isolated object tests. I cannot hope to complete a thorough quantitative study on the matter. Instead, I simply want to raise the issues, make some conjectures, reason well about them, then let the reader decide. I have decided to write more isolated object tests and fewer integration tests unless I find myself in a drastically different context than the ones I’ve seen over the past decade or so.

July 20, 2009 21:17 testing, agile, stories, coding standards, design, article, extreme programming, integrated tests are a scam

Nominate someone for the 2009 Gordon Pask Award!

me@jbrains.ca (J. B. Rainsberger) — Thu, 16 Jul 2009 17:51:58 GMT

The Gordon Pask Award recognizes two people whose recent contributions to Agile Practice make them, in the opinion of the award committee, people others in the field should emulate. In order that people might emulate them, the Agile Alliance will fund each recipient’s travel to two different suitable conferences on two different continents. In order to grow the next generation of Agile thought leaders, we give the award to people who have not yet become conference speaking regulars, in part because they have not yet developed a widespread reputation as a top practitioner.

Who is Your Mentor?

We need your help to identify the next two Gordon Pask Award winners. Please send your nominations to pask-nominations@agilealliance.org, including the nominee’s name, email address and a short summary of your reasons for making the nomination, limited to 200 words.

In the spirit of Gordon Pask’s work (see below), we expect you to nominate someone you’ve learned from directly, face-to-face. You might also consider asking for additional people to add their names to your nomination. More names don’t necessarily carry more weight, but they do give us more people to ask about the nominee. Previous winners can be found at the Agile Alliance’s site. Award founder Brian Marick comments that the selection process is always difficult: “We always worried a lot that it would feel arbitrary… I’ve gotten complaints that it’s too much of a programming award and not enough of a management award and that could well be true.” There are always many qualified nominees, who are ruled out when the committee asks “Does this person actually need our help?”

We will accept nominations until August 1, 2009.

About the Gordon Pask Award

Laurent Bossavit, a 2006 recipient, says “one of the more appealing traits of the agile community [is] that it provides room for new voices to be heard and to offer original contributions”. This is a community that fully embraces the notion that through face-to-face conversation comes enhanced understanding… a community that believes that thoughtful critics and new enthusiasts alike have something to offer. This emphasis on discourse is partially inspired by the work of Gordon Pask and other cyberneticians, who practically “had no effect. Eventually they retired, or died, and that was kind of the end of it. The first wave of people failed to build up the next wave,” according to Brian Marick. The Agile Alliance’s support of this award shows a strong commitment to nurture growth and discovery in the agile arena, and to further emphasize its significance, currently it is the “only award that the Agile community gives,” says James Shore (2005 recipient).

Agility is a Social Phenomenon

This is a community of artisans, constantly trying to hone their skills by taking notes from one another. Bossavit says “I benefited a lot from the writings of the ‘official’ founders of Agile, many of them among the original signatories of the Manifesto… [but I] couldn’t have learned about XP, Scrum and all that solely from reading books or articles. Rather, my understanding grew from the opportunity to participate, interactively, in several communities. These included on-line communities such as Ward Cunningham’s Wiki and the XP mailing list, and real-life gatherings such as the european XP200x conference, the various XP Days, and so on. I have a huge debt to Jerry Weinberg… for fostering a community of people passionate about ‘peopleware’, about the human, sociological, psychological aspects of software.”

Agilists are finding better ways to work, to learn, and to teach. 2005 recipient James Shore says he learns by “trying things and seeing if they work”, but that’s not all. He gained a lot of insight by working with his local Agile User’s group. He says, “I’d bring in my problems and we’d talk about them and I’d say, ‘That can’t possibly work’ and I would go away and try it and come back and say, ‘Well, you know… that worked. Here’s what I did and now here’s the new problem I’m having,’ [something] I wish more people would do.” Regarding learning by doing, he goes on to say that, “training some times works… you can pick this stuff up from books… [but] following a leader who has done it before; having them work with you directly is by far the most effective way of getting it in to place quickly”. Instead of training sessions in lecture format, 2005 winner J.B. Rainsberger says that he “tells people stories… which helps them understand”. If you go to any of the agile conferences, you’ll find games, workshops, debates, and other engaging, interactive formats focused on improving communication. Not only are the user groups and conferences lively. “Agile is bringing back the freedom, creativity and innovation back to software development. It is making life easy and enjoyable for software craftsmen. And I’m glad to be a part of such a movement,” says 2007 winner Naresh Jain.

Gordon Pask—Improved Understanding through Discourse

The Gordon Pask Award embeds a special message for the Agile Community. “Lots of big names are projecting a very dogmatic and rigid view about Agile. In my experience Agile is nothing on those lines,” says Naresh Jain. The problem with mass-broadcasts from “big names”, from a Gordon Pask perspective, is that we lose out on the collaborative learning. It’s not to say that a rigid view of Agility is incorrect. James Shore says: "we can’t just say we won’t do that piece of Agile. [Instead of asking] “How are we going to solve that problem in a different way?”, I see people saying, ‘That’s hard. We’re just not going to worry about that piece of it.’" He clarifies that newcomers would be “better served by… seeking excellence than trying to fit in.” Trying to fit in by following the letter of the law will not give us the gains in productivity promised by Agile. “The big wins are not in doing work in two-week Sprints. The big wins are increasing your communication, working simultaneously, because simultaneous phases are also a way of improving that communication so that you don’t have a throw-it-over-the-wall mentality.”

Kent Beck talks about self-similarity in nature—that is, design patterns that work well, often are replicated in various sizes and environments. The fact that communication helps us improve our effectiveness on the job, as well as in the Agile community, is a self-similar pattern mastered by award recipient Kenji Hiranabe. He says that it was not he who won the award in 2008, but it was the strength of the community in Japan that brought the award to him. This obvious valuing of community before self is also repeated in their conference marketing: “we prepared ‘Pair discount’ pricing and strongly recommended the attendees to come with their boss or clients. The result was 75% of them came in pairs! I believe it is a sign that engineers, managers, and clients have started talking to one another to make this software development world better… Along the way of introducing Agile to Japan, they came and formed a good community.”

Now it’s your turn. Nominate someone that has helped you out… better yet, collaborate with a few colleagues, face to face, to discover who to nominate. It takes less time than reading this article!

July 16, 2009 17:51

Three upcoming events

me@jbrains.ca (J. B. Rainsberger) — Mon, 13 Jul 2009 21:12:00 GMT

I’d like to draw your attention to three upcoming events.

Code Retreat in Toronto on August 8, 2009. Hone your craft in a pressure-free environment. Costs nothing but your time.

Your first steps in TDD in Chicago from August 31 to September 2, 2009. World-class training in TDD from a leading practitioner. USD 1500 per student with group discounts available.

Agile 2009 remains the premier conference in the world to learn about all things agile. Learn and practise with top practitioners across the spectrum of software and business roles.

Please join us!

July 13, 2009 21:12 agile, extreme programming, agile 2009, TDD From the Beginning, Code Retreat

Please vote for the next Gordon Pask Award logo

me@jbrains.ca (J. B. Rainsberger) — Thu, 07 May 2009 20:28:00 GMT

Sebastian Hermida has prepared more logo ideas for us, and we’d like your feedback.

May 07, 2009 20:28 agile, gordon pask award 2009

XP 2009 conference is only one month away!

me@jbrains.ca (J. B. Rainsberger) — Thu, 30 Apr 2009 00:25:00 GMT

XP 2009 is the leading conference on Agile Methods for software development and industry management held annually in Europe. With keynotes from Mary Poppendieck and Ivar Jacobson and tutorials with Pask Award winners Jeff Patton and Steve Freeman, you wil find yourself among the experts with a rare chance to really talk to them face to face! Register today.

April 30, 2009 00:25 xp2009

Code Retreat Reykjavík, May 9, 2009

me@jbrains.ca (J. B. Rainsberger) — Wed, 29 Apr 2009 08:00:00 GMT

I take great pleasure in announcing the first ever Code Retreat outside the US, scheduled in Reykjavík, Iceland on May 9, 2009. I had the pleasure of co-pre-announcing this event at my March 2009 course there and feel great that the guys at Sprettur have fulfilled their commitment to organize this event. I hope this represents the first step towards a vibrant Software Craftsmanship community in Iceland.

Please support your local Code Retreat event. I will present one in association with PlateSpin in Toronto on August 8, 2009.

April 29, 2009 08:00 java, junit, testing, agile, people, coding standards, refactoring, design, extreme programming, Code Retreat

Catalysts Coding Contest

me@jbrains.ca (J. B. Rainsberger) — Thu, 16 Apr 2009 16:59:00 GMT

I received this reminder from Christoph Steindl about the contest, now it its third year. I hope you’ll take a look and even participate!

Do you have a linear performance curve?

As a software developer, if you can choose you’d prefer an algorithm with linear run-time complexity “O(n)” over one with quadratic “O(n²)” or even exponential complexity “O(2^n)”.

As an employer or client, you would prefer software developers who show a linear performance curve even if working under heavy load and stress.

The best developers solve difficult problems with the same speed as simpler ones – their performance curve is linear. On our Hall of Fame you can see for last year’s contest which participants exhibited a quasi linear performance curve, and which ones showed a quadratic or exponential one.

This year, everyone can participate in the Catalysts Coding Contest over the Internet, so it’s a real worldwide competition.

During the last years we had 60 onsite participants, this year we hope to get 100 onsite + remote participants – which would then be a large enough code base to draw some valuable conclusions for our research questions:

Who is faster? Who is more efficient? Who is more effective? Who is more productive?
Does “Pair Programming” really make you faster?
Does “Test-Driven Development” really lead to fewer bugs?
How many ways are there to solve a problem?
Which programming language is most appropriate for the problem?
How many lines of code are necessary?

The contest will take place on Friday, June 5th, in the afternoon. The participation fee is just 1 EUR for remote participants (otherwise we couldn’t probably distinguish real registrations from fake registrations). Please join us!

April 16, 2009 16:59 design

Part 2: Some Hidden Costs of Integration Tests

me@jbrains.ca (J. B. Rainsberger) — Wed, 08 Apr 2009 19:47:00 GMT

Read more in this series

I fear that this first article in the series may be attacking a view that very few people hold: the idea that one should test all code paths by integration testing alone. — Dan Fabulich

When I tell TDD practitioners my opinion about integration tests, some treat my position as a straw man. They point out that “no one” seriously tries to test entire systems exclusively with integration tests. While I understand their reaction, I need to point out that I never made that claim. I see far more damaging behavior in teams that practise TDD: they duplicate a sizable amount of their effort by designing their objects with thorough focused tests, then adding a suite of integration tests that verify a substantial amount of the same behavior. I understand why they do it. I used to do it. And I want them to stop.

Every integration test costs… well, I don’t know how to accurately say how much it costs. After computing the superficial cost of writing and maintaining the test, I quickly lose track of the varying effects of writing integration tests in place of, or even in addition to, focused object tests. I can compute the raw execution time tax on integration tests: an average focused test executes in 4 ms, while an average integration tests takes closer to 100 ms. I feel comfortable estimating the difference at a more conservative order of magnitude base 10. Beyond that, I find myself lost in the implications of writing integration tests to form a clear picture of the cost. Let me give you an idea of what I mean.

A Tale of Two Test Suites

Consider two test suites. One executes in 6 seconds, and the other in 1 minute. Pretend they cover the same code equally well. I mean that they have the same power to uncover mistakes in the system. Now imagine yourself writing code and executing the 6-second suite. You make a handful of edits, then you run the tests. What do you do for 6 seconds? You predict the outcome of the test run: they will all pass, or the new test will fail because you’ve just written it, or the new test might pass because you think you wrote too much code to pass a test 10 minutes ago. In that span of time, you have your result: the tests all pass, so now you refactor. You probably needed about 6 seconds to read up to here.

Now imagine you run the 1-minute test suite. Once again, you predict the result, during which time 6 seconds pass. If you work alone, then after 8 seconds you’ve started drumming your fingers on the desk or letting your eyes dart around the room. You notice the long list of tasks on the team task board. You start to feel your stomach rumble, noticing the time: 11:42. Time for lunch soon. You wonder what the cantina has for lunch, so you point your browser at their intranet site. Tilapia sounds good. You wonder whether Lisa will join you for lunch, so you switch to your email client. Before you write her, you notice a notification to pay your credit card bill. You can do that in 30 seconds, so you switch back to your browser to log in to online banking and quickly make a payment. It turns out Lisa has a lunch meeting, and you reconsider your choice of fish. Today, you decide, feels like a burger day. In the time you imagined yourself doing that, assuming you guessed how long it took to actually do what you imagined, over 1 minute passed. The computer has spent valuable computing time waiting for you.

Pairing doesn’t seem to solve this problem. If you ran this test suite during a pair-programming session, then you probably spent time chatting. At first, you discussed the recent test. After a while, you discussed the task. That killed about 40 seconds, so you started drifting to other topics: the weekend, the kids, XBox, Battlestar Galactica, baseball, management… then you turned around to notice the test run finished while you were arguing whether Cliff Lee deserved the Cy Young award. I don’t mind injecting plenty of relaxed conversation into my work, but when waiting repeatedly for a 1-minute test suite it doesn’t take long to run out of things to talk about.

I need to point out the dual cost here. The first, we can easily see and measure: the time we spend waiting for the tests plus the time the computer waits for us, because we find it hard to stare at the test runner for 60 seconds and react to it immediately after it finishes. I don’t care much about that cost. I care about the visible but highly unquantifiable cost of losing focus.

TDD works well for me in large part because it helps me focus. When I write a test, I clarify my immediate goal, focus on making it pass, then focus on integrating that work more appropriately into the design. I get to do this in short cycles that demand sustained focus and allow brief recovery¹. This cycle of focus and recovery builds rhythm and this rhythm builds momentum. This helps lead to the commonly-cited and powerful state of flow. A 6-second test run provides a moment to recover from exertion; whereas a 1-minute test run disrupts flow. It acts like an annoying short interruption every few minutes. We can try to measure the cumulative effect of these interruptions, but I guess you can imagine a day, possibly a recent one, when periodic short interruptions made it nearly impossible for you to concentrate. How productive did you feel that day? How much did you achieve? How much pressure did you feel to catch up the next day? How relaxed did you feel that evening at home? Did you enjoy dinner? Did you feel present for your spouse or kids or pets? How well did you sleep? How refreshed did you feel the next morning?

Among the early TDD literature I distinctly remember reading that practising TDD would help me focus, relax, achieve more and feel better at the end of a task. I remember agonizing over integration tests. Teams call me expressly to learn how to tame big, slow, brittle test suites. They don’t call me when they feel focused, relaxed and productive. I tell you: integration tests will slowly kill you.

So What Now?

But you have integration tests now, and you haven’t yet learned about the alternatives. How can you cope with your reality? You could regain your focus by running the most important 10% of those tests. That would take 6 seconds and fit into your flow. It also runs a substantial risk of failure. You’ve experienced this. Remember the last time you changed a line of code in one part of the system and it broke something way over there in another module? How did you feel when that happened? How long did you spend tracking down a mistake in some arcane part of they system that perhaps no one understands? How did you deal with having to branch your code changes to deal with the bigger problem? How many times have you told your wild goose chase story to your fellow programmers? How long did you need to recover before returning to a decent state of flow while working on your original task?

So it appears you have a choice between frequent annoying disruptions and less frequent but comparatively catastrophic disruptions. A Morton’s Fork you can blame squarely on integration tests. Stop writing them.

¹ For more about the focus/recovery cycle, I highly recommend The Power of Full Engagement

Read more in this series

April 08, 2009 19:47 junit, testing, agile, design, antipatterns, article, extreme programming, integrated tests are a scam

Toddlers, novelty, and planning

me@jbrains.ca (J. B. Rainsberger) — Wed, 08 Apr 2009 18:32:00 GMT

I visited a dear friend this week and had the chance to meet her young son for the first time since before he turned one year of age. I believe he turned four years old this year, and I got to watch him ready himself to leave his pre-school program. Since Toronto still has winter, Kieran had to negotiate a coat, snow pants, boots, mittens, and all the while he was greeting and saying goodbye to his friends, running around getting some additional exercise, and just generally living in the moment. I don’t remember how long it took to leave the building, but it took some time. Melissa turned to me and remarked at how slow toddlers move. I disagree.

A toddler looks slow, but doesn’t move slowly at all. On the contrary, they move quickly from idea to idea, input to input, person to person, thread to thread, processing a ton of information. Novelty dominates the toddler’s life, robbing them of the opportunity to focus, as they dart around to every new piece of input. Their apparent speed, then, comes not from moving slowly, but from trying to do everything at once, responding to novelty and generally having no real plan.

I simply found that interesting. No connection to software. (Wink)

April 08, 2009 18:32 agile, people, planning, antipatterns, extreme programming

See the Tigers at the Jays tonight (April 6)

me@jbrains.ca (J. B. Rainsberger) — Mon, 06 Apr 2009 13:20:00 GMT

We have one extra ticket to the Tigers/Jays game tonight: it’s the Jays home opener for 2009. If you’d like to go, you can have the ticket free of charge, but I must warn you of my conditions.

We plan arrive in time for the pre-game ceremonies. That likely means we’re walking into the park no later than 6:15 PM.
We plan to stay until the last out, so if you want to leave early, you’re leaving alone.
You will talk baseball and be happy that I will talk baseball. A lot. Pat Wilson-Welsh calls me his personal color commentator.
You will not talk software. Three strikes and you’re out.

If you’re still interested, send email to the address at the top of this page. If you know my phone number, text me instead, since I won’t have internet access throughout the entire day—it will depend on the various coffee shops and restaurants I go to.

Okey dokey, rum and cokey, let’s chase balls!

(If you know that reference, you’re in.)

April 06, 2009 13:20 baseball

Integrated Tests are a Scam: Part 1

me@jbrains.ca (J. B. Rainsberger) — Sun, 05 Apr 2009 08:00:00 GMT

Read more in this series

On March 1, 2010 I changed the phrase “integration tests” to “integrated tests” in this article.

Integrated tests are a scam—a self-replicating virus that threatens to infect your code base, your project, and your team with endless pain and suffering.

Wait… what?

I mean it. I hate integrated tests. I hate them, and with a passion. Of course, I should clarify what I mean by integrated tests, because, like any term in software, we probably don’t agree on a meaning for it.

I use the term integrated test to mean any test whose result (pass or fail) depends on the correctness of the implementation of more than one piece of non-trivial behavior.

I, too, would prefer a more rigorous definition, but this one works well for most code bases most of the time. I have a simple point: I generally don’t want to rely on tests that might fail for a variety of reasons. Those tests create more problems than they solve.

You write integrated tests because you can’t write perfect unit tests. You know this problem: all your unit tests pass, but someone finds a defect anyway. Sometimes you can explain this by finding an obvious unit test you simply missed, but sometimes you can’t. In those cases, you decide you need to write an integrated test to make sure that all the production implementations you use in the broken code path now work correctly together.

So far, no big deal, but you’ll meet the monster as soon as you think this:

If we can find defects even when our tests pass 100%, and if I can only plug the hole with an integrated tests, then we’d better write integrated tests everywhere.

Bad idea. Really bad.

Why so bad? A little bit of simple arithmetic should help explain.

You have a medium-sized web application with around 20 pages, maybe 10 of which have forms. Each form has an average of 5 fields and the average field needs 3 tests to verify thoroughly. Your architecture has about 10 layers, including web presentation widgets, web presentation pages, abstract presentation, an HTTP bridge to your service API, controllers, transaction scripts, abstract data repositories, data repository implementations, SQL statement mapping, SQL execution, and application configuration. A typical request/response cycle creates a stack trace 30 frames deep, some of which you wrote, and some of which you’ve taken off the shelf from a wide variety of open source and commercial packages. How many tests do you need to test this application thoroughly?

At least 10,000. Maybe a million. One million.

Wie ist es möglich?! Consider 10 layers with 3 potential branch points at each layer. Number of code paths: 3¹⁰ > 59,000. How about 4 branch points per layer? 4¹⁰ > 1,000,000. How about 3 branch and 12 layers? 3¹² > 530,000.

Even if one of your 12 layers has a single code path, 3¹¹ > 177,000.

Even if your 10-layer application has only an average of 3.5 code paths per layer, 3.5¹⁰ > 275,000¹.

To simplify the arithmetic, suppose you need only 100,000 integrated tests to cover your application. Integrated tests typically touch the file system or a network connection, meaning that they run on average at a rate of no more than 50 tests per second. Your 100,000-test integrated test suite executes in 2000 seconds or 34 minutes. That means that you execute your entire test suite only when you feel ready to check in. Some teams let their continuous build execute those tests, and hope for the best, wasting valuable time when the build fails and they need to backtrack an hour.

How long do you need to write 100,000 tests? If it takes 10 minutes to write each test—that includes thinking time, time futzing around with the test to make it pass the first time, and time maintaining your test database, test web server, test application server, and so on—then you need 2,778 six-hour human-days (or pair-days if you program in pairs). That works out to 556 five-day human-weeks (or pair-weeks).

Even if I overestimate by a factor of five, you still need two full-time integrated test writers for a one-year project and a steady enough flow of work to keep them busy six hours per day and you can’t get any of it wrong, because you have no time to rewrite those tests.

No. You’ll have those integrated test writers writing production code by week eight.

Since you won’t write all those tests, you’ll write the tests you can. You’ll write the happy path tests and a few error cases. You won’t check all ten fields in a form. You won’t check what happens on February 29. You’ll jam in a database change rather than copy and paste the 70 tests you need to check it thoroughly. You’ll write around 50 tests per week, which translates to 2,500 tests in a one-year project. Not 100,000.

2.5% of the number you need to test your application thoroughly.

Even if you wrote the most important 2.5%, recognizing the nearly endless duplication in the full complement of tests, you’d cover somewhere between 10% and 80% of your code paths, and you’ll have no idea whether you got closer to 10% or 80% until your customers start pounding the first release.

Do you feel lucky? Well, do you?²

So you write your 2,500 integrated tests. Perhaps you even write 5,000 of them. When your customer finds a defect, how will you fix it? Yes: with another handful of integrated tests. The more integrated tests you write, the more of a false sense of security you feel. (Remember, you just increased your code path coverage from 5% to 5.01% with those ten integrated tests.) This false sense of security helps you feel good about releasing more undertested code to your customers, which means they find more defects, which you fix with yet more integrated tests. Over time your code path coverage decreases because the complexity of your code base grows more quickly than your capacity to write enough integrated tests to cover it.

…and you wonder why you spend 70% of your time with support calls?

Integrated tests are a scam. Unreliable, self-replicating time-wasters. They have to go.

¹ True: few code bases distribute their complexity to their layers uniformly. Suppose half your 12 layers have only two branch points—one normal path and one error path—while the others have 5 branch points. 2⁶·5⁶ = 1,000,000 and for 4 branch points 2⁶·4⁶ > 262,000. You can’t win this game.

² Aslak Hellesøy points to a way to take luck mostly out of the equation. His technique for choosing high-value tests will certainly help, but it stops short of testing your code thoroughly. I believe you can achieve truly thorough focused tests with similar cost to writing and maintaining integrated tests even using the pairwise test selection technique. (Thanks, Aslak, for your comment on April 12, 2009.)

Read more in this series

April 05, 2009 08:00 junit, testing, agile, coding standards, design, antipatterns, article, extreme programming, integrated tests are a scam

Why I try to communicate in E-Prime

me@jbrains.ca (J. B. Rainsberger) — Fri, 03 Apr 2009 13:59:00 GMT

I started trying to communicate exclusively in E-Prime less than a year ago. I felt motivated to do this primarily by this claim:

The translation [into E-Prime of the sentence “the movie was good”, which could become “I liked the movie”] communicates the speaker’s subjective experience of the movie rather than the speaker’s judgment of the movie. In this example, using E-Prime makes it harder for the writer or reader to confuse a statement of opinion with a statement of fact.

This claim resonated with me for at least two reasons: I tend to judge quickly, and sometimes harshly, so I wanted to reduce the amount of judging I do; and I pride myself on distinguishing opinion from fact, so I’d like any tool that helps me do that more effectively.

Rather than reproduce a general argument about the benefit of E-Prime, I’d rather share an incident that occurred recently to illustrate how E-Prime could improve communication. Granted, each of us gets to decide what constitutes an improvement.

I had just delivered a two-hour presentation to managers on the subject of test-driven development. I spent the first hour providing the context for test-driven development, reviewing how to apply concepts from Lean manufacturing to software, but focusing on design: concepts like YAGNI, evolutionary design, writing tests first, and refactoring. I spent the second hour taking questions from the audience in batches of five and answering them quickly — about ten minutes per batch. I felt good about the session; however, one person decided to give me some feedback just before we closed.

He did an excellent job of introducing his feedback, almost as though he had recently learned some popular feedback-giving model. He said, almost verbatim:

I have a comment for you. It’s more of a Simon Cowell comment.

I told him that I felt ready to receive his comment.

The first hour was useless evangelism. The second hour was much more valuable. I wish you had run the first hour like the second hour.

If I had felt particularly insecure at that moment, I’d have likely reacted strongly and negatively. Fortunately, I felt great, so I interpreted his comment more generously. I appreciated his directness, and although I thought he used unnecessarily judgmental language, I didn’t mind that he did so in front of the rest of the group. That gave me the opportunity to ask this question.

Why didn’t you say that after ten minutes?

He realized I had made a Lean-related joke, so he smiled and shrugged, before answering that he held his tongue out of respect. I understood. I followed up by telling him that I would have found it more respectful if he had saved me from wasting 50 minutes of everyone’s time.

It turns out that few people in the audience agreed with him. At least one person emphasized on his evaluation form how valuable he found the first hour. To borrow from the writers of Frasier, that’s pretty much what I figured.

If we’d had more time, I would have taken that moment to launch into a discussion of the Satir Interaction Model, given this perfect example of an action (not interrupting me to claim I was wasting people’s time) with two diametrically opposing interpretations: paying respect by not interrupting; showing lack of respect by letting me crash and burn on stage. You can probably reduce any rocky communication to an instance of a severe difference in interpretation.

What if this person had communicated using E-Prime? How might this have played out? I offer this potential translation of my commenter’s comments into E-Prime.

I have a comment for you in the style of Simon Cowell. I found the first hour useless, as though you wanted to proselytize me. I found the second hour much more valuable. I wish you had run the first hour more like the second hour.

As I wrote this, I hesitated on translating “evangelism”. I settled on the periphrasis “you proselytized me”, which I think captures the essence of “evangelism” well. I know I could have chosen different words there. I recognize that the words I chose reflect my lingering subconscious feelings about the incident. By writing his comment this way, I better surface my interpretation of it, which I find both clearer and quite instructive. I could have translated it this way.

I have a comment for you in the style of Simon Cowell. I found the first hour useless, as though you simply wanted to evangelize about TDD. …

I react to this slightly less strongly than to the first version, but that difference doesn’t interest me much. I more care about which the commenter would have chosen: did he choose the word “evangelize” because he wanted to emphasize how I related to him, or because he wanted to emphasize my intention? I believe that knowing that would have helped save me from a harsh reaction had I received his comment from a less centered place than I happened to find myself at the time.

Communicating with E-Prime could have helped avoid a gross difference in interpretation between the commenter and I, and perhaps could do so more regularly. I count this as one of the many reasons I choose to communicate as much as I can in E-Prime.

April 03, 2009 13:59 people, coaching, communicating effectively

TDD: From the Beginning

me@jbrains.ca (J. B. Rainsberger) — Fri, 03 Apr 2009 11:45:00 GMT

This course runs well both as a public course and a private in-house training session.

Join J. B. Rainsberger and learn whether test-driven development will work for you. In this course, you will learn the secrets of modular design from one of test-driven development’s master practitioners. Bring your laptop and be prepared to change the way you write software.

Audience

You have had professional experience on at least one software project in Java, C#, Python or Ruby. You would like to know how to design software incrementally with test-driven development.

You will learn…

how test-driven development can help you deliver software your users will love
how test-driven development can help you earn revenue sooner on your software projects
how to perform the steps of test-driven development
the secrets of truly modular software design
how to practise test-driven development and integrate it into your daily practice
how to design effectively with interfaces
how to test-drive a web user interface without having to deploy your application

Agenda

Day 1: TDD Bootcamp

An introduction to test-driven development and the theory of constraints
Realizing the promise of modular design with test-driven development
A demonstration of the technique of test-driven development
Exercise: test-drive a single-class design
Making test-driven development a daily habit

Day 2: TDD and Evolutionary Architecture

A demonstration of evolving an architecture with test-driven development
Exercise: test-drive a multiple-class design
Zero integration defects without integration tests
A demonstration of evolving an architecture through interfaces

Day 3: TDD and Modular Enterprise Design

Exercise: test-drive a multiple-class design with interfaces and test doubles
A demonstration of test-driving a dynamic web page without running the web server
Remaining questions and answers

What attendees have said about this course

View davidhalldor’s tweet

View a13xnet’s tweet

Inquire about booking this course by sending email to the address at the top of this page.

April 03, 2009 11:45 testing, agile, design, extreme programming, training, TDD From the Beginning

Some comments on TDD: From the Beginning in Reykjavík, Iceland

me@jbrains.ca (J. B. Rainsberger) — Fri, 03 Apr 2009 11:38:00 GMT

I recently presented my course TDD: From the Beginning in Reykjavík, Iceland in associated with Sprettur. I had a great time working with local programmers, testers. and managers, and I had my first opportunity to visit Reykjavík, which I’ve wanted to do for several years.

I want to thank Sprettur publicly for all they’ve done for me to prepare for this course. They did what any great host does: let me prepare to teach and take care of the rest. I’ve only had one difficulty in this trip: deciding where to eat each day.

As always with these courses, we discussed more than just the mechanics of TDD. We also spent time discussing:

debugging communication with the Satir Interaction Model (see Don’t Let Miscommunication Spiral Out Of Control for more)
how your personal financial situation affects how you work (see We Live Here Now to read about how we retired on April 1, 2008)
how The Goal relates to test-driven development and evolutionary design
how test-driven development teaches the principles of modular design, and good object-oriented design
how test-driven development brings a sense of completion to your work and helps you relax more

I also had the chance to see the birth of a Software Craftsmaship Group in Reykjavík. Gulli and I announced the first non-North American Code Retreat, tentatively scheduled to happen before May 31. This will launch a new group in Reykjavík concerned with issues of software craftsmanship. Thanks to Patrick Wilson-Welsh, Corey Haines, Nayan Hajratwala, LeanDog, and all the people who helped make the Code Retreats in Ann Arbor MI and Cleveland OH such a success. I look forward to Code Retreats in Montréal, Halifax, and Reyjavík, if my budget allows.

In all, a great week, and it hasn’t ended yet!

April 03, 2009 11:38 agile

Appearing Thursday night in Boston

me@jbrains.ca (J. B. Rainsberger) — Wed, 25 Mar 2009 16:47:00 GMT

Just a quick announcement: I will appear at Agile Bazaar in Boston with Niraj Khanna with a talk entitled Your Agile Sales Approach ~~Sucks~~ Stinks! or, Effective Agile Sales:
A Good Suit and a Great Pitch Just Doesn’t Cut it Anymore. Our talk centers on applying the strategic selling model of Miller to selling agile concepts. It doesn’t matter whether you’re an employee selling the idea of agile to your co-workers and manager or an independent service provider selling the idea of agile to prospective customers: you need to stop treating agile like a simple sale and instead understand a model that helps guide you through your sale.

Please join us!

March 25, 2009 16:47 speaking, people, consulting

Need your feedback on the title "Your Agile Sales Approach Sucks"

me@jbrains.ca (J. B. Rainsberger) — Fri, 13 Mar 2009 11:06:00 GMT

It’s conference proposal season, and I have recently had a proposal rejected from XP 2009 entitled “Your Agile Sales Approach Sucks”. The tutorial focuses on the difference between a simple and complex sale, with the thesis that one must sell any kind of agile transition or practice adoption as a complex sale, whereas most people continue to try to sell it as a simple sale. One of the reviewers labeled the title as “uselessly provocative” and, while he didn’t reject on that basis, might have rated the proposal down due to the title. Another organization asked us to change the title before we presented it at their user group.

Now I chose the title as an homage to the book Your Marketing Sucks, whose author calls his approach “extreme marketing”. I thought our society generally accepted “sucks” in a way they didn’t 15-20 years ago. Perhaps I have that wrong. I’d like your help to find out.

Please leave a comment to help me understand how people react to a tutorial or user group session entitled “Your Agile Sales Approach Sucks”, focusing on the word “sucks”.

March 13, 2009 11:06 agile, speaking, people, extreme programming, consulting

Please comment on draft logos the Gordon Pask Award

me@jbrains.ca (J. B. Rainsberger) — Tue, 03 Mar 2009 03:00:00 GMT

Sebastian Hermida has drafted some logos for the Gordon Pask Award. Please vote below!

March 03, 2009 03:00

The Gordon Pask Award program needs volunteers

me@jbrains.ca (J. B. Rainsberger) — Sat, 28 Feb 2009 03:00:00 GMT

Laurent Bossavit and J. B. Rainsberger invite you to participate in the Gordon Pask Award program. We would like to improve the program in a number of ways, including collecting nominations throughout the year, researching candidates’ contributions to the agile community and giving everyone a greater chance to get to know past winners. We need your help to do this well.

For the moment, we seek volunteers to help with work such as:

advertise and promote our initiatives on weblogs, in discussion groups, in user groups, at conferences, and wherever you can garner attention
design a physical Gordon Pask Award prize
interview Brian Marick about the story behind instituting the Gordon Pask Award in 2005
interview past award winners and write articles about them
connect the program with public relations or press outlets to help promote the award and raise its profile in the larger software community
suggest changes to the nomination process
suggest something special for the fifth year of the award (2009)
design a logo and color scheme for the Gordon Pask Award

If you would like to help, please send email to gordonpaskaward@agilealliance.org and tell us how you’d like to help. You might tell us you’d simply like to help in whatever capacity we need, or that you have a specific task or project in mind to which to contribute. We welcome all comers.

Thank you for your time, attention and interest.

Laurent Bossavit and J. B. Rainsberger,
Directors of the Gordon Pask Award Program

February 28, 2009 03:00 agile, people, gordon pask award 2009

Please comment on sessions for Agile 2009!

me@jbrains.ca (J. B. Rainsberger) — Tue, 24 Feb 2009 03:00:00 GMT

Dear readers, I need your help.

I want to comment on at least 200 of the nearly 1000 sessions proposed for Agile 2009, but I have only managed to comment on 40 so far. I will add comments to about 40, but I need your help to get to 200.

Please go to http://agile2009.agilealliance.org, register or sign in, pick 10 proposals, read the reviews and comments, then add your own.

Thanks for your help.

February 24, 2009 03:00 agile, agile 2009

Solve Just Enough Of Your Worst Problem

me@jbrains.ca (J. B. Rainsberger) — Thu, 19 Feb 2009 03:00:00 GMT

This session can run as a public conference tutorial or as a private in-house training session.

Many change campaigns fail because we don’t see the results we expected from the change. We can attribute this failure to a variety of issues: attempting to solve the wrong problem, attempting to solve the right problem with the wrong skills, or failing to measure progress towards solving the problem. Most organizations overlook a key possibility: wasting time solving too much of the right problem.

Voltaire once said that the perfect is the enemy of the good, and that principle applies here. While we find it comforting to completely solve a well-understood problem, we sometimes spend weeks or months continuing to solve a problem even though another has risen to the level of the most immediate problem. While you tweak your build to perfection, you might forget that it still takes two weeks to deliver upgrades to your customer, or that your customer needs a month to install the upgrade. Stop wasting time solving a problem when you’ve already solved it enough.

In this session, J. B. Rainsberger introduces concepts from the Theory of Constraints and Lean Software Development to help attendees uncover their biggest problems, and decide how much of that problem to solve before another biggest problem takes its place. From there, we work together to formulate a plan to solve just enough of your worst problem.

This session includes An introduction to Agile Through the Theory of Constraints in a full day tutorial aimed at people who want to explore their software delivery system for problems and solutions.

Understand how to uncover your biggest problem by identifying productive and wasteful activities.
Formulate a plan to solve just enough of your biggest problem.
Walk away with a deep understanding of the various activities that contribute to the time it takes for you to deliver features once they’ve been requested.

Please inquire about booking this session by emailing the address at the top of this page.

February 19, 2009 03:00 agile, training, consulting

Some changes at jbrains.ca

me@jbrains.ca (J. B. Rainsberger) — Thu, 19 Feb 2009 03:00:00 GMT

I have decided to change jbrains.ca a little. I hope you like the improvements.

You’ll notice the search box, a Twitter feed, and a new comments and rating system courtesy of JS Kit.

Thank you to all my readers, and I hope these improvements bring more readers. In the meantime, please feel free to rate old entries, and perhaps even Digg or Reddit a few of them!

February 19, 2009 03:00

An introduction to Agile Through the Theory of Constraints

me@jbrains.ca (J. B. Rainsberger) — Thu, 19 Feb 2009 03:00:00 GMT

This session can run as a public conference talk or as a private in-house training session.

Agile has all these weird, expensive-looking practices: pair programming, test-driven development, regular planning meetings, moving the programmers and business people closer together, focusing people on a single project, multi-disciplinary teams. We can’t afford to go agile!

In this session, J. B. Rainsberger introduces agile practices by relating them to core business matters: compounding early earned value and reducing unnecessary costs. Learn why practice and learning are really profit centers. Maybe you can’t afford not to go agile!

This is a 90-minute talk aimed at people with business knowledge who want to understand how the practices of XP help benefit the bottom line.

You can find an excerpt from this presentation at XP Day Manhattan 2007 at YouTube.

Understand how agile practices relate directly to core business concerns.
Feel more comfortable with agile practices as an investment, rather than a sunk cost.
Understand how to present agile practices in a compelling way to business people.
See a more concrete, relevant justification for agile practices than “you’ll like it, and people will feel better”.

Combine this with Solve Just Enough Of Your Worst Problem for a complete one-day course.

Inquire about booking this session by emailing the address at the top of this page.

February 19, 2009 03:00 agile, training, consulting

Sponsor me to speak; receive free consulting

me@jbrains.ca (J. B. Rainsberger) — Thu, 19 Feb 2009 01:00:00 GMT

Would you like to support a local software user group or community event? I have begun a speaker sponsorship program with a twist: free consulting.

When you support a local software user group by sponsoring me to speak at their meetings or conferences, you receive a sponsorship package including a half day of remote consulting, coaching, pairing or training. All this for only CAD 495. (Canadian sponsors pay GST.)

Most local software user groups have to raise money to invite well-known out-of-town speakers. They have a few avenues: local fundraisers, local benefactors, and the Agile Alliance speaker reimbursement program. Most such organizations, however, don’t have fundraising experience, and the Agile Alliance’s program still has a relatively limited budget. The people who started these groups didn’t plan to become expert fundraisers, so let them benefit from your sponsorship to bring me to speak to them.

The Speaker Sponsorship Package includes

two 90-minute remote consulting sessions on the topics of your choosing
acknowledgement on the user group or event web site of your sponsorship
acknowledgement on jbrains.ca of your sponsorship
acknowledgement during my talk of your sponsorship
acknowledgement during all my 2009 conference talks of your sponsorship

Acknowledgement includes your (or your company’s) name, logo and a link or pointer to your website.

I will conduct your consulting sessions with Skype (http://www.skype.com) and its screen sharing feature. You need a headset, a webcam and a high-speed internet connection. You can use your sessions to do the following:

work with me as a pair partner: programming, writing stories, designing business tests, personal planning, and more
map your value stream, identify bottlenecks, and devise plans to deal with them
run a code review or planning meeting
ask for my advice on issues of design, testing, planning, teamwork, communication, installing practices
suggest your own session, and as long as I believe I can help you, I will do it

Upcoming sponsorship opportunities:

Sponsor the Agile Bazaar, the top agile user group in New England, where Niraj Khanna and I will explain on March 26, 2009 why Your Agile Sales Approach Sucks!
Sponsor my appearance at Code Retreat 2, where I will help Patrick Wilson-Welsh and his crew give programmers a place to practice their technique.

Unfortunately, you cannot use your sessions to do classroom training. If you would like to hire me to train your team or organization, please read about my training services.

February 19, 2009 01:00 speaking, coaching, consulting

On 100% unit test coverage and other nonsensical ideas

me@jbrains.ca (J. B. Rainsberger) — Mon, 16 Feb 2009 03:00:00 GMT

I will simply riff for a while on things I read Joel Spolsky say (I read a transcript of a podcast from here) about test-driven development.

Nobody should strive for 100% test coverage, let alone microtest coverage, for obvious reasons. Among those obvious reasons, I find two glaring ones: we generally don’t agree on what the term means; and trying to do it leads to writing tests for their own sake, rather than as a means to write sufficiently correct software. I have learned two important things through practice and observation: no single optimal number for test coverage can exist for all projects; and if you insist on an optimal number for test coverage, choose 85%, meaning that the average team ought to test all but the most straightforward 15% of the average system. When I practise TDD, I end up with around 85% test coverage because of the way I apply the principle of Too Simple to Break. Among the 15% untested you will find dead simple get/set methods and dead simple delegation. When Joel concludes something based on the hypothesis that otherwise thoughtful people have 100% test coverage as a goal, he runs well off the track. I don’t doubt that some people seek 100% test coverage, because those people help keep me in business. Stop it, or I’ll bury you alive in a box.

Some innocuous-looking changes cause an unusual number of tests to fail. While I don’t like this situation, I draw a different conclusion from it than Joel does. I conclude that this points to a design flaw worth exploring. I don’t have a “proof” for this, but I have observed good results when I have treated my own designs this way. In this vain, I follow the maxim I learned from the Pragmatic Programmers: abstractions in code and details in data. Joel uses this example:

Because you’ve changed the design of something… you’ve moved a menu, and now everything that relied on that menu being there… the menu is now elsewhere. And so all those tests now break. And you have to be able to go in and recreate those tests to reflect the new reality of the code.

I don’t understand why we would have microtests that check that a specific menu shows up in a specific location. Remember: abstractions in code and details in data. Also remember: three strikes and you refactor. Putting these two principles together, once I have a few menu items, I’ve extracted the details about individual menus to some List of Menu objects and an engine that operates on them. Also, I have probably separated that List from the code that presents the menus. If I don’t like how my code presents the menus, I can fix that with test data that has no bearing on the actual menus. If I don’t like the order of my menus, I can change the Menu objects in the List—just data—and do a quick manual inspection without having to change the tests for my menu-presenting engine. Moving a specific menu somewhere should not require any code changes; and if it does, then you have a design flaw: you have details in code. Stop it, or I’ll bury you alive in a box.

In general, if a single change causes an unusually high number of tests to fail, then your tests have a duplication problem. Stop letting duplication flourish in your tests, or I’ll bury you alive in a box.

Thanks for Bob Newhart for the line “Stop it, or I’ll bury you alive in a box”, which I heard for the first time on Mad TV.

(Edit 2009-02-23: Corrected Saturday Night Live to Mad TV.)

February 16, 2009 03:00 java, testing, agile, coding standards, refactoring, design, antipatterns, extreme programming

Looking for work in Europe in March

me@jbrains.ca (J. B. Rainsberger) — Fri, 30 Jan 2009 03:00:00 GMT

I am teaching a public TDD course in Istanbul February 26-28, so I’d like to continue the trip elsewhere in Europe. I’d like to offer my services at a reduced rate to facilitate bunching together work in Europe. If you would like to hire me for some consulting, mentoring, coaching or training, or can introduce me to someone who should be interested, I can offer an expenses-included price that competes very well with other top-notch consultants. For the right client, with the right personal reference, and in the right place (Cote D’Azur? Coastal Spain? Austria?) I can lower the price even further.

Please inquire by email, and be patient, as I’m on vacation until February 9 and will be entirely out of contact until then. I realize this makes it short notice, but that’s part of what reduces the price!

January 30, 2009 03:00 agile, extreme programming

Code Retreat 1 in Ann Arbor, Michigan

me@jbrains.ca (J. B. Rainsberger) — Fri, 30 Jan 2009 03:00:00 GMT

I took some time off to attend the first Code Retreat in Ann Arbor on January 24, 2009, the purpose of which was to practice and discussing coding techniques. I would like to thank the organizers for making me feel welcome and driving me around.

I found a related video. Enjoy.

I was glad to see familiar faces: Bill Wake, Pat Welsh, Ron Jeffries, Chet Hendrickson and Corey Haines. I hope to come back some day.

January 30, 2009 03:00 java, ruby, testing, agile, people, coding standards, refactoring, design, emotional health

We don't need to define good design

me@jbrains.ca (J. B. Rainsberger) — Tue, 27 Jan 2009 03:00:00 GMT

Over the years, I have witnessed a number of attempts to develop a complete, constructive definition of good design. I have witnessed most of this in the Extreme Programming Yahoo! group, in threads that crop up every year or so. A pattern repeats itself: someone asks about how to tell how good a design is, a bunch of people offer suggestions, they start to argue the fine points, someone points out the impossibility of developing a complete definition of good design, someone else points out that a generative definition would suffice, someone else claims that a generate definition doesn’t do the job… I could almost write the entire thread myself by now. Some people lament the lack of a complete, constructive definition of good design. I don’t, and today I finally articulated why I don’t think we particular need to worry about this.

I don’t mean to disparage the search for a clear test of a design’s “goodness”, because I think great things could come from that search: automated design critics, better objective measures of design health, possibly even a model for estimating the cost of maintaining a given design. I would find these things personally useful and I believe the software community would benefit from them. Still, the fact that we don’t yet have these things doesn’t need to cause us such consternation, because we can still do so much without it.

In the past ten years I have learned some incredibly useful things about design:

When programmers write design tests, they tend to find more of their own defects more quickly, which reduces the overall cost of realizing their design.
When programmers duplicate code, defect rates increase, and when they reduce duplication, defect rates decrease.
When programmers first start to change unfamiliar code, they tend to start by clarifying unclear names in the code: variable names, method names, class names. This practice helps them change code more safely and less expensively.

I have learned these things through my own practice, through pairing with others, and through observing other programmers at work. I find it more significant to note that even with only these three observations, we have improved the value of software design considerably. Even more significant than that, we can still improve the value of software design more by continuing to spread these observations to ever more programmers, projects and teams. We can still do so much more good with these observations than we have already done. We can wait for the next great breakthroughs.

Imagine the day arrives when every software designer in the world uses tests (or specs, if you prefer) to guide their design, focuses on reducing duplication and pays attention to naming their design elements appropriately. Either we’ll have seen the next great design breakthrough by then, or we’ll have seen so much good design that we’ll have extracted the essential patterns of good design that can lead to a meaningful, useful, deep, objective test for design goodness. Either way, I think we will win.

In the meantime, I leave the search for a definition of great design to the programmer-philosophers. I get by with the Miller Test: I know it when I see it.

January 27, 2009 03:00 testing, agile, coding standards, refactoring, design, article, extreme programming

Please review my session proposal for Agile 2009

me@jbrains.ca (J. B. Rainsberger) — Mon, 26 Jan 2009 16:38:00 GMT

I have proposed a 90-minute talk entitled “An Introduction to Agile Through the Theory of Constraints”. Please review it. Thanks.

January 26, 2009 16:38 agile, speaking, presenting, extreme programming, agile 2009

The Quality/Speed Barrier

me@jbrains.ca (J. B. Rainsberger) — Wed, 21 Jan 2009 03:00:00 GMT

[Update on February 7, 2009: I need to rewrite this article, and I will, so if it has confused you, don’t worry. I will fix that soon.]

I haven’t yet learned how to measure it, but I believe I have identified a kind of Law of Software Development that I call the Law of the Quality/Speed Barrier. This law states the following.

For any project we can find a quality level below which one must trade off quality and speed and above which one derives more speed from better quality.

Now I admit that this definition suffers from a lack of precision, so let me explain what I mean. Please hold your cards and letters about the pointlessness of the word
quality.

We can measure quality by looking at any useful measure of the general software development community considers to represent quality: defect rate in time, defect density, defect totals, weight defect totals by severity or urgency, marginal cost of a feature, average cost to fix a defect, average cost to assess impact of a proposed change. I don’t mind which you choose, because for the purposes of the Law of the Quality/Speed Barrier, any will do.

We can measure speed by looking at the usual measure of speed: effort required to design and correctly implement an average-difficulty feature, team velocity, team velocity trends over time, cost to deliver an average-difficulty feature. Again, choose the one you like, since any one will do.

However you wish to measure quality and speed, if you have high enough quality, then more quality helps you attain more speed; and if you have low enough quality, then you have to sacrifice quality for more speed and you have to sacrifice speed for more quality. I have not studied hundreds of projects to defend my position; however, I have worked to varying degrees on dozens of projects, and I believe the law has held in all those cases.

You might have observed this in your own project, largely as a general feeling that you might find difficult to substantiate with data, but that nonetheless your every observation seems to confirm.

What I find most vexing about this law concerns the conclusion that in order to move above the Quality/Speed Barrier, one must sacrifice speed in the interim. My consulting practice includes helping organizations accurately decide when they should start investing more heavily in the kind of change program that would help them increase quality, reach, then eventually surpass, the Barrier. For most, a simple awareness of the Barrier makes it easier to know whether to invest in trying to cross it. In most cases, teams find themselves above the Barrier because they made an agreement to start above the Barrier and not allow themselves to fall below it. It appears much easier to maintain your position above the Barrier if you’ve started there, just as it appears easiest to maintain your position below the Barrier if ever you’ve let yourself fall below it, whether you’ve started below it or not.

I encourage you to gather some informal feedback from your team about this question. Do you believe you operate above or below the Barrier? How do you know? Do you believe you have started above the Barrier and fallen below it? What have you seen or heard that makes you believe that? Most importantly, if you find yourself below the Barrier, what can you measure or detect that would help you estimate the return on a potential investment in training, changes in work habits and changes in work systems that would help you climb over the Barrier? How would you know you’ve succeeded?

As always, the questions matter more than the answers.

January 21, 2009 03:00 agile, people, design, article, extreme programming

If I can't inspire myself, at least I can inspire someone else

me@jbrains.ca (J. B. Rainsberger) — Sat, 10 Jan 2009 03:00:00 GMT

I enjoy speaking to people at conferences mainly because perhaps they will try some of the things that I find myself too unmotivated or just plain lazy to try. I just found out that Corey Haines’ Pair Programming Tour had as part of its inspiration a conversation Corey and I had about Paul Erdős’ unusual career. Thanks, Corey, for acknowledging me during your tour.

January 10, 2009 03:00 agile, people

Please propose sessions for XP 2009 and Agile 2009

me@jbrains.ca (J. B. Rainsberger) — Sat, 10 Jan 2009 02:24:00 GMT

I would like to invite you to submit a proposal for a workshop, tutorial or talk to XP 2009 or Agile 2009. The deadlines for proposals are in mid-February, so you have a few weeks. Don’t forget to read Kent Beck’s paper about submitting papers to OOPSLA to help you get started.

January 10, 2009 02:24 agile, presenting, extreme programming

Agile and innovation

me@jbrains.ca (J. B. Rainsberger) — Sat, 22 Nov 2008 03:00:00 GMT

A friend who is working towards learning to be a game developer, and whose instructor is exposing him to some agile concepts, asked me this:

[O]ne of the problems I see with Agile Development with relation to Game Development is on the ‘creative’ end, and with research and development. Researching new technology (speaking in software teams) takes time, usually an undetermined amount of time. But, given the methods used in Agile development, it seems that there is little room for allowing ‘creative freedom’ in order to innovate a genre.

I answered this way, which is rough and unedited.

I believe, on the contrary, that agile is one approach that explicitly allows for creative freedom by focusing our energy away from deadlines towards minimum marketable features. I see R&D fueling agile development in a simple way: the ongoing R&D activity uncovers something, which we decide to turn into or add into a product, from which we create stories, then we deliver those stories. Agile focuses on making those stories as lean as possible: maximum business value per unit of effort. A traditional perspective on R&D is that it generates projects or product lines, while an agile perspective is that it generates ideas for features. The difference is batch size.

One consequence of an agile project’s heartbeat is that the team delivering stories forgets to spend time innovating because they simply deliver stories. A high-functioning agile team is probably producing enough business value to be able to add slack into their schedule for innovation. Read DeMarco’s “Slack: The Myth of Total Efficiency” for some specific cases. I recommend two kinds of slack: (1) Split the year into 4 quarters, each 13 weeks; spend 12 weeks delivering stories and 1 week doing anything except delivering stories; this follows a natural business rhythm of one release per quarter followed by a solid week of creative time. (2) Within an iteration, spend up to 20% of your time on innovation: exploring technology, exploring business ideas, or just plain gazing into the distance; most teams don’t do this because they’re buried under a mountain previously-promised and not-yet-delivered projects; such a team has no slack, whether it does agile or not.

I have taken many of these ideas from well-respected sources of opinion on strategic thinking. Most notably, although I can’t remember where I read it, I remember reading about spending a half-day per week, a full day per month and a full week per quarter purely on strategic thinking. I wish I did a better job of following this advice myself. I did not mention gold cards, but you should look for “Innovation and Sustainability with Gold Cards” by Julian Higman, Tim Mackinnon, Ivan Moore and Duncan Pierce as another source of information on how to save time for innovation in an XP project. I don’t remember where I first read the 12 weeks/1 week idea. I’d appreciate a reference in case you read it, too, and remember where.

[2008-12-18 Tobias Fors brought this to my attention, and while I don’t think that’s the reference I was thinking of, it’s a damn fine one. Read it.]

November 22, 2008 03:00 agile, people, extreme programming

Looking for a Project Manager and Business Analyst (one person) in the Toronto area

me@jbrains.ca (J. B. Rainsberger) — Fri, 07 Nov 2008 03:00:00 GMT

I have a friend looking for someone with both Project Manager and Business Analyst skills for a contract position running 9-12 months in the Toronto area. If you’d like to inquire about this opportunity, please respond to the email address prominently displayed on this page.

November 07, 2008 03:00 employee rescue

I expect to be in Paris in January...

me@jbrains.ca (J. B. Rainsberger) — Thu, 06 Nov 2008 23:39:00 GMT

…so if you live there and would like to visit, please email me to let me know that. I’d enjoy seeing you.

At the same time, if you know a company in the area* who you believe would benefit from my services and would be interested in hiring me at a greatly reduced price, I would like to explore that possibility, too. I would appreciate an introduction by email.

As always, send email to the address displayed prominently on this page.

*By “in the area”, we mean someplace within a 4-hour train ride of Paris, so even if your company is not in the city, we can probably work something out. Possible destinations include Frankfurt, Bruxelles, Lyon, Marseille, Bordeaux, Amsterdam and London.

November 06, 2008 23:39

"Failing Quickly" via Productivity501

me@jbrains.ca (J. B. Rainsberger) — Thu, 02 Oct 2008 02:48:00 GMT

I started reading productivity501.com about a year ago and have really liked what I’ve read to date. Occasionally, I see an article there that relates quite directly to agile software development, so I wanted to share that with you. I hope you start reading productivity501.com and enjoy it.

Failing Quickly begins

Failing can be one of the most productive things you can do. Most people try to avoid failure. I’m not saying that this is bad, but in many cases they are just delaying failure to a later point in time. If something you are doing is going to result in failure you should do your best to make sure it happens sooner rather than later. With few exceptions, failing now is going to be less expensive (in time, money, mental stress) than failing one year from now.

Enjoy the article.

October 02, 2008 02:48 agile, extreme programming

Call for samples of integration tests

me@jbrains.ca (J. B. Rainsberger) — Wed, 01 Oct 2008 03:00:00 GMT

I need your help.

At the Better Software Agile Development Practices conference in November I will present my tutorial entitled Avoid Integration Defects Without Integration Tests. I will describe and demonstrate the design benefits of reducing your reliance on integration tests (specifically end-to-end tests) to gain confidence in the basic correctness of code. I’d like to take sample integration or end-to-end tests from the audience and turn them into good, focused object tests, but at a busy conference, few audience members prepare such material in advance.

Enter you.

If you have some end-to-end or integration tests that you’d like to turn into good, focused object tests that help improve your design while offering the same or better confidence in the correctness of your code, then please contact me to receive instructions on how to send me your sample. I will, of course, give you whatever credit you want, or promise not to identify you if you’d rather remain anonymous. Whether I use the sample in the tutorial, I will work with you to show you how to improve your design through focused, object tests, rather than relying on integration tests.

Thanks.

October 01, 2008 03:00 testing, agile, presenting, design, extreme programming, agile dev practices 2008

Microtechniques: typing

me@jbrains.ca (J. B. Rainsberger) — Sat, 20 Sep 2008 03:00:00 GMT

I remember Alistair Cockburn presenting a keynote address at XP/Agile Universe 2002 in Chicago. I remember most vividly his comments on microtechniques, a phrase that struck me and has stayed with me since that time. He described how microtechniques enable higher-level improvements by speeding up the rote parts of one’s work. Put another way, quicker typing buys slack, and since slack compounds, higher-level improvements are significant and inevitable. To write code, we type, and we learn to type by rote. While programming involves much more than typing, programming includes typing, so one can argue convincingly that typing well helps people develop as programmers. I contend that typing combines with knowing your text editor or IDE well to drastically amplify a programmer’s skill, which explains the typing test badge attached to this entry. I believe my typing speed helps make me a better programmer.

At times, though, fast typing gets me into trouble. I do manage to spend too much time typing quickly and not enough time typing thoughtfully. Does this mean, then, that typing quickly really slows me down? I haven’t measured it closely, so no-one knows the answer; however, I have become conscious of this, which explains why I so easily get up and walk away from the keyboard when things don’t go well. I know that I need to walk away from the keyboard to avoid letting my quick typing lead me down a rathole and, perhaps more importantly, I know when I come back to the keyboard with better ideas that typing won’t pose a bottleneck to completing the task. In a sense, I treat typing time as free and feel comfortable taking all the time I need to think. More than anything else, this helps make me a better programmer.

Would you do well to take a typing class? Perhaps. I suppose if you can afford to spend an hour per day for three months to practise typing and if you plan to type for more than about 10 more years, then you ought to at least consider it.

Suppose a full-time programmer sits at the keyboard prepared to type about four hours per day, half of that time actively typing. If you increase your speed from 30 to 40 words per minute, then you’d reduce typing time from two hours to 90 minutes. An investment of 65 hours (1 hour per day for three months, meaning 250 / 4 < 65 working days) would return 0.5 hours per day * 250 working days per year * 10 years = 1250 hours of saved typing. I count more than 1920% return over 10 years, or 35% return per year compounded annually for 10 years. (1250 / 65 > 19.23 and (1 + 19.23) ^ (1/10) – 1 > 0.35) The payback period for the 65 hours of investment is approximately 130 days (65 working days * 0.5 hours saved per day) or 7 working months (12 * 130 / 250 < 7). In other words, if you took a three-month typing course for one hour per day that improved your typing speed from 30 to 40 wpm, the decrease in typing effort would return you the investment in 4-10 months (7 +/- 50%). This ignores your increase in effectiveness from spending more time thinking about what you type before you type it! It sounds like a win to me.

102 words

Typing Test

September 20, 2008 03:00 agile, design, extreme programming

JUnit: A Starter Guide

me@jbrains.ca (J. B. Rainsberger) — Fri, 19 Sep 2008 03:00:00 GMT

Not long after the Christmas break between 2001 and 2002 I wrote “JUnit: A Starter Guide” in response to a flurry of complaints over the lack of a decent JUnit tutorial. I didn’t know at the time that I would turn this simple tutorial, written somewhat in haste, into JUnit Recipes: Practical Methods for Programmer Testing, which I completed in 2004. It has surprised me to note that several hundred people continue to read the Starter Guide, so I thought I would include a link to it from here. In order not to deal with differences in HTML formatting, I have decided to link to the document as a PDF and keep it mostly for historical purposes. Much has changed since 2002, and I hope the Starter Guide remains a solid introduction to JUnit, test-driven development and software design.

JUnit: A Starter Guide

September 19, 2008 03:00 java, junit, testing, agile, coding standards, design, article, extreme programming

Gordon Pask Award: write the future

me@jbrains.ca (J. B. Rainsberger) — Fri, 12 Sep 2008 03:00:00 GMT

At Agile 2008 I agreed to take the reins of the Gordon Pask Award from Brian Marick, who had stewarded the award through its first four years. Laurent Bossavit and I have agreed to administer the award for the foreseeable future, although I promise Laurent that I will do most of the work. I have quite strong personal feelings about the award, since the committee awarded it to Jim Shore and me in 2005, and I also have some strong feelings about public recognition in general, so I felt it wise to canvas the public a little to find out what they think about the award. In the past month, a handful of you have responded, and I have organized those responses into a few categories. I wanted to share them with you in the hopes that more of you would provide some input, even if just “me, too”.

Most of the respondents said that the Gordon Pask Award helps them know whom they should talk to. I consider this the primary mission of the award: to shine a light on the people the community ought to pay attention to and even push to greater heights. I also consider this the award’s greatest strength, and I will encourage the selection committee to keep this point uppermost in its collective mind when it meets to select the 2009 winners. What problems do you believe this approach will create?

A few respondents said that they look at the award winners as models to emulate. One person said that seeing someone win the award made him think he should “get off (his) ass and add value.” Another said that the winners’ actions serve as a model to him. A third said that the award “breathes new life” into the community. I consider this to be an important part of the award’s influence: a kind of call to action to the rest of the community. I felt especially proud of Arlo Belshee’s call to action: come back to Agile 2009 and tell us what you’ve invented in the past year. I believe this kind of rallying helps the community grow, although I remain concerned about the award’s effective on people’s intrinsic motivation. I have read Kohn’s Punished By Rewards and I find it important to dampen the negative effects of the award on the community. I don’t want people to do things expressly hoping to win the award, and a part of me believes that karma will stop those people from winning, anyway. What other problems do you believe the award will create?

A couple of respondents pointed out the importance of knowing on what basis people nominated others, and especially on what basis we chose the winners. I understand the desire for transparency, but I fear that if we act too transparently, then we will lose our opportunity to be flexible and dynamic in our choices. Our selection committee meetings take long enough already and as the committee expands to include two more winners, I imagine the complexity will only increase. To add things like precedents and worry about how this group of people who react to choosing Person X over Person Y… frankly, if that starts to happen, then I will walk away from the program entirely. On the other hand, I do counsel businesses to be uncomfortably transparent, so I don’t know how to take my own advice here. I don’t know how to balance transparency with freedom to make choices without undue recrimination from the agile community. Do you have any advice for us on that front?

Someone suggested we publish a collection of references to the award winners’ work shortly after we present the award as a starting place for learning about the award winners and their work. I really like this idea and I plan to invite Kenji Hiranabe and Arlo Belshee to help me prepare an anthology of sorts for them. I encourage you to suggest references to their work as well by email.

One person commented about how easily one could see the award winners become a clique, meaning that one would need to belong to an inner circle to win the award. This represents by far my greatest fear for the Gordon Pask Award. Given that the previous winners get together with Brian Marick, Rachel Davies and Big Dave Thomas to select the next winners, and given that the nominating process has progressed somewhat haphazardly so far, I can see the risk of becoming another Old Boys Network. I don’t know how to deal with this potential problem, except to keep it in mind as the selection committee works towards selecting new winners, as well as working with you to make the nomination process more open. I want desperately to avoid turning the Gordon Pask Award into American Idol! I don’t want the public the vote and I especially don’t want to see effects like “Vote For The Worst” infiltrate this award. This might mean less transparency, but I remain open to other suggestions. If you feel concerned about the award winners becoming a closed circle, what might we do to allay your concern?

One person commented that no woman has yet won the award. On this point, I must remain firm. I will influence the selection committee as much as possible against letting issues of gender, religion, sexual orientation, or any similar issues directly affect the choices we make. I do not want to give the award to a woman in 2009, an Eastern European in 2010, then someone fitting some other particular “type” in 2011. Anyone can win the award. A diverse group selects the winners, and that group grows more diverse each year. I don’t see anyone trying to keep the award away from women, gays, or the handicapped. I especially don’t care to dispute the notion of ‘proper terms’ for groups of people. On this basis, I see no need to encourage the selection committee to consider any particular group of people for the award. We consider anyone and everyone.

No-one yet has taken the time to tell us that they want us to discontinue the award. If you happen to feel that way, I really want to hear from you, because those opinions will tend to differ from mine the most. I need those opinions to have a balanced view. Please don’t hold back.

Finally, if you have any suggestions related to the questions above, please tell me about them, otherwise I will simply choose the suggestions I like and change nothing else. Thank you for your time.

September 12, 2008 03:00 gordon pask award 2009

Employee Rescue Wednesday for September 10, 2008

me@jbrains.ca (J. B. Rainsberger) — Wed, 10 Sep 2008 03:00:00 GMT

Act fast! Positions either fill quickly or clients move on. Don’t waste this opportunity.

Are you looking for the contract that will let you take the plunge as an independent contractor? We have an opportunity in Des Moines IA that could let you live for a year on only six months’ worth of work. You need to be an expert-level .NET/C# programmer with at least one professional Java project and who knows Extreme Programming. Give yourself some slack by building up an emergency fund while you take your first steps towards financial independence. Send your resume and a write-up of your last .NET/C# project, including how you applied agile concepts to your work!

Are you frustrated that your co-workers won’t listen to your great ideas about how to deliver software? Our New York City-based client wants you to teach them while you work! You need to be a strong Java programmer with agile skills (TDD, evolutionary design, adaptive planning) who has a desire to teach. Put your ideas to good use and build up slack in your work schedule while you do it. Send your resume and a write-up of the three ideas your co-workers won’t let you implement!

Looking for your first contract as a programmer? You need to be well-versed in agile practices and have experience with Java technology skills for a project in Columbus OH that will run at least until December. Earn more than you can as an employee while we pay your living expenses for at least four months. Send your resume and a write-up of your experience as an agile programmer today!

Interested to see whether you could live someplace small and inexpensive? Give yourself a chance to live the cheap life and contemplate earlier retirement by house-sitting for six to eight weeks in Dauphin, Manitoba, Canada. The fastest way to retirement is to live simply: it builds slack in your finances that you can use to learn to become as rich as you want to be. We pay your expenses; you take care of a house and a few cats. Tell us you’d like the house-sit starting October 13 until sometime between November 17 or December 8, depending on our travel schedule.

September 10, 2008 03:00 employee rescue

Employee Rescue Wednesday for September 3, 2008

me@jbrains.ca (J. B. Rainsberger) — Wed, 03 Sep 2008 08:38:00 GMT

Act fast! Positions either fill quickly or clients move on. Don’t waste this opportunity.

Are you frustrated that your co-workers won’t listen to your great ideas about how to deliver software? Our Newark-based client wants you to teach them while you work! You need to be a strong Java programmer with agile skills (TDD, evolutionary design, adaptive planning) who has a desire to teach. Put your ideas to good use and build up slack in your work schedule while you do it. Send your resume and a write-up of the three ideas your co-workers won’t let you implement!

September 03, 2008 08:38 employee rescue

Story Test-Driven Development: don't start here

me@jbrains.ca (J. B. Rainsberger) — Tue, 02 Sep 2008 03:00:00 GMT

I don’t want to claim that story test-driven development doesn’t work, because some of my most respected colleagues teach the practice with success; however, I do want to warn people who might find themselves seduced by STDD, especially if they think of it as an easy replacement for TDD.

Allow me to clarify the two terms, TDD and STDD. To practice TDD, the programmer begins with a small, well-defined behavior they’d like to implement. Typically, they design that behavior as a method on a class, although they could get away with doing even less, then brainstorm a list of tests they might write. With such a list in hand, they run through the TDD cycle, illustrated beautifully by Bill Wake’s stoplight analogy. When the design behaves adequately and correctly, the programmer stops.

To practice STDD, the programmer begins with a story and several story tests, which I tend to call “examples”. The programmer then selects a story test, watches it fail, then test-drives enough code to make it pass. One by one, the programmer makes each story test pass until they complete the entire story.

I have been teaching people about TDD and stories for years, and have practiced STDD most of that time, in one form or another. I find the technique helpful; however, when I have pushed STDD to its limit, I have found it to guide me in directions I don’t like, which TDD has generally never done. When I watch others attempt to practice STDD, especially novices and advanced beginners, I see how they misapply STDD and lead themselves towards a Big Ball of Mud, despite what the agile community’s marketing machine says about TDD and stories. I believe the intersection of the two creates problems for those not accustomed to the different goals of TDD and user stories.

I use examples, the term I use for story tests, to show progress towards delivering a story, or feature. Broadly, I add examples to reflect increasing levels of understanding of the system to design, and as examples pass, that reflects progress towards delivering an ever more powerful system. I use programmer tests, the term I use in place of unit tests, to test my design ideas as they come to me and to help me type code in correctly. Any time all the programmer tests pass, the system works as designed, even if it does not yet do everything the business needs. Any time all the programmer tests pass, I can freely commit changes to the main line of the project’s design repository.

More succinctly, examples help us design the right system and programmer tests help us design the system right. (I prefer “correctly” there, but then I lose the symmetry.)

I often see programmers try to use passing examples as an absolute criterion to stop designing. They underestimate, in my opinion, the role of programmer tests to put positive pressure on their design. Examples, especially when written as end-to-end or integration tests (a test whose failure does not isolate the mistake to a single method), simply do not put positive pressure on a design: their high-level nature can’t constrain a design enough to support careful refactoring. For this reason, I recommend novices and advanced beginners not practice STDD until they first see or feel for themselves the impact focused, small programmer tests have on their design.

I want to leave no room for doubt: I do not mean to say that novices should avoid STDD as an “advanced practice”; but rather that a combination of novice tendencies makes STDD harder than TDD to practice well. Specifically, the novice tends to write examples as end-to-end tests, which provide too much design freedom and exert too little positive pressure on the design to guide refactoring and prevent defects. Instead, I would counsel novices and advanced beginners to focus on TDD and run the examples every hour or so to measure their progress towards delivering the story.

Read more about how to practice STDD well.

September 02, 2008 03:00 testing, agile, stories, people, refactoring, design, antipatterns, article, extreme programming

Istanbul, Eindhoven, Bled

me@jbrains.ca (J. B. Rainsberger) — Wed, 20 Aug 2008 03:00:00 GMT

In case you don’t religiously follow where I’m appearing, I simply wanted to announce that we will visit Istanbul August 21-23, travel from their to Eindhoven, Netherlands August 25-29, and finally on to Bled, Slovenia August 30-September 7. If you live near these places and would like to get together or would like me to speak to a local company or user group, please contact me by email and we will attempt to arrange things. Since I do not drive, you’d need to provide transportation to and from the event, which could be a pre-paid taxi, a ride from a friend or detailed instructions on using public transport to get there and back.

August 20, 2008 03:00 speaking

Gordon Pask Award 2009

me@jbrains.ca (J. B. Rainsberger) — Tue, 12 Aug 2008 03:00:00 GMT

I have agreed to administer the Gordon Pask Award starting in 2009. Brian Marick has done a wonderful job, just at the edge of chaos, in starting the program and I hope to be able to continue in his footsteps. Laurent Bossavit has agreed, at least in principle, to co-administer the program and I know I will need his help.

I have several ideas for improving the mechanics of the award in addition to a personal vision of the award, but I certainly don’t mind receiving your advice. Since I cannot handle thousands of emails on the topic, I would like you to answer one of these questions regarding the prize, how we award it and how we present it.

What does it mean to you to see someone other than you win a Gordon Pask Award?

What does it mean to you to see someone other than the person you nominated win a Gordon Pask Award?

All things considered, would you rather we continue the program or abandon it?

Please send me an email with your thoughts. Write what you will, but please include an answer to at least one of these questions.

August 12, 2008 03:00 agile, people, extreme programming, gordon pask award 2009

A review of Agile 2008

me@jbrains.ca (J. B. Rainsberger) — Tue, 12 Aug 2008 03:00:00 GMT

I must admit to some bias in reviewing Agile 2008, because they held it in Toronto, where I lived from 1996 to 2007. I grew up in a Toronto suburb. I can’t account for what portion of my positive review depends on my great familiarity and comfort with the city. Even so, I can’t remember having as enjoyable a time at the Agile 200x conference since Agile 2005 in Denver when I received the Gordon Pask Award.

I FELT CONNECTED. I have been particularly concerned about how much the conference has grown in the past few years. Large conventions like Java One do not hold my interest, which explains why I don’t attend them. As attendance at Agile 200x grew from Denver to Minneapolis to DC I became concerned that I would find myself increasingly lost among the sea of people. I felt deeply connected to people in Toronto and managed even to make a handful of new connections. Even though I believe the conference consists of “600 of my closest friends and 1000 people I will never meet”, I must admit that I felt much more connected to the people than I did in Minneapolis and DC. I attribute much of this to the space: there were more open spaces for gathering, and I spent less time in long, narrow hallways. Granted, I found it difficult to navigate through some of the winding paths inside the Sheraton Centre, but overall I felt like I could find people I needed to find and bumped into enough people to keep it interesting. I hope I can feel this way again in Chicago in 2009.

I REALLY LEARNED. I have had some doubt about how much of the program would excite me, and I must say that while none of the sessions intrigued me enough to draw me there, I dropped in to a handful of sessions and the presenters welcomed me in and allowed me to participate even though I sometimes tend to try to take over. I learned from those sessions and even more from hallway conversations with my peers. I hadn’t felt like I’d learned much from the last few years, but rather that I’d spent most of my time teaching. This time I found a good balance. I don’t know how much of that to attribute to my mindset, to the program, to the people the conference drew and to random chance. No matter: I love the result. I should thank Arlo Belshee for putting the thought in my head that cost estimates might not always matter much. That one will stick with me for a while, I imagine.

I PUSHED THE ENVELOPE OF EXHAUSTION. I measure the success of a conference experience by my energy level on the last day. When I find myself exhausted, I imagine I rushed too much, committed to too much and wasted too much time getting around. When I find myself lethargic, I imagine I didn’t care much, didn’t see the people I wanted to see, didn’t find much of interest in the program and didn’t learn anything worthwhile. This time, I felt energized at the tipping point of exhaustion. Perfect! In the words of the great Calvin (the modern one), the days were just packed! I kept my schedule fluid and managed never to spend a moment bored. I imagine my fluid schedule make it difficult for other people to co-ordinate with me, so I apologize to my wife and my friends for their difficulties reaching me throughout the week, but I enjoyed it immensely. By the end, I felt ready for week two of the conference, but it abruptly ended. I call that a success.

REVIEW IN A BOX. We stayed at the Hilton across the street, mostly because I forgot to book our room until two weeks ago.

Program	B
Open Jam	B
Location	A
Attendees	A
Amenities	B
Expense	B
Hotel	B
Overall	A-

I had a few minor nits to pick: I didn’t like the breakfast, which featured cost-cutting pastry over energy-boosting protein and berries; I found it difficult to carry around the large program book, so I would have preferred schedule-on-one-page on a day-by-day basis; I have become a coffee snob, so I never like the coffee anywhere, and the Sheraton fit that pattern.

As I like to say, if you have no bigger problems than these, then you deserve a vacation. Thank you to Rachel Davies and her crew for doing an excellent job organizing and running this conference. Good luck to Johanna Rothman, as you have big shoes to fill. I feel confident in the result.

August 12, 2008 03:00 agile 2008

How are you dealing with Homeland Security confiscating electronics?

me@jbrains.ca (J. B. Rainsberger) — Sun, 03 Aug 2008 03:00:00 GMT

As a Canadian consultant with many US-based clients, I enter the US quite frequently, and I now know that I face random seizure of my electronics even without reasonable suspicion. I find it difficult to enter the US under these circumstances with my electronics, notably my computer and phone.

Have you done anything interesting to deal with this problem? I have had to contemplate measures including requiring US clients to provide me with a MacBook Pro when I visit them. Even if I do that, what about my data? How can I guarantee that I have a bootable copy of my hard disk when I cross the border if the TSA can confiscate my external hard disk?

The simplest solution is to stop working in the US until the proposed law on the books requiring reasonable suspicion passes, but even then, I run a considerable risk of having materials seized even though I have nothing to hide. I don’t trust Homeland Security to be reasonable.

Is shipping hard disks any better? I can’t risk having material held up in customs. I can’t rely on internet services, because it takes days to download a 100 GB bootable disk image.

I would like to know what you do about this, aside from refuse to work in the US.

August 03, 2008 03:00

"Dear XP" with new English lyrics

me@jbrains.ca (J. B. Rainsberger) — Wed, 30 Jul 2008 03:00:00 GMT

Kenji Hiranabe asked me to write new English lyrics for the “Dear XP” song, and with his lyrics as a starting point, here is the result:

July 30, 2008 03:00 extreme programming, agile 2008

Any title would be superfluous

me@jbrains.ca (J. B. Rainsberger) — Mon, 28 Jul 2008 03:00:00 GMT

July 28, 2008 03:00

Help us nominate David Chelimsky for the Gordon Pask Award

me@jbrains.ca (J. B. Rainsberger) — Sat, 26 Jul 2008 03:00:00 GMT

Once again, nominating season for the Gordon Pask Award has begun. I have so far put my support behind one excellent candidate, David Chelimsky. The nominating process has changed and we would like to garner some additional support for David. If you are interested, then please click the Discuss link for this article (which takes you to reddit) and write a blurb in the style that the selection committee has asked for. (If you haven’t already, read the link above.)

Thank you for helping us show support for David as a significant contributor to agile practice who is well due the recognition of the Gordon Pask Award.

July 26, 2008 03:00 agile, people, extreme programming

Please nominate someone for the 2008 Gordon Pask Award for contributions to agile practice

me@jbrains.ca (J. B. Rainsberger) — Sat, 26 Jul 2008 03:00:00 GMT

Please nominate someone for the 2008 Gordon Pask Award for contributions to agile practice. Read more.

July 26, 2008 03:00 agile

Your "Discuss" links are broken?

me@jbrains.ca (J. B. Rainsberger) — Thu, 10 Jul 2008 08:56:00 GMT

I could use your help, if you have the patience to help me.

At least one person has reported the “Discuss” links are broken for him. They work for me, whether I read postings on the web or through my RSS reader Net News Wire. If you have trouble with the “Discuss” links, I’d appreciate knowing about them. Please send me email describing the problem so I can diagnose it. Thanks!

July 10, 2008 08:56

If we are serious about speed...

me@jbrains.ca (J. B. Rainsberger) — Mon, 07 Jul 2008 03:00:00 GMT

I have been reading the Cutter IT Journal from March 2003, when they ran a special issue on Critical Chain Project Management. I wanted to share this especially salient point. I don’t know how to help my clients understand this, particularly because my clients usually find themselves behind the eight-ball and in desperate need of this advice.

If we are serious about speed, we must understand what is required for people to “go faster.” We are not asking them to work faster! We are asking them to wait, to rest, and then work at full speed. And then rest again. Our strategy is to remove all the obstacles that cause them delay and to recognize that relay runners don’t run at full speed all day. They are not “fully utilized” because full utilization of resources is inefficient for speed. For our people to do tasks faster, we must reduce their workload and lower their utilization. This is not a sacrifice for the organization, it is the means for substantially greater project throughput. For our people to do tasks faster, we must reduce their workload and lower their utilization.

How do I help them understand? Click the Discuss link to give me your suggestions.

July 07, 2008 03:00 agile, people, extreme programming

Find out where I'm appearing

me@jbrains.ca (J. B. Rainsberger) — Mon, 07 Jul 2008 03:00:00 GMT

To borrow from Garr Reynolds, who has taught me much about presentations:

So if you’d like to know where I plan to appear next, click the link under my photo or subscribe to my appearances calendar:

as an RSS feed
from your iCal-supported calendar
anyway you like with calendar ID @p2j53mga3v3e595bkdhfth0o84@group.calendar.google.com@

Feel free to invite me anywhere with any amount of notice. You never know what we can work out. Be sure to tell me enough about your invitation to pique my interest!

See you on the road, which would be a town near you!

July 07, 2008 03:00 speaking, people, presenting

Agile Adoption Patterns, the book

me@jbrains.ca (J. B. Rainsberger) — Thu, 03 Jul 2008 03:00:00 GMT

I would like to announce the release of Amr Elssamadisy’s book Agile Adoption Patterns on Safari at O’Reilly. Amr invited me to write a foreword, but even if he hadn’t, I would heartily endorse his book.

July 03, 2008 03:00 agile, people, extreme programming

A rare opportunity in September

me@jbrains.ca (J. B. Rainsberger) — Tue, 01 Jul 2008 00:57:40 GMT

Friends, I have been carefully constructing a rather complex travel itinerary for August and September, and one of my prospective clients has gone rather dark on me. As a result, I have ten days of time available that I would like to offer to you at cost. You read that correctly: you can hire me to help your organization between September 1 and September 10 at the unusually low rate of covering reasonable travel costs for Sarah and me. As you might expect, some conditions apply.

I will be in Amsterdam, Netherlands on August 31 and I need to fly to Chicago, USA on September 11, so you could hire me in the period in between for up to 9 days, as I’d prefer to have Monday as slack in our travel schedule.

I would like to work out a fixed travel budget for our travel expenses, rather than submit receipts.

We don’t need a fancy hotel, but prefer someplace with a kitchenette so we can prepare our own meals in the room.

We need to eat well, so we prefer a hotel near a local market or good-quality grocery store with fresh produce that is either less than a 15-minute walk or easy to reach with public transport.

I want fun work, which means a multi-disciplinary opportunity, including all aspects of your software delivery system, from the boardroom to the bullpen.

If prospective client gets back to me by Friday and wants me during this time, then I need to give them priority.

If this interests you, please send email right now to the address in the top-left corner of the page with the subject “Crazy Joe’s September 2008 Consulting Special” or something like that, and I’ll get back to you.

July 01, 2008 00:57 agile, speaking, extreme programming

What I've said so far...

me@jbrains.ca (J. B. Rainsberger) — Wed, 25 Jun 2008 03:00:00 GMT

…courtesy of wordle.net.

June 25, 2008 03:00

On the importance of disciplined software design and the implications of succumbing to poor practice

me@jbrains.ca (J. B. Rainsberger) — Tue, 24 Jun 2008 03:00:00 GMT

Proceed at your own risk.

June 24, 2008 03:00 testing, agile, coding standards, design, extreme programming

Testing the UI: presentation and rendering

me@jbrains.ca (J. B. Rainsberger) — Thu, 19 Jun 2008 03:00:00 GMT

I recently read Jeff Patton’s column at StickyMinds. His latest article tells us the secret to automated acceptance tests. I responded, and I include that response here.

I like this article, Jeff, but I’d like to point out that programmers can automate more tests in advance without risking a ripple effect when a customer wants to move a field around.

We know that many designs exhibit high coupling between “the UI” and “the logic”, and teasing that coupling apart—mostly moving (business) logic out of the UI—is one step towards more flexibility, less ripple effect and more valuable automated end-to-end tests. We have all seen it. I invite programmers to take one more step.

Inside “the UI” I find two major kinds of code: UI toolkit client code and more general toolkit-neutral code. When I format a monetary amount as “$12.50”, I can make that decision without involving the UI toolkit; but when I decide to display the text “$12.50” as a label or in a text field, I need to involve the UI toolkit in that decision. I invite programmers to separate their UI into presentation logic (UI toolkit neutral) and rendering logic (UI toolkit specific). If you do this, you will have an “abstract UI” or “presentation layer” you can test without drawing a real UI. These tests run quickly because they run in memory without having to paint a screen or invoke a UI toolkit component of any kind. You don’t need end-to-end tests here. When someone decides to move a field around, none of your presentation layer tests need to change, and you avoid the ripple effect. Yes, your end-to-end tests change, but over time you’ll automate fewer of those, preferring instead to automate the presentation layer tests.

So programmers, do your worst! Introduce a true presentation layer into your design, starting with the next screen or page. You’ll thank yourself, and maybe me.

June 19, 2008 03:00 testing, agile, refactoring, design, antipatterns, extreme programming

JUnit Recipes coming soon to Safari Online

me@jbrains.ca (J. B. Rainsberger) — Wed, 18 Jun 2008 03:00:00 GMT

I would like to announce that Manning Publications has begun sending its books to Safari Online, the subscription-based O’Reilly service. I have found the service useful over the past three years, particularly after our flood wiped out much of my professional development book collection. If you subscribe to the service, but have not yet read JUnit Recipes, you will soon have your chance!

June 18, 2008 03:00 junit, testing, agile, writing, design, extreme programming

Fixing Mail.app as it pertains to IMAP and gmail

me@jbrains.ca (J. B. Rainsberger) — Wed, 11 Jun 2008 03:00:00 GMT

I am in the process of making gmail my One and Only Mail Database. My first tentative steps showed that gmail filters duplicate emails, which is great, because I have multiple copies of several hundred emails, thanks to POP. Naively, I just started dragging emails from my other Inboxes to my gmail/IMAP/personal mail Inbox and letting the messages synchronize on the gmail server. My goal was to make my other Mail.app accounts empty so I could disable them. This worked well for a while, but for most of today, Mail.app has been telling me this:

Mail has undone actions on some messages
so that you can redo the actions while online.
Mail has saved other messages in mailbox “INBOX”
in “On My Mac” so that you can complete the 
actions while online.  

Additional information: The attempt to read data 
from the server “imap.gmail.com” failed.

I read an article or two and figured I’d overburdened my gmail server and it was scolding me by limiting my access for a while. When about eight hours passed without any change, I knew I had a problem, and that problem was the same email over and over again. Something about embroidery of all things. Each time the message popped up in my “On my Mac” INBOX, I moved it to Trash, then erased deleted messages… nothing worked. Finally, out of desperation, I simply pasted the entire message—you can see it’s quite long—into Google.

Seek and ye shall find.

The advice there, however, didn’t impress me. I might not be a Mail.app developer, but I imagine that if I delete my entire offline cache, I’ll lose all the emails I moved into my gmail/IMAP/personal mail inbox. That would be bad, considering it’s about 10000 messages, many of which matter to me. I thought I should investigate, and fortunately, it wasn’t too hard to figure out what to do.

I went to ~/Library/Mail/IMAP-[myemailaddress]/.OfflineCache and saw about 10000 numbered files. I looked at one of them and saw an email. I figured I could grep to find the offending email, delete it, restart Mail.app, then all would be well. So I did, and so far it is.

To be clear, here is what I did:

$ cd ~/Library/Mail/IMAP-****/.OfflineCache
$ ls
1000		1001		1002		1003		1004		1005		1006		1007		1008		1009
1010		1011		1012		1013		1014		1015		1016		1017		1018		1019
1020		1021		1022		1023		1024		1025		1026		1027		1028		1029
....
$ grep -i embroidery *
[...Matched email 854....]
$ rm 854

That worked great. I hope it helps you, too.

June 11, 2008 03:00 mac, just to be clear

Recommended: Pragmatic Screencasts

me@jbrains.ca (J. B. Rainsberger) — Tue, 10 Jun 2008 03:00:00 GMT

I am writing this from a hotel room in Winnipeg on the way to XP 2008 in Limerick, Ireland. Since I live 400 km (that’s 260 miles for the metric impaired) from Winnipeg and don’t drive, I typically have to endure a 4.5-hour bus ride at the beginning and end of every trip. You can imagine that I need to keep myself occupied during those stretches, which often involves my trusty iPod Touch. I used this trip to watch my first two Pragmatic Screencasts and they impressed me.

I started to watch a screencast on Expression Engine which I hadn’t heard of before, but as I get older I find building web sites less interesting, so I am always looking for ways to simplify the task. When I noticed this screencast I thought it would give me an idea whether Expression Engine would interest me as a web site platform. It does. Worse, I wanted to follow along with Ryan Irelan so much that I had to stop the screencast in frustration because I wasn’t at my computer and connected to the internet. I look forward to returning to that screencast next week, if I can wait that long.

The other screencast that caught my eye was building a chat system in Erlang. I tried reading the Pragmatic book on Erlang, and while that book receives excellent reviews, I just didn’t like it. I found it too abstract and didn’t stick with it. I like the author’s writing style well enough, but it just felt like I was reading the encyclopedia, rather than a tutorial. I needed an example to follow, and the screencast gave me just that. Kevin Smith builds a tiny chat system before your eyes and does so quite well. I found the screencast very engaging, not just because it illustrated the content and helped me finally begin to understand what Erlang is all about, but also because I found myself wanting to argue with Kevin about coding style, which I always enjoy. I look forward to watch the third episode a little later.

The quality of the screencasts is high, the production is good and they are a suitable length. Even on the small screen of an iPod Touch I found them easy to follow. I think that Mike Clark has done a very good job so far on both the vision and execution of these screencasts. I hope to do one or two for them sometime soon. (Hint, hint.)

Go to http://www.pragmatic.tv and enjoy. I think you’ll be very satisfied with the result.

June 10, 2008 03:00 agile, extreme programming, review

Mac OS X: choosing the default currency symbol

me@jbrains.ca (J. B. Rainsberger) — Sat, 07 Jun 2008 03:00:00 GMT

This is just a quick tip for Mac OS X users who might want the symbol “$” to represent their dollar, rather than the US dollar.

I’ve been working on expense reports with Numbers.app and I noticed that my laptop was formatting Canadian and US dollars as “Can$” and “$”, respectively. While I thought this a tad US-centric, that didn’t bother me much, so I gave it no real thought until I opened the same spreadsheet on my Mac Mini, where I saw “$” and “US$” instead. I thought this was neat, except of course that now the columns were the wrong width. I saw the difference, figured there was a difference in the International settings, but no! To quote Swiss chess master Gereben, “wie ist es möglich?!” The settings are the same, and yet one window has “Can$” and the other “$”. There is no “Customize…” button, so I can’t change the number format. What can I do?

I did what any self-respecting programmer would do: I played around with the settings until it worked. I found out that by switching the currency to something else, then back to Canadian Dollar, I reset the number formatting, and now both computers use “$” for real dollars and “US$” for the fake kind.

Now you know.

June 07, 2008 03:00 mac

Death (march) and taxes

me@jbrains.ca (J. B. Rainsberger) — Wed, 04 Jun 2008 12:00:00 GMT

I am late filing my taxes for 2007, which explains why I’m awake at 5.00 this morning. I’m not entirely sure how many consecutive mornings I’ve been waking up earlier and earlier: maybe it’s six, maybe it’s seven. My fingers feel a little heavy, I’ve yawned three times since I opened my computer, and it’s too dark in here to scan paper, so I decided to write these words.

Let me tell you a little about my project: I have to file my taxes. Since I have been audited, I no longer trust myself to file my own corporate taxes, so I’m preparing paperwork for my accountant. My goal is to deliver a DVD of my data and let my accountant and her staff do a first draft of my taxes while we’re at XP 2008. When we return, I’ll be able to answer questions, then I hope to file before June 28 when we have to leave for the next trip. That is the goal, some context and a few constraints, and I think that’s enough for you to understand me.

This, dear friends, is a death march. Here is how I know: I have a pile of things to do long enough that I don’t know how much there is, I don’t know when I will finish, I don’t feel like measuring what I’ve done will help he know how much more time it will take, I have doing this essentially 12-14 hours per day, I have no system for choosing the next task, and I feel like I’m making up the tasks as I go. As a result of all this, I’m in here at 5.16 and I don’t think I’ll leave here until 22.00, and I need to do this until further notice, and until it’s done. And oh yes, I can’t really describe “done” precisely, but I’ll know it when I see it. That all sounds like a death march to me. It’s not a fun place, so how did I get here?

A big part of it is fear: I am at the tail end of an audit for the four preceding years, and I don’t think I’ve ever felt so much stress in my life. I dealt with my father’s alcoholic rages better than I’ve dealt with this audit. I have coped (if you can call it that) mostly by withdrawing from life in general and certainly avoiding anything that looks like financial record-keeping. Of course, I’ve also spent a lot of time blaming myself for being such a poor accountant, even though my last bit of real accounting training was 1991 in high school. I’ve been afraid to deal with the audit, and terrified to keep records carefully since about October 2007 or so, and my year end is October 2007. As a result of this fear I have delayed tackling my current taxes, wanting to focus my accountant and tax lawyer on the audit. Only now that the audit is mostly settled have I turned my attention back to the present.

Another part is incompetence: in 2002 I walked away from my first accountant because I started a full-time job and let my company hibernate indefinitely. On that basis I couldn’t justify the expense of an accountant. As a result, I hired myself as accountant by default, and while the job wasn’t very demanding in 2003, I left my full-time job that year to write JUnit Recipes, which led me to more of the work I’d wanted to do as an independent, then I started XP Day North America, which introduced me to my current business partner, … you can see where that’s headed: more money, more records to keep, more taxes to pay, and more financial information to get wrong. It’s that incompetence that directly led to the audit and ignorance of a good filing system that has led to the long string of files of paperwork I need to process here. If I were any good at this, not only could I file my taxes sooner, but I probably wouldn’t have been audited in the first place, and even if I had I would have been confident enough to handle it well.

As you can see, incompetence and fear play a big role, and not that my incompetence—at least as far as it has hurt me in this context—has mostly to do with something I was never trained properly to do! It’s worth arguing that if I’d hired someone to do it, I’d be in better shape, and that that is the truly incompetent part. I grant that, but part of the reason I didn’t hire anyone is that I was too ignorant to see that I needed to do it, then once I realized I needed someone, too ashamed of the mistakes I’d made to let anyone look at them. Fear, incompetence, shame… I’m doing really well so far.

Finally, there are the tangible effects of my fear, incompetence and shame. The audit has contributed to my sinking into a fairly deep depression (and no, not just sadness, believe me), the result of which has been many days spent in bed, rather than taking care of these matters. Every day I went to bed thinking, Tomorrow I’ll get up, start working on my financial records, and within a couple of weeks, I’ll have organized everything, and every morning the first big thought in my head was, Not today! As a result of this, not only were my 2007 records remaining disorganized, but my incoming paperwork began to create a serious backlog. Even more, I wasn’t separating the 2007 material from the 2008 material, which is one of the reasons my current work is going so slowly: I first have to figure out whether I need to handle a piece of paper before I handle it. Such waste!

In addition, as you might expect, I am ignoring my other responsibilities in the name of Getting This Done, but when an urgent request comes up, it completely ruins my flow. My business partner needed me to pay him for some long-outstanding invoices. Nothing huge, but big enough to matter, and because the invoices were months old, I had to wade through old reports, old receipts, and so on, in order to help him. What should have taken 45 minutes took over 3.5 hours and knocked me completely off my rhythm. (I did manage to track down the cause of a $107 credit I had in my books, though: it turns out the credit was my mistake. Big surprise.) Yesterday, after paying him (but not for everything, because I’m just not that well organized) I had to stop working, even though it was only 17.30, because my mind simply folded up its tent and left. I couldn’t concentrate at all. I managed to go grocery shopping, but even that manifested this death march: we usually shop every 2-3 days and carry home 2-4 bags of groceries. Sometimes those bags are pretty heavy, but usually they aren’t. This time, even though we were leaving the country in 5 days, we carried 5 bags home—after buying another bag at the store—and just barely. I don’t know about Sarah’s, but my bags were heavy! I was struck by how my work problems were affecting my home life. About the only benefit of staying in my office is that I’ve mostly avoided working around the contractors finishing up the main floor in our house.

So it’s now 5.37 and the sky is brightening despite the rain. Pretty soon I’ll be able to see enough that I can’t justify not scanning papers and organizing them. I don’t know how much I’ll get done, nor how far along the project that represents, nor when it will be done, nor how to pace myself to finish it. I don’t yet know whether I’ll be late and delay my taxes an extra 1-2 weeks as a result, not to mention having this waiting for me when we return from Ireland. I don’t know much about this project, but I’m busting my ass on it, and that is what makes it a death march.

The foregoing is a true story. The names have not been changed. The events are real. I hope you feel a little compassion and even pity for me, even though this is a situation largely of my own creation. I have a question: do you think the causes of your last (or current!) death march are much different? Do you feel compassion and even pity for the people who landed you there?

June 04, 2008 12:00 people, article, emotional health

The perfect item for your team room...

me@jbrains.ca (J. B. Rainsberger) — Tue, 03 Jun 2008 03:00:00 GMT

…if your project is a death march.

June 03, 2008 03:00 agile, people, planning

You're invited! "Test-Driven Enterprise Code" at XP 2008

me@jbrains.ca (J. B. Rainsberger) — Sun, 01 Jun 2008 03:00:00 GMT

Allow me to invite you to XP 2008 in Limerick, Ireland on June 11, 2008 at 2 PM local time to join me for Test-Driven Enterprise Code, my long-running tutorial aimed at programmers who want to practise test-driven development in the complicated world of platforms, frameworks, libraries, and more. Stay tuned to this channel for presentation slides, and possibly more.

June 01, 2008 03:00 java, junit, testing, agile, presenting, refactoring, design, extreme programming, xp2008

Rescuing disk space from Parallels

me@jbrains.ca (J. B. Rainsberger) — Fri, 30 May 2008 03:00:00 GMT

I use Parallels to run Windows under my MacBook Pro which has a 93 GiB hard disk. Since I also live a flight away from the nearest authorized Apple reseller, I find it difficult to buy a new hard disk whenever I need one. These reasons form the constraints under which I spent much of a recent afternoon reclaiming disk space, rather than focusing on real work. Since I have more than a neophyte’s, but less than an expert’s, knowledge of UNIX, I needed to look up the command to show me how to ask UNIX how much disk space folders used. I invoked this command

$ du -h -d 1

This command tells me how much space each immediate folder (-d 1 means “depth of one”) takes up in human-readable (-h) form. This gave me a report like the following

....other folders....
 24M	./Applications
 24K	./bin
7.3M	./Desktop
2.5G	./Documents
....yet other folders....

Since I want to focus on the really big folders, I looked for a way to do that. I decided to grep for a “G” in the fourth position.

mel:~ jbrains$ du -d 1 -h | grep ^...G.*$
2.5G	./Documents
 20G	./Library
1.0G	./Movies
5.8G	./Music
3.3G	./Pictures
3.3G	./Workspaces
 36G	.

Since I plan to use this command frequently, I added it to ~/.profile

alias find_big_folders="du -d 1 -h | grep ^...G.*$"

I found that Library took up the most space, and within it Parallels took up over 20 GiB on its own. I searched the web and learned that Parallels has a “Compressor Tool” that compresses hard disk images, but when I tried to use it, it failed, telling me I had snapshots or had enabled “disk undo”. Since neither condition held true, I searched further and saw that Parallels has a long-standing defect (back to July 2007 at least) that causes this problem. Fortunately, the same search gave me a solution: MakeVM.

MakeVM creates disk images for Parallels and VMWare, and although it cost USD 19.99, it appeared to solve my problem, so I decided to try it. I installed it on the Windows XP image running under Parallels and found the “Custom Clone” feature ridiculously easy to use. Since I had no experience with this tool and wanted to recover from each step, I did the following

Back up my entire Parallels virtual machine image by tar-ing it to an external disk.
Back up my second Parallels hard disk image (disk2.hdd).
Choose “Custom Clone” under MakeVM to clone my second hard drive (not the “Virtual Hard Disk” feature, which wants to clone a hard disk image), writing the clone to my external hard disk, since I had little space on the internal disk. When asked whether I wanted to compact the cloned disk, I naturally chose “yes”.
Shut down my virtual Windows XP.
Edit the Windows XP virtual machine settings, removing the existing “Hard Disk 2” image and adding the newly-cloned disk image as “Hard Disk 2”. Windows XP should treat these disks as identical.
Start my virtual Windows XP and judge the results. Although I had to re-install Java to make Eclipse work, everything else appeared all right.
Shut down my virtual Windows XP.
Remove the old Hard Disk 2 image from my internal disk and copy the newly-cloned Hard Disk 2 image to my internal disk, updating the virtual machine preferences accordingly.
Back up my entire Windows XP virtual machine image again, repeating the rest of the process for Hard Disk 1.

This entire process took about a half day, so it helped that I had another computer in the room on which to continue working. Once I completed the process, my Windows XP virtual machine image folder reduced in size from about 22 GiB to its current 9.2 GiB. That rectified my disk space problems. I now have over 16 GiB of breathing room, which means I don’t have to upgrade my hard disk, but rather I can wait to upgrade my entire machine. That makes me happy.

If you have disk space problems, or even if you simply want to save disk space, and you run Parallels or VMWare, I recommend MakeVM to safely compact your disk images. I found it well worth the USD 19.99 I paid for it. If this helps you, then please use the “Discuss” link below to comment.

May 30, 2008 03:00 mac

A reason for a relative lack of congruence in the world

me@jbrains.ca (J. B. Rainsberger) — Thu, 29 May 2008 16:07:00 GMT

Just a little something to think about…

From a writer’s point of view, congruent interactions aren’t very dramatic; people just act sensibly, are considerate of one another, get their work done, and enjoy what they’re doing. That kind of behavior might not make as good a soap opera scene as your manager throwing a tantrum and you cringing in the corner, but it definitely makes a better project.

From Jerry Weinberg, Beyond Blaming.

May 29, 2008 16:07 people

Mercurial, Python, Mac OS X and duplication

me@jbrains.ca (J. B. Rainsberger) — Thu, 29 May 2008 03:00:00 GMT

As you all know, I’m not a fan of duplication. When we duplicate code we create safe, warm places for defects to hide. The more we duplicate, the more things go wrong, the harder they are to debug and, most importantly, the more we need to know in order to find the root cause of the problem. (In particular, we need to know we’ve duplicated something and where it is duplicated.) Just to emphasize that this is not some arcane theoretical notion about programming, allow me to share with you an adventurous half-hour I just spent trying to get mercurial (or hg, if you like) to play nicely between my MacBook Pro and my Mac Mini.

I have a working copy of a Mercurial forest in the same place on two different computers, one is my MacBook Pro and the other is my Mac Mini. When I have to do book-keeping work, I often use the laptop for handling paper and my desktop for running QuickBooks. This helps me avoid overworking either computer and that slowing me down. At least, this is my intent.

Since I’m using hg, by its nature a decentralized version control system, I have to be sure to keep my two working copies synchronized. This means periodic push operations from the laptop to the desktop or pull operations to the desktop from the laptop, depending on which keyboard happens to be in front of me at the moment. Since push from here to there and pull from here to there are essentially the same operation, it stands to reason that I should be able to do either one equally well.

I could push from the laptop, but not pull from the desktop. I was getting this error:

hobbes:Operations jbrains$ hg incoming ssh://mel.local/Workspaces/DiasparSoftwareServices/Operations
remote: Traceback (most recent call last):
remote:   File "/usr/local/bin/hg", line 11, in <module>
remote:     from mercurial import demandimport; demandimport.enable()
remote: ImportError: No module named mercurial
abort: no suitable response from remote hg!

After some searching, I came across an article that suggested I had an ssh problem, and since I hadn’t swapped keys from the desktop to the laptop yet, I did that, hoping it would magically solve the problem. It did not. It saved me typing my password for each pull or incoming operation, but what other value it has, I don’t know. I had to search on.

After a few more minutes, I found this article, which suggested to me that my PYTHONPATH or PATH was wrong. I compared the environment variables on both computers and that wasn’t the problem. I compared the locations of Mercurial on both computers with a quick which hg and they were the same. I was beginning to think that I just didn’t know enough about installing Python packages to make this work, but then I asked each computer to locate mercurial.

Aha!

The laptop answered /usr/local/lib/python2.5/site-packages and the desktop answered /Library/Python/2.5/site-packages and there it is: the two environments expect Python packages in different places. I bet some symbolic links will do the trick.

On the desktop, I did this:

/usr/local/lib jbrains$ sudo ln -s /Library/Python/2.5 python2.5

Now when someone looks for Python packages in the usual UNIX place (/usr/local/lib/python2.5), the file system points them to the usual Mac OS place (/Library/Python/2.5@). I’m not thrilled about two different conventions, but as long as I can make one be like the other, it’s all good.

On the laptop, however, I found a defect as a result of duplication. I found Python libraries both in /usr/local/lib/python2.5 and in /Library/Python/2.5. It’s a wonder anything Python works correctly in that environment. This is the defect I fixed today. I moved the Python libraries into the usual Mac OS place (/Library/Python/2.5) before adding the same symbolic link that I’d added on the desktop.

And yes, folks, now it all just works. Mostly because now there’s only one place for Python libraries to live on each computer.

If you remove duplication, you don’t just improve the design, but you remove places defects can hide.

May 29, 2008 03:00 agile, mac, design, extreme programming

If you defer the decision long enough...

me@jbrains.ca (J. B. Rainsberger) — Wed, 07 May 2008 05:39:00 GMT

…then someone might implement the feature for you. In surfing around, I recently found out about creating “subreddits”, which are subdomains of reddit.com. I learned this when I saw Joel Spolsky’s weblog had a “Discuss” link that submitted the item to joel.reddit.com instead of hosting comments on his own weblog. I think this is a good idea, so you’ll notice that I’ve done the same here. This is especially helpful, given that in order to add comments to this weblog, I either have to build the feature myself or migrate my content to TextPattern or one of its ilk.

The next time someone insists you need a doubtful feature, ask them to choose something more important first. By the time you get to the doubtful feature, you might have discovered that someone’s built it for you!

May 07, 2008 05:39 agile

The post-iteration demo: practice or anti-pattern?

me@jbrains.ca (J. B. Rainsberger) — Wed, 30 Apr 2008 15:36:05 GMT

The standard, universal data processing answer is “it depends”. Specifically, it depends on the ongoing participation of your stakeholders.

If the development team is demonstrating the application at the end of the iteration to the stakeholders, then that’s an anti-pattern. If you’re not getting any constructive criticism from the stakeholders about the demonstration, then the stakeholders are likely not engaged by the demonstration, and it’s a waste of time. If your stakeholders are engaged, then they’re likely giving a sizable amount of constructive criticism, the result of which is re-working a substantial number of stories in the next iteration. Of course, you could just be that good, but I haven’t met that team yet.

The last time I worked with a team in this situation, they held demonstrations once per iteration, which for them meant every two weeks. They expressed to me that they were not getting feedback soon enough, so I asked them whether they thought weekly demonstrations would work better. They did, they asked the stakeholders to make at least two people available every Friday afternoon, and that worked. After a while, they added a Wednesday morning demonstration just before lunch. The next step would be daily demonstrations, then finally continuous stakeholder participation. The secret was to sneak up on the daily demonstrations.

Rather than ask your stakeholder to go from hands-off to daily meetings, hold demonstrations once per iteration. When they point out how much feedback causes rework, suggest having a mid-iteration demonstration to avoid so much rework. You might be able to fix a small problem or two right in front of the stakeholders, and if you can, then do. (It looks impressive.) Once you’ve established that you can fix some problems without putting the stakeholders to sleep, they’re more likely to want to work directly with you. Each time they notice a demonstration leads to substantial rework, suggest doubling the frequency of the demonstrations. Eventually you’ll arrive at the right amount of stakeholder participation for your project. The key is to let your stakeholders notice the problem of not enough feedback, because if it’s their problem, they might look for solutions, but if it’s your problem, they’re less likely to care. If they can’t see it’s their problem, then look for subtle, non-destructive ways to make it their problem.

My goal is for a key stakeholder and the development team to demonstrate the product together to any and all interested parties. This is an important step towards the whole team approach to building software that I find so incredibly effective.

April 30, 2008 15:36 agile, people, antipatterns, article, extreme programming

When you're the bottleneck...

me@jbrains.ca (J. B. Rainsberger) — Mon, 28 Apr 2008 15:22:13 GMT

I remember being a technical lead, believing that it was my job to make sure everything was doing correctly and as quickly as possible. The result was predictable: I made myself a bottleneck because I was afraid to delegate important tasks to other people, for fear that they’d do it poorly and have to redo it, or even simply because it would take me less time to do it than to explain to someone else how to do it. I know now that letting myself be a bottleneck is a bad idea, but I wasn’t able to explain why very well until just a moment ago when a long-awaited neural connection finally happened. I almost felt the crackle in my brain at the point of impact.

Tim Ottinger wrote about Sooner, Not Faster, which I describe to people frequently in my work as a consultant. My goal in teaching test-driven development is not to help programmers write code more quickly, but rather to help them deliver solid code sooner. The time-saving techniques include being clear about what to build before trying to build it (write a failing test first), building only what you need (write just enough code to pass the test), stopping when you’ve built enough (continue until you can’t think of more failing tests to write), and keeping the code clean as you go to avoid building up inventory of uncompleted necessary work (“clean the kitchen” refactoring). Not all these techniques involve thinking or typing more quickly. Some involve thinking more to type less and knowing what’s enough then stopping. In general, I help teams by focusing on how to deliver a satisfactory result sooner, no matter how fast or slow the individual tasks are completed.

Now I wish I’d thought that way as a technical lead. If I have a backlog of 10 tasks that take a total of 4 weeks to complete, but I could delegate some of those tasks to others, then even if they take 5 times as long as I do to complete those tasks, I could delegate any task up to 3 days in length and, as a group, we could be done in 3 weeks, even if we spend more total time working. The alternative is to keep those tasks for myself, then have the others do busywork to avoid looking idle. You might think this is a false alternative, but how many people on your team are working on its top three priorities, and how many are working on other things? The other things are busywork!

Had I thought this way, I could have benefited dramatically. More important work would have been completed, I’d have learned how to delegate effectively, and I would have felt (and probably now feel) less stress.

If only.

April 28, 2008 15:22 agile, people, article

New review of JUnit Recipes

me@jbrains.ca (J. B. Rainsberger) — Sun, 20 Apr 2008 16:05:04 GMT

It’s nice to see that nearly five years after I started writing JUnit Recipes, people continue to read and review it. I imagined it would have become obsolete by now, especially with the proliferation of Java 5, Java 6 and JUnit 4.

The review ends with “If you use JUnit as your test tool and if you do any of the ‘things’ covered in the contents list of recipes then I recommend getting hold of this book.” I appreciate it.

April 20, 2008 16:05 java, junit, testing, agile, review

Quick guideline for using experimentation as an aid for decision making

me@jbrains.ca (J. B. Rainsberger) — Sun, 20 Apr 2008 15:57:33 GMT

An anonymous person at blog.isnotworking.com whose name I could not find on the site has written a short piece on helping teams avoid getting stuck arguing over different solutions to a given problem. It was inspired by my November/December 2007 article in IEEE Software Magazine.

http://blog.isnotworking.com/2008/03/quick-guideline-for-using.html

April 20, 2008 15:57 people

Five Mistakes New Agile Teams Make

me@jbrains.ca (J. B. Rainsberger) — Tue, 01 Apr 2008 16:52:44 GMT

I recently had the honor of speaking at the Emerging Technologies for the Enterprise Conference, where I renewed some friendships, made some new acquaintances, and spoke about something I enjoy: failures.

Last summer I debuted XP: My Greatest Misses 2000-2007, which became popular due to its honesty and directness. (See an example of the response to it.) I followed this theme of reflecting on failures to gather some mistakes I have seen people make as they make the transition from work group in chaos to agile team. It’s important to note that I didn’t talk about the five biggest mistakes, the five most common, nor the five most dangerous; but rather, simply about five mistakes that came to my head. As you’d expect, once I’d written my five in the notes, I found a number more, especially as I sat in my fellow presenters’ sessions. Even when they weren’t describing mistakes at all, they triggered a number of memories—so many that I could easily have written the 20 mistakes new agile teams make.

Please enjoy Five Mistakes New Agile Teams Make, and if you’d like me to visit your user group, please contact me at the prominently-displayed e-mail address on this site. You should also consider contacting the Agile Alliance to find out how to qualify for funding to bring out-of-town speakers to your user group or event.

April 01, 2008 16:52 agile, speaking, people, article

A clear violation of the Single Responsibility Principle

me@jbrains.ca (J. B. Rainsberger) — Mon, 25 Feb 2008 22:27:12 GMT

(From XKCD)

Should a class be a factory for itself?

February 25, 2008 22:27

McCabe Complexity and Design

me@jbrains.ca (J. B. Rainsberger) — Mon, 11 Feb 2008 19:44:04 GMT

Another in the Enerjy TV series. This time, the question is “How do you believe McCabe Complexity helps programmers?”

February 11, 2008 19:44 testing, agile, coding standards, refactoring, design, extreme programming

Is excellent design "too Eastern" for us?

me@jbrains.ca (J. B. Rainsberger) — Thu, 17 Jan 2008 01:00:41 GMT

I have spent the last two days with Mary and Tom Poppendieck at one of their Practitioners Courses, and I find myself inspired. Among the interesting moments for me was a point at which I reached an unsettling notion: are we “too Western” to design software well?

I came to this question while watching course attendees talk about the problems in their organization. As they explored the flow of value through their IT organizations, I kept hearing about managers interrupting the flow and of centralized decision-makers as bottlenecks, when it occurred to me: I’ve heard about these problems in code before.

Specifically, I heard the word “manager” and my mind wandered towards thinking of Manager classes in a code base, rather than flesh-and-blood managers. In that wandering instant I saw a connection between the two kinds of managers: human managers have mostly commonly been trained over the last century to micro-manage, make important decisions and direct their people; and Manager classes do essentially the same thing in code. Now, while our ideas of management have changed in the past 50 years, mostly due to the work coming out of Toyota, we are still over-run by micro-managers whose effectiveness is limited.

It’s quite similar with code. In spite of the object-oriented design movement and the advance of test-driven development with its emphasis on simple design, procedural thinking dominates, even in code bases that use object-oriented languages. Most programmers approach code with Procedural Mind, even when they believe they want to design with objects. Even when I teach people how their can arrive at excellent designs by following four simple rules, Procedural Mind dominates.

So I wonder: given the parallels between tactical, command-and-control management and highly procedural code where important decisions are centralized in these Manager classes, and given that our most common human management style is a relic of western military thinking, and given that it perpetuates in part due to culturally-entrenched ideas about managing people, are Western programmers conditioned against excellent design? Are we mostly doomed to gather our code in Manager classes, rather than distribute responsibilities evenly and focus on object interaction?

Are those notions simply too Eastern for us?

January 17, 2008 01:00 agile, people, coding standards, refactoring, design, antipatterns, extreme programming, personality types

Backpack helps me change my habits

me@jbrains.ca (J. B. Rainsberger) — Fri, 04 Jan 2008 17:22:41 GMT

I use Backpack to help me change my habits for the better, and I wanted to share this little technique with you.

The programmer in me values version control systems because they allow me to keep an indefinite record of what I’ve done. If something goes wrong while I’m working, then I can go back to an old version of a file and continue working. This is why I use Mercurial every day.

The entrepreneur in me values off-site backups because if a fire destroys my office, then all I need is any computer and an internet connection and I can get back to work. This is why I use Amazon S3 every day.

The scanner in me values getting things done, because when commitments start to sneak up on me, I have my commitments, actions and priorities in one place, and I can get back on track. This is why I use OmniFocus every day.

What I’ve noticed, though, is that my tasks aren’t really getting done. For me, most tasks require building or changing some key assets. Sometimes that’s code, or expense receipts, or drafts of an article. It’s not good enough to write the article, I want to put it into version control and know it’s backed up off site. It’s natural for me to end a coding session by committing changes to Mercurial, but it’s not yet natural for me to end a non-coding work session the same way. I need to remind myself to do this.

Whenever I hear myself think or say, “I need to remind myself…” I immediately log in to Backpack, because it does such a great job of reminding me of things. Today, I added a reminder that reads

A task isn’t done until the assets are safe: under version control and backed up

I set the reminder for tomorrow, and every day after that, until the idea is burned into my brain and becomes second nature. I’m not sure how long that’ll take, but by this time next month, I should be able to switch that reminder to every month, just to make sure it doesn’t fall completely off my radar.

This is how Backpack helps me move away from bad habits and move towards better habits.

January 04, 2008 17:22 people, planning, being a scanner, emotional health

Forget velocity

me@jbrains.ca (J. B. Rainsberger) — Thu, 03 Jan 2008 00:08:56 GMT

What does velocity measure?

First, let’s be clear: by velocity, I mean story points delivered per iteration over time. Of course, that means we need more definitions, so let me get those out of the way now.

“A story point” is a unit that programmers invent solely to make it easier to estimate the work it takes to deliver a story. A story point is however big the programmers decide it is, no more, and no less. Story points are useful to the extent that they help programmers compare the effort required to deliver different stories, so that the team can decide how many stories to commit to delivering in a given iteration. Although story points necessarily fluctuate in value, one hopes that over a sufficiently short span of time – say the length of a release – the fluctuation is small enough that a constant approximation of velocity is helpful enough to plan the release.

“Delivered” means realizing (in the accounting sense) the value the customer intended to realize by asking the team to work on the story. A story is not delivered until it either reduces cost or generates revenue.

“Iteration” means equal-length time boxes the goal of which is to provide natural breaks in daily work to reconsider the plan and stop work from expanding indefinitely. On teams that have less trouble stopping when they’ve done enough, iterations are less important.

“Over time” refers to the trend of spot measurements over at least the length of a release.

I hope that makes it crystal clear what I mean by velocity. Now that I’ve clarified the meaning of velocity, what does it measure? It simply aggregates past estimates of effort of a set of stories the team selected to complete in the last several iterations. That doesn’t sound like much, does it? There’s more. Here are some things that velocity does not measure:

productivity
efficiency
value
suitability to re-hire or retain

…and, of course, past performance does not guarantee future results. Read your prospectus before investing. If velocity is so meaningless, then why measure it? Well, it turns out that:

It is a good approximation (accurate about 2 times in 3, we think) of what the team can commit to in the next iteration
It is a good approximation (we think) of what the team can commit to over the next handful of iterations (say 4-6)
It is a good approximation of when the current stack of work we’ve identified will be done, as long as the stack of work isn’t too large (up to about 4-6 iterations’ worth)

I have just witnessed a conversation on the extremeprogramming Yahoo! group that illustrates the knots in which we tie ourselves when we allow ourselves to be too imprecise about what a measurement measures. The whole thing puts me in mind of personal financing and when budgets don’t work.

Think about budgeting your expenses at home: you know how much you actually pay for some expenses, like car payments, mortgage or rent, insurance… the amounts you owe are usually spread out over such a long period that you can anticipate what you’ll owe next month with certainty. Moreover, you know that it takes concerted effort on someone’s part, or human error, to change the amount you owe on a mortgage, car loan or your home insurance. Changes in those amounts, at least correct ones, generally don’t sneak up on you.

There are other expenses that vary from month to month: food, clothing, entertainment, communications… the amounts you owe usually depend on how much of a given resource you consume, such as how much you eat, how much you talk on the phone and how stressful your work is that month. You can budget these amounts fairly accurately, because the variation is low enough and mostly under your control: you can choose to eat less, take better care of your clothes, read more library books and rent fewer movies. Not only is it easier to guess what you’ll spend in a given month, but if you start spending too much, you can easily correct course to spend less.

There are still other expenses that you just can’t foresee. You are injured in an accident and rack up $20k in hospital bills; this is the year out of the last ten that you finally need new shingles on the roof; you find out your son needs braces. You might buy insurance as a way of smoothing out the costs over time, but they are generally big expenses that you know are coming in the larger sense, but which arrives without warning and needs to be paid immediately.

These are the expenses that make budgeting not work, because they prove that there’s no such thing as a typical month. This is also why you cannot rely on velocity to plan far ahead: there is no such thing as a typical project or even a typical iteration. If velocity doesn’t bring a project under control, then what might? For an answer, I invite you to consider personal finance again.

I read Your Money or Your Life to help me bring my personal finances under control and become financially free. One of the key exercises the book asked me to perform was to track all money coming in and out of our household for several months. This exercise is designed to call attention to our spending habits, so we can decide what to do about them. In particular, we identified those expenses we valued and those we didn’t value, so we could stop spending money on things we don’t value. This tactic, spending money only on things we value, doesn’t necessarily make one rich, but it ensures that one is not wasting money on things one doesn’t actually value. You’d be surprised how much money we were throwing away on things that didn’t ultimately make our lives any better, and you’d be amazed at the results when we stopped: we used that money as capital to generate passive income, and within five years, we’ve become financially free. But I digress. The point is what we measured, then how we analyzed it.

We measured actual spending, rather than estimated future spending or even estimated past spending. When we had the numbers, we didn’t start slashing expenses we cared about, and we didn’t start looking for cheaper alternatives to all our expenditures. Instead, we simply looked for those expenses we did not value, then cut them off. In some cases, this required investment of money: we bought a coffee grinder, an AeroPress, then started brewing coffee at home, rather than spending $2 per on coffee at our local coffee shop. In some cases, this required investment of time: we reviewed our work commitments and changed the way we work so that we wouldn’t be so tired so often, which meant we no longer “needed” to order dinner in as often as we did. We measured our actual spending, we looked at those numbers to identify waste, then we eliminated it. We did not waste effort staring at our budget, wondering how accurate it was, wondering how realistic it was, desperately trying to spread not enough money over too many expenses. We didn’t have to: we had actual expense numbers and could decide which items we valued and which we didn’t. More to the point, this exercise was far more instructive and effective than budgeting ever was.

Does your company value the areas where your software team spends its money? Do you know how to measure the value of what your team produces? How much money (time, energy, or actual cash) does your team spend on things no-one values? Could you pick three such wastes and eliminate them? What would you do with the recovered time, energy, or cash? How would you know that things got any better?

Forget velocity for the time being. Measure it and report it to whoever still wants it, but just between you and me, forget velocity and focus on these key questions. Try it for a few months. Share with us what happens. I’d love to hear from you.

January 03, 2008 00:08 agile, stories, people, planning, antipatterns, article, extreme programming, emotional health

Happy New Year

me@jbrains.ca (J. B. Rainsberger) — Wed, 02 Jan 2008 03:33:27 GMT

describe "Year 2008" do
    it "should be happy" do
        Date.new(2008, 1, 1).year.should be_happy
    end
end

Best wishes to all my readers for a happy 2008!

January 02, 2008 03:33 ruby, people, adventures in RSpec, emotional health

Stub your worries away

me@jbrains.ca (J. B. Rainsberger) — Sun, 30 Dec 2007 22:37:25 GMT

I recently came across this question on the testdrivendevelopment Yahoo! group.

Hi everyone,

I’d like some advice/opinions on how to test some existing code. It’s a web
application using Spring and struts.

I have a class called the ProcessedFilesManager which contains a number of
methods used by Struts Action classes. This manager communicates with five
different DAOs to get the information that some of the Struts actions are
interested in. Now, I want to test this manager class
(ProcessedFilesManager). The way I’ve started doing it is stubbing up each
of the five DAOs, however, this is proving to be quite painful. I didn’t
want to use a mocking approach, nor did I want to use a DB solution like
Hypersonic, but now I’m open to suggestions.

Seeing as there a number of approaches I could use, what do you think would
be best for this situation?

It feels wrong to stub the DAOs because what if I’m introducing behaviour in
there that differs from the actual DAOs? My tests will not be accurate.

Any advice/comments would be much appreciated.

Read the thread

I used to have this fear, and I do something now that has eliminated that fear.

When I stub a DAO method, I make an assumption about what that DAO method does. I used to be worried about making the wrong assumption, but now I have a contract test for the DAO interface that tests for the assumption I’m making in my Service test. The contract test gives me confidence that any implementation of the DAO method passes the same tests, so every implementation of that DAO method behaves the way I assume it does. Once I have this, I feel comfortable stubbing that DAO method that way in a Service test.

A contract test is a test for an interface. I describe contract tests in some detail in JUnit Recipes, recipe 2.6, although back then I called them “abstract test cases” because I hadn’t yet discovered the better name “contract test”. If you prefer, I’ve provided a diagram showing some contract tests for a typical DAO class.

Since classes inherit methods from their superclasses, the Hibernate Customer DAO Test will inherit the contract tests from its superclass, as will the JDBC Customer DAO Test. This means that each implementation has to pass not only its own tests (like testClosesSession() or testClosesResultSet()) but also the tests inherited from Customer DAO Contract Test Template. (I call it a “template” because it plays the role of template in the Template Method design pattern.) When you test-drive a new implementation of Customer DAO, simply make the new test extend the contract test template and you’ll automatically inherit its contract tests. This way, I have confidence that any implementation of Customer DAO behaves the way I’d expect any Customer DAO to behave.

Returning to our example, these contract tests give me confidence to stub the DAO when I test-drive the Service, and that confidence brings with it a happy side effect. I am confident that findAllWithPendingOrders() only returns customers with pending orders, so I don’t have to worry about that issue at all when I design the Service that reports all customers with pending orders. Now that I notice it, Report All Customers With Pending Orders Service is really just a Report on Customers Service that needs a Customer Filter, which could be a Pending Orders Customer Filter. I don’t think I would have felt comfortable with this level of generalization if I weren’t so confident in the way I’ve separated the responsibilities.

The next time you want to avoid stubbing a method because you’re worried you’ll make a wrong assumption about what the method does, try writing enough contract tests to give you the confidence you need. I think you’ll like the results.

December 30, 2007 22:37 java, junit, testing, agile, coding standards, design, article, extreme programming

Interested in what interests me?

me@jbrains.ca (J. B. Rainsberger) — Sun, 30 Dec 2007 20:57:04 GMT

I’m starting to tag more stuff with del.icio.us, so if you think you might find interesting what I find interesting, then add http://del.icio.us/rss/jbrains762 to your favorite RSS feed reader.

December 30, 2007 20:57

Why are companies slow to adopt metrics programs?

me@jbrains.ca (J. B. Rainsberger) — Sun, 30 Dec 2007 18:34:09 GMT

Another in the series of videos from Enerjy in which my fellow conference speakers and I answered the question, “Why are companies slow to adopt metrics programs?”

December 30, 2007 18:34 agile, speaking, people, antipatterns, extreme programming

Which agile practice most benefits programmers?

me@jbrains.ca (J. B. Rainsberger) — Sat, 29 Dec 2007 00:13:14 GMT

Thanks to Richard Sharpe for interviewing me at Agile Development Practices Conference 2007 in Orlando, Florida. This is the first in a series of short videos about agile software practice.

December 29, 2007 00:13 agile, people, extreme programming

"Agile People Still Don't Get It"?

me@jbrains.ca (J. B. Rainsberger) — Fri, 28 Dec 2007 14:59:45 GMT

I ran across Cédric Beust’s article Agile People Still Don’t Get It again, and I just wanted to point one little thing out for you, for him, for everyone. He writes about a presentation he attended that illustrated why agile people still don’t get it:

One of the first slides that deeply troubled me claimed the following: Tests are (executable) specs; (and) If it’s not testable, it’s useless.

Cédric went on to show a number of examples of algorithms that aren’t worth test-driving and useful code that isn’t testable. All very good, all understood, all makes sense; but all in his acerbic, off-putting style.

Cédric, I love you like a brother, but this Bileblog nonsense is wearing thin. We’re not 21 any more; and it’s time to reach a wider audience of more thoughtful people through sensible and reasonable discourse. I’m afraid that, in this case, your conclusion does not at all follow from the hypothesis.

It’s true that there is a steady supply of agile evangelists out there that push agile like a religion, but not only is none of this is news, but it’s a natural part of the evolution of any idea. I went through my proselytizing phase. It was at a time when my primary concern was getting to practice agile, and I thought that if more people liked it, more people would give me the chance to practice it. Instead, I started taking myself more seriously as a business person, made more money, and that has translated to more free time to practice whatever I want to practice. This allowed me to feel more secure about my own agile practice and my own effectiveness as both a practitioner and consultant. Not everyone takes the lead in their careers like I did, so when you see someone lashing out, proselytizing, don’t hate them, but help them. There’s something missing in their lives, and it’s worth offering them a chance to find out what it is and fill the void. People did that for me, and I’m willing to do that for others. Are you?

On the question of the agile religion, you might think Bob Martin is one of the High Priests of Agile, but as early as 2002 (!) he warned us about this behavior, and I take away two key points from his message. I believe it was at a dinner talk at XP/Agile Universe 2002 that he invited us not to make absolute statements about agile.

Those absolute statements served us well to rile up the visionaries (in the Crossing the Chasm sense), but as we reach the mainstream, statements like these hurt more than they help. I prefer to tell people that the more they test, the better their features are; and the more testable their features are, the more easily maintained they are. They seem to respond to that, especially when I show them how that is. I still astonish people, as unexpectedness is a key component of a sticky message, but I prefer not to use divisive, absolute rhetoric to do that. I use different techniques for that now.

I believe it’s become more important to be less overtly provocative, and instead be clearer with our advice. I don’t think most thoughtful agilists will claim that they write production code the way they teach others to do it; but this is not a simple case of “do as I say, but not as I do”, but rather a case of the student needing to learn the lessons by following some useful rules before leaning too much on under-developed judgment. Not everyone agrees that we should give novice rules to novices, but it works well for me, so I do it. This means that I sometimes tell people “delete that code because it isn’t tested” or “stop and refactor the code until it’s testable”. I find it an effective way to help them learn and develop judgment, the skills I believe will serve them best. I tell my students directly:

Do I take tiny steps like this every time I write code? No. Do I think you should take tiny steps like this when you write code? Yes. Why? Not because it’s the best way to write software, but because you learn a lot when you do it and, more importantly, when it’s 2 AM, you’ve been called back from vacation, you’re performing surgery on a production system that’s losing $100,000 per hour of downtime, you’ll be glad you can work in such small steps.

More succinctly, I’m more up-front with people about the pedagogical aspects of what I do. They seem to respond well to that, rather than patting them on the head and saying, “No, trust me, just write the tests. You’ll learn.” I’m sure there are plenty of trainers out there, agile and otherwise, who treat their students like children, rather than adults. They make absolute statements of the type that Cédric is right to complain about. I just wish he wouldn’t make it seem like a uniquely agile problem, and I wish he wouldn’t lump us all in one bucket. I suppose it’s convenient to do that, but it’s not true.

In fact, it feels downright religious to do so.

December 28, 2007 14:59 testing, agile, people, presenting, writing, antipatterns, article, extreme programming, personality types, emotional health

A user-friendly tool for Mercurial?

me@jbrains.ca (J. B. Rainsberger) — Mon, 24 Dec 2007 10:19:29 GMT

This is an open request for help. I’ve started using Mercurial as my version control system of choice, and I’d like to start sharing controlled documents with a business user. Now this person is relatively sophisticated as a business user, but he’s not a programmer, so I sense he wouldn’t be comfortable using the hg command-line tool. I’ve asked him, but in the interim, I’m looking for a potential solution to a problem I anticipate having. Can anyone recommend a tool that wraps around hg suitable for a business user? Something with buttons that don’t say “update”, “commit”, “push”, and “pull”, but sensible business user equivalents? I would prefer not to build one myself, so if someone out there wants a nice exercise, I have one for them!

I appreciate any help. Write to us at info anAtSign diasparsoftware possiblyADot com.

December 24, 2007 10:19

Dynamic test doubles and brittle tests

me@jbrains.ca (J. B. Rainsberger) — Wed, 19 Dec 2007 19:02:09 GMT

Just a quick one. I’ll write the proof later.

People commonly complain to me that when they try to test-drive code with test doubles (say with JMock), they end up with brittle tests: when the code changes, all these tests change. I understand, because it used to be that way for me, too. Nowadays, it doesn’t cause me a problem, and I believe it’s because my interfaces tend to stabilize quickly, and I believe that happens because my interfaces tend to be minimal with appropriately-distributed behaviors. How did I get to design so well?

When JMock told me my tests were brittle, I changed my design so that the tests were more robust. The result, as a side effect, was smaller, more cohesive interfaces and less coupling between classes and their collaborators.

December 19, 2007 19:02 testing, coding standards, refactoring, design, extreme programming

(Omni)Focus on what matters now!

me@jbrains.ca (J. B. Rainsberger) — Tue, 18 Dec 2007 15:25:09 GMT

In the process of learning to use OmniFocus to Get Things Done, I have changed the way I group projects into folders. I started by grouping projects by purpose. I later realized why OmniFocus doesn’t have task priority: it has project priority built in, just by moving projects around in the Projects view.

This made me think that I should throw away most of my task due dates, which I’ve done, and replace “which task to do next” with “what are the next actions in my projects”. This encourages me to prioritize projects, rather than simply dump them into the Projects view and, perhaps, collect them by related purpose. Now, I group projects by “urgency”, which I happen to measure in how happy they make me: do they take care of me? do they generate more passive income? do they help me spend more time with cool people?

Incidentally, notice that I wanted to hide some of the information in the “urgency” picture, but not in the “purpose” picture. That’s a clue in itself about what I should really be working on: the stuff I don’t want you to know about until I release it. :)

So if you have found that your projects list has grown out of control, maybe you should re-prioritize your projects and group them by urgency, rather than purpose. You could even hide the “not important, not urgent” projects and look at them only during a periodic review.

December 18, 2007 15:25 people, planning, personality types, being a scanner, emotional health

How I got Rails working on Leopard

me@jbrains.ca (J. B. Rainsberger) — Tue, 11 Dec 2007 05:56:27 GMT

I hope this helps someone. After installing Leopard, I had some repair work to do. Here is a summary of what I’ve done.

First, ruby and gem both worked, which made me happy.

Next, I re-created the usual directories in /usr/local to install software there. My intention was to install ruby there by building it from source, but I ran into problems I just didn’t feel like trying to solve, so instead, I decided to stick with the stuff that Apple shipped with Leopard.

I use PostgreSQL, so I needed to re-build and re-install that. Since my TextDrive server uses v8.0.x, I decided to install a version from the same minor release level, which was 8.0.14. I downloaded that from here and installed it with the usual commands:

./configure
make
sudo make install

This installed PostgreSQL into /usr/local/pgsql/*. I then added some configuration to /etc/profile to make PostgreSQL available on the system path.

PGHOME=/usr/local/pgsql
export PATH=/usr/local/bin:/usr/local/sbin:$PGHOME/bin:$PATH
export PGDATA=$PGHOME/data

After re-starting my shell, I could use the PostgreSQL utilities, so I then initialized the data directory. Since I use the user postgres to manage my databases, I initialized

sudo mkdir /usr/local/pgsql/data
sudo chown -R postgres /usr/local/pgsql/data
su - postgres
initdb /usr/local/pgsql/data
exit

Next on the list was installing the postgres gem, which I learned how to do here. With that done, I could try running one of my Rails applications again. Of course, I couldn’t do that as my normal user jbrains because of this

mel:jbrains.info jbrains$ createdb weblog_development
createdb: could not connect to database template1: FATAL:  user "jbrains" does not exist

I want to be able to drop and create databases as jbrains to make it easier to run tests through rake, so I added the user in PostgreSQL.

su - postgres
mel:~ postgres$ createuser -a -d -P jbrains
Enter password for new user: 
Enter it again: 
CREATE USER
exit

Next I created my Rails development database and migrated it to the current schema version. Finally, I could run the legacy tests and my new specs.

createdb weblog_development
rake db:migrate
rake test
rake spec

In the process, rake identified some missing gems, which I installed and froze to the project. After that, I could resume work on my Rails projects. I’m keeping an eye on this space for instructions on building Ruby on Leopard.

I would like to thank heartily all the people who published instructions to help me get back to this point relatively quickly. I don’t know what I’d do without you guys. If you ever meet me, remind me that I owe you a beer.

December 11, 2007 05:56 ruby

JUnit is just opinionated software

me@jbrains.ca (J. B. Rainsberger) — Sun, 09 Dec 2007 15:24:08 GMT

In the process of discussing the TestNG/JUnit distinction with Willem van den Ende, I came to the realization that JUnit is simply another example of opinionated software. If JUnit had been released in 2006, after Rails had made opinionated software fashionable, I doubt there would be the same kind of backlash. More people might have been prepared to try to learn the lessons JUnit tries to teach.

Again, I want to be clear: I don’t care whether you use JUnit or TestNG. I merely wish to point out that I let JUnit and my TDD practice teach me a few things about design that have served me very well in the intervening seven years.

December 09, 2007 15:24 junit, testing, agile, people

Definitely not a book review: Next Generation Java Testing

me@jbrains.ca (J. B. Rainsberger) — Sun, 09 Dec 2007 15:04:06 GMT

I want to be clear: I have not yet read Next Generation Java Testing, Cédric Beust’s book about TestNG. I am not writing this to make a comment about the quality of Cédric’s book one way or the other; however, the first reader’s comment put me in mind of a conversation I had at Better Software’s Agile Development Practices conference about TestNG v. JUnit, Cédric v. J. B., and all that good stuff. In that conversation I reached what I felt at the time was an insightful conclusion. This might be obvious to some, but it’s significant to me. I now firmly believe I know the source of our differences, between JUnit and TestNG, between Cédric and me.

TestNG is about testing. JUnit is about design.

Once I reached this conclusion, any notion of one tool being better than the other has absolutely no relevance. A while ago, I proposed that TestNG and JUnit were complementary in the sense that TestNG was more about end-to-end testing and JUnit was more about object testing. I now see that as a false division. If you write tests to do primarily validation or verification, then maybe you should use TestNG, because its features fit better for a testing focus. If you write tests in order to explore design ideas concretely, then maybe you should use JUnit, because its features fit better for a design focus. (Of course, since BDD is TDD done well with less cognitive load to the learner, Java people doing BDD could use JUnit if they didn’t mind calling them “fixtures” and “tests”.)

December 09, 2007 15:04 java, junit, testing, agile, people, design

Book review: Behind Closed Doors

me@jbrains.ca (J. B. Rainsberger) — Tue, 04 Dec 2007 17:51:37 GMT

I’ve never been a manager, but if I became one, I know where I’d turn for advice. Johanna Rothman and Esther Derby’s excellent new book, Behind Closed Doors is the first management guide I’ve read that makes me feel like I could learn to be an excellent manager. It even makes me want to try to be a manager, something I swore I’d never undertake. I have spent most of my career seeing managers as an obstacle to doing good work, but Johanna and Esther have painted me a picture of a manager that is an ally, not an obstacle. If nothing else, Behind Closed Doors gives me hope for managers and their reports everywhere. But it’s not just a fairy tale—it’s a practical guide to manager/report harmony.

One important step Behind Closed Doors takes is to both show respect for managers and hold them accountable for their own performance. Rather than simply advocating for managers as unappreciated people, it identifies what good managers ought to do, then guides the reader to do it. Instead of siding with managers against “those annoying reports”, Johanna and Esther emphasize what their readers can do to develop better working relationships with everyone around them. When I think about the managers I have respected throughout my career, I realize that they already do some of the important things that Behind Closed Doors recommends.

The authors also make the point of using systems thinking to solve problems. Not only is this approach highly effective, but it encourages managers to view their environment holistically, rather than focusing on their direct reports, their manager, their turf, and nothing else. It encourages the managers to be better citizens at work, and this can only rub off on the people around them, creating lasting positive change. That’s quite an accomplishment, compared to other books for managers.

Most helpful are the 35 pages of specific guidelines and techniques the reader can start using right away to improve their communication, to both plan and manage their projects and to bring spiraling problems back under control. There are even plenty of examples of what not to do, which are effective teaching in their own right. No management book can promise to make managing easy, but Behind Closed Doors certainly makes it look possible to me, and that’s about as high praise as I can imagine giving a book on the subject.

Some gems from Behind Closed Doors:

Evaluations are different from feedback
People don’t know unless you tell them
Don’t blame the other person for wanting what they want
Management exists to organize purposefully

December 04, 2007 17:51 agile, people, review

Why I don't miss anything anymore

me@jbrains.ca (J. B. Rainsberger) — Sun, 02 Dec 2007 19:34:02 GMT

I used to be the type of person to miss meetings and deadlines like crazy. This happened to me primarily because I tried to keep everything in my head. I have tried a bunch of little techniques for reminders, and nothing really worked until I started using Backpack. Here are the things I tried.

I tried writing things in a pocket-sized notebook, believing that writing things down increased my chances of remembering them. This didn’t work, either because I forgot to look at the notebook every day or, quite simply, I’d lose the notebook.

I tried writing things on index cards, since I used index cards effectively as part of my software practices. This didn’t work because I wouldn’t carry the cards around with me enough nor look at them enough to recall appointments.

I tried a PocketPC, but frankly that became little more than a way to keep myself entertained while waiting for the bus. My subconscious recognized how useless it was for me and helped me leave it “by accident” on a flight from Philadelphia to Toronto.

I tried calendar software on my computer, but found it hard to get appointments onto the calendar, because I didn’t always have my computer handy. I tried a workflow that involved index cards that I later transcribed to computer… and it just didn’t work, so I abandoned it.

Now I use Backpack, a service from the nice folks at 37signals. Backpack reminders are flexible, simple and quick to use. I set up reminders for tasks that don’t have a definite due date, but as a “tickler” in the Getting Things Done sense of the term. I have reminders set five years into the future on Backpack as a testament to how much I believe I’ll be using the service in the years to come. While I tend to use Backpack mainly for reminders, I also use the Writeboard to share composition space with friends and family.

So if you’re looking to get re-organized, I recommend reading Getting Things Done, grabbing a copy of OmniFocus (you are a Mac user, aren’t you?) and subscribing to Backpack. You’ll be glad you did.

December 02, 2007 19:34 people, planning, personality types, emotional health

Presenting "Refactoring: Where Do I Start?" in Orlando

me@jbrains.ca (J. B. Rainsberger) — Sun, 02 Dec 2007 19:08:57 GMT

This is just a reminder that I am presenting Refactoring: Where Do I Start? at Better Software’s Agile Development Practices conference in Orlando on December 6 at 10:00 AM. I’ll spend about 20 minutes talking about refactoring, about 40 minutes doing it and about 30 minutes answering your questions. If you’re unsure how to refactor code, how to begin to learn about refactoring or which part of your system to attack first, this presentation is for you. I hope you see you there.

December 02, 2007 19:08 java, junit, testing, agile, speaking, people, coding standards, presenting, refactoring, design, extreme programming

Tutorial "Evolutionary Design in Practice in Java" in Orlando

me@jbrains.ca (J. B. Rainsberger) — Sun, 02 Dec 2007 19:06:33 GMT

This is just a reminder that I’m presenting Evolutionary Design in Practice in Java at Better Software’s Agile Development Practices conference in Orlando on December 3 at 1:00 PM. I hope you’ll be able to join us to experience hardcore evolutionary design. Don’t write any unnecessary code! See you there.

December 02, 2007 19:06 java, junit, testing, agile, coding standards, presenting, refactoring, design, extreme programming

Tutorial "Test-Driven Enterprise Code" in Orlando

me@jbrains.ca (J. B. Rainsberger) — Sun, 02 Dec 2007 19:02:03 GMT

This is just a reminder that I am presenting Test-Driven Enterprise Code at Better Software’s Agile Development Practices conference in Orlando on Monday, December 3 at 8:30 AM. I hope you’ll take the chance to join us to learn how to tackle enterprise applications test first.

December 02, 2007 19:02 java, junit, testing, presenting, refactoring, design, extreme programming

How Getting Things Done is helping me

me@jbrains.ca (J. B. Rainsberger) — Sun, 02 Dec 2007 18:57:37 GMT

I have recently become a Getting This Done disciple. I hesitate to use that term a little, but I am a disciple in the true sense: I have devoted myself to learn GTD for a while and I don’t really know what I’m doing yet, so I’m mostly following the rules and observing the results. The nicest result I’ve noticed so far is the way that GTD helps me focus on work or play, whichever I’m doing at the moment. This makes work go more smoothly and play be, well, more fun!

Since I don’t much have to worry about remembering to do things, I don’t have to worry about work while I’m playing, in whatever form that takes. Also, since I know what I need to do in a given day and I break things down to mostly 30-minute tasks, I can easily focus on the current task, get it done, then take a 10-minute break before continuing. It’s like being at a meeting where everyone gets to be heard: people listen and focus, rather than merely waiting for their turn to speak.

Thanks to David Allen, the GTD community and the nice folks who build OmniFocus for their help.

December 02, 2007 18:57 people, emotional health

The Curse of the Serial Master

me@jbrains.ca (J. B. Rainsberger) — Tue, 27 Nov 2007 16:41:30 GMT

This is probably why I stayed so depressed for so long. To learn about the personality types of Scanners like the Serial Master, read Refuse to Choose.

November 27, 2007 16:41 people, being a scanner, emotional health

With whom, exactly, are you arguing?

me@jbrains.ca (J. B. Rainsberger) — Sat, 24 Nov 2007 13:02:16 GMT

I have been reading a bit more about the Satir Interaction Model, which describes how we understand the way we interact with people. I find this model helps me communicate more effectively with people, at work and at home. In Dale Emery’s Untangling Communication, he shares this story about giving significance to a conversation.

I was once in a meeting with Larry, the product manager for whom I had worked for several years, and six engineers. We were trying to decide whether to make our proprietary thread package available to customers through our public API, as a key potential customer had requested. Larry thought that making the threading functions available was a good idea. I was adamantly against it.

Larry and I were unable to reach consensus. The meeting ended with everyone feeling frustrated and spent. Tom, one of the engineers at the meeting, visited me in my office, and said, “Wow, you sure were angry in that meeting!”

“No, I wasn’t angry,” I said. “I just think it would be a mistake to expose such a low-level interface.”

“Well,” he said, “You sure sounded angry to me.”

As I drove home that night, I slowly began to realize that Tom had been right. Though I had been unaware of it during the meeting, I had been not just angry, but furious. Later, as I tossed and turned trying to sleep, I realized that the topic of the meeting, the decision about exposing the thread package, had played only a small role in my anger. What I had been really furious about were the many “similar” situations over the previous few years in which Larry had made design decisions over my strong objections. Though I had not been consciously aware of it, I had come to resent these decisions. My resentment had contaminated this meeting and a number of others.

The next morning, I met with Larry to talk about what I had learned. We still disagreed about the API, but we were able to express our disagreement much more calmly and to understand each other’s point of view much more compassionately.

I had given this conversation much greater significance than it warranted. For me, the conversation was not just a single decision about an API, but a symbol of all of the unresolved issues in my relationship with Larry.

It’s this last bit that hits home for me. I have trained myself to treat every argument as though it were about my entire relationship history with the other people involved, and not just the current topic. This helps me understand better when I react strongly to something, what that’s about. When someone asks me, “What’s going on for you right now?” I know that what’s going on goes back weeks, months, years, well before this conversation ever started. By being on the lookout for such things, I find I’m better equipped to handle the current conversation without letting it fly off the rails too quickly. I recommend it to you, too.

When you are arguing with someone, stop and ask yourself what past transgression, disagreement or problem is coming up for you at that moment, beyond just the issue before you.

[Here is a comment from Don Gray.]

Your post title “With whom, exactly, are you arguing?” wonderfully juxtapositions with Virginia Satir’s original writing “With Whom Am I Having the Pleasure?”

When a conversation includes information that doesn’t fit the current situation, I use “Them, there, then” and “Us, here, now” to see if that helps explain why the energy level seems mismatched with the context.

Virginia said “We come together through our similarities, we grow through our differences.” Arguing contains negative meaning for me. It feels like a cross between the super-reasonable and blaming coping stances. I’ll call it “super-blaming”.

For me to be right, you have to be wrong. It’s a common position. I’m watching it play out in an on line discussion group. On person said “XXX isn’t suited for automated regression testing.” Others rejoined “Oh yes XXX is.” It’s been going on for four days.

If we chose to be congruent, and hear the difference as a learning opportunity, it changes the dynamic from argument to cooperation. The hard part is catching the initial fight/flight adrenalin rush. The cool part is the other person doesn’t have to agree not to argue. Changing what you ask, and how you ask it transforms the conversation.

November 24, 2007 13:02 people

Ask a Question for Agile Dev Practices

me@jbrains.ca (J. B. Rainsberger) — Fri, 16 Nov 2007 16:56:48 GMT

[This comes from Better Software, hosts of the Agile Development Practices conference at which I will appear in December.]

Have you ever wanted to ask an industry expert a particular question? Well, here is your chance: the Agile Development Practices Live Podcast. The conference staff is giving you, a chance to submit a question you want answered by an industry expert. StickyMinds.com editors will select some of the submitted questions to ask the experts during the live recordings. The selected questions will be credited back to you! Your questions must be submitted by Wednesday, Nov. 28 to be considered for these live interviews.

Submit your questions to editors@stickyminds.com to have your question considered.

Hurry, All questions are due by Wednesday, November 28, 2007, 5:00 PM EST.

What information is needed to submit your question?

Your name (and how to pronounce it)
Your question and which expert it should be directed to (see the experts listed below)
Your email address and location (state/province and country)

Learn More

Hear from some of the best in the business…

Featured Speakers Include:

J.B. Rainsberger
-——————-
Joe is a programmer, coach, mentor, and author. His book, “JUnit Recipes”, which has become “the bible of JUnit,” is a manual for Java programmers to improve their programming skills through programmer testing. Beyond helping programmers learn how to test, Joe teaches teams about XP, teamwork, and object-oriented design. He is a dynamic presenter who likes to teach by example. Read his blog at http://jbrains.ca

Linda Rising
-————-
Linda has a Ph.D. from Arizona State University in the field of object-based design metrics and a background that includes university teaching and industry work in telecommunications, avionics, and strategic weapons systems. An internationally known presenter on topics related to patterns, retrospectives, and the change process, Linda is the author of “Design Patterns in Communications Software”, “The Pattern Almanac 2000”, “The Patterns Handbook”, and co-author with Mary Lynn Manns of “Fearless Change: Patterns for Introducing New Ideas”. Find more information about Linda at http://www.lindarising.org

Jean Tabaka
-————
Jean is an agile mentor and coach with Rally Software Development. In addition to being a certified Scrum trainer and practitioner, she is also a certified professional facilitator. Her unique blend of passions and skills has been applied in a variety of organizations—large and small, co-located and distributed—eager to adopt the best of agile and bring out the best in their teams. Author of the Agile Software Development series book “Collaboration Explained”, Jean holds a Masters in Computer Science from Johns Hopkins University.

Learn More

Submit your questions to editors@stickyminds.com now! At each of the three interview sessions, one person will be selected from all those who have submitted questions to receive a StickyMinds.com Prize Pack! You must be present to win.

November 16, 2007 16:56 agile, speaking, extreme programming

Book review: Test-Driven

me@jbrains.ca (J. B. Rainsberger) — Wed, 14 Nov 2007 08:26:43 GMT

On a recent trip, I read Lasse Koskela’s Test-Driven, one of Manning’s latest releases. I opened it with the preconceived notion that there was nothing left for me to learn about Test-Driven Development, but Lasse presents the topic with a fresh perspective that I admire. Introductory text books tend to go stale, even after only a few years, and while Kent Beck’s Test-Driven Development: By Example remains a classic, Test-Driven provides a much-needed update to the literature. Koskela goes beyond the basics to give the reader a valuable overview of today’s TDD landscape, including an extensive section on TDD at the story level, current information on tools and more recent examples of test-driving Enterprise Java components and applications.

Test-Driven‘s overview is quite extensive; any reader is sure to be satisfied by its reach. It was an ambitious project, not one I think I would have undertaken, but Lasse has come through it gracefully. The result is a solid addition to the literature that TDD practitioners can heartily recommend to their novice colleagues. While I don’t agree with some of Lasse’s test design style, he has plenty of great things to say about TDD and designing Java code, and readers will benefit from his experience.

Lasse’s writing is engaging, his examples illustrate his points well and he doesn’t beat around the bush. If you like directness of approach and of exposition, then Test-Driven is for you. I give it 4/5 on the amazon.com scale and plan to add it to the bibliographies of my TDD-related seminars and courses.

November 14, 2007 08:26 java, junit, agile, design, extreme programming, review

Trying a new Subversion client

me@jbrains.ca (J. B. Rainsberger) — Sun, 11 Nov 2007 15:06:30 GMT

Until now, my Subversion client has been Eclipse. Unfortunately, both it and my primary repository have grown so much that Eclipse is no longer a viable Subversion client for me. I have tried svnX, but I don’t find it quite ready for prime time. Specifically, it can’t handle svn revert --recursive, which I needed last night. I don’t want to criticize *svnX*’s maintainer. I just can’t use it yet, and I don’t have the energy to help the project out. I need something to work and do everything I need, which is why I’m now trying out syncroSvnClient.

This new client is not free, so I’m using a 30-day trial licence for now. I’m writing this while I use syncroSvnClient for the first time, so you’re getting my (mostly) unedited first impressions.

Installing the software was not as straightforward as I would have liked. I’m used to just dragging the .app file to Applications, but that didn’t work. Instead, I was supposed to drag the entire syncroSvnClient directory to Applications. Not the end of the world.

Getting a trial licence was straightforward. I had one by e-mail in moments and was able to use it easily.

I linked to a repository easily enough. The experience is very much like Eclipse’s Subversion client in this respect. Of course, I realize now that I should have added a working copy, and not a repository. Doing that was less obvious, as there is no icon that immediately suggests “add” or “link to”. The icon I wanted is a little wrench. A minor annoyance, but I’m past it.

So I linked to the working copy I use to develop this site. That was quick and easy. My next test for this client is how easily it lets me ignore files. This is something svnX doesn’t seem to support yet. I want to ignore the log files, like development.log and test.log. That was easy: select, right-click… hey, this looks exactly like Subclipse! If I can have the benefit of Subclipse without the bulk of Eclipse, that would be cool.

In fact, that’s good enough for now. I’m temporarily sold. I’m going to keep using it for the 30 days, then decide what to do after that. I don’t want to claim I’m ready to buy it, but I like what I see so far.

November 11, 2007 15:06 mac

"Please change your free service", part deux

me@jbrains.ca (J. B. Rainsberger) — Fri, 09 Nov 2007 08:11:31 GMT

Not long ago, I stood up for my friend, Reg Braithwaite-Lee. You can read about that here. With the benefit of some distance, and at the prompting of a response I read here, I would like to say a little more about this situation.

First, let me be clear: I stand by my statement. I find it arrogant to ask someone for more free stuff without offering something in return. (There’s a special word for that.) This might just be a rule I have, but it has at least a kernel of truth. I don’t apologize for feeling this way.

I do, however, regret being unclear. I didn’t want to say that one should always offer money for a customized experience; however, I believe one should always offer something the requester finds valuable. Something the requester would want others to offer him. Now, people with a strong bond of trust can ask each other for anything and expect to get it, mainly because the trust is built on only asking for what’s truly important when it’s truly needed; but in all other relationships, it’s merely polite to offer something. Money, sincere gratitude, helping out, something. I inferred from Reg’s reaction that his requesters did not offer him much.

I must grant that I assumed that, based solely on Reg’s reaction. It’s entirely possible that his requesters were polite, showed tremendous gratitude, and thought they were helping their fellow raganwald readers, but I find it a safe guess that if they had, Reg wouldn’t have considered taking away some of the free stuff he’s giving us. A mother rarely threatens to take away a child’s toys because the child does something nice. Still, if I wanted to be sure, I should have asked Reg. Sorry, Reg, if I over-reacted and embarrassed you. I don’t think I did, because you didn’t tell me I did, but I apologize all the same.

So that’s all I have to say about that. If you lost respect for me over this, then I invite you to let me earn it back.

November 09, 2007 08:11 people

"Please change your free service" (updated)

me@jbrains.ca (J. B. Rainsberger) — Sat, 27 Oct 2007 21:49:56 GMT

I prefer not to rant on this weblog, because I don’t find ranting very becoming; however, there are a few hot-button issues that I want to rant about, and so here it is. I promise it will be brief.

I know, like and respect Reg Braithwaite-Lee, who writes here. Frankly, I don’t understand everything Reg writes about, but I love his enthusiasm and I often learn from him. All the more reason, then, for this to annoy me. Recently, he wrote:

I have now received my second request for an RSS feed that does not include a daily summary of links I find relevant to this weblog. So I’m thinking about dropping them outright.

I’m not thinking about offering three feeds (one just links, one just posts, and one blended). I’m not even thinking about offering two feeds. There is one feed for this weblog; the question I am asking myself is whether it should contain my words or whether it should contain my words and a daily summary of interesting links.

To be blunt for a moment, this chaps my ass. To the two people who made this request to Reg, did you read your own e-mail before you sent it? This is what you’re asking Reg:

I know you offer us a lot of useful information and opinion, and I know I don’t have to pay a dime for it, but would you please customize my experience by doubling your effort so I can avoid having to press Delete?

You want a custom experience? Offer to pay for it. If you can’t hit delete once per day because you don’t find Reg’s del.icio.us links interesting, that’s fine; but if you expect Reg to rearrange his writing for you, then you should offer to pay him. I find it the height of arrogance to ask someone to do more work without offering him something in return.

If I were Reg, I would, after calming down, politely decline the request. If I were to act without calming down, I would think along the lines Reg is thinking, and reduce my output to the lowest common denominator. And my readers would likely lose, on the whole.

So Reg, to hell with those two people. I find 90% of your del.icio.us links to be a waste of time, but every week or so I read something I’m glad I read. Funny… it’s like I read something about that somewhere recently.

Updated November 9, 2007. Read more about this here]

October 27, 2007 21:49 people, writing

A call for code for "Refactoring: Where Do I Start?"

me@jbrains.ca (J. B. Rainsberger) — Sat, 27 Oct 2007 17:11:44 GMT

I am running a session entitled Refactoring: Where Do I Start? at the first Agile Development Practices conference. Although I plan to speak for a few minutes, I’d like to spend most of the time answering your questions and refactoring some real code on stage. As a result, I’d like your code! I have a sample code base to refactor, but I’d rather refactor your code, to show everything that goes into refactoring: learning a code base, making some initial small refactorings, then envisioning how they can collect into something bigger and more significant. I put out the challenge to you, then: give me your code and I’ll refactor it!

Here are the guidelines:

Java or Ruby, please. I’ll look at other code bases, but this session is not the time for me to be learning the finer points of a language.
If it’s Java code, it must compile. If you want to take a small section of your code base out, put back enough libraries or stubs to make it compile.
It must do something useful to someone. It can have bugs, but it can’t be a total mess. I don’t want to spend most of the time getting your code to do something, anything. If a refactoring uncovers a possible bug, that’s cool.

A request: if you can send the code to me as an Eclipse project, that would be great. It’s not absolutely required, but it would help. If I can’t get the code compiling and running in Eclipse within 15 minutes, I’ll probably give up and move on.

If you have a code base you’d like to send me, please e-mail me at refactoring the beautiful at sign diasparsoftware the dazzling dot com and I’ll give you instructions where to send the code. Thanks!

October 27, 2007 17:11 java, ruby, agile, presenting, refactoring, design

Having trouble explaining refactoring?

me@jbrains.ca (J. B. Rainsberger) — Thu, 11 Oct 2007 00:33:04 GMT

I just read this and it seems to describe refactoring almost exactly. I don’t know why I hadn’t thought of it before. Excellent.

October 11, 2007 00:33 coding standards, refactoring, design

Another way TDD reduces design complexity

me@jbrains.ca (J. B. Rainsberger) — Tue, 25 Sep 2007 22:03:56 GMT

I read this at worsethanfailure.com, and it sparked something in me. It is a quote of Michael A. Jackson from Principles of Program Design.

Programmers… often take refuge in an understandable, but disastrous, inclination towards complexity and ingenuity in their work. Forbidden to design anything larger than a program, they respond by making that program intricate enough to challenge their professional skill.

I find this interesting, because I want to write simple programs. I find the simplicity comforting and safe. The less complex it is, the less likely I’ll screw it up. Still, I do recognize my own tendency to add complexity as a challenge, rather than when it’s truly called for. I think practising TDD has helped with that. TDD itself is enough of a technical challenge that I don’t need to add unnecessary complexity to feel challenged. Perhaps that represents another of its benefits.

Try this at work: the next time someone tells you TDD is a waste of time, frame TDD as a design challenge. Say it’s a way to find the minimally complex design for a given problem. Maybe that will intrigue that someone. Maybe not, but it’s worth a shot. Looking back, I’m pretty sure that TDD helped me feel challenged when writing software that was otherwise mostly easy.

September 25, 2007 22:03 testing, agile, people, design

I wrote JUnit Recipes; Vince wrote JUnit in Action

me@jbrains.ca (J. B. Rainsberger) — Sun, 16 Sep 2007 01:32:58 GMT

I’m not sure why it keeps happening, because I don’t notice it much with other authors and their books. A number of times, I have seen people confuse Vincent Massol’s excellent book JUnit in Action with my book JUnit Recipes. Most recently, I found the error in Checking Java Programs by Ian Darwin, although his web site correctly refers to JUnit Recipes. I imagine that means that Ian knows about the error, but wasn’t able to fix it in time for his e-book. Shame.

Don’t get me wrong: I’m happy for the reference, but I feel bad for Vince when someone attributes his book to me. Please get it right, folks.

September 16, 2007 01:32 junit, agile, people, review

Safari woes: Tidy to blame

me@jbrains.ca (J. B. Rainsberger) — Sat, 01 Sep 2007 02:00:21 GMT

I like Safari; however, for about two months, it hadn’t been working. Since it’s easy to blame someone who isn’t around to defend himself, I yelled at Safari each time it didn’t work. It turns out that Safari wasn’t entirely to blame. In the interest of providing some Google bait, here are some details.

The problem. When I started Safari 3.0 Beta 2 or Beta 3, the browser window would not launch without my expressly choosing it (with Command+1, for example). Also, Safari would not load any pages. No matter which page I tried to browse to, Safari would response “page failed to load”. I had asked Google a few times to find me a cause, and it couldn’t; but finally, I insisted, and after searching Apple’s support forums for a few minutes, I found this article, which suggested that the Tidy plugin was to blame. I tried their suggested solution of removing the Tidy-related folder from ~/Library/InputManagers, and Safari now works! And a cool browser it is.

I hope this helps someone out there.

September 01, 2007 02:00 mac

The electronic to-do list, revisited

me@jbrains.ca (J. B. Rainsberger) — Fri, 31 Aug 2007 22:45:34 GMT

Since I have been spec-driving Rails code, and since I have very limited table space at home right now, I have been experimenting with something I’d never liked before: an electronic test and refactoring list. So far, it’s not too bad.

Like many people, I like to avoid keeping lists in my head, since I tend to forget things. Normally, I use an index card and write tests from the top and refactorings from the bottom, crossing each out as I perform them. It works well. So well, in fact, that I generally question anyone who attempts to use an electronic system, rather than a paper system. The idea, of course, is that we tend to fixate on electronic systems, whereas we use paper systems simply and quickly. Using the computer for anything that doesn’t benefit from automation seems counterproductive to me. Still, since we’re low on table space, I’ve had to try something else, and RSpec gives me the opportunity to maintain a test list without having to implement multiple failing tests (or specs) at once.

With RSpec, one can describe a test with prose without implementing it, simply by invoking it without a block.

describe "The thing I'm spec-driving" do
  it "should do something important"
  it "should do something else important"
  it "should do this third, equally important, thing"
end

When it’s time to implement the spec, add the corresponding block. In the meantime, RSpec reports the other specs as “pending”, rather than attempting to execute them. I had never thought it was a good idea, before, but I’ve been trying it recently, and I’m less annoyed by it than I used to be. That might be because I’m more comfortable spec-driving than I was years ago when I started; but it might just be because my personal taste has changed. I can’t say. What I can say is that I haven’t managed to get lost yet, and it takes little extra effort to describe a handful of specs up front. If it starts bothering me, I’ll be sure to describe my experience.

August 31, 2007 22:45 ruby, testing, agile, coding standards, design, extreme programming, adventures in RSpec

The smartest thing I've read in a long time

me@jbrains.ca (J. B. Rainsberger) — Mon, 27 Aug 2007 01:11:36 GMT

Jeff Patton is one seriously smart guy. I really need to pay much more attention to what he writes. While reading his older blog entries, I came across this nugget in an article attacking the myth of bad estimates sinking agile projects. Even entirely out of context, it’s great:

Treat estimates as solution budgets and focus on solving the original problem

Suppose the programmers estimate a story at 1 point, which happens to be around 3 days’ work on this project. Now suppose the team starts writing customer tests for this story and the story balloons into 2 weeks’ work. What should we do? Here are some options.

Let it be 2 weeks’ work, then re-plan and re-prioritize.
Work overtime in an attempt to squeeze 2 weeks’ work into 3 days.
Yell at each other over it.

Sadly, I see the teams take the last option more often than the others. They might yell subtly at each other, but they yell all the same. If the programmers have the upper hand in the relationship, they insist it’s 2 weeks’ work and they force the customer to re-prioritize and re-plan. If the customers have the upper hand in the relationship, they insist it be done in 3 days, and the programmers “knuckle down” to try to do it. In each of these cases, the result is not good.

Now there is another option I didn’t give earlier. Split the story into smaller pieces, the most urgent of which we hope is only 1 point. This is usually more effective, but I have already written about how difficult this is to do well. I wish I had read Jeff’s words before I wrote what I did, because Jeff’s advice provides a concrete goal for splitting this exploding story beyond “it’s a good thing to do¹”. Combining Jeff’s advice with mine, we arrive at something better.

Find the most urgent part of the story that costs only 1 point, then split the rest into less urgent parts that the customer can put back in the backlog.

This way, the customer gets the essence of what she wanted when she chose this story as the next one to build; but the programmers aren’t asked to do the impossible. It seems like a good outcome to me. Thanks, Jeff, for helping me justify my advice.

¹ I haven’t found much success justifying my advice to software people with “trust me; it’s good for you”. I’m constantly on the lookout for a better answer.

August 27, 2007 01:11 agile, stories, people, planning, extreme programming

Patching RedCloth: unique footnote hyperlinks

me@jbrains.ca (J. B. Rainsberger) — Sun, 26 Aug 2007 04:20:58 GMT

Recently, I integrated Textile into this blog via RedCloth. As I started to write articles in my Adventures in RSpec series, I found I wanted to use footnotes. Since Textile supports them, I figured I was in luck; however, I soon found a hyperlink collision when two fragments of Textile markup appear on the same page, each with the same-numbered footnote. RedCloth simply generates a hyperlink to target fn1 for footnote #1, so if there are two footnote #1s on the same page, they both link to target fn1, making it the equivalent of a race condition.

I looked for guidance to the Textpattern folks. A certain Mary told me that Textile has fixed this problem, but likely RedCloth has not. After some investigation, I agreed that this was the case. I looked through the Textile source, to the extent I can understand PHP, and saw their fix was simple: keep a table of footnote numbers to unique IDs, then use the unique ID in place of the number in the hyperlink and target. I figured that I could do that.

It took a couple of hours, and I’ll spare you the details. Here is what I wrote:

require 'digest/sha1'

class UniqueFootnoteIdGeneratingRedCloth < RedCloth
  def initialize(markup)
    @footnote_ids_by_number = {}
    super(markup)
  end

  def next_footnote_id
    # SHA1 isn't significant; I just figured it'd make a good unique ID
    Digest::SHA1.hexdigest(rand(2**64).to_s)
  end

  def to_html(*rules)
    self.scan( /\b\[([0-9]+?)\](\s)?/ ) do |match|
      @footnote_ids_by_number[$1] = next_footnote_id
    end
    
    super
  end
  
  private

  def footnote_ref(text)
    text.gsub!( /\b\[([0-9]+?)\](\s)?/ ) do |match|
      "<sup><a href=\"#fn#{@footnote_ids_by_number[$1]}\">#{$1}</a></sup>#{$2}"
    end
  end

  def textile_fn_( tag, num, atts, cite, content )
    atts << " id=\"fn#{ @footnote_ids_by_number[num] }\""
    content = "<sup>#{ num }</sup> #{ content }"
    atts = shelve( atts ) if atts
    "\t<p#{ atts }>#{ content }</p>"
  end
end

I ended up copy/pasting more code than I wanted to, so I’ll have to submit something to why for his perusal. Perhaps this will make it into a future version of RedCloth.

August 26, 2007 04:20 rails, ruby, design, adventures in RSpec

Don't mock the clock

me@jbrains.ca (J. B. Rainsberger) — Sat, 25 Aug 2007 01:52:38 GMT

I just read this while cleaning up my unread blog subscriptions. This is an old topic for me. I once participated in a mailing list discussion that led to this paper. Since 2003 I have come across this question many times, and after trying a few different designs, I have come to this conclusion: parameterize the time; don’t mock the clock.

Looking at the example from mockobjects.com, rather than passing in a Clock interface to Receiver, I would change the design of acceptRequest() to accept an instant in time¹ as a parameter. I would end up with this:

public boolean acceptRequestAsOf(Request request, Instant requestInstant) {
  Date requestInstantAsDate = requestInstant.toDate();
  if (dateOfFirstRequest == null) {
   dateOfFirstRequest = requestInstantAsDate;
  } else if (firstDateIsDifferentFrom(requestInstantAsDate)) {
   return false;
  }
  // process the request
  return true;
}

This leaves me with two options: add acceptRequest to delegate to acceptRequestAsOf, specifying the current time or push the responsibility for choosing “now” up a layer in the design. I favor the latter option, because that option is more likely to introduce design tension, signaling inappropriate layering or a missing abstraction. My experience tells me that would push me in the direction that the mockobjects.com article moves: raising the talking level of the code by introducing the notion of a request expiring. It turns out that we’d end up at the same place anyway: someone has to instantiate the SameDayChecker with either a clock or the current day. I think it’s clear which I’d choose.

¹ You can use java.util.Calendar, java.util.Date or the joda-time package; that’s hardly the point here.

August 25, 2007 01:52 testing, refactoring, design

Breaking the unconscious will to implement too early

me@jbrains.ca (J. B. Rainsberger) — Fri, 17 Aug 2007 08:51:00 GMT

(From the testdrivendevelopment Yahoo! group.)

At the story level, I look for a concrete (all constants, no variables)
example of the story I’m trying to implement. That forces me to hardcode
values in the production code. Then, at each step of the way, I change a
value to force me to generalize in each direction as I go. Once I’m done
identifying values that need to change, I’m done writing examples.

At the code level, I do much the same thing. Once I have a design
sketch, I just pick one object, one method, then write a concrete test
with constant input and constant expected result. Once that passes, I
look again for directions in which to generalize.

I like what you wrote: at the object/method level, if you can’t identify
the single thing the method needs to do, then write a concrete
example, identify the first constant whose value needs to change, and
that is the first single thing a method needs to do. Lather, rinse,
repeat.

Any way you slice it, the key part of the technique for me is writing a
concrete example with real numbers, words and people. No variables. Even
when you think you know exactly what to do, start with a concrete
example. Doing this enough times will help you start thinking in terms
of examples/tests, rather than in terms of implementation code you need
to check with tests. At that point, the tests really drive the
production code.

August 17, 2007 08:51 junit, testing, agile, refactoring, design, extreme programming

Live Preview with RSpec on Rails

me@jbrains.ca (J. B. Rainsberger) — Sun, 12 Aug 2007 19:52:04 GMT

Today I’m waiting at Così Cafe for our train to Washington DC for Agile 2007, so it’s time to add the next part of the “preview” feature. I have an internet connection, so I can afford to be a little more aggressive with the story I tackle next, because Google knows all. I think I’ll try to build the real-time preview I imagined earlier this morning. Now I don’t think I can spec-drive the real-time aspect of the preview, but I can certainly spec-drive showing the preview in a nearby window while I’m typing in the posting content text area. To get a sense for how that would look, I do some quick UI design.

In order to make room, I shrink the “content” text area and put the live preview, as it’s called, below it. This looks reasonable to me. In the process, I make one design decision: the <div> that contains the live preview text has the ID content-live-preview, which I’ll need to spec-drive the RJS I’ll have to write.

Speaking of spec-driving RJS, I have no idea how to do that, so I need to read a little about that before I get started.

Unfortunately, after reading Rails Recipes, I’m convinced that I need to implement this first before I can learn how to spec-drive it for next time. I find this happens a lot with Rails: it’s almost too simple. I paste an implementation into my view and inspect it manually. When I do that, it becomes clear that I need an action to handle the live preview, so although I didn’t drive the controller behavior with an automated test or spec, I’m certain I need something. Now I think I can spec-drive the controller behavior. Since this is familiar territory, this should go smoothly. Let’s see.

According to Rails Recipes_, all I need to do in my action is render the default template without a layout, which means I will need to move the live preview markup to a new @livepreview.rhtml@ template. I’ll do that first, to make sure it will be wired together properly.

After a few false starts, I have these specs:

describe "Live Preview for weblog postings" do
  it "should have a section to display the live preview" do
    assigns[:posting] = Posting.new(:content => "Some @textile@ content.")
    render "/postings/live_preview"
    
    response.should have_tag("div#content-live-preview")
  end
  
  it "should be able to handle nil content" do
    assigns[:posting] = Posting.new(:content => nil)
    render "/postings/live_preview"
    
    response.should have_tag("div#content-live-preview")
  end
end

This is the live_preview.rhtml template:

<div id="content-live-preview" class="entry">
	<%= textilize(@posting.content) if @posting.content %>
</div>

That decidedly doesn’t work. When I consult Rails Recipes, I realize I should display the request parameter posting[content] and not the Ruby object @posting.content. For this, I need to learn how to stub the request parameters in the view. Evidently this is as simple as assigning to a params Hash. I fix the specs to match this new information.

describe "Live Preview for weblog postings" do
  it "should have a section to display the live preview" do
    params[:posting] = { :content => "Some @textile@ content." }
    render "/postings/live_preview"
    
    response.should have_tag("div#content-live-preview")
  end
  
  it "should be able to handle nil content" do
    params[:posting] = { :content => nil }
    render "/postings/live_preview"
    
    response.should have_tag("div#content-live-preview")
  end
end

I’m on a green bar, but the UI doesn’t work. Firebug tells me that my controller live_preview method works, but the corresponding <div> is not updating. I don’t know how to spec-drive this, so I need to hack for a while. It’s 14.44; let’s see how long I need to hack.

Fortunately, only about five minutes. I had one <div> too many.

After fixing that, and making a few small changes, it looks like I’m done. I would have preferred to spec-drive the observe_field code, but at least I have less untested code than I used to. Now I can remove the preview button and the code that went with it. It served its purpose; now it can go to its rest.

August 12, 2007 19:52 rails, testing, agile, coding standards, refactoring, design, article, extreme programming, adventures in RSpec

Getting Started with RSpec

me@jbrains.ca (J. B. Rainsberger) — Sun, 12 Aug 2007 08:29:16 GMT

I decided, at last, to investigate RSpec in the course of my work in Rails. I should be clear about something: I’m not writing Rails code for profit, only for fun and the experience, so I’m learning slowly and not really pushing the envelope the way I would on the job. Read this series with that in mind.

Here is the story I want to implement next: “Preview postings”. That story is for this very weblog. When I add an entry, I want to be able to preview it without publishing it. Of course, now that I write that, I realize that I might also want to preview edits to existing entries, but that’s another story. I suppose this story is “Preview new postings”. It’s good to know that I can still negotiate scope with myself!

Not being a big RSpec user yet, rather than get stuck writing a story test, I thought I’d do my bit of design, dive in, then RSpec-drive my model¹.

First, I had to install RSpec and RSpec on Rails. That wasn’t too hard. I followed these instructions and issued these commands in the root of my Rails project:

ruby script/plugin install -x svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec
ruby script/plugin install -x svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails
ruby script/generate rspec

After a few seconds, I could run my specs using the new Rake tasks in my project, like spec. When I run my specs, of course I have none, but I do see weird ANSI codes in my output. I’ve asked a question about that, and when I get an answer, I’ll let you know what I found out.

It’s time to write a spec. My design has a class Posting, so I figured I would add the notion of “publishing” a posting, so that I could save a posting without publishing it. This would allow me to preview it. For this, I decided to add a published_at timestamp. For that, I wrote this spec:

describe Posting do
  it "should not yet be published" do
    Posting.new.should_not be_published
  end
end

What I find neat and disturbing at the same time is that RSpec magically looks for a method published? on Posting because I’ve used the “should… be” syntax. I think it’s neat, but what disturbs me is that I have to know where the underscores go. I expect to write that as Posting.new.should not_be_published or Posting.new.should_not_be published. Not exactly “least surprise” for me².

I satisfy this spec by adding a published? method than answers false and move to the next spec.

describe WeblogController do
  it "should be published when it has a published timestamp" do
    new_posting = Posting.new(:published_at => DateTime.now)
    new_posting.should be_published
  end
end

To satisfy this spec, I add the column published_at to the postings table. When I migrate, though, I should mark all the current postings as published, so I make them published as of the time they were created. It’s not perfectly accurate, but it will do. I haven’t been tracking the last updated at timestamp. Here is the migration I wrote:

class EnablePreviewForPostings < ActiveRecord::Migration
  def self.up
    add_column :postings, :published_at, :datetime, :default => nil

    Posting.find(:all).each { | each |
      each.update_attribute(:published_at, each.created_at)
    }
  end

  def self.down
    remove_column :postings, :published_at
  end
end

When I migrate the database, I see that all is well. Now I can implement published? like so:

class Posting < ActiveRecord::Base
  def published?
    !self.published_at.nil?
  end
end

I’m green, so I can continue³. The essence of preview is that I can save the entry, display it, but not include it in the published entries. To that end, I need to retrospec the method that grabs all the postings so it’ll exclude unpublished ones. This is the first time I’m spec-ing a controller, so I’ll learn something. I create my new spec at $RAILS_ROOT/spec/controllers/posting_controller_spec.rb and write this:

describe WeblogController do
  fixtures :postings

  it "should only select published entries when browsing" do
    get 'browse'

    postings = assigns[:postings]
    postings.size.should == 3   # 4 articles, 3 published
  end
end

Unfortunately, this doesn’t find my existing postings fixture. I get this rude answer:

No such file or directory - /Users/jbrains/Workspaces/dauphin/jbrains.info/spec/fixtures/postings

(I should note that that’s not the exact output, but the exact output tripped some security filter at TextDrive, so I couldn’t paste it in. That only cost me a half hour to figure out. Thanks, TextDrive.)

So what does Google have to say about this? Curiously, one article says Lose the fixtures with rSpec, which I like, so I’m inclined to try it. I change my spec to this:

describe WeblogController do
  it "should only select published entries when browsing" do
    Posting.create!(
      :published_at => nil,
      :title => "Irrelevant detail", :content => "Irrelevant detail"
    )

    get 'browse'

    postings = assigns[:postings]
    Posting.find(:all).size.should == 1
    postings.size.should == 0
  end
end

I don’t like the irrelevant details, but when I try to switch to test doubles, it’s a dead end, so I stick with this spec and try to satisfy it. By adding the condition published_at is not null, I get the job done. The problem, though, is that there are two code paths in my browse method, depending on whether the URI is /browse or /browse/12. The latter means “show only articles in category 12”, which supports my entry tags. I wrote this before I knew about custom routes, so I could consider refactoring to a custom route and simplifying browse, but that’s more work than I’m willing to take on at 01.25, so I’ll leave a REFACTOR comment and add a spec for the /browse/12 case.

describe WeblogController do
  it "should only select published entries when browsing within a single category" do
    category = Category.create!(:name => "Irrelevant detail")
    Posting.create!(
      :published_at => nil,
      :title => "Irrelevant detail", :content => "Irrelevant detail"
    ).categories << category

    get 'browse', :id => category.id

    postings = assigns[:postings]
    Posting.find(:all).size.should == 1
    postings.size.should == 0
  end
end

That spec is violated, so I satisfy it. After some refactoring, browse looks like this:

class WeblogController < ApplicationController
  def browse
    if params[:id].nil?
      @postings_pages, @postings = paginate :postings, :order_by => default_order, :conditions => [published_condition], :per_page => 5
    else
      # REFACTOR Move this to a custom route
      @postings_pages, @postings = paginate_collection(:per_page => 5, :page => params[:page]) {
        Posting.find_by_sql([
          %Q(
            select * from postings where postings.id =
            any (select posting_id from tags where category_id = ?)
            and (#{published_condition})
            order by #{default_order}
          ), params[:id]
        ])
      }
    end
  end

  private

  def published_condition
    "published_at is not null"
  end
end

I’m pretty happy with that, and I can’t think of another spec that might be violated, so I move on to the “preview” action. I imagine this is as simple as adding a “preview” button to the form where I add a posting which creates the entry without publishing it, then display it a new window. This way I can close the window, go back, then press “save” when I’m ready. I might even rename “save” to “publish” to emphasize the fact that I’d be publishing the entry. I need to do some more retrospec-ing (“retrospecking”?) to prepare for that.

describe PostingsController do
  it "should not publish a new entry when I preview it" do
    post 'preview'

    new_posting = assigns[:posting]
    new_posting.should_not be_published
  end
end

I can satisfy that easily enough.

def preview
  @posting = Posting.new(params[:posting])
  @posting.save
  redirect_to :action => "read", :id => @posting
end

Rather than pop up a window, I’ll just remember to use the “Back” button. My customer side wants a real-time preview, and it’s now 01.54, so since I’m not prepared to do that now, my programmer side will ship the simplest thing that could work, get feedback, then add the cool Web 2.0 crap. The next step is to add my preview button, but the scaffold code doesn’t directly handle two submits for the same form, so I need to do some research. The best solution I find is to add a name attribute to my buttons and “case” on the name in my controller method. Not pretty, but adequate. I refactored my new entry form to prepare for that, and when I did, I noticed I couldn’t see any new entries. Of course, that’s because create doesn’t publish. I was hoping to do that later, but I guess I need to do it now. Since I’m on a green bar, I can retrospec create.

describe PostingsController do
  it "should publish a new entry when I publish it" do
    post 'publish'

    new_posting = assigns[:posting]
    new_posting.should be_published
  end
end

Evidently my subconscious insists I rename create to publish, so I do that. Now my spec is violated, so I satisfy it. In the process, I introduce the new method publish on Posting, which I’ve spec-driven.

class Posting < ActiveRecord::Base
  def publish
    self.published_at = DateTime.now
    save
  end
end

This makes the change to the controller easier.

def publish
  @posting = Posting.new(params[:posting])
  if @posting.publish
    update_tags_for(@posting)
    flash[:notice] = 'Posting was successfully created.'
    redirect_to :controller => 'weblog'
  else
    render :action => 'new'
  end
end

I only had to change @posting.save to @posting.publish. That looks like that works, so I try it manually through the UI⁴. Now I can publish a new entry, so I need to be able to preview one. It’s time for another spec.

describe PostingsController do
  it "should preview when I press the 'Preview' button" do
    post 'submit_new', :submit => "preview"
    assigns[:posting].should_not be_published
  end
end

Satisfying this spec is pretty straightforward, so I retrospec for the ‘Publish’ case. After a little refactoring, I have this:

class PostingsController < ApplicationController
  def submit_new
    self.send(params[:submit].downcase)
  end
end

Clever, no? Perhaps too clever, but time will tell. It works for me. I’d worry about a security hole if I weren’t the only user who could submit this form.

A quick manual test reveals a problem: “Couldn’t find Posting without an ID.” It looks like I’m missing a preview-related spec, so I add one… and when I do, all hell breaks loose. Here’s the short version of the story:

I noticed my authorize filter wasn’t right, so I fixed it.
I didn’t notice that this would cause all my specs to fail because they don’t login with an authorized user first.
I didn’t notice that this was the problem, because I made a change to unspec-ed code and didn’t think anything of it.

Great how that happens, no? So I search for something on the topic of how to stub out filters, and I read this, which suggested I write

controller.stub!(:login_required).and_return(false)

to indicate that there’s no need to login. I tried that and it didn’t work, so I added this instead:

describe PostingsController do
  before(:each) do
    controller.stub!(:authorize)
  end
end

Now everyone is authorized in my specs. With that distraction out of the way, I can get back to the point.

describe PostingsController do
  it "shouldn't preview an incomplete entry" do
    post 'preview', :title => "", :content => ""
    assigns[:posting].should be_new_record
    assert_redirected_to :action => "new"
  end
end

This is violated because I redirect to the wrong place. It’s an easy fix, but with a little manual testing, I see that while “Publish” gives me nice error messages when it fails, “Preview” doesn’t. Upon further inspection, it’s because preview redirects to new on failure, rather than merely rendering it, as publish does. I should write a spec for that. This time, I add some expectations to the last spec I wrote.

describe PostingsController do
  it "shouldn't preview an incomplete entry" do
    post 'preview', :title => "", :content => ""
    assigns[:posting].should be_new_record
    response.should_not be_redirect
    response.should render_template("new")
  end
end

I notice that I had typed assert_redirected_to up there. Old habits die hard, especially when the fingers can work without the conscious mind. Frightening. This spec is violated because I redirect, so I fix that. Now I see that publish and preview are structurally similar.

def publish
  @posting = Posting.new(params[:posting])
  if @posting.publish
    update_tags_for(@posting)
    flash[:notice] = 'Posting was successfully created.'
    redirect_to :controller => 'weblog'
  else
    render :action => 'new'
  end
end

def preview
  @posting = Posting.new(params[:posting])
  if @posting.save
    redirect_to :action => "read", :id => @posting.id
  else
    render :action => "new"
  end
end

The differences? The method they invoke on @posting and the true branch of the if statement. It takes a little to refactor this, but I arrive at the following.

class PostingsController < ApplicationController
  def publish
    save_posting :publish, :on_success => lambda { | posting |
      update_tags_for(posting)
      flash[:notice] = 'Posting was successfully created.'
      redirect_to :controller => 'weblog'
    }
  end

  def preview
    save_posting :preview, :on_success => lambda { | posting |
      redirect_to :action => "read", :id => posting.id
    }
  end

  private

  def save_posting(save_action_symbol, events)
    @posting = Posting.new(params[:posting])
    if @posting.send(save_action_symbol)
      events[:on_success].call(@posting)
    else
      render :action => 'new'
    end
  end
end

Now, I think, the feature works. Just to be sure, I try a few manual tests. I would prefer to rely on specs, but it’s 03.21 and I don’t plan on much more retrospec-ing tonight. One thing I notice is the “preview” view doesn’t say anything about being a preview, so I should fix that.

describe PostingsController do
  it "should tell me a preview is a preview" do
    post 'preview', :posting => {
      :title => "Irrelevant detail",
      :content => "Irrelevant detail"
    }
    
    response.should redirect_to(
      :action => "preview",
      :id => assigns[:posting].id
    )
  end
end

Making that pass is easy: I redirect to preview, rather than read. A little manual inspection reveals that nothing about the “preview” template makes it look like a preview, so I add a little color to make that more obvious. I’ll go with this for now:

<% @title = "Preview '#{@posting.title}'" %>
<div style="border: 1px solid; padding: 5px; background: pink">
<%= render :partial => "posting" %>
<p style="text-align: right">preview</p>
</div>

It looks reasonably good, and although I have to use the browser’s Back button to edit the draft, and although the “edit” button in the entry doesn’t do what I expect, I can live with it for now.

So, my first RSpec experience has been a good one. In spite of a couple of minor problems, I felt I proceeded steadily, if a little slowly. I imagine I could get used to this quite quickly. RSpec on Rails is a terrific plug-in.

Still, I’d prefer not to have to create real entries in order to write specs for my controllers. I’m sure there’s a better way, but learning what that is will have to wait for another day. It’s 03.43, I have to pack and get some sleep before traveling from Philadelphia to DC for Agile 2007. Before I go, though, I should deploy.

In the process of preparing to commit my changes to my code repository, I updated the RSpec plug-ins, and can no longer run my specs. It looks like a problem in one of the plug-ins. Needless to say I’m not impressed with that. Fortunately, it’s not a big problem: I simply needed to do script/generate rspec again, and all was well. As a result, I’d better freeze my plug-ins before deploying. How do I do that?

Ask, and ye shall receive.

So while that took longer than it usually does, I was able to preview this entry with the new feature, so I’m satisfied with it. The next step might be to add real-time preview or the primitive preview feature when editing an entry. Either way, I learned a lot, and I think I’ll be more comfortable spec-ing my next new feature.

¹ What’s the verb for doing BDD? In TDD, we say “test-drive”. What do I say when doing BDD with RSpec? Write me and let me know.

² I tried Posting.new.should_not_be published, but it didn’t work. Shame.

³ You can change some of the language of TDD, but you’ll take my green bar from my cold… well, you get the idea.

⁴ Yes; I wrote untested, unspec-ed code. I’m not proud of it. Why do you think I’m writing this article?

August 12, 2007 08:29 rails, ruby, testing, agile, refactoring, design, article, extreme programming, adventures in RSpec

Three tutorials at Better Software's Agile Development Practices conference

me@jbrains.ca (J. B. Rainsberger) — Sun, 12 Aug 2007 03:16:39 GMT

I’d like to announce that I am hosting three tutorials at Better Software’s new Agile Development Practices conference. Please join us and tell your friends!

(The schedule is subject to change without notice. Don’t blame me; I’m just a presenter. Changes affect me, too.)

December 3, 2007 at 8:30 AM is Test-Driven Enterprise Code, my popular tutorial on test-driving code in the enterprise environment. The examples and demo are in Java, but you can apply these concepts to other platforms, including .NET. This is a half-day tutorial with lecture, demo and Q&A.

December 3, 2007 at 1:00 PM is Incremental Evolutionary Design. If you’ve never seen a design evolve before your eyes, here’s your chance. This is a half-day tutorial that is decidedly hands-on, so bring a laptop with Eclipse 3.2+ and JDK 1.4 (not Java 5 or 6).

December 6, 2007 at 10:00 AM is Refactoring: Where Do I Start? If you want to refactor code, but are overwhelmed by how much you have, learn some tips for getting started. Learn about which refactorings are the most safe to do without tests, which parts of your code base are the best places to start refactoring, and how to crack the chicken-and-egg problem of “I need to refactor to write tests, and I need to write tests to refactor”. This is a 90-minute tutorial with lecture and Q&A.

I look forward to meeting you in Orlando this December!

August 12, 2007 03:16 java, junit, testing, agile, speaking, people, coding standards, presenting, design, extreme programming

Rethinking "Rethinking Stand-Up Meetings"

me@jbrains.ca (J. B. Rainsberger) — Sun, 12 Aug 2007 02:50:23 GMT

Recently, I commented on Steve Smith’s article Rethinking Stand-Up Meetings. Steve wrote me to clear the air: it’s the standing up part he takes issue with, and not the meeting. To clarify his position, he has said more, and for whatever it’s worth, I believe his argument is spot-on.

Even so, if you’re new to this kind of meeting, you should try standing up first, to interrupt the usual meeting patterns of straying off topic, monopolizing the time, and goofing off. If, after you’ve held true Stand-Up meetings, you find that standing up has outlived its usefulness, you should consider sitting down; however, if the old habits return, try standing up again. If it didn’t work, no-one would have called them “Stand-Up”s.

August 12, 2007 02:50 agile, people, extreme programming

Cutting through the bullshit

me@jbrains.ca (J. B. Rainsberger) — Sun, 12 Aug 2007 00:00:45 GMT

Sometimes, in the middle of a long, drawn-out discussion, someone says something that cuts to the heart of the matter, or some portion of it. I usually find it refreshing, and I love it, even when I’m not the one saying it. I just read one and would like to share it.

I think that there is one kind of business value, profit.

It’s funny, but funnier in context. Click the title of this entry to read the entire thread, but only if you have some energy to spare.

August 12, 2007 00:00 agile, people, writing, extreme programming

The worst kind of writing

me@jbrains.ca (J. B. Rainsberger) — Thu, 09 Aug 2007 08:10:31 GMT

Some colleagues have drawn my attention to this, from an MSDN article:

Although the idea of code coverage is simple enough, actually performing code coverage analysis in a non-.NET environment can be very time consuming, difficult, and expensive. (Source)

Ignoring for a moment whether the statement in the article is true, it’s pointless, because it sets up a comparison without describing what it’s comparing to. It’s a vacuous statement masquerading as a fact. This is the worst kind of writing.

There are several reasons this statement is valueless:

Even if performing code coverage analysis can be expensive, that doesn’t mean it must be expensive. Almost anything a person might do could be expensive, if done poorly enough.
Performing code coverage analysis can be relatively easy and cheap. I haven’t done it in a while, but the last time I set up a project with Maven I got code coverage analysis free of charge, and it only took me a half-day to learn and do. Not free, but relatively cheap, considering everything I get for my investment of a half day.
The author cites nothing to support this statement, making an opinion (debatable) look like a fact (not up for debate).
Later, the author writes “In the days before .NET, code coverage was one of the most frustrating parts of my job as a tester.” On which platforms? In which contexts? At least tell us a story to entertain us. Maybe you were an idiot back then and you’re smarter now, and your current self would have been able to easily perform code coverage on that project.

I could go on, but I believe you get the point.

Let me be clear: I don’t mean to say that one shouldn’t try to express one’s opinion in the best possible light; and I don’t mean to say that one ought not to promote one’s work. I do both. Still, when one writes, one needs to remember to separate opinion from fact and one needs to support one’s opinions with at least one concrete anecdote to give the reader an idea that one is not simply talking out of one’s ass. To do any less is to show an astounding lack of respect for one’s readers.

August 09, 2007 08:10 testing, people, writing

I'm up for deletion

me@jbrains.ca (J. B. Rainsberger) — Sat, 28 Jul 2007 04:22:19 GMT

I noticed tonight that my Wikipedia article is being considered for deletion. I was honored to have someone add me to WIkipedia in the first place, but now I have to wonder. I hadn’t had a window into the self-important Wikirati until now. Their discussion about deleting my bio reads like a bunch of people who talk out of their ass, sprinkled with a person or two who might have a clue.

To wit:

“It did list first on Amazon (search term: “junit java”, rank order “bestselling”; first book with JUnit in title) but I found a book or two with very comparable sales ranks (60,000 for those counting)"

This refers to JUnit Recipes. The commenter is using its Amazon sales rank to evaluate its importance. In the last year, its sales rank has swung mightily from as high as 9,000th to as low as 190,000th. I’ve seen it swing from 80,000th to 10,000th in one day, as well as the other way around. To say the least, Amazon’s sales ranks can’t be taken too narrowly once you get below the top 1,000 books.

In case the commenter wants to know, according to my publisher, it has sold over 7,000 copies. For a purely technical book in the agile world, that’s very good.

“…the IEEE “standard reference” quote is not exactly disinterested, considering he works for them."

This refers to the comment that IEEE software considers JUnit Recipes to be the standard reference for JUnit users. It’s worth saying that I write a column for IEEE Software magazine, but I don’t “work for IEEE” in the sense of a full-time employee. I have no real desire to advance any particular agenda of the IEEE. On the contrary, freelance writers tend to write for publications that can advance the writer’s agenda!

I will, however, give one commenter some credit:

“Reads like an ad.”

I’m not surprised. The original version of the article was pasted from a bio I submitted to a conference at which I was speaking, which I certainly wrote as soft advertising copy. Good eye.

The whole experience makes me feel like I’m in a room with people talking about me while not acknowledging my presence and not seeming to care what I think about that.

Epilogue on July 30, 2007. It appears they’ve decided to keep my article around at Wikipedia, for now. My ego is mollified, but I remain uncomfortable about the entire incident. It felt creepy.

July 28, 2007 04:22 people, writing

Google Singleton Detector

me@jbrains.ca (J. B. Rainsberger) — Tue, 24 Jul 2007 19:12:41 GMT

Google Code have released a version of Singleton Detector, which does pretty much what you think it would do, on Java bytecode. I think this is a neat project. I especially like their FAQ answer Why Singletons are Controversial, and the little developerWorks article they refer to.

July 24, 2007 19:12 java, junit, testing, agile, coding standards, design, antipatterns, extreme programming

Intentional Software Development

me@jbrains.ca (J. B. Rainsberger) — Tue, 17 Jul 2007 21:21:27 GMT

What is Intentional Software Development? A half-serious attempt to sidestep the “how does one define agile?” question and perhaps ask a question more likely to need more valuable answers. Join the discussion.

July 17, 2007 21:21 agile, writing, extreme programming

Why stand up?

me@jbrains.ca (J. B. Rainsberger) — Tue, 10 Jul 2007 05:22:08 GMT

I just read an article by Steve Smith entitled Rethinking Stand-Up Meetings. I encourage you to read the article, in case you disagree with my interpretations and conclusions here. As always, I might be wrong.

I was particularly struck by this passage:

When I started my career, I had to wear a tie every day. The next job required a suit. Management told me clothing built teamwork. I think standing up during a meeting is like wearing a tie. My teamwork isn’t any better wearing a suit and tie than it is when I wear shorts and a t-shirt And I don’t believe my team’s effectiveness changes whether they are standing up or sitting down during a meeting.

Steve is welcome to believe his team’s effectiveness doesn’t depend on standing up or not standing up, but I’m worried about his logic. He seems to conclude, incorrectly I think, that since stand-ups don’t help his team be effective, therefore standing up at a meeting, in general, doesn’t matter. This is a false generalization.

While it’s true that stand-up meetings don’t indicate team effectiveness, stand-up meetings do at least help people re-think how they meet. If nothing else, it reminds people to get to the point, and when someone drones on, it gives others a chance to practise holding that person to account for droning on. Granted, I’ve seen bad stand-up meetings, but given that stand-ups have a clear objective and focus on essential communication, when I watch a painful stand-up meeting, I can easily point to it as an example of the team’s communication problems. It clearly illustrates some ways they need to improve. If nothing else, the way a team behaves in a stand-up meeting tells me a great deal about how it communicates overall. I find that very useful.

I have also found stand-ups useful as a participant, so they’re not just useful to a consultant trying to learn about how the team behaves.

So Steve, while I applaud your title, “Rethinking Stand-Up Meetings”, I think the passage I’ve highlighted is too easy for doubters to excerpt and say to themselves “See? These stand-ups are as useless as neckties.” On average, that’s just not true.

July 10, 2007 05:22 agile, people, extreme programming

Make your users say "Wow!"

me@jbrains.ca (J. B. Rainsberger) — Sun, 01 Jul 2007 18:38:54 GMT

One of extreme programming’s practices is “daily deployment”. That name sounds imposing, but don’t ask your team to start deploying daily on Monday. We’re not in it to deploy for its own sake. Like everything else in XP, deploy intentionally. There are a number of reasons to deploy your product more frequently:

Practise deployment so that it is effortless when you would normally deploy. I find teams underestimate the value of practising in general, let alone practising deployment. Still, if your deployment mechanism is complex enough that a specialist or team of specialists needs to perform it, then you have room for improvement. Anything you can do to move in the direction of one-button deployment would be good.

Deploying more frequently means paying greater attention to “done”. Many of the teams I work with suffer the same problem: they underestimate what it means to be “done”, so they find a lot of unplanned work piles up at the end of an iteration, and because iterations are shorter than they used to be, they experience the pain of delivery more often than they used to. Unfortunately, since they often don’t really deliver to a paying customer, these iterations become little more than more frequent, but arbitrary deadlines, and we all hate arbitrary deadlines. It’s important to make iterations mean something by truly delivering to a real customer.

Let your users steer your feature set. The most obvious reason to deploy frequently is to let your users give you feedback on what to build, what not to build, and how well you’ve built what you’ve built. When your users are involved in choosing features, they are more likely to be happy with the results, as you tend to build what they plan to use.

With all this, though, there is another important reason to deploy frequently: give your users a chance to say “Wow!”

A few days ago, I logged in to Google Documents. The night before they must have deployed a new version of the service, because I found a new, nicer user interface. I actually said “Wow!” aloud when I saw it, not because it’s so great, but because I didn’t expect to see it. It was a pleasant surprise, and whenever you can pleasantly surprise your customers, that’s certainly to your advantage.

If you’re able to deploy daily, then you’re able to release your product at any time, especially early. Releasing early helps set up the opportunity for your users to say “Wow!” If Google Documents hadn’t run with the less attractive interface, then I wouldn’t have been as impressed by the nicer-looking one. To be frank, the nicer-looking interface is nothing special: it looks a lot like Outlook or any other e-mail client I’ve ever used. Still, it’s nicer than what was there before, and it’s that contrast that made the difference for me. Am I advocating releasing crap so that when you release not-crap your users will be impressed? Not at all. I am, however, advocating releasing as soon as you have an adequate product, in part so that you know which bells and whistles are worth building. If, in the process, you impress your users, then so much the better.

Now early on I wrote that switching from, say, yearly deployment to daily deployment overnight is a mistake. I’ve made it before. It frustrates the team no end to try to do something its infrastructure is simply not set up to do, so I have changed my approach here. However frequently you deploy your product now, try doubling the frequency. If you released twice last year, release four times this year. If you were releasing every month, then try every two weeks. This way you can build up the infrastructure gradually, rather than having to stop the line and face a host of difficult, frustrating problems at once. There’s no reason why we have to kill ourselves to move in the direction of deploying daily, so let’s not do that. Pick one aspect of your deployment mechanism, automate it (or make the current automation easier to use), then try deploying twice as frequently as you currently do. When that becomes more comfortable, double the frequency again. Before you know it, you’ll be able to deploy every day and your users will say “Wow!” even when you release something you feel isn’t all that impressive.

How can you lose?

July 01, 2007 18:38 agile, planning, extreme programming

Splitting stories: an example

me@jbrains.ca (J. B. Rainsberger) — Sat, 30 Jun 2007 04:01:02 GMT

Most user stories are too big—at least, this is how it tends to be for teams making the transition to incremental development and delivery. After discussing the benefits of splitting stories into manageable increments, a team generally goes through (at least) these stages of development:

splitting stories along process lines, then
splitting stories along architectural lines, then
splitting stories along procedural lines, then finally
splitting stories into smaller stories

What’s the difference? Allow me to explain with an example from my own work.

I am currently working on the xpday.info site, and one of the key themes is collecting registrations for XP Day North America. In particular, we are preparing to host XP Day Montreal 2006 on September 23, 2006. It’s obvious that “collect registrations” is more of a theme than a single story, so I split the theme into a coarse-grained stories like these—

anyone can register by paying immediately with paypal.com
anyone can register, then request an invoice
anyone can register (and pay for) an entire group, rather than just themselves
anyone can register and pay later
automatically generate the invoice
remind all unpaid registrants on demand
automatically remind unpaid registrants on a regular basis
a registrant can cancel his registration
a registrant can add or remove people from the group

Now these might not seem coarse-grained, but when your iterations are on the order of a half-day each, it’s nice to have stories that I can complete in about an hour. (Yes, an hour.) Since I am also the Product Director on this project, and my primary goal is to be able to collect money from registrants, I identified the first story as the minimum for the first release, and estimated it at about 2 hours. That’s a little big for a 3-hour iteration, so I want to split it. The first thing I did was a little modeling, to make sure I knew what I meant by “anyone can register by paying immediately with paypal.com”.

Notice that, even here, I jumped to handling the case where the registrant did not pay. I didn’t realize that until I started writing this entry, so I suppose this is a kind of substitute for pairing. (Thank you.)

Stepping into the shoes of the teams that allow me to work with them a little, here is what I often see when we try to split the story anyone can register and pay immediately with paypal.com. First, the split along process lines:

design
code
write programmer tests
write acceptance tests
document

This is a fine checklist, but whether splitting a story into smaller ones or into tasks, this doesn’t work very well. None of these items produces value on their own. The closest, perhaps, is “write acceptance tests”, but even those don’t represent value until someone has tried to test-drive with them, because only then do we learn what we missed and what we mis-wrote. A team generally does this in their first planning session after deciding to “go agile”. It’s a good effort, but it does nothing to encourage them to change the way they work. It is certainly not incremental. When we apply the INVEST test, this split of stories mostly fails. While these “stories” are perhaps negotiable and somewhat estimatable (estimable? neither seems correct), they depend on one another, have little inherent value on their own, are likely not all small and are definitely not all testable. We need to try again.

Once the team gets past this troubling first phase, they tend to split across architectural lines:

test-drive the UI
test-drive the business logic
test-drive the database client
write acceptance tests
document

Now this is an interesting hybrid approach between architectural and process-based splitting. This looks more like a traditional work breakdown structure, which appears to allow for concurrent work, but doesn’t. (Can you see why?) It is tempting to say that this split satisfies the independent property of INVEST, but it really doesn’t, as you would find out as soon as you tried to integrate the work of the individuals who performed each task independently. There is still no value in just the UI or just the database client, the items are smaller, but probably not small enough, and as a result, I would not trust any estimates on them. We need to try again.

Once the team gets past this second phase, they tend to split across procedural lines:

collect registrant information
integrate paypal.com
e-mail registrant after payment
e-mail organizer after payment

This is much better, because at least we no longer see “write acceptance tests” and “document” as separate tasks. These are almost stories, as they are self-contained bundles of work that include “code, design, programmer tests, customer tests, document, deploy, install” and all those wonderful things. There is still one big problem: this split of “stories” fails the “V” property: just how valuable is collecting registrant information? We certainly can’t deliver that on its own. We need to try again.

After the team gets past this third phase, which tends to last a while, they finally get it, and split the stories into self-contained increments of value:

register with just e-mail, then pay with paypal.com
collect more information from registrant (name, address, phone)
notify both registrant and organizer after registration

That’s it! This story split satisfies all the INVEST properties—

Independent. It is relatively easy to see how to build each of these stories on its own. #1 is a one-field form whose submit action includes going to paypal.com; #2 is a multiple-field form with a simple “create” submit action; #3 is a one-field form whose submit action sends out an e-mail to two recipients. We can build these in any order.

Negotiable. We can negotiate the scope of each of these stories. For #1, is it just a link to paypal.com, or do we have to bring the user back to xpday.info? Do we have to handle an incomplete payment, or will humans verify that by looking at the list of registrants and the payers in their paypal.com account? For #2, how much information do we have to collect? For #3, do we send out a standard e-mail? Is it a form e-mail with some user-based personalization? Do we need a tool for writing or changing the e-mail template? For each story, we can easily negotiate economy or luxury versions.

Valuable. If we do #1 on its own, then at least we can take their money and we have enough information to contact them after they register. We can easily choose to do #2 or #3 in either order after that. Even better, we can do #2 on its own, if “the business” decides that a human requesting payment is good enough, but we really need an automated way to capture registrants’ information. We could even do #3 first: a person could take all the registration information (by phone or e-mail), then enter the registrant’s e-mail address in a form that sends out a form letter to her as well as the organizer. Any of these could have value, depending on the needs of the customer.

Estim(at)able. The first story is the biggest, because I don’t remember how to do the whole paypal.com thing, but I’m pretty sure I can put the bare bones together in 30 minutes. It might take another 30 minutes to handle a return link, and another 30 minutes for the “receiving page” to know whether payment was complete or not. I did this before, but about a year ago. For story #2, we can have something in 15 minutes, then it’s up to the product director to critique the UI layout and suggest changes. For story #3, we can have a standard e-mail in 15 minutes, it’ll take another 30 minutes for a form e-mail, and another 30 minutes to be able to change the e-mail template through the web UI. Make that 90 minutes, because we would have to add role-based security for the first time.

Small. Only one story is 90 minutes; the others are 30 minutes or less. For a 3-hour iteration, we can fit about 4-8 stories into an iteration. According to my good friend Jim Shore, that’s a good number of stories for an iteration, and I agree.

Testable. I would hate to see what someone like Michael Bolton would do with these little stories. I should ask him to test the site, just for laughs. (Well, I think I’d be crying by the end, but he would be laughing.) As a product director, though, I can easily tell when these stories are complete, so I can easily write acceptance tests for them.

So there you have it, I hope: a thorough example of splitting a story into smaller increments, each able to be built and delivered independently. If our plan starts to show that we’re running long, we can cut 2 of the 3 stories, but still meet our primary business objective: collect payments from registrants. That would be good enough for our first release. Now would be a good time to freshen my coffee (during which I have my stand-up meeting with myself), then get to work. We absolutely must have a working first release in the next 3 hours… or at least that’s what the product director claims.

June 30, 2007 04:01 agile, stories, people, design, article

The myth of the repeatable process

me@jbrains.ca (J. B. Rainsberger) — Sat, 30 Jun 2007 01:17:44 GMT

A “repeatable process” is some confused perverted combination of engineering and manufacturing.

The only thing you want to repeat is the success. As we cannot predict the future, we can only assume the ability to repeat success is inherent in people that have achieved success.

Maybe the single cleverest thing I’ve read in months. I only hope Kevin Casey is the guy’s real name, so I can credit him properly.

June 30, 2007 01:17 agile, people

XP 2007: a review

me@jbrains.ca (J. B. Rainsberger) — Tue, 26 Jun 2007 02:25:33 GMT

My review at a glance:

Program	D
Agile Cafe	A
Location	A
Attendees	B
Amenities	C
Expense	C
Hotel	B
Overall	C+

Program. Part of the grade for the program had to do with its structure: sessions before the conference, 1-1/2 days of “actual conference”, then sessions after the conference. Given how it was structured, some people came in for a day or two, then left, rather than sticking around all week. That weakened the experience considerably.

Part of the grade for the program had to do with the pricing structure. All workshops and tutorials were pay-per-use, which means that I had to know in advance exactly what I wanted to do in order to attend sessions other than my own. While I’m accustomed to paying extra for tutorials, I find it ridiculous to pay for workshops. In fact, even the workshop facilitators paid to attend their own workshops, albeit at a half-price EUR 15. I thought that was a joke when I heard about it, but it wasn’t. I can’t fathom that, even now after knowing it had happened. It’s an affront to workshop facilitators. I didn’t attend any sessions other than my own, because the free content was more than competitive.

Part of the grade for the program had to do with the keynotes. There were 3 keynotes on the schedule, only 1 of which was any kind of keynote. The presentation from Ferrari was a solid experience report, in which we got a glimpse of an organization that really needs short iterations. The presentation from Exoftware was a shaky description of a strategy model, including vision, mission and execution. While the presenter attempted to integrate some entertainment, he fell victim to a “Vista moment” as well as letting live game-play muddle his point. For about 20 minutes there, I didn’t know what was happening. While I can empathize with the presenter’s plight, it was still an under-prepared presentation, and his message was lost as a result. Only Kent Beck’s talk, entitled “Ease at Work”, had the element of inspiration that I believe is essential to a keynote, and not even Kent’s talk was universally lauded. Some felt Kent was trying to shed his former smartass persona, but I don’t buy it. I believe Kent is more than sincere in describing the next step beyond XP, towards a more holistic notion of ease. Some love it, some don’t, and I suppose that’s good for a keynote. It had people talking.

Part of the grade for the program had to do with a lack of Open Space, which has become a staple at agile conferences.

By and large, I would have been upset to pay for the conference and be given that program.

Agile Cafe. With a lack of Open Space, Charlie Poole led a number of people in developing the “Agile Cafe”, a light version of Open Space. We simply designated the tables on the terrace outside the conference hotel as the agile cafe and conducted impromptu discussions there. Some gave real results, as my brief collaboration with Rick Mugridge on his story-testing IDE and others were simply enjoyable for their ephemeral nature. We chatted, we drank, we argued, it was excellent. I think I might prefer this to Open Space!

Location. Como, Italy. Enough said. Go.

Attendees. I missed a lot of people in Como, but I also saw some people I hadn’t seen in a long time. While some key members of the European agile community were not present, I very much enjoyed almost everyone I saw or met. I would like to have met more people, but that’s partly my fault for not reaching out and partly their fault for not sitting down at an agile cafe table.

Amenities. Specifically I mean the conference amenities, and even if they were fantastic, no-one ever told us about them, so we would never have known. The hotel lunch was atrocious for the EUR 22 per person. Bad enough that we had to book in advance each day in order to attend, but the food was only a shadow of the high quality food almost everywhere else in the city. The coffee breaks were good, once one understood not to wait in line for the espresso bar. It’s the Italian way, I was told, simply to elbow one’s way up to the bar and bypass the orderly queue filled with North Americans and meeker Europeans. The coffee itself was excellent, even if it took 20 minutes to get a coffee the first day, before I’d learned the Italian way. Finally, I felt under-supported in my tutorial. I didn’t have the right room at first, didn’t get quick support when I thought I was having LCD projector problems, and the room itself was hot. Certainly not what I’m accustomed to as a presenter at other conferences. It’s as through the industry folks were mostly left to their own devices, and that’s a shame.

Expense. The trip was costly, compared to Oulu, Finland. Food was especially expensive: lunch the first day was EUR 55 for Sarah and me. Once she found a piadineria, though, our budget came back under control. I was happy to belly up for my share of Argentinian Steer for 4 people at San Agostino’s. What an experience! Thanks to the Agical folks for suggesting it.

Hotel. The Alberto Terminus was quaint, the people were friendly, the room was comfortable, and the breakfast was diverse and satisfying. Internet access was an extra charge, but not enough to cause us to complain. We spent EUR 30 on the internet service for the week, which is comparable to most North American hotels.

Overall. I’m glad I didn’t pay to attend the conference proper. I probably would have considered that a complete waste of money. Still, the people, their commitment to self-organization and the charm of Como made it a good experience. The conference gets a D, but the rest of the trip rates a solid A, for a total of C+.

We look forward to XP 2008 in Limerick, Ireland, which promises to be a wonderful experience.

June 26, 2007 02:25 agile, speaking, people, xp2007

XP 2007: Wish they were here

me@jbrains.ca (J. B. Rainsberger) — Fri, 22 Jun 2007 07:53:23 GMT

Not everyone could be here in Como, Italy for XP 2007. I asked for some well-wishes and greetings from those who ~~didn’t bother to~~ couldn’t make the trip. These folks were nice enough to say hello:

Ilja Preuß says, “Hi, this is Ilja. I’m sorry I couldn’t make it out there to be with you this week. I’m sure you are having great discussions and a lot of fun, so what remains is to wish you better weather than we have here in Karlsruhe. Have a great time!”

June 22, 2007 07:53 xp2007

Test-Driven Enterprise Code at XP 2007

me@jbrains.ca (J. B. Rainsberger) — Sat, 16 Jun 2007 05:31:15 GMT

Once again this year, I am happy to present a tutorial at XP 2007 in Lake Como, Italy. This will be the first time presenting my greatly improved Test-Driven J2EE, now named Test-Driven Enterprise Code. According to the current XP 2007 schedule (as of April 18), my tutorial will be on June 21, 2007 at 2:00 PM. If you’re planning to attend the conference, I hope you’ll consider attending this tutorial. You can learn more about the tutorial here.

I hope to see you there!

June 16, 2007 05:31 java, agile, speaking, presenting, refactoring, design, xp2007

I'm an HTTP moron

me@jbrains.ca (J. B. Rainsberger) — Fri, 08 Jun 2007 00:38:48 GMT

I’ve spent the past several hours trying to build a simple application in PHP. I’m doing this in PHP because I’ve run out of allowable processes on my TextDrive account, and don’t want to build a Rails application just to do some very simple dynamic web pages. I’ve wanted to do an HTTP redirect after POSTing a form, so I did what I thought was sensible:

I went to the PHP manual, searched the function list for “redirect”, found http_redirect, found out it was in a separate library called pecl_http, learned what the hell PECL and PEAR were, found out why PECL doesn’t work so well with MAMP, finally got a fresh Apache 2.2 and PHP 5.2 installation working on my Mac, finally installed pecl_http properly with PECL, all of which only took about six hours.

Then I found out that I could just have done this:

<? header("Location: http://www.where.i.want.to.go/"); ?>

This is one consequence of all these convenience APIs. It’s easy to forget that sometimes a header is just a header.

June 08, 2007 00:38 design

ObjectMother, or something like it, for Rails

me@jbrains.ca (J. B. Rainsberger) — Wed, 06 Jun 2007 17:05:39 GMT

XP Day Toronto 2007 is coming up soon, so I’m busy working on xpday.info, preparing it for the stampede of registrations we expect in the coming weeks. (I can dream.) In the process, I am writing Rails unit tests, which means using fixtures again. I wasn’t thrilled with my use of fixtures last time I coded Rails seriously, because it felt like the “One Dataset For All Tests” anti-pattern that I discovered so painfully on my first XP project. I would be much, much happier if I could have fixtures with the flexibility of named datasets per test, just as I can get with DbUnit. Still, I remembered
reading something about DRY database configurations and it gave me an idea for implementing a kind of ObjectMother pattern in YAML. This is what I did.

dummy: &dummy
  id: 10
  where: "Nowhere, man"
  web_site_url: http://default.xpday.info
  start_date: 2007-01-01
  registration_open_on: 2006-11-01

open:
  <<: *dummy
  id: 11
  registration_open_on: 2006-12-01

The dummy fixture object must provide values for all the required properties, but should not provide values for the optional ones. The idea is for the properties to be overridable so that later fixture objects can specify only those property they care about specifying, accepting defaults for the rest. It seems pretty similar to ObjectMother to me! We’ll see how it works for me.

June 06, 2007 17:05 xpday, testing, design

Textile spoken here

me@jbrains.ca (J. B. Rainsberger) — Wed, 06 Jun 2007 01:54:18 GMT

Thanks to Textile it is now a good deal easier for me to write entries for this weblog. Whether it has an effect on the number and quality of entries is yet to be seen, but I really do like the fact that Textile handles both raw HTML and textile markup the way I’d expect. Very nice.

June 06, 2007 01:54

An example: the difference between simple and easy

me@jbrains.ca (J. B. Rainsberger) — Sun, 03 Jun 2007 05:35:02 GMT

My wife has this shower curtain for SAT preparation in mathematics. It’s mostly for humor, but I suppose it might work for some. It reminds me of a clear example of the difference between simple and easy. Recall that agile suggests doing “the simplest thing that could possibly work” and describes “simple design” in terms of passing tests, good names, eliminating duplication and removing unnecessary complexity. One of our struggles in teaching simplicity to others is that they often believe that what’s easiest is what’s simplest. We don’t often have good examples, so when I find one, I feel I should share it.

So the shower curtain describes how to multiply binomials such as (x+5)(x+7) using the acronym FOIL for “first, outer, inner, last”. This is a mnemonic device to help students remember to multiply all four pairs of terms before adding them together. FOIL, as a mnemonic device, makes multiplying binomials easier (for some), but it is not simple. Simpler would be to apply the distributive law twice, like so:

  (x+5)(x+7)
= (x+5)(x) + (x+5)(7)
= x^2+5x + 7x+35
= x^2+12x+35

This is simpler because in order to do it, I only have to apply a more general technique (the distributive law) twice, rather than knowing both the distributive law and the FOIL mnemonic. FOIL, while easier, adds to the student’s cognitive load by making him remember two things that he could easily believe were different, even though FOIL is a special case of the distributive law. A student who learns these two techniques might never see the relationship between the two, and so taking the easier route is doubly bad: it adds cognitive load and gets in the way of seeing an important relationship between two seemingly different ideas.

We see this all the time in designs: two structures that look different are really the same, but you need to dig a little more deeply than usually to see the similarity. If we insist on piling “easy” design elements on top of one another, rather than looking underneath for the similarities and removing the superficial duplication, we might never take advantage of our chance to simplify the design. It’s not as easy right now, but simpler designs tend to put less cognitive load on the reader, and so actually cost less once they’re built.

If you have other good examples of the difference between simple and easy, please share them so we can make this concept clearer to those to whom we teach agile programming techniques.

June 03, 2007 05:35 agile, coding standards, design

Why I don't worry about growth

me@jbrains.ca (J. B. Rainsberger) — Thu, 31 May 2007 22:57:30 GMT

I’ve been reading 37signals’ “Getting Real” and I like what I’ve read so far. The most striking passage so far is this one:

All the cash, all the marketing, all the people in the world can’t buy the agility you get from being small.

This is one of the reasons I don’t worry about growth. I intentionally keep my needs modest so that they don’t conflict with my desire to be free from overcommitment. The more committed you are to longer-term courses of action, the more money you need, the more you need to do what you’ve been doing (but better, faster, cheaper) and the less intentional your work becomes.

Have you ever looked at a child and said, “Don’t be in a hurry to grow up; it’s not as great as it looks”? I feel the same way about small companies: don’t be in such a hurry to grow up; it’s not as great as it looks.

May 31, 2007 22:57 agile, people, review

Reaction to XP Day Toronto 2007

me@jbrains.ca (J. B. Rainsberger) — Wed, 30 May 2007 21:33:17 GMT

XP Day Toronto 2007 was successful, even though attendance was down quite a bit from 2005. I am learning to be happy about a smaller event, as the more intimate setting is good for almost everyone participating. We have some changes to make to the format, but I can safely say that the experiment we call XP Day North America is mostly giving good results, so we intend to continue. Next stop, Manhattan on September 22, 2007, with details to come soon.

The XP/Agile Toronto user group hosted a session entitled “What we learned at XP Day Toronto 2007” soon after our event, featuring five talks from various people at Intelliware. It was certainly satisfying to see people excited about the event and happy with their attendance and involvement. Brian Marick certainly delivered a thought-provoking keynote and Open Space was a definite hit, thanks mainly to Deb Hartmann’s expert facilitation. One person, Jason Cheong-Kee-You, wrote about his reactions to the day at length on his weblog, which makes for good reading. If you’d like details, I’m sure he’d provide them.

May 30, 2007 21:33 xpday

Don't go too fast

me@jbrains.ca (J. B. Rainsberger) — Mon, 28 May 2007 17:24:48 GMT

In his keynote at XP Day Toronto 2007, Brian Marick cautioned against the team going too fast early in a project, because it sets up false expectations about the team’s long-term velocity. He said, in essence, that if your customers are really happy, then you’re probably going too fast. In a blog comment, Mike Wasserman wrote

It is statements like this that make me cringe and give XP a bad name.

I understand Mike’s concern, but I think his reaction points to a problem with most approaches to software development: teams are motivated to attempt to go more quickly than they are able to go. This appears to be simply the nature of business: shareholders (whether for a public or privately-held company) want growth, which comes from market dominance, which comes in part from speed to market. It seems rational, then, for the business to want to produce software (whether products or support for the rest of the business) as quickly as possible. The problem, though, is when a business plans to deliver software more quickly than possible given their current people. Typically, this causes teams to do one of two things: try to go too quickly and deliver poor software, or over-react and hold back their velocity in protest. Neither achieves the desired goal of sustained growth through maximum velocity over time. So what can we do?

One option is to timebox our overdrive period. If we truly need the software organization to sacrifice in the short term to “get over a hump”, then we owe them an explanation. Specifically, we should tell the software organization how long we intend them to work in overdrive, why we need them to do so, under what conditions the overdrive period will end and how we will compensate them for working in overdrive. If we do this, we greatly increases our chances of guarding our capital investment in our top people, a competitive advantage that I believe is largely ignored in today’s marketplace. Software people are reasonable people: if you tell them you need them to work 60-hour weeks for 4-6 months until revenue is up to $400k/month, after which time they’ll receive 4 paid weeks of vacation and the opportunity to reorganize their teams however they like, then they can make the decision whether to pitch in or not. If not, you can replace them with more willing people while the cost to replace them is lower. For the ones that stay on, they will most likely get behind you and push hard, which is exactly what you need at a time like this. To do otherwise is to create an army of people who only cash their paycheques during your biggest crunch and who leave the moment it’s over. I recognize that being this transparent is frightening, but as I have become more transparent as a businessman, I’ve been happy with the results.

Another option is to fix the problems that led to the overdrive situation in the first place. There are many reasons to need to deliver software more quickly than you’re capable of: an overzealous sales organization, poor communication between the software teams and salespeople, desperation due to long periods with low sales, and generally unplanned growth. This list is by no means exhaustive, but it’s enough for the current discussion. All these problems have a common source: the quest for growth by wishful thinking and not through planning. If your company intends to grow by some magical rate year over year, you need to have a plan that supports that growth, and if delivering software is a key component of achieving that growth, then you need an accurate picture of how quickly your software organization can deliver. Remember the lessons of the Theory of Constraints: the throughput of a system is bounded by the throughput of its slowest component. Not only is there no point in selling software you can’t deliver, but it actually hurts your business to try to do it, and from a number of angles: disloyal customers or customers who refuse to pay, driving good customers to your competition, higher employee turnover including your best people moving to the competition, and decreasing trust between the “front and back of the house”. If your organization can’t execute on your growth plan, then you need to consolidate your organization first, because hoping for the best is not a management strategy. Perhaps you need to invest in training, in more people, in different people, or perhaps you simply need to rein in your sales staff a little. Satisfy one customer, then two, then four, then 20. Even in industries where this seems impossible, it must be better than the alternative of abject failure to satisfy anyone.

So when Marick says, “don’t go too fast”, don’t take it to mean that we should slow down for its own sake; we need to slow down because otherwise the business will make unrealistic plans based on our unsustainable performance, and once they start to do that, it’s a ticking timebomb, and only a matter of time before the entire house of cards falls down.

May 28, 2007 17:24 agile, people, planning, article

Catalysts' Coding Contest: neat!

me@jbrains.ca (J. B. Rainsberger) — Fri, 18 May 2007 04:37:38 GMT

I just found out about a very neat programming contest. If you want to test your skills against people from around the world, here is your chance. If we’re settled in enough after the move to Dauphin, I will participate myself.

May 18, 2007 04:37 testing, agile, coding standards

May 29, 2007 at the TPMA

me@jbrains.ca (J. B. Rainsberger) — Sat, 12 May 2007 02:15:47 GMT

I will be speaking at the Toronto Product Management Association in downtown Toronto on May 29, 2007. We will discuss what it means to manage a product in an agile environment, why it’s difficult and what we can do about it. If you’re interested in attending a highly interactive discussion of the topic, do join us! Click the title of this entry for details.

May 12, 2007 02:15 agile, speaking, people

Post-agile? I don't get it; I don't know why I care so much

me@jbrains.ca (J. B. Rainsberger) — Thu, 10 May 2007 16:33:39 GMT

I just finished reading some of Jonathan Kohl’s writings about “post-agile”, which he describes (and I paraphrase) as going past the agile doctrine by taking what works and leaving what doesn’t work behind. He seems to emphasize leaving “the hype” behind, too. I don’t know why this line of thought bothers me, beyond a very basic logical fallacy I can’t help but see: the notion that agile is the hype or that agile is the practices. It isn’t now, and it never was. Being agile requires adapting the process to local conditions, so I can’t understand why adapting the process to local conditions would be something other than agile. I hope stating it that way makes the fallacy apparent.

Kohl concludes one of his pieces with this:

At the end of the day, Post-Agilism is just an idea, or a model that some of us find helpful right now. Don’t find it helpful? Don’t worry about it. We aren’t trying to change minds, we’re just trying to get people to think about what they are doing. If Agilism works for you, great! If something else does, that’s great too. There are a lot of good ideas to choose from, particularly if you expand your view.

I have added emphasis for the portion I want to deal with. Since when can one be agile without thinking about what one is doing? The essence of Scrum is “inspect and adapt”. From what I understand, you can’t do either of those without thinking about it quite deeply. The essence of XP, as Beck described it even in the first edition of “XP Explained” is pick a problem, solve it “the XP way”, then repeat on the next problem. You can’t do that without thinking about what you’re doing. What I dislike about Kohl’s post-agile formulation is that it assumes that agile is the worst way it’s practiced: thoughtlessly. That is not agile; and Kohl’s conception is not post-agile. It might be post-bad-agile or post-dogmatic-agile, but what he calls post-agile is really just agile. This, in spite of his claim to the contrary. (My apologies for the long excerpt to come; I will interleave my comments.)

Isn’t This Really Just “Pure Agile”? Aren’t You Just Reacting to Agile Corruption?

No, we are reacting and adapting to experience on our own projects, and to change. Furthermore, post-agile thinkers I’ve spoken to tend to be contextualists who, like the Context Driven Testing community, believe the value of a practice depends on its context. […]

But this is agile. From what I understand, agile is what the various schools (XP, Scrum, FDD, DSDM, Crystal) all have in common, and they are all context-driven. Some recommend a set of practices to start with, but once you’ve mastered the practices, you know which to use when. Others give you the responsibility to discover the practices you need. Each is driven by a set of principles and values, among which is the notion that we continually improve the way we work. I don’t think any is considered dogmatic, although XP is strongly interpreted by many to say, “Don’t mess with it until you understand how it works; and you won’t understand how it works until you try it as is.” Agile or not, I simply find that advice generally sensible.

Ravi Mohan: "…each agile practice (or the whole lot together with an appropriate label) makes sense only in certain contexts (certain types of enterprise software, with certain types of teams) even in the “uncorrupted”, “pure” state. A “pure agile” process is not superior to a “non agile” process de facto. Agile is not the “best way we know how to create software”. It is one way we know how to create software. It has no intrinsic superiority (except against obvious straw men like “pure waterfall” for projects with rapidly changing requirements). “Post Agile” is just an adjective that describes people who have used agile extensively, adopted what made sense, rejected the parts that didn’t work (and the hype) and choose to think for themselves. It is not a reaction against the perceived corruption of an originally perfect process." (From comments on Vlad Levin’s blog.)

I believe Kohl (in quoting Mohan) confuses “agile” for “a set of practices” here. He may do this just because he uses the term “agile” to mean “a set of agile practices”, but the larger community has been saying for years that agile is not the practices. Ron Jeffries says that XP is what you do after you’ve mastered the practices, echoing Charlie Parker’s line that jazz is what you do once you get past the rules of music and just play. Bill Caputo says, “XP isn’t out there; it’s in here.” Agile is certainly the same: agile is what you do once you internalize the practices; agile, it seems, is Kohl’s “post-agile”.

A popular misconception is that if you are in an iterative lifecycle, focus on communication, customer involvement, value testing, and delivering great software, then you are, by definition “Agile.” […]

I’m pretty sure “agile” was defined at Snowbird as “what’s the least we can do and still build great software?” Recall that “agile” is the term only because people didn’t want to be called “lightweights”, otherwise it’s likely that “lightweight” would have been the term. So if “agile” isn’t its definition, then what is it? It seems to me that being iterative and evolutionary with excellent communication is one sure way to deliver good software without unneccessary process. That sounds agile to me.

The Agile movement did not create these practices, and does not have sole ownership of them. Many of us were doing these things on projects in the pre-Agile era. In my own experience, I was on teams that used iterative lifecycles with two week iterations in the late ‘90s. We looked at Rapid Application Development and adopted some of those practices, and retained what worked. We also looked at RUP, and did the same thing, and a big influence at that time was the Open Source movement. If you go back to the ’60s, thirty-forty years before the Agile Manifesto was created, Jerry Weinberg describes something very similar to extreme programming on the Mercury project. That doesn’t mean the Agile movement is wrong, it just shows that there are other schools of thought other than Agile when it comes to iterative, incremental development.

The Agile movement did not invent these practices – they’ve been around for a long time. Some of us were very excited about what the Agile movement brought to the industry, because we had also been working in that direction. What the Agile movement gave to us was a shared language, a set of tools and practices and advances in these techniques that can be very useful. The Agile movement has given us a lot of innovative ideas, but we can look at pre-Agile and Agile eras for great ideas and inspiration.

This sidebar is irrelevant to the discussion. The agile community doesn’t lay claim to inventing these ideas, although in some pockets, it claims to have re-packaged them in interesting ways. Much of the agile movement has been about rediscovering and repopularizing grand old ideas that were lost in the furor of the CASE revolution and its flawed thesis that programming is just typing. I dislike assuming intent in others, but I have to ask: is Kohl angry because he feels the agile movement co-opted ideas that he held dear? I don’t know that it matters, except to further understand his perspective, which I find troubling in its inherent contradiction. After all, if agile is nothing new, then certainly neither is post-agile.

The bottom line is that whenever I work with a new team, when I find it’s time to introduce a new practice, I start with something appropriate from XP, then adapt as needed. If it’s a new team starting out, I try to use as many of the XP practices as make sense, then fix what’s broken. I’ve done this from the moment I had experienced enough XP to feel comfortable doing it. According to Kohl, that makes me post-agile. According to everything I’ve ever read and known on the subject, that makes me agile.

But why spend an hour writing about this? After all, Kohl says he’s not out to change the hearts and minds of men. What does it matter? Well, let me share something I read on “The Daily WTF”, now called worsethanfailure.com:

To a manager, refactor means to upgrade or add functionality. It is a danger of us techies using our language to explain something to non-techies.

You might well imagine my jaw dropping upon reading this. A term has been warped to mean its exact opposite. How could that possibly help me communicate to both programmers and managers in the course of my work as a change agent? So it is with Kohl’s “post agile”: if he calls “post agile” what large numbers of people already call “agile”, how does that help us communicate?

It takes me one step closer to simply keeping bees and growing asparagus.

PS, added May 10, 2007: It seems these opinions have gained some external visibility. It’s always nice to know someone’s reading.

May 10, 2007 16:33 agile, people, article

Speaking: May 17, 2007, Ames, Iowa, USA

me@jbrains.ca (J. B. Rainsberger) — Thu, 10 May 2007 03:32:47 GMT

It’s a little last-minute, but I’ll be speaking at the Agile Iowa user group in Ames on Thursday, May 17, 2007. It will be an abbreviated preview of “My Greatest Misses: XP 2000-2007”, which I will present as a tutorial at Agile 2007. I will tell stories of how I have failed adopting and evangelizing XP over the years, what I’ve learned from those failures and what I do differently now. It will be a lot of fun! If you’re in the general area, please drop by and join us! Click the title of this entry for details, which should be posted soon.

May 10, 2007 03:32 agile, speaking, people, agile2007

Travelocity.ca can't add, either

me@jbrains.ca (J. B. Rainsberger) — Wed, 09 May 2007 19:47:57 GMT

I feel sorry for book-keepers, especially because I’m acting as one for my own company. (Don’t do it. I’m a masochist.) In particular, I just booked a flight on travelocity.ca, and their ever-helpful receipt shows an astounding carelessness. Here is a recreation of an excerpt.

Total airline charges........ CAD 614.56
Total Travelocity.ca fees.... CAD   6.60
Total GST.................... CAD  33.73
Total........................ CAD 621.16

Then, later

Your credit card statement may show separate airline charges for each passenger, as listed below:
Joseph Rainsberger: CAD 647.89

So in order to put this into QuickBooks, I have to know all these things:

The GST on the Travelocity.ca fees are $0.40, and on the flight, the remaining $33.33.
Travelocity.ca can’t add: the total is CAD 654.89, not CAD 612.21.
The separate fee, which shows up as “travel services” on my credit card, is $7.00 total.

…and this is when the charges add up nicely… eventually. Don’t get me started on Travelocity.ca and European flights.

It’s a big company. Can’t they teach their systems to add?

May 09, 2007 19:47 coding standards

99 bottles of beer...

me@jbrains.ca (J. B. Rainsberger) — Sun, 06 May 2007 17:09:25 GMT

I have been accepted into the annals of computing history with my interpretation of “99 bottles of beer” in Ruby. I’m so proud!

May 06, 2007 17:09 ruby, coding standards

A sign you're mocking too much

me@jbrains.ca (J. B. Rainsberger) — Sat, 14 Apr 2007 19:06:30 GMT

I recently read this article at mockobjects.com and it reminded me of advice I give when I teach people about test doubles.

At some point after you learn how to use test doubles, and perhaps dabble with JMock or Mocha, you notice that you’re using test doubles everywhere. With any luck, you notice it, stand back, scratch your head, then wonder, “What exactly am I testing here?” If you’ve reached that stage, then you’re ready for this advice.

First, remember that everything in your system is either a Service, Entity or Value. I didn’t make those names up: I learned them from Eric Evans in Domain-Driven Design.

A value has no lifecycle, is usually immutable and behaves with value semantics. This last point mostly means that “equals” depends on the value and not the location in memory. Strings, numbers, points, lists, monetary amounts, intervals, instants in time, these are values.

An entity has a lifecycle, is usually persisted, and behaves with ID semantics. That means that two entities can look the same by value, but represent different things, and therefore aren’t equal. Think of George Foreman’s kids, all named George. If your system only stores the child’s name and its parents’ names, then all those Georges look the same, but each is unique as a snowflake. Entities often use values. People, accounts, banks, transactions, these are entities.

A service co-ordinates work and provides an API for applications to use it. A service is transient, can be pluggable and is often best when stateless. The notion of equality doesn’t much make sense for a service, and in many applications, one instance of a service is enough. (That doesn’t mean services should be singletons in the Gang of Four sense! They might be singletons in the Spring dependency injection container sense.) Services mostly figure out which entities need changing or retrieving, then either change or retrieve them. Transfer funds, deposit, withdraw, post interest, these are services.

Now that we have a common language that’s probably wrong, but suitable enough for the current purpose, here is the advice I have to offer.

Never mock values, sometimes mock entities, but mock services freely.

That’s the version that’s easy to remember. Here’s the longer answer.

If you want to mock a value, then you’re not using it as a value, or your “value” is really trying to be an entity, or worse, a service. Values just are. They don’t persist themselves, they don’t find themselves… you just instantiate them, calculate with them, then throw them away. Entities will typically hold onto them, and when entities persist, the values go with them, but typically, that’s the entity’s concern, and not the value’s. A value should be so simple that there’s no benefit to mocking them. You should have no test doubles for values. If you do, it’s time to uncover what mislaid responsibility your value has, extract it out, then try again.

You might want to mock an entity, but more likely you want to mock how you got the entity. Again, I use the term I learned from Evans: Repository. A repository is a place to look up and store entities. A repository is a service for keeping track of entities. Most of the time, I should be able to instantiate an entity and use it, so there’s no need to use a test double in its place. Typically, when you think you want to mock an entity, first try mocking the repository from whence it came.

Services, you can mock with impunity. In fact, the only time not to mock a service is when you’re testing the service. Since services are typically interfaces and pluggable, you’ll want to use test doubles when you test how the application uses the service, or how a service uses another service. Since services tend to use repositories, entities and values, when you test the service, you’ll likely use test doubles for the repositories, but not for the entities nor the values.

So that’s a summary of when I mock what. Of course, given that “mock” makes a great verb, and given the history of the term, I used mock in the foregoing mainly as a general term for “substituting a test double”, which I generally don’t like to do. I apologize for that. If this were going in a book, I’d be far more careful. There are several types of test double: mock, spy, stub, fake, dummy… I once wrote about when to fake and when to mock, so read that if you’re confused about how to use the different kinds of test doubles.

I hope you found this useful, and if you didn’t, tell me why and I’ll find a way to make it up to you.

April 14, 2007 19:06 testing, coding standards, design

One year later: an Agile podcast

me@jbrains.ca (J. B. Rainsberger) — Wed, 11 Apr 2007 20:15:41 GMT

Click on the title to listen to a podcast from Agile 2006, with Bob Payne as your host. I spoke mostly about XP Day North America, and the plan sounds dated now. We didn’t run the conference in Austin, in Portland, in St. Louis… but we still have plans to get there eventually. Manhattan is likely a “go” for autumn 2007, and we hope to pick up the pace in 2008. And yes, I am a columnist for IEEE Software, but no, I haven’t started writing that other book yet.

April 11, 2007 20:15 xpday, agile, speaking, people, agile 2006

Best rant ever (rated PG-13)

me@jbrains.ca (J. B. Rainsberger) — Tue, 10 Apr 2007 20:02:00 GMT

I apologize if the foul language offends you, but I laughed uncontrollably for several minutes upon reading it. For complete context, click the title.

…God damn Edward… GOD DAMN EDWARD! AAAUUUGGHH! I CHANGE THREE LINE! THREE GODDAMN LINE! Two comment! AND IT NO COMPILE! AUUUGHHH! GOD DAMN EDWARD! You have to READ HIS F*CKING MIND AND HE NO EVEN HERE!!!

April 10, 2007 20:02 people, coding standards

Perl and Scrabble

me@jbrains.ca (J. B. Rainsberger) — Wed, 04 Apr 2007 01:41:57 GMT

I certainly don’t like to denigrate entire classes of people in public. It’s not nice, it’s bad for business, and it’s bad for karma. Still, I found this statement about perl programmers and I absolutely had to share it with a wider audience.

(“Programmers” is in inverted commas [that’s British for ‘quotation marks’ -JBR] since we all know Perl guys don’t actually code, they just throw fistfuls of scrabble tiles on the floor and type in whatever characters show face up)

April 04, 2007 01:41 people

Mac OS widgets won't go away!

me@jbrains.ca (J. B. Rainsberger) — Sat, 31 Mar 2007 17:59:44 GMT

I just ran into a little trouble: I was removing a Dashboard widget while starting Windows XP under Parallels, and when I looked down at the bottom of my screen, I saw widgets instead of the Dock. The widgets actually blocked the Dock, rather than just annoyingly being superimposed on them. Nothing I clicked seemed to help, but Google did. Although I didn’t find an exact hit on the subject, I found out that I can kill the Dock and restart it. When I tried that, it worked. So if you find yourself in that situation, try this:

% sudo killall -TERM Dock

That might do it for you, as it did for me. Enjoy.

March 31, 2007 17:59 mac

Thank you, J. Lozano

me@jbrains.ca (J. B. Rainsberger) — Thu, 29 Mar 2007 02:52:53 GMT

I hope you don’t think it’s bad form for me to post this here, but I was so pleased with the latest review at amazon.com for JUnit Recipes that I wanted to thank the reviewer in public. Your words are very kind, and I appreciate them.

March 29, 2007 02:52 java, junit, agile, review

Simply disturbing

me@jbrains.ca (J. B. Rainsberger) — Thu, 29 Mar 2007 02:14:40 GMT

There are no words.

March 29, 2007 02:14 people

A riff on "Mentoring, as Team Leader"

me@jbrains.ca (J. B. Rainsberger) — Mon, 12 Feb 2007 23:18:00 GMT

George Dinwiddie recently wrote about mentoring as a team leader (click through the title to read him), and I would like to share a little about my wife’s business: tutoring for secondary school students. Sarah works routinely with undermotivated, underachieving students, some of whom show an astonishing lack of the basic knowledge of the subjects they study. She once told me that one way she gets more out of these students is setting higher expectations for them than anyone else in their lives. To paraphrase her, if you don’t set the bar at least a little off the ground, the kid won’t try to jump. I find it’s the same with adults: when left in an environment that doesn’t explicitly expect them to learn and grow, adults eventually lose the desire to do it. It’s even happened to me, and I consider myself quite the self-starter. So I do the same: when I find myself face-to-face with someone who has stopped learning, I use language that expresses that I expect them to keep learning. It can be subtle; it can be overt; either way, I tend to have more positive than negative responses.

Returning to the substance of George’s question, let me assume the problem is that an internal person (not a consultant) is being asked to be a mentor where he wasn’t expected to be one before. I have been there, and I did a poor job of it. (I was young!) I don’t think those people understood why I was asserting myself in a teaching role, so they resented me for it. If I could do it again, I’d be clear, telling them that I have been asked to act more as a teacher, and that I’ll do my best to balance criticism with respect. Finally, if they think I’m going too far, they should come to me and tell me, or if they prefer, they should speak to our manager (who, I assume, gave me the assignment). Put simply, it’s easier for a peer to teach when his peers are set up to expect to be taught.

Of course, if an employee could master the Weinbergian art of the Lone Ranger touch, that would be great. I still don’t know how to do that.

February 12, 2007 23:18 people

I'm "it": five little-known things about me

me@jbrains.ca (J. B. Rainsberger) — Fri, 26 Jan 2007 01:53:51 GMT

James Shore wrote about five little-known things about himself, then he tagged me, so I’m “it”. Here, then, are five things about myself that might be well-known by some, but not generally known by readers of this weblog.

I have been a life-long enthusiast of languages, and am capable of reading several with varying degrees of competence. Some of you know that I presented in French at XP Day France 2006, and that was my first public speech in French since my university days. I can also converse reasonably in Spanish, very annoyingly in German, and can read enough Portuguese, Italian, Catalan and Provençal to avoid starvation. Strangely, though, I prefer to know things about language over actually learning them. While not a true student of linguistics, I am always interested in the peculiarities of languages like Hungarian and Finnish, Russian, Mandarin, Japanese, and Piraha, among others. I can easily get lost for hours on Wikipedia, surfing the pages devoted to languages and linguistics.
I am a member of the Ontario Winter Games 1991 champion (young) mens 5-pin bowling team from Central Ontario. As I recall, we placed fourth in Canada that year. I returned to the 1993 Winter Games as a member of a much improved Central Ontario team, but we tanked, finishing fourth. I was a competitive bowler for 20 years, ending about 8 years ago. When we move to Dauphin, Manitoba this year, I plan to take up the sport again seriously.
For 19 years, I was a member of the Toronto Houseleague Religiously Obsessed with Winning, or THROW, a simulation baseball league that plays Dynasty League Baseball. If you have no idea what that might be, imagine a Role-Playing Game for baseball, where you get to own a team, be responsible for its finances, trade players, sign free agents and manage games on the field, mostly by throwing dice at another person for 6 hours on a Sunday afternoon once a month. After over a decade of losing, I won my first and only championship in 2003 before walking away from the team at the end of the 2004 season. I have attended the weddings of 4 of my fellow league members over the years, and in spite of leaving, many of them continue to be valued friends.
I have appeared on Canadian national television once, in January 1986, on a family-oriented magazine show entitled “Lifetime”. I appeared with my mother on a segment about parents living with and raising gifted children. When asked what it was like to live with me (then 12), my mother answered, “It’s like playing ”http://www.trivialpursuit.com/“>Trivial Pursuit 24 hours a day.” Fortunately, no copy of that show is known to have survived.
I fully expect to have retired before I turn 40 (on May 4, 2014, health and weather permitting). Here, by “retired” I mean that I will no longer need to work in order to pay the bills: passive income will cover all our important expenses and any work I do will be either on a volunteer basis, for “mad money”, or to further increase our wealth. (Our wealth ratio is tough to compute right now, but it’s somewhere between 0.4 and 0.6.) The only reason I could foresee wanting to increase our wealth past the point where I don’t need to work for living is to have more choice about where in the world we can afford to live without working.

At this point, I am supposed to tag five more people, but I don’t know whom to tag, so instead, if you can read this, you’re it!

January 26, 2007 01:53 people

Ah, spammers

me@jbrains.ca (J. B. Rainsberger) — Sun, 14 Jan 2007 16:24:21 GMT

Recently, TextDrive has been overrun by spammers attacking their mail servers. This morning, when I grabbed my mail, I had about 1,700 “Unable to deliver” bounceback messages in my inbox, because someone has got hold of my e-mail address and been sending out naughty e-mails in my disguise. This time, it was phishing e-mails for Wachovia Bank accounts, I think. Fantastic.

I know this will mostly fall on deaf ears, because anyone who reads this weblog likely knows already that I am not a spammer, but on the off chance that someone Googles and finds me in response to this phishing e-mail, it did not come from me. I don’t know enough technical detail to take a step to protect myself. I’m quite sure this is not a virus problem. I believe it is TextDrive, and not me, that they are attacking. There is likely nothing I can do. I’m really sorry.

Please don’t think I’m a spammer.

January 14, 2007 16:24

Burnout

me@jbrains.ca (J. B. Rainsberger) — Wed, 13 Dec 2006 21:43:09 GMT

I think I might finally have hit the end of my tether. I have been fighting burnout for about two years, now, and I think I’m out of fight. In re-reading Jerry Weinberg’s Secrets of Consulting, I’ve just recently re-read the section about how consultants are always either Busy or Idle. For the past two years I have been Busy, which is generally a good thing, but I think I’ve bit off more than I can chew. There are a number of personal reasons why I’ve done this, and I’m not ready to go into those in public just yet, but suffice it to say that I’m going to have to scale back my professional activities in 2007, quite literally for the sake of my sanity.

One of the things I’ll need are people to help me with the projects I’ve committed to. XP Day North America is a considerable drain on me, and I’m considering canceling the Portland and Austin events, just to give myself some breathing room. If someone out there wishes to volunteer to organize these events, I’m open to the help. I am willing to oversee and provide guidance, but you’d need to do the legwork. You’ll receive free entry to the conference, hearty public exposure and free travel to another XP Day somewhere else on the continent in 2007.

If anyone would like to send me their suggestions for how to deal with burnout, feel free to send e-mail to me at jbrains dot ca. I would be glad to hear from you, even if they’re just well-wishes.

December 13, 2006 21:43 people

What is your customer's job?

me@jbrains.ca (J. B. Rainsberger) — Sat, 02 Dec 2006 00:31:50 GMT

In listening to Ron Jeffries talk about Running, Tested Features, he reminds us of something very important for us to understand. Our customer’s job is to envision a product with more features than could possibly exist, sooner than it could possibly exist. Our job, as software delivery professionals, is to work with them to define a product that can exist by the time they need it and be “meaty” enough to satisfy them.

I believe this reformulation of our relationship to our customers helps remove some of the antagonism we tend to find when “they” ask “us” to do the impossible. That’s their job.

December 02, 2006 00:31 agile, people, planning

An obsession with Agility

me@jbrains.ca (J. B. Rainsberger) — Thu, 23 Nov 2006 18:50:34 GMT

I attend the XP/Agile Toronto User Group fairly irregularly these days, but I still consider myself a member and contributor. This week, Dmitri Zimin(e) presented “Agile Enough”, a case study of Opalis Software. In it, he mentioned their early setbacks, among which the biggest obstacle was an “obsession with agility”. When I read this, I thought back to all the projects I’ve worked on since 2000 when I was still at IBM, and I see a common theme. The failures have had, at their root, the obsession with acting agile, being agile, performing the agile practices, appearing to be agile… all this instead of focusing on helping the project succeed. The successes have had, at their root, a lack of this obsession, primarily because in those cases, no-one was opposing the agile practices. So it’s reasonable to wonder why this happens.

My greatest successes have been either solo projects (my last six months at IBM, my work with the Toronto Blue Jays) or projects where everyone agreed to focus on delivering incrementally, quickly, with quality (the first two months at Toyota) and allowed agile practices to be the way we achieved that goal. My greatest failures (the rest of my time at Toyota, my most recent transitions over the past 18 months) have stemmed in part from wasting energy trying to convince people to work one way or from wasting energy on “compensating” (as arrogant as that sounds, that’s what we were doing) for the poor habits other team members seemed to insist on maintaining. It is clear to me now that there wasn’t true buy-in from everyone about how we would work, so that, for example, when schedule pressure kicked in, they would immediately go back to the old ways of working. I know, from my experience and from that of others, that this back-sliding is human nature and part of any change program, but I’m left wondering what to do about it. What can I do differently?

First, I can stop fighting or trying to convince people to work my way, but rather offer them the opportunity to work my way and evaluate that for themselves. If it helps them, then we can work together, and if not, then we can’t. That’s all right: there is no rule that says we must be able to work together to be friends, or even to be civil to one another. Next, I can stop focusing on the practices and instead focus on the results. This means measuring the current results before trying to change things. I’ll admit that I’ve generally done a poor job of that so far. Finally, I can stop ramming change down people’s throats, but instead invite them to take the journey with me. I think I can achieve this through regular retrospectives in which we examine what’s working and what isn’t working, then propose together ways to improve. I need to remember that my solution, although it works for me, isn’t always best for everyone else, including whichever team I’m on. I think if I apply these three ideas to my consulting work, I’ll find better results. This means learning what to measure, how to measure it, and how to present that information in non-threatening ways. I suppose I know my next area of research… now we’ll just see whether I actually do it.

“I didn’t ask ‘can he do it’, I asked ‘will he do it’. With Eddie, those are two different things.” – Bert Gordon, The Hustler

November 23, 2006 18:50 agile, people

Parallels + hotel connection = pain on wheels

me@jbrains.ca (J. B. Rainsberger) — Mon, 06 Nov 2006 14:36:07 GMT

Recently I have found that when I use Parallels to run Windows under Mac OS X, then connect to the internet at a hotel, I have to do the “I’m here” dance. This consists of signing in on Mac OS, browsing for a while, then going to Windows, signing in there, browsing for a while, and back and forth… since I use QuickBooks under Windows and, of course, have my company file under version control and, of course, have marked the company file as “needs locking”, it becomes a hassle whenever I need to do a little book-keeping on the side. Here at AYE Conference it’s become worse: I couldn’t sign in under Windows, for reasons I was not willing to explore. Fortunately, Google came to the rescue. I found out that Parallels has “Shared Networking” mode, and that sounded like it would help. It’s simple. (Even I could handle it.)

In Mac OS, enable Internet Sharing on your network adapter. In Parallels, shut down your VM, edit its settings, then choose “Shared Networking” for your networking needs, instead of “Bridged Ethernet”. Restart your VM and voilà, both Mac OS and Windows use the same connection and your hotel will never know the difference. Of course, if you’re using your VM to host an outside internet service, then the outside world won’t be able to distinguish your VM from your Mac, but I can’t imagine why you’d do that, anyway.

November 06, 2006 14:36 mac

Commenting by intention

me@jbrains.ca (J. B. Rainsberger) — Thu, 02 Nov 2006 00:28:50 GMT

JBR: You see? This is precisely the kind of comment I can’t stand. If this is what the code does, then why not extract a method and program by intention?

Client: We are programming by intention; it’s just that we’re capturing the intent in the comments.

(If you’re looking for my client’s tongue, you might want to check his cheek.)

November 02, 2006 00:28 agile, people, coding standards, refactoring, design, antipatterns

JDO? NFW.

me@jbrains.ca (J. B. Rainsberger) — Mon, 30 Oct 2006 05:51:44 GMT

I just finished testing something for a client (and friend) that involved JDO. I wanted to test the case where one detaches a parent object, changes one of its children (foreign keys), then re-attaches the parent. My client was having trouble because Kodo was attempting to insert a second copy of the child object, rather than simply changing the parent to point away from its old child object towards its new, existing child object. Thinking how easy that is to write in Ruby, I wasn’t prepared for the work it would take with JDO.

I went with the simplest solution I could imagine: Java, JPOX, HSQLDB, so that everything ran in memory and there would be no need for direct SQL manipulation. Even so, the documentation for JPOX was incredibly hard to find. Their web site is a frustrating maze of endless links. Not only that, the code I had to write was obscene. Duplication everywhere! No wonder people can’t build decent designs with JDO. I applaud their effort and think we should all bring them beer and pretzels to help them while they try to wrangle this absurd standard.

I didn’t need another reason to run, screaming away from Java, but I have one. Oy. Friends don’t let friends use JDO.

October 30, 2006 05:51 java, testing, refactoring, design

Kent Beck on the attitude of spreading Agile

me@jbrains.ca (J. B. Rainsberger) — Mon, 23 Oct 2006 02:45:33 GMT

In the process of catching up with the extremeprogramming mailing list, I read the following, and found it hit home. It is a reaction to Martin Fowler’s observation that management imposing Agile is rarely successful.

We think that we, as programmers or consultants, have the right to say “We should all be working in an agile way.” Why not a manager or a CEO? What makes that entirely a programmer’s perogative? Agile development is not a process that can only be dictated from the programmer level. I think that this points to an attitude problem with the structure inherent in a company, that money and power are not equally distributed and that process/work style/work culture like many other aspects of company life may not be in your individual control. If you accept company structure, how best to adopt agile process? Programmers like it if it is their idea, but long-term success is dependent on management buy-in, not programmer buy-in. Agile development is not a process that can only be dictated from the programmer level.

While I agree with Martin that imposition from on high rarely succeeds, I suspect it has much to do with the common thread of imposing process (effectively turning it into a defined process—oh, the irony), rather than aligning people to the corresponding goals. I wonder what we could do to help executives feel more comfortable trusting us with their (business) goals?

October 23, 2006 02:45 agile, people

From Java to Ruby

me@jbrains.ca (J. B. Rainsberger) — Sun, 22 Oct 2006 05:32:45 GMT

About a year ago I wrote that I was no longer a Java programmer—or rather, that my days as a professional Java programmer were numbered. I wrote this in reaction to the announcement that sooner or later the Java language was going to force us to use parameterized types. I simply found that too depressing to continue, so I chose that as a good time to switch to Ruby and have already implemented one small, but successful piece of software on the Rails platform: this weblog. Fortunately, I don’t have a manager dictating the technology I use for my projects. On the contrary, we have just started a medium-sized project in Rails, rather than being beholden to a client’s “requirement” to use a legacy platform like Java Enterprise Edition or .NET. It’s quite liberating.

Still, if I did have to convince a manager, director or client to choose Rails over Java EE, I’m glad I now have Bruce Tate’s From Java to Ruby to give them. It is a quick read, as most of the Pragmatic Programmers’ books are, and it does a very good job of outlining the advantages and disadvantages of Ruby as a development platform. If you know Ruby, then you won’t be surprised by his arguments in favor: shorter development cycles, higher productivity for simpler tasks, more design flexibility and quicker feedback. If you’re a Ruby fan then you might be surprised to read about the disadvantages, because they are likely things that do bother your manager, but don’t bother you. I’ll invite you to read the book, rather than enumerate them here.

If you are thinking of starting a grassroots movement in your organization to move even one subproject from Java to Ruby, then you need to read this book, understand its message, then be better capable of formulating an argument your management can appreciate, understand and believe. If you don’t, then you might be dooming yourself to yet another “crackpot disinformation campaign”, the kind of thing I used to do at IBM before I knew any better.

If you are a manager and your people have started putting pressure on you to adopt Ruby as a development platform, this book will help you navigate the waters, learn how to dip your toe in, or give you the solid arguments you need to convince them that you’re not ready. I suppose you could just veto them with an “I told you so”, but a reasoned argument will be better received and less likely to drive them a step closer to polishing up their resumes.

Bruce Tate’s From Java to Ruby is an indispensable field guide to those who need to decide whether to carry out a campaign to supplant Java with Ruby as your development platform of choice.

October 22, 2006 05:32 rails, java, ruby, people, review

Useless comments, an example

me@jbrains.ca (J. B. Rainsberger) — Wed, 18 Oct 2006 22:20:00 GMT

People often ask me for examples of code smells, but I never seem to have any handy, most of the ones I see are from clients, and by the time I have energy to write about them, I forget them. Today, at thedailywtf.com, I saw an example of code with plausible, but useless comments. See whether you can spot them.

//SQL Query to retreive all unbroadcast messages
string sqlCmd = 
  "SELECT o.*, r.*, ..., c.*, u.* " +
  "  FROM Orgs o, Recipients r, Contacts C, " +
  "       ... " +
  "       Groups g, Users u " +
  " WHERE m.Group_Id = g._Group_Id " +
  "   AND u.User_Id = gu.User_Id " +
  "   AND ... " + 
  " ORDER BY o.Priority_Code, o.Delivery_Num, ...";

//Execute SqlCommand
DataTable dt = DataHelper.ExecSqlToTable(sqlCmd);

//For each row retreived, insert a row into the Queue table
for(int i=0; i&lt;dt.Rows.Count; i++)
{
  //Insert Sql command
  SqlCommand insCmd = DataHelper.CreateCmd(
    "INSERT INTO Queue (Sender_Id, Recipient_Id, ...) " + 
    " VALUES (@Sender_Id, @Recipient_Id, ...))";
    
  //Add Parameters to command
  AppendParam( insCmd, "@Sender_Id", dt.Rows[i]["Sender_Id"]);
  AppendParam( insCmd, "@Recipient_Id", dt.Rows[i]["@Recipient_Id"]);
  ...
 
  //execute command
  insCmd.ExecuteNonQuery();
}

If you answered “every one”, you win!

October 18, 2006 22:20 java, coding standards, refactoring

"I don't have a name..."

me@jbrains.ca (J. B. Rainsberger) — Mon, 16 Oct 2006 00:13:18 GMT

There are some things you just want to shout to the world right away. My business partner and good friend, Niraj Khanna, just gave me a teaser for a story about his ordeal with Air Canada today. He’ll tell the complete story later, but I wanted to share this chestnut.

Niraj: What’s your name?

Agent: I work for Air Canada; I don’t have a name.

Niraj: What do you want me to call you?

Agent: “Ticket Agent.”

What?! Awesome. I’ll try that the next time I’m stupid enough to fly Air Canada.

October 16, 2006 00:13 people

The Leaky View: An antipattern in MVP

me@jbrains.ca (J. B. Rainsberger) — Fri, 06 Oct 2006 03:53:48 GMT

I have written an article about an antipattern I found in code that someone designed using the Presenter-First approach as a guideline. The Leaky View is not limited to Presenter-First, but it is a smell that I think careful application of Presenter-First should entirely eliminate, so I was surprised when it crept in.

October 06, 2006 03:53 java, testing, coding standards, refactoring, design, antipatterns, article

Shotgun Programming

me@jbrains.ca (J. B. Rainsberger) — Wed, 04 Oct 2006 11:57:41 GMT

This entry comes from a guest blogger who wishes to remain anonymous for now. As he wrote to me

I’d blog about this but some parties to whom this is directed might end up reading it and get offended. So prepare for a rant. :-)

The image is so vivid that I had to post this on his behalf. Enjoy.

The most dreadful style of programming is shotgun programming. Perhaps you’ve heard of cowboy coding. This is its ugliest, rudest form. A cowboy at least uses a pistol, a weapon which in the right hands can be wickedly accurate and effective. But the shotgun totin’ programmer makes for a completely different game. It’s a wild, drunken attack at the keyboard, launching random code at the compiler and seeing what sticks. It ignores all logged messages and compiler warnings. Documentation is never consulted. Who actually reads that stuff anyway? Thinking before shooting is not just discouraged, it’s never considered. Who needs to think when you’ve got a bloody shotgun!

The way a shotgunner approaches programming is to blindly start shooting first and ask questions later. And when something does work, well, don’t sit around worryin’ about why, just start doin’ it again! Do it again and again and again. It worked once (somehow) so it must work again, right? To take the time to understand why or how something works is a waste of time. I suppose it’s a sort of evolutionary approach to programming, where intelligence and design have no place.

And when I say blindly, I mean the “blind-folded swinging at the pinata” style. It starts with wild swings in any direction. Who knows what the right direction might be? That’s impossible! Computers are magic black boxes (of the devil, I might add). As soon as something connects, whether or not it happens to actually be the pinata, you beat the hell out of it. Of course, you never take the blindfold off to see what you’re doing, so you end up with a bloody pulp of code.

What am I talking about specifically? I’m talking about spending hours randomly debugging a problem when looking at the actual runtime error message would lead you directly to the bug within minutes. I’m talking about never, ever, looking at the documentation. I’m talking about cut and paste-ing the wrong code, sometimes entirely different applications, that’s right, cut and paste as a whole, and then strangling it into submission. I’m talking about learning one compilable trick and then using it for every solution. Or it’s the other extreme of the engineer who thinks good code is measured by the absolute number of design patterns and acronyms one can cram into an executable. It’s randomly adding methods to whatever class happens to be within reach at the moment with no thought of encapsulation or separation of concerns. I’m talking about fundamentally not caring about what it is you end up with and what depths you sink to along the way.

Of course, shotguns are so 1999. With today’s modern code generating IDE’s we allow former shotgunners to lay down their punitive arms and take up carpet bombing their code instead. And that tragedy is another rant all to itself.

October 04, 2006 11:57 people, coding standards

An alternate version of Parameterized Test Case

me@jbrains.ca (J. B. Rainsberger) — Mon, 02 Oct 2006 13:19:29 GMT

In JUnit Recipes, I wrote about the Parameterized Test Case pattern, in recipe 4.8 “Build a data-driven suite”. The problem occurs when we want to run the same test with different input and output. If we write these tests the most straightforward way, we duplicate the algorithm in the test. Even if we extract that into a method, we have to remember to invoke that method from each test. Either way, it’s avoidable duplication. In recipe 4.8, I described how to build a custom test suite so that you can specify the input and output data in a table and run a test for each row in that table. Although this involves fairly intermediate use of JUnit, it eliminates a lot of duplication. At the time, I considered it the way to express parameterized tests in JUnit.

Of course, we now have JUnit 4 and its direct support for parameterized tests. I won’t write about that here, primarily because I don’t use Java 5 much, so I also don’t use JUnit 4. Instead, I’d like to share an alternate design for parameterized tests with JUnit 3 that a student intern showed me while consulting on a large Agile transition. It’s a bit strange, but it works.

The previous approach I described consisted of these steps:

Implement a custom suite() method that iterates through a table of data and creates TestCase instances, passing each row of data to the constructor.
Implementing a constructor to store the input and output data in fixture objects (fields).
Overriding runTest() to execute the test, rather than writing a test method.

Now, instead of building a custom test suite, we can use test methods to set the fixture objects. This improves clarity of intent in the code (to a degree) at the cost of confusing the first-time reader by setting fixture objects in a method whose name starts with test. Let yourself be the judge of whether this is an improvement.

public class AlternateParameterizedTest 
       extends ParameterizedTestCaseTemplate {

    private Integer[] sides;
    private TriangleType expectedType;

    public void testEquilateral() throws Exception {
        sides = new Integer[] { 3, 3, 3 };
        expectedType = TriangleType.EQUILATERAL;
    }

    public void testIsoceles() throws Exception {
        sides = new Integer[] { 3, 4, 3 };
        expectedType = TriangleType.ISOCELES;
    }

    public void testScalene() throws Exception {
        sides = new Integer[] { 6, 4, 5 };
        expectedType = TriangleType.SCALENE;
    }

    public void testNonPositiveLengthSide() throws Exception {
        sides = new Integer[] { 5, 0, 4 };
        expectedType = TriangleType.INVALID;
    }

    public void testInconstructible() throws Exception {
        sides = new Integer[] { 3, 1, 2 };
        expectedType = TriangleType.INCONSTRUCTIBLE;
    }

    public void testInconstructibleLooksLikeIsoceles() throws Exception {
        sides = new Integer[] { 1, 4, 1 };
        expectedType = TriangleType.INCONSTRUCTIBLE;
    }

    @Override
    protected void doTest() {
        assertSame(expectedType, new Triangle(sides).classify());
    }
}

I have pulled a couple of methods up into a test template class to remove the unnecesary elements from each parameterized test case. There is one big thing not to like: those methods should be named something like fixtureInconstructible() or caseInconstructible(), rather than testInconstructible(), but that’s not something we can implement in a JUnit 3 extension. We would have to separate selecting the test methods from the test runner, something that appears already to have happened with JUnit 4. Still, I do like the way the tests read more than seeing a big table of data in a suite() method, or worse, having the test data sit outside the test case class. It’s worth experimenting with, so if you try it, please share your opinions or improvements with the junit Yahoo! group.

October 02, 2006 13:19 java, junit, testing, agile, coding standards, refactoring, design, article

There are open workspaces, then there are open workspaces

me@jbrains.ca (J. B. Rainsberger) — Sat, 30 Sep 2006 21:40:34 GMT

I spotted this in the agile project management Yahoo! group, and it caught my attention.

If someone in marketing sneezed on 11th Ave the “bless yous” made it all the way to 12th Ave.

That might be a little too open a workspace. To read more about it: go here.

September 30, 2006 21:40 agile, people

You can't please them all

me@jbrains.ca (J. B. Rainsberger) — Fri, 29 Sep 2006 03:49:45 GMT

At Agile 2006 I hosted a discovery session entitled “The Truth about Programmers and Testers”. The goal of the session is to help programmers and testers understand each other more, have more insight into the other group’s motivations and concerns. I thought the session was quite successful, and I remember feeling quite good about it when it ended. Today, I received feedback from the attendees, which was mixed. One comment stuck out.

I hoped for more ideas on how to get past the animosity between testers and programmers… not so much [a] gripe session.

I’m stumped by this one. I think the key way to get past the animosity between the two groups is to sit them down together and ask them to talk about the exact things we discussed in the session! The exercise itself is the killer idea on how to get past the animosity between testers and programmers!

This is a hazard of a real discovery session, I guess. Next time, if you simply want to be told what to do, please attend a tutorial.

September 29, 2006 03:49 agile, people, agile 2006

Is your build process under control?

me@jbrains.ca (J. B. Rainsberger) — Fri, 29 Sep 2006 01:41:33 GMT

From the text of a book I’m currently reviewing and editing.

Being able to quickly get a new developer building the project is a sign that the build process is under control.

Simple—very simple—and oh, so true.

September 29, 2006 01:41 agile, people, extreme programming, review

Flexible like in yoga or Flexible like in C++?

me@jbrains.ca (J. B. Rainsberger) — Tue, 26 Sep 2006 23:38:54 GMT

I read an article comparing JUnit 4 to TestNG today. I didn’t much care for it, although some of it was quite good. I don’t want to go point-by-point through it to rebut it, although I will share my observation that the author exaggerated the significance of a point or two. In particular, he claims TestNG pioneered—his emphasis and not mine—the use of annotations for testing in Java. Who cares? NUnit was doing that years ago and TestNG copied that. Not only that, who wouldn’t have known how to do that? Being the first to do something obvious is a pretty weak way to define “pioneer”. I digress. The one particular point I want to call out has to do with his claim that TestNG is more flexible than JUnit 4 because, in part:

Obviously the two listings [here as listings 1 and 2] are pretty similar, but if you look closely, you’ll see that the TestNG coding conventions are more flexible than JUnit 4’s. In Listing 1, JUnit forced me to declare my @BeforeClass decorated method as static, which consequently required me to also declare my fixture, finder, as static. I also had to declare my init() method as public. Looking at Listing 2, you see a different story because those conventions aren’t required. My init() method is neither static nor public.

I just don’t understand this. TestNG allows the programmer to make a class-level relationship look like an instance-level relationship and that’s a good thing? I don’t think so—it’s just poor design. What good is having an instance-level field on a class where the value of that field is the same for every instance of the class? Don’t you find that confusing? I’m sure I would, especially in the heat of battle. In fact, I’m sure I have. I imagine you have, too, at least once.

If this is the kind of “flexibility” TestNG offers, then thank you, but no thank you. I’m not going to claim that TestNG is a poor tool because of this, but I certainly think any claims of flexibility borne out of obviously poor design do a disservice, both to the claimant and to TestNG itself. Congratulations: TestNG allows you to test poorly-designed code by writing poorly-designed tests. Enjoy.

September 26, 2006 23:38 junit, testing, coding standards

Not Just Coding

me@jbrains.ca (J. B. Rainsberger) — Tue, 26 Sep 2006 00:51:33 GMT

I am pleased to announce that my new column, Not Just Coding will debut in IEEE Software magazine’s January/February 2007 edition. I hope to use this column to help coders become all-around programmers, looking beyond code into other issues related to writing software, and not just touchy-feely, interpersonal issues, but technical and practical ones. I am excited to have the opportunity to reach a broader audience, and I hope they receive me well.

September 26, 2006 00:51 writing

Attention: do not do anything that will expose our bugs

me@jbrains.ca (J. B. Rainsberger) — Mon, 25 Sep 2006 01:41:23 GMT

I won’t embarrass the site developers in public, but my wife Sarah tells me an event registration system showed her this warning message when she tried to register for an event.

ATTENTION: DO NOT USE THE SAME EMAIL ADDRESS TO TRY TO REGISTER ANOTHER PERSON. Your Email address is used to identify you and if you register another person with this email address YOUR OWN REGISTRATION WILL BE REPLACED. Each person you register must use a UNIQUE email address.

September 25, 2006 01:41 testing, coding standards, design

XP Day Montreal 2006

me@jbrains.ca (J. B. Rainsberger) — Fri, 15 Sep 2006 21:29:54 GMT

Saturday, September 23 is fast approaching. That’s the day of XP Day Montreal 2006, the third in our series of one-day conferences dedicated to Extreme Programming in North America. Although we’ve taken a year off, we’re back with top-notch speakers, including Laurent Bossavit and Michael Feathers. This, to our knowledge, is the first officially bilingual XP conference in North America, with content in both French and English. Please join us!

September 15, 2006 21:29 xpday, agile, presenting

The first goodbyes: Labball 2006

me@jbrains.ca (J. B. Rainsberger) — Wed, 30 Aug 2006 07:21:22 GMT

This past week I said my first goodbyes as we prepare to move to Dauphin, Manitoba next June. For eight years, I played a variant of softball most accurately called “recreational, sexist three-pitch”, because it’s six pitches for women. When I first joined the team, it was a rag-tag bunch. There was plenty of enthusiasm, but not much knowledge or experience, so I taught a bunch of them how to play, starting with 90-minute seminars explaining the rules of the game. (No joke. “The objective of baseball…”)

Those first few years, we were horrible. The kind of horrible that gives you nightmares, if you sleep at all. A few years of losing heavily gave us time to develop our skills, inject some more talent and gel as a team. After seasons of 1-11 or 2-10, the last three seasons we finished third, second and third, respectively, after regular seasons winning at least 75% of our games. In the meantime, we had plenty of turnover, but we had a core group of people dedicated to giving a strong effort, improving their skills and learning how to play the game well. Only the rain stopped us from our best chance at a championship in 2005.

Reflecting on this time of my life, not only am I reminded of the ups and downs, specific moments of pain and trimuph, but I also see that this has been the only real team in my life. Referring to Patrick Lencioni’s five dysfunctions of a team, I can honestly state that, for the most part, we have trusted each other, engaged in healthy conflict, come through on our commitments, held one another accountable and cared more deeply about the team’s results than our own. I see it in little things, like accepting responsibility for poor play to big things, like rearranging one’s personal schedule to be available to play for the team. Everyone on the team has grown, as players, as leaders. This is the experience I wish I could have on software projects. If I did, I think I’d look forward to them as eagerly as I looked forward to each May and the start of Labball season.

Here’s wishing you find a team like that someday.

August 30, 2006 07:21 baseball, people, moving

The Daily Scrum and accountability

me@jbrains.ca (J. B. Rainsberger) — Tue, 29 Aug 2006 23:30:19 GMT

These days I have been going back through some of my favorite books, including Patrick Lencioni’s Overcoming the Five Dysfunctions of a Team. I am certainly interested in team dynamics, not only as a coach of software teams, but also because I use these principles in my daily life in relating to my wife, my friends and others. In re-reading the section on accountability, I am struck by the idea that the Daily Scrum or Stand-up Meeting is, at least in part, an exercise in holding team members accountable to their work commitments. By asking the questions, “What did you achieve yesterday?” and “What do you commit to achieving today?” we are taking the meeting beyond a mere checkpointing activity into the realm of asking team members to account for their time in front of the rest of the team, and possibly their managers and stakeholders. This strikes me as a remarkably advanced practice!

Lencioni describes embracing accountability as the fourth step in his five-step model towards becoming a team. Before embracing accountability, we should build trust, master conflict and achieve commitment. This presents an interesting dilemma. When a team decides to adopt Scrum or XP or some other agile method, can it really institute the Daily Scrum or Stand-up Meeting right away? or is such a team jumping the gun with regard to its own development as a true team? Should we spend time overcoming the first three dysfunctions before attempting to employ this practice? If so, then why is this practice among the very first things we recommend for teams learning to become agile?

There is one way that I can reconcile these ideas, each of which I believe in separately, and that has to do with the questions we ask at the Stand-up Meeting. When starting out, team members tend to ask each other, “What did you do yesterday?” and “What do you plan to do today?” These questions are much softer than the ones I gave earlier, and perhaps a team has to spend time answering these softer questions before they can benefit from answering the harder ones related to commitments. I can’t be sure that’s the case, but it’s one way to explain the apparent contradiction. I would enjoy hearing about other ideas on the topic, so I just might write about this on a mailing list somewhere. Any recommendations on which one?

August 29, 2006 23:30 agile, people, article

I am a spammer by association. Thanks.

me@jbrains.ca (J. B. Rainsberger) — Fri, 25 Aug 2006 04:49:24 GMT

I didn’t realize that the info top-level domain is the domain of spammers. Apparently at least Yahoo! groups feels this way. After some help from James Knox and a little testing, I have found out that when I include a link to http://www.jbrains.info in my signature, Yahoo! groups counts the message as spam; whereas when I change it to http://www.jbrains.ca, all is well.

Awesome.

So how on earth did I manage to be lumped in with spammers, just for uttering—not using, because I send e-mails to Yahoo! groups with a rogers.com account—a URL that ends in .info?

August 25, 2006 04:49 people

PayPal sandbox: Message 3005

me@jbrains.ca (J. B. Rainsberger) — Fri, 25 Aug 2006 04:12:56 GMT

What is the #1 rule of software? When you demo it, it won’t work.

So there I was at the home of my business partner, demonstrating the application I was working on, which included integrating with PayPal. The big finish, of course, was how the site goes to PayPal, the shopper gives us his money, then returns to our site.

Message 3005

Have you ever seen this? According to Google there are 50 ways to get this message. (Did you sing the last part of that sentence? I did.) I tried a few fixes, like clearing my cache, destroying all my PayPal cookies, standing on one leg and barking like a dog. (OK, I made up one of those fixes.) Still, no love. I did, however, notice something out of the corner of my brain that ended up helping me solve the problem: I had changed the payee account (that is, the account receiving the funds), but that account hadn’t confirmed its e-mail address. Aha? As it turns out, yes. Once I went through the confirmation and verification ritual, all was well. I eventually remembered that the e-mail the sandbox sends is not a real e-mail to my real e-mail address. (That took only 10 minutes.)

Now, an error message with even a faint whiff of an explanation of the problem would have helped, but all I can do about that is cry. In the meantime, I am leaving this here so the next poor sap can find it when he desperately types paypal sandbox “message 3005” into Google.

August 25, 2006 04:12 testing, coding standards

Toronto: the disengaged customer

me@jbrains.ca (J. B. Rainsberger) — Wed, 23 Aug 2006 21:03:20 GMT

The last leg of the MacDonald-Cartier Freeway Experience was last night in Toronto with the XP/Agile Toronto user group. Once again, I split the group into two and asked each to develop a plan for my talk, the theme of which was Steering the Ship: the Joy and Heartbreak of Planning. It went well, on the whole. This group took only about 40 seconds to ask me a question, whereas Ottawa took 13 minutes and Montréal around 6 minutes. The Toronto group using the computer cheated (in a good way) and abandoned the computer as a planning tool, despite my objection, after about 30 minutes. That was quickest among the computer teams at all three sites. These statistics, however, aren’t the most interesting part of the evening for me.

In Toronto, two very different things happened than Ottawa and Montréal: first, after two iterations, the two customer teams joined forces and worked on a single plan, recognizing that that would create more value and reduce the effort; second, I noticed a handful of customers very disengaged, sitting in the corner and chatting among themselves. By way of the Telephone Game, word reached me that some of those people felt thrown into the deep end with no idea what to do, so they pulled out and did nothing. I also heard at least one person was quite disappointed with the event as a result. Whoever that person is, these words are for you: now you know how a typical XP customer feels on her first project.

One of the themes of XP Day Montréal 2006 is the importance of the customer role in XP. “It’s more important than you think… no really, even more important than that.” After more than half a decade, the XP community still doesn’t seem to have a learning roadmap for customers. As a result, they are thrust into the role on a team, mostly because the programmers want to work that way, and are left with the most difficult jobs of all: decide what to build, in what order, and how to describe it in a way that programmers can build. These are all responsibilities that these people might or might not have had in their past as the customer of a software project. At a minimum, it’s likely no-one has held them this responsible and demanded such relative formality in the way they ask for features. (Isn’t that ironic?) We need to do more to support our customers, especially the would-be customers who are doing this for the first time. So if you’re undertaking your first XP project, or if your customer is undertaking his first XP project, work more closely with the customer than you think you should… no really, even more closely than that. No other single decision has as much impact on the project’s success.

Really.

August 23, 2006 21:03 agile, speaking, people

Alternate implementation, or fake?

me@jbrains.ca (J. B. Rainsberger) — Wed, 16 Aug 2006 15:30:10 GMT

Sometimes it only takes a few years to figure out what I’m talking about… for me, I mean.

Years ago, when I was first learning how to use test doubles (stubs, fakes, spies, mocks), I made the distinction between fakes and alternate implementations. The distinction was always semi-clear in my mind, but I could never quite articulate it well enough to explain it to others. In the process of reviewing TDD in Action, I think I finally have it. Let me try to explain it to you.

An alternate implementation (typically, of an interface) mimics the logic of the production implementation, but is lighter weight. A fake merely hardcodes the results of methods.

Clear, isn’t it? Fine, an example is in order.

Let’s consider an authentication service, which determines whether a given user name/password pair represents a valid user. Such a thing would have a simple interface.

public interface AuthenticationService {
    User login(String userName, String password);
}

Some controller, let’s pretend it’s a plain Java class for now, needs to use this authentication service to decide whether to forward the user to the personalized welcome page or back to the login page with a “nice try” message. My test list for this feature is pretty short.

Existing user means valid User object on the welcome page.
Non-existent user means back to login page; don’t include the parameters in the request.

One way to write these tests is to create a “mock” authentication service in the style of the mockobjects.com project, that has an addUser() method. With this method, you would add users to the user directory (stored as a Map, say), then look them up with the login() method. You could use the same mock authentication service for both tests by simply attempting to login with the existing user for one test and some random obviously non-existent user for the other test. This would work, but it violates a principle of interaction testing:

When simulating a collaborator, don’t reimplement its logic.

Why not? Simple: if you reimplement the logic, you run the risk of reimplementing it incorrectly, simple though that logic may be. This is the danger of alternate implementations: you might incorrectly simulate the production implementation. This is the reason I use fakes, instead.

The fake simply answers whatever User object you need for the given test. In the happy path case, it would answer any non-null User object; in the error case, it would answer null. As my friend Pat Welsh would ask, “How do it know?” Well, each test knows how it wants the authentication service to behave, so, it just know. To show you what I mean, here is one way to write the happy path test.

public void testHappyPath() throws Exception {
    final User jbrains = User.named("jbrains");

    AuthenticationService authenticationService = new AuthenticationService() {
        public User authenticate(String userName, String password) {
            return jbrains;
        }
    };

    LoginController controller = new LoginController(authenticationService);
    controller.handleRequest(requestFor("/login")
                            .withParameter("user", jbrains.getName())
                            .withParameter("password", "don't matter")
                            .withEmptySession());

    assertForwardedTo("/welcome");
    assertModelContains("user");
    assertEquals(jbrains, modelObject("user"));
}

The key point here is that the cotestntroller doesn’t have to know the right password. There’s no way the test can use
the authenticate service incorrectly, because the test simply tells the authentication service, “Return a valid user
(meaning not null); I don’t care why.” You’ll notice that I intentionally gave the password
parameter a nonsense value, to emphasize the fact that we’re not even looking at it. This test is really
resistant to change, and that’s a big deal to me.

Incidentally, we can do better, by refactoring a little.

public void testHappyPath() throws Exception {
    final User jbrains = User.named("jbrains");

    AuthenticationService authenticationService = fakeAuthenticationServiceReturning(user);

    LoginController controller = new LoginController(authenticationService);
    controller.handleRequest(requestFor("/login")
                            .withParameter("user", jbrains.getName())
                            .withParameter("password", "don't matter")
                            .withEmptySession());

    assertForwardedTo("/welcome");
    assertModelContains("user");
    assertEquals(jbrains, modelObject("user"));
}

You can imagine how to extract code into the method fakeAuthenticationServiceReturning(). Now to write the error path test, simply have the autthenticate service return null.

public void testNoSuchUser() throws Exception {
    AuthenticationService authenticationService = fakeAuthenticationServiceReturning(null);

    LoginController controller = new LoginController(authenticationService);
    controller.handleRequest(requestFor("/login")
                            .withParameter("user", jbrains.getName())
                            .withParameter("password", "don't matter")
                            .withEmptySession());

    assertRedirectedTo("/login");
    assertModelDoesntContain("user");
    assertModelContainsMessageWithKey("login.invalid");
    assertRequestDoesntContainParameters("user", "password");
}

We could reveal more intent by extracting code into a new method named, say, neverAuthenticates(). I’m not sure about that, since I like uniformity in naming conventions.

Hm… maybe the method names should be neverAuthenticates() and alwaysAuthenticatesAs(User). Actually, those are better. If this were a real project, I’d change them, but I want to leave them as is so you can glimpse into my thought process. I hope you appreciate it, rather than finding it artificial or egotistical. You can’t please everyone.

This is one case I might introduce a class called NeverAuthenticates just to make it clearer what’s happening. I’m not a fan of the test knowing that null means “not authenticated”.

Hm. Maybe I should have separated returning the User object from determining whether the user/password combination maps to a user. Even with small tests, they can be smaller.

Still, I hope this illustrates the difference between an alternate implementation and a fake, and explains why I prefer using fakes in my tests to alternate implementations.

August 16, 2006 15:30 junit, testing, agile, coding standards, refactoring, design, article

Refactoring: Replace Conditional with Polymorphism

me@jbrains.ca (J. B. Rainsberger) — Tue, 15 Aug 2006 20:04:05 GMT

While reading a draft of Lasse Koskela’s upcoming TDD in Action, I came across a code sample that got me thinking about judging what is a code smell. As I’ve doubtless written in the past, I like really simple rules, because I can follow them easily. In particular, I like simple rules that lead me to behave agreeably. I propose such a simple rule:

Replace any structure like this
if (isFoo(someObject)) {
    doFoo(someObject);
}
else if (isBar(someObject)) {
    doBar(someObject);
}
...
with something polymorphic.

Is this a good rule to follow all the time? No. Is this a good rule to follow all the time while learning about Object-Oriented Design? Absolutely.

August 15, 2006 20:04 testing, agile, coding standards, refactoring, design

MCFE: First stop, Ottawa

me@jbrains.ca (J. B. Rainsberger) — Tue, 15 Aug 2006 16:56:53 GMT

I am in lovely Oshawa, Ontario, stopped at the local Via Rail station, on my way to Ottawa by about 16:30 today. Tonight is the first stop the MacDonald-Cartier Freeway Experience, where I’ll be both facilitating a planning session and giving a talk on planning at Cognos, located at 3755 Riverside Drive. All are welcome. For details, click the title of this entry.

August 15, 2006 16:56 xpday, agile, speaking, planning

If only TestNG were more like JUnit...

me@jbrains.ca (J. B. Rainsberger) — Wed, 09 Aug 2006 19:30:24 GMT

Please don’t interpret this as bad-mouthing TestNG. On the contrary, I like TestNG, even though I don’t use it. I think there’s plenty of room on the stage for complementary testing tools: JUnit, more rigid in its philosophy, and therefore more valuable as a design tool; and TestNG, more accommodating in its philosophy, and therefore more valuable as a testing tool. As I practise TDD more as a design activity than a testing activity, JUnit continues to be my tool of choice.

That said, I had to share part of a weblog entry, because it’s the first time I’ve seen someone say, in essence, “I wish TestNG were more like JUnit”, and in particular, JUnit 3.

The only significant change is that I changed the TestBase base class to extend from org.testng.Assert, so you can access all the assertion methods without doing a static import.

I have to chuckle at this. One of the key design points in TestNG and JUnit 4 is no longer needing to extend a TestCase class, which itself extends an Assert class. Instead, use the static import feature of JUnit 5 to use the core assertion library in your tests. To see a respected programmer (Howard Lewis Ship!) make this change tells me that it’s not just a bunch of people complaining that JUnit should be more like TestNG. Some people appreciate the design of JUnit 3, even some TestNG users. I like that.

August 09, 2006 19:30 java, junit, testing

The MacDonald-Cartier Freeway Experience

me@jbrains.ca (J. B. Rainsberger) — Wed, 09 Aug 2006 01:28:55 GMT

The schedule is set for my speaking tour of Highway 401, also known as the MacDonald-Cartier Freeway, although I will only be on the portion stretching from downtown Toronto to downtown Montréal. Here is my speaking schedule. Please join us!

Tuesday 8/15 at 7 PM, Ottawa, Cognos Inc.

Wednesday 8/16 at 5:30 PM, Montréal, le CRIM. (The presentation will be in English, mais je serai capable de répondre aux questions posées en français.)

Tuesday 8/22 at 7 PM, Toronto, Ryerson University.

August 09, 2006 01:28 xpday, agile, speaking

Webinar at agitar.com

me@jbrains.ca (J. B. Rainsberger) — Wed, 09 Aug 2006 01:17:44 GMT

Tonight I gave the first of two webinars on Test-Driven Development with J2EE. This is a condensed version of my popular tutorial, one which I have conducted at Agile 2006, XP 2006, Agile 2005, SD West 2005 and XP/Agile Universe 2004. This version has new, up-to-date content and provides a key insight into how to test complex J2EE applications almost entirely in memory. If you’re interested, click the title of this entry to learn more. The next show is 10 AM ET Wednesday, August 9.

August 09, 2006 01:17 java, junit, agile, speaking, xp2006, agile 2006

MTS: paragon of responsiveness? Surprisingly, yes.

me@jbrains.ca (J. B. Rainsberger) — Fri, 04 Aug 2006 20:04:38 GMT

I am a customer of MTS (Manitoba Telecommunications Services), because of the Academy of Learning we run in Dauphin, Manitoba. Recently I had to change the pre-authorized credit card payment settings, because we’re switching from one dividends card to another. (If CIBC’s Platinum Dividend card didn’t have a ceiling on the number of rewards dollars they handed out per year, we wouldn’t have to deal with this, but that’s another story.) I had to fill in a form, which you can see by clicking the title of this weblog entry, in order to make those changes. The form allows me to specify any province (not just Manitoba, which probably accounts of 99% of their customers), but the validation ruleset for the phone number insists on the 204 area code, which is all of Manitoba. As a result, I can choose “Ontario” for the mailing address province, but cannot specify our phone number, which is in the 416 area code. I wrote it off as yet another example of poor domain modeling, and even mentioned it in the latest version of Test-Driven J2EE (now Test-Driven Enterprise Code) as an example of creating form validation problems for yourselves.

I just received an e-mail from the nice folks at MTS Allstream, reading in part:

I had someone look into the reason why the form will only allow phone numbers starting with ‘204’. They checked into the requirements for the form, and have removed the edit on the field so you will be able to put in any phone number as well as ‘Extra’ phone numbers.

Awesome. I let them know that many of the teams I’ve worked with wouldn’t be nearly this responsive. How sad it is to be so impressed by this, but I’m impressed. Good for them!

August 04, 2006 20:04 testing, agile, coding standards

jbrains.ca is on the air

me@jbrains.ca (J. B. Rainsberger) — Fri, 04 Aug 2006 01:21:03 GMT

This web site is now also jbrains.ca. If you’ve met me, you know that I’m a proud Canadian, but not in a way that is a synonym for “anti-American”. (I won’t kid you: I used to be, but not any more.) I am especially proud to have brought XP Day North America first to Toronto, then Montréal. We are planning to hit Vancouver in 2007 and looking for other key Canadian locations. Finally, the Toronto community is working to help bring Agile 2008 to Toronto.

I plan to attend CASCon, IBM’s conference for its Centers for Advanced Studies. The Canadian Agile Network is meeting there, and I’m finally going to have the chance to become involved. (They kept meeting in Banff, which was all right, but I could never join them.)

August 04, 2006 01:21 agile

Two Ruby idioms

me@jbrains.ca (J. B. Rainsberger) — Sun, 30 Jul 2006 19:27:17 GMT

I am working some more on the registration application for XP Day North America, and find myself wanting the ternary operator, which I generally do not like to use. As a result, I have discovered two interesting idioms, the first of which I like the other of which is, well, dubious.

The first one is to replace this implementation of whether an order is taxable. At present, the design is a bit broken: an order can have a payer and an invoice, and while I’m waiting to unify the payer and invoice into a single class, the invoice takes precedence over the payer for the purposes of determining whether to charge tax on the order. As I am Canadian, I should only charge tax to other Canadians, so even if all registrants in an order are Canadian, if the invoice is sent to someone outside Canada, the order ought not to be taxable. Here’s the straightforward implementation of that method.

  def taxable?
    if invoice.nil? 
      return payer.taxable?
    else
      return invoice.taxable?
    end
  end

Notice that payer and invoice each understand taxable?, so I can eliminate the if statement by finding the first object that isn’t nil, looking first at the invoice, then the payer. This observation prompted me to type this new implementation.

    [invoice, payer].find { |each| !each.nil? }.taxable?

Aside from !each.nil?, which I wish were each.!nil? or some such, I find this idiom a bit nicer than the if statement that came before it. I welcome your opinions.

For the other idiom, I take my inspiration from Smalltalk. I have another method, which computes the tax amount, that asks the order whether it is taxable, returning either $0 or the subtotal times the tax rate. Here is the straightforward implementation.

  def tax
    if taxable?
      subtotal * tax_rate
    else
      Money.ca_dollar(0)
    end
  end

In Smalltalk, this would be

  Order>>tax  
    ^self.taxable
      ifTrue: [ self.subtotal * self.tax_rate ]
      ifFalse: [ 0 ]

Essentially, this is like mapping true and false to their respective blocks, then looking up the block using self.taxable as the key. I liked this idea, so I wrote this (in Ruby now).

    { true => subtotal * tax_rate, 
      false => Money.ca_dollar(0) } [ taxable? ]

This idiom, I think, obscures more than it reveals, so while I like removing the if statement, I’m not sure I like the resulting code. Is there a way to write this that avoids the if statement without resorting to this syntax?

Worse, this only works because the hash values are, well, values. If they were closures, it might look something like this.

    { 
      true => Proc.new { subtotal * tax_rate },
      false => Proc.new { Money.ca_dollar(0) }
    }[ taxable? ].call

Given that I still need time to get used to closures, I’m sure I got that wrong.

I suppose this is the result of talking to someone at Agile 2006 who wants to run a programming session where flow-of-control statements are not allowed… in Java. It’s a neat exercise, if nothing else.

July 30, 2006 19:27 ruby, coding standards, article

Logo contest

me@jbrains.ca (J. B. Rainsberger) — Sun, 30 Jul 2006 17:00:19 GMT

I need a logo for jbrains.info, now also jbrains.ca. I would like to hold a contest for my readers and their friends who have artistic talent. Here are the requirements for all submissions:

one version suitable for use on posters,
one version suitable for use on web site banners,
one version suitable for use in print advertising,
vector graphics format,
color and black-and-white versions, unless you’re using black-and-white only for effect.

I don’t want to constrain your design, because I want your imagination to run wild, but I will prefer entries that suggest Canada without hitting me over the head with it. For example, a big red maple leaf, beaver or beer bottle in the middle is too much.

Send your entries to logo at jbrains dot info. First prize includes:

permanent advertisement on this site as the logo’s designer,
public acknowledgement at all my speaking engagements for the next year,
free attendance to one XP Day North America event,
free sponsorship for one XP Day North America event.

The attendance and sponsorship are transferable, in case the entrant doesn’t need the advertising or has no real interest in extreme programming.

The contest ends September 30, 2006 or later, if I haven’t received an entry that I absolutely fall in love with.

July 30, 2006 17:00

Stand-up/Daily Scrum: focus on achievement and commitment

me@jbrains.ca (J. B. Rainsberger) — Fri, 28 Jul 2006 13:02:26 GMT

I’ve just finished reading an article by Jason Yip collecting some patterns and smell related to the daily stand-up or Daily Scrum. Rather than review the article, I wanted to emphasize a point you can find in the article, but that I believe is not adequately highlighted.

Here is one smell Jason did not mention that I have observed repeatedly: Yesterday I worked on X. Today I’ll continue working on X. You can smell this when more and more team members express their progress in terms of working on some vague, high-level unit of work, such as a larger story. This is especially a problem with teams whose average story takes several days to complete. The problem I have with reporting progress this way is that it tells me little about what’s really happening. It’s very easy to talk about the same X for several days, indicating that someone might be stuck and needs help.

Rather than describe what you were or are working on, focus on what you achieved yesterday and what you’ve committed to for today. This gives me a much better feeling of progress, and when someone says, “I achieved nothing yesterday”, but doesn’t report any obstacles in their path, you know it’s time to ask some questions. Finally, by committing to something today, you are practising keeping your commitments. The more you do that, the more your team will do that, and your team probably needs to do much more of that. Even if your commitment is small, don’t underestimate it. Think of this: “If I get nothing else done today, I’ll at least have done Y.” Indeed, Y might be the only important thing you absolutely must complete today. If so, concentrate on it.

If you’ve encountered this smell on your team, then I hope my suggestion will help you. If you have alternate solutions to this problem, feel free to send me some details by e-mail.

July 28, 2006 13:02 agile, people

Add your notes: the Truth about Programmers and Testers

me@jbrains.ca (J. B. Rainsberger) — Fri, 28 Jul 2006 12:25:56 GMT

Our discovery session entitled “The Truth about Programmers and Testers” created some wonderful discussion. We brainstormed a number of topics about the relationship between programmers and testers, broke into groups, discussed them, then reported results to the larger group. I am asking you now, if you have notes from that discussion, to post them. Click the title of this entry get started.

Thank you for everyone who took the time to join us and explore this important topic. I will keep in touch about whether there is enough material for a paper.

July 28, 2006 12:25 testing, agile, people, agile 2006, writing

Webinar: Test-Driven Development in J2EE

me@jbrains.ca (J. B. Rainsberger) — Fri, 28 Jul 2006 09:58:16 GMT

Agitar is hosting a complimentary live seminar based on my popular tutorial (now called) “Test-Driven Enterprise Code”. If you are interested in learning how to apply TDD effectively to enterprise applications, and avoid the typical pitfalls of the most comon approaches, then join us in August for an hour! Click the title of this entry to learn more.

July 28, 2006 09:58 java, junit, testing, speaking

Test-Driven Enterprise Code: Wednesday at 1:30 PM

me@jbrains.ca (J. B. Rainsberger) — Wed, 26 Jul 2006 06:31:27 GMT

I will be presenting a tutorial entitled “Test-Driven Enterprise Code” (formerly “Test-Driven J2EE”) on Wednesday at 1:30 PM at Agile 2006. In this tutorial, which combines lecture, demonstration and a question-and-answer period, I will share techniques I have uncovered, learned, developed and stolen to solve the fundamental problem of writing fast, small, easy-to-understand tests in the presence of a wrath of expensive, external resources and frameworks. This session complements the “Agile Web Development” hands-on session in which I participated on Monday. I hope you’ll be able to join us, as Gareth Powell and Naresh Jain will join me in answering your questions for the last hour of the session.

See you in the afternoon!

July 26, 2006 06:31 junit, testing, speaking, agile 2006

Extreme Test Makeover, Monday at 1:30 PM

me@jbrains.ca (J. B. Rainsberger) — Mon, 24 Jul 2006 12:54:46 GMT

Although I had originally planned to hang out at Extreme Test Makeover most of the afternoon, plans change. I will be there during my “official” time slot after lunch, and if I manage to get away from my other responsibilities long enough, I’ll spend some more time there. If you have a codebase that needs tests, any kinds of tests, we have the makeover artists to help you out! We’ll help improve the testability of your design and teach you a few tricks of our trade.

Are your tests disheveled, flabby, or unfocused? Bring them in for a makeover! We’ll have makeover artists who are experts in unit and acceptance testing, with tools such as Fit, JUnit, NUnit, Watir, and more. This is a hands-on session—bring your laptop with your tests and a development environment, running and ready to test. Or just come and observe how the experts work….

July 24, 2006 12:54 junit, testing, agile, agile 2006

Freebird

me@jbrains.ca (J. B. Rainsberger) — Mon, 24 Jul 2006 12:48:49 GMT

The “Agile Web Development” session got off to a rocky start, as all such sessions do—setting up the attendees’ machines is never straightforward in spite of our best efforts. Still, once people got going, it went well. Gareth Powell and Pat Welsh of Ternary Software unveiled a small Java framework named “Freebird” that aids in doing something the Java EE platform has never seem to got right: making simple things easy. One of the things I’ve often said about Java EE is that simple features are as painstaking and time-consuming as complex ones, due to all the configuration. Freebird aims to change that.

Thanks to all the people who joined our session. Thanks to Gareth and Pat for inviting me. Thanks to Dmitri Dolguikh for also joining the staff for the afternoon. I had fun.

July 24, 2006 12:48 java, testing, agile 2006

Agile 2006: "Agile Web Development" at 1:30 PM on Sunday

me@jbrains.ca (J. B. Rainsberger) — Sun, 23 Jul 2006 16:22:20 GMT

The first item on the program is the hands-on session “Agile Web Development”, where I’m helping out the folks from Ternary Software. From the abstract:

This session is a fully hands-on guided opportunity to test-drive real software changes using both unit and acceptance level tests working with these frameworks. […]

People attending this session are highly recommended to also attend Test-Driven J2EE: Life Outside the Container with J.B. Rainsberger for a more in-depth understanding of the principles and techniques involved.

See you there.

July 23, 2006 16:22 speaking, agile 2006

Arrived at Agile 2006

me@jbrains.ca (J. B. Rainsberger) — Sun, 23 Jul 2006 16:17:52 GMT

We made it, and it was a very dull flight—just the way I like it.

Now it’s off to register, find some lunch and meet up with old friends. Be on the lookout for me and don’t hesitate to introduce yourself!

July 23, 2006 16:17 agile 2006

True object testing when using the file system

me@jbrains.ca (J. B. Rainsberger) — Mon, 17 Jul 2006 22:12:42 GMT

Click the title of this entry to read about how Vincent Massol tests Java code that uses the file system. I’m glad to know there’s such a thing as the VFS library, part of Jakarta Commons. I imagine I would have done essentially the same thing Vincent has done. I think I would try using VFS the next time I’m doing file system-intensive work in Java.

July 17, 2006 22:12 java, junit, testing

Extreme Test Makeover at Agile 2006

me@jbrains.ca (J. B. Rainsberger) — Mon, 17 Jul 2006 20:22:07 GMT

I am one of the “makeover artists” at Extreme Test Makeover for Agile 2006. If you’re attending and would like some code made over to be more testable and tested, please bring it with you to Agile 2006 Monday afternoon. I will try to hang out there for much of the day, but my “official” time slot is 1:30 PM to 3:00 PM.

For more information, join the discussion at the Extreme Test Makeover Yahoo! group. See you there!

July 17, 2006 20:22 junit, testing, agile, speaking, agile 2006

Mr. Happy Object, or Useless Examples in Articles

me@jbrains.ca (J. B. Rainsberger) — Fri, 14 Jul 2006 03:17:08 GMT

I recently answered a question on the junit Yahoo! group. The questioner included text from an article about when to use class-level (static) methods and when to use instance-level methods. While I don’t wish to single out the article’s author, I do wish to single out the article, because I found its example ludicrous. To give you an idea, here is some of the article’s example:

public class MrHappyObject {
    private String _mood = _HAPPY;

    private final static String _HAPPY = "happy";
    private final static String _ANNOYED = "annoyed";
    private final static String _ANGRY = "angry";

    public void printMood() {
        System.out.println("I am " + _mood);
    }

    public void receivePinch() {
        if (_mood.equals(_HAPPY)) {
            _mood = _ANNOYED;
        }
        else {
            _mood = _ANGRY;
        }
    }

    public void receiveHug() 
        if (_mood.equals(_ANGRY)) {
            _mood = _ANNOYED;        
        }
        else {
            _mood = _HAPPY;
        }
    }
}

Mr. Happy Object?! What kind of example is that? I don’t mean to be rude, but an example like this seems to serve only to insult the reader’s intelligence. I also find it lazy, although I admit it’s better than examples with nonsense like int a = 3; int b = 4;.

Please, if you’re writing articles with code, please make the code examples at least somewhat meaningful. Use concepts that your readers will generally be able to understand. One person’s humor is another person’s condescension.

As a footnote, let me make it clear that this is not an indictment of the author of this article. Many more than he use nonsensical examples in their writing.

July 14, 2006 03:17 coding standards, writing

This site's downtime

me@jbrains.ca (J. B. Rainsberger) — Thu, 13 Jul 2006 20:22:17 GMT

If you’ve noticed this site has had some unusual downtime recently, I’ve noticed that, too. It looks like some differences between my TextDrive account’s environment (notably the PATH variable) and cron’s environment mean that my Rails applications were not starting when the server restarts. I think we have that fixed now, so I hope to avoid the problem in the future. I apologize for any annoyance or inconvenience as a result.

It would be nice, though, to have a way of running my scripts in the same environment as cron runs on my TextDrive server. I’ll ask the nice folks at TextDrive about that, and see what they say.

July 13, 2006 20:22 testing

Rails: associations, foreign keys and NOT NULL

me@jbrains.ca (J. B. Rainsberger) — Sat, 08 Jul 2006 03:01:18 GMT

I’m confused, and I welcome some help.

The Rails application I am working on has a richer model than my weblog does, so I have had to work with associations between model objects more than I had to before. This, on its own, is not a problem. The problem occurs when I combine Rails associations with NOT NULL foreign keys. It seems to be slowing me down.

Here’s an example: when you register for XP Day Montreal 2006, you can request an invoice if your company is forward-thinking enough to pay your way. (I’m just jabbing a little—hold your cards and letters.) No problem: you enter your company’s contact information and we e-mail them an invoice. So far, so good, but what happens when we consider what happens in the model… and the database?

It’s no surprise that an Order has_one :invoice and that an Invoice belongs_to :order, I hope. This means that table invoices has a foreign key to orders, referring to the latter’s id column. Of course, an invoice shouldn’t exist without an order to which to attach itself, so the foreign key is NOT NULL. I would think this makes perfect sense, but I’m finding it difficult to deal with in Rails. The problem comes when I try to attach the invoice to its order in my controller. I seem to have fallen into a chicken-and-egg problem.

When someone requests an invoice, it’s possible they don’t type enough information in, so of course I have added validate_presence_of for those attributes of Invoice. Now the only way I know how to check whether the invoice is fully filled-in is to save it:

  def request_invoice
    flash[:notice] = "We have sent an invoice as requested."
    @invoice = Invoice.new(params[:invoice])
    if @invoice.save
      session[:order].invoice = @invoice
      RegistrationMailer.deliver_invoice(@invoice)
      redirect_to :action => 'thank_you'
    else
      render :partial => 'request_invoice'
    end
  end

The problem is that when I try to invoke Invoice#save, I get this:

ActiveRecord::StatementInvalid: RuntimeError: ERROR     C23502  Mnull value in column "order_id" violates not-null constraint....

Now, since I invoke Invoice#save explicitly, and before the invoice is attached to the order, the invoice’s order is nil. Just before I attach the invoice to its order, the database complains that I’m inserting a NULL into a NOT NULL column. I wouldn’t have this problem if I didn’t invoke Invoice#save, but then I wouldn’t validate the invoice’s fields that way, either.

Damned if I do…

From where I sit, here are my options:

Remove the NOT NULL constraint from the order_id column, which I dislike, because a NULL foreign key doesn’t make sense here.
Explicitly set the :order attribute on the new invoice, which I dislike, because everything I’ve read makes it look like I shouldn’t have to do that.
Validate the invoice another way, such as invoking Invoice#validate directly. I’m unsure of this, because I don’t even know whether it’ll work at all, and I’ve never had to do explicit validation before, so it seems too low-level—Rails ought to handle this for me, somehow.

So since I don’t know what good Rails style is yet, I could use some advice.

I decided to invoke Invoice#valid? instead of Invoice#save, since that communicates best of the above options. If there’s something obviously better that I should I have done, do tell me.

July 08, 2006 03:01 rails, ruby

Rails annoyance: ActionMailer and nil

me@jbrains.ca (J. B. Rainsberger) — Tue, 04 Jul 2006 23:44:52 GMT

I’m test-driving some e-mails, checking that the recipients are computed correctly and I have come across some annoying behavior in ActionMailer. I would be indebted to anyone who could explain this to me.

When I pay for your registration, I want to be CCd on the e-mails involved; however, when I pay for my own registration, there is no need for a CC list, so I think it ought to be empty. As a result, here is the test I wrote:

  def test_pending_recipients_self_pay
    jbrains = people(:jbrains)

    response = RegistrationMailer.create_pending(
                   :attendee => jbrains, 
                   :payer => jbrains)
    
    assert_equal [jbrains.email], response.to
    assert_equal [], response.cc
    assert_equal [RegistrationMailer::ORGANIZER_EMAIL], response.bcc
  end

Unfortunately, response.cc returns nil, rather than []. This forces to write the test this way:

  def test_pending_recipients_self_pay
    jbrains = people(:jbrains)

    response = RegistrationMailer.create_pending(
                   :attendee => jbrains, 
                   :payer => jbrains)
    
    assert_equal [jbrains.email], response.to
    assert_nil response.cc
    assert_equal [RegistrationMailer::ORGANIZER_EMAIL], response.bcc
  end

Why, oh why have this silly behavior? Is this a Ruby idiom I just have to get used to? It seems downright careless to force me to worry about whether the “cc” list is nil.

Am I missing something? Is there a method I can invoke that hides this craziness from me? Should I report this to the Rails project as a bug? Please let me know.

July 04, 2006 23:44 rails, ruby, testing, coding standards

Review: Rails Recipes

me@jbrains.ca (J. B. Rainsberger) — Tue, 04 Jul 2006 22:17:56 GMT

I am a novice Rails programmer, that much is certain. As a result, I’m quite happy to have Chad Fowler’s Rails Recipes by my side. I have been part of the beta program for this book, so I’ve been reading it in parts for the past few months. It has been impressive, to say the least. As an author of my own “recipes” book, I am interested to see other authors’ version of the recipe format, just in case I am able to incorporate something they do into a future book of my own. While Rails Recipes hasn’t taught me much about writing a recipes book, it has taught me an awful lot of great things about Rails.

I look forward to using Chad’s recipes in my current projects. I already have a couple of ideas, including prettying up my URLs and creating a custom form builder. If I had one criticism, it’s the relative paucity of testing recipes. Writing Rails applications test-first is still a struggle for me, and I know there are those from whom I can learn. I would like the opportunity. (How many of you would like to come to Toronto to teach me?) I suppose I’ll have to write a few testing recipes of my own. Stay tuned.

Overall: 4 out of 5 on the amazon.com scale.

July 04, 2006 22:17 rails, ruby, testing, agile, review

See you at Agile 2006

me@jbrains.ca (J. B. Rainsberger) — Tue, 04 Jul 2006 18:07:18 GMT

To those of you attending Agile 2006, I look forward either to seeing you again or meeting you. Find me and say, “Hello.” Buying me a drink is always welcome.

Here is my speaking or presenting schedule, in case you want to catch me in action:

Sunday 7/23 at 1:30 PM—Hands-on #1, Agile Software Development, co-hosting with Gareth Powell and the folks from Ternary Software

Monday 7/24 11:00 AM onward—Hands-on #2, Extreme Test Makeover

Tuesday 7/25 at 1:30 PM—Discovery session #12, The Truth about Programmers and Testers

Wednesday 7/26 at 1:30 PM—Tutorial #30, Test-Driven J2EE

The rest of the time, I’ll be in Open Space, attending other sessions or just generally hanging out. Naturally, in the evenings, I’ll be partying.

See you there!

July 04, 2006 18:07 agile, speaking, agile 2006

The 401 tour

me@jbrains.ca (J. B. Rainsberger) — Tue, 04 Jul 2006 17:56:55 GMT

In August I will be going on a three-city tour to promote XP Day Montreal 2006. I will be speaking in Ottawa, Montreal and Toronto at the local XP or Agile user groups. The topic of my talk is Steering the Ship: The Joy and Heartbreak of Planning.

Planning is easy: pick a direction, write stories, prioritize, estimate, project and it’s clear we can ship something in November and we’ll be done in 2008.

Planning is hard: I need it all, I need it all now, you’re the programmer—you know what to do.

So which is it? Let’s find out. Whatever else happens, plan on planning.

For more information, stay tuned to this weblog, or visit the various user groups’ web sites or mailing lists.

(If you’re wondering what “401” means, it’s the highway that stretches in part from Toronto, through Ottawa to Montreal. It would be funnier if you lived here.)

July 04, 2006 17:56 xpday, agile, speaking

I'll let you run the business if you let me handle the 1s and 0s...

me@jbrains.ca (J. B. Rainsberger) — Tue, 04 Jul 2006 16:16:56 GMT

I’m a fan of The Daily WTF, even though much of the time, they show us things I’ve never seen from co-workers or a client. Sometimes it’s helpful to be reminded just how differently people think. Ordinarily, I join in with the chorus of people singing, “What an idiot!” A recent thread, however, got me thinking.

If you don’t want to go read the thread, here is a summary: both the Product Manager and then the Marketing Directory of some random company don’t want to include build information in the software because the users might interpret Release 2.8 Build 448 as “it took us 28 releases and 448 builds to get it right!” Naturally, what follows are reactions like What idiots! and Support would have nightmares!. Eventually, though, someone pointed out that we could simply use the release date to uniquely identify versions of the product for support. That’s simple enough.

One person responded with this:

These people should not be making technology related decisions. I guess when 99.99% of the world is full of retards, then the last 0.01% are left to do all the heavy thinking… I really think that product managers should be able to be fired by the engineering staff, not the other way around.

I wonder about this. Is this really a technology-related decision? We are displaying information to the end users, and everything we display is part of the corporation’s brand image. This is why we have splash screens and put logos into web forms. If it is customer-facing, it affects how the customer perceives the brand and so perhaps it’s a business decision. In particular, it might be a marketing or public relations decision.

Imagine how far we can take this, though.

Which of these are business decisions and which are technical decisions?

Splash screens and logos on forms
Build numbers or version identifiers
Release notes
Information written to log files
Defect rates
Simplicity of the design

July 04, 2006 16:16 testing, agile, people, coding standards

Just To Be Clear: Rails and customized model relationships

me@jbrains.ca (J. B. Rainsberger) — Sat, 01 Jul 2006 20:20:11 GMT

This is the beginning of a new pseudo-column, titled Just To Be Clear. I intend to write about things I learn after either misunderstanding or finding unclear the existing documentation on the subject. In many cases, I simply don’t read carefully enough, but in general, I try to make as few assumptions as possible, and when that happens, sometimes I find gaps in either the literature or in product documentation. When I find those things, I will share them with you, partly as Google bait for the next poor soul who goes down the same path I do.

The first instalment of Just To Be Clear has to do with customizing model relationships in Rails. As you might know, you can easily express a parent-child relationship by adding foreign keys to the underlying database tables, then the appropriate use of :has_one, :has_many and :belongs_to. (While there’s more to it than that, I hope that’s enough explanation for now.) If you follow the naming conventions, you can get away with just doing this, for example:

class Order < ActiveRecord::Base
  belongs_to :person
end

In your database, you’ll have a table named orders with a foreign key named person_id that refers to the people table’s id column. But the person to whom the order belongs isn’t just any old person, but rather the payer. As a result, I’d rather call this person the payer in my code. Consulting Agile Web Development with Rails, I find I can do this:

class LineItem < ActiveRecord::Base
  belongs_to :paid_order,
             :class_name => "Order",
             :foreign_key => "order_id",
             :conditions => "paid_on is not null"
end

That seems simple enough, but I want to name my foreign key payer_id, so Rails will probably understand that an order’s payer should correspond to the column payer_id. It does everything else magically, so why not? I tried this:

class Order < ActiveRecord::Base
  belongs_to :payer, :class_name => "Person"
end

Well, it didn’t work. After 15 minutes of playing around in the Rails console, I noticed that my order objects had both a payer_id and a person_id, so while the payer attribute was correctly assigned, the payer’s id was assigned to person_id, and not payer_id. When I tried to save my order, the database would understandably complain about my trying to save a NULL value in the payer_id column.

So, just to be clear, Rails’ magic does not extend to knowing that the relationship :payer corresponds to a foreign key column payer_id; instead, it assumes the foreign key column name follows the model class name convention, which in this case is person_id. If you want the behavior I want, you need to specify the :foreign_key option.

July 01, 2006 20:20 rails, ruby, testing, just to be clear, article

This is why we pair (or, I am colossally stupid)

me@jbrains.ca (J. B. Rainsberger) — Fri, 30 Jun 2006 02:49:05 GMT

I would like to publicly thank Anthony Williams for telling me the obvious reason why this weblog’s font looked five sizes too big with Internet Explorer. This screenshot should say it all:

When I changed the second <h2> to </h2>, the page magically looked normal in Internet Explorer.

I would also like to think Anthony for introducing me to the Tidy plugin for Safari. With its help, I have eliminated all the errors and warnings from my main weblog page. I will be even happier once such a plugin appears for Camino.

Anthony, I owe you a beer.

June 30, 2006 02:49 testing, agile, people

CSS, Internet Explorer... I give up

me@jbrains.ca (J. B. Rainsberger) — Wed, 28 Jun 2006 01:52:25 GMT

For the moment, this site does not support Internet Explorer. Although I use the site stylesheet on three different sites, IE does not seem to render the pages on this site correctly. Since I don’t know what to do, I’m going to stop trying for now. Do not bother trying to visit this site with IE, as you won’t be able to read it. At least there’s an apologetic message awaiting you if you try. For now, it’s the best I can do.

June 28, 2006 01:52

This weblog has a defect

me@jbrains.ca (J. B. Rainsberger) — Tue, 27 Jun 2006 23:29:14 GMT

Today I tried to show someone an article on my weblog. When we navigated there with Internet Explorer, we were surprised to see very, very large letters. The font on IE appears to be about 5 times as large as it renders with Camino or Firefox. I don’t know what the problem is yet, but I’m dealing with it now. In a few moments, I’m going to add an alert to the site that detects IE and says, “Sorry, there’s a defect here that makes this site look weird in IE. Please try another browser until we fix the problem. We’re working on it.” I hope to have fixed the problem in the next hour or so. We’ll see.

I suppose I could say I didn’t test enough, but I’ve never seen this kind of problem before, so I couldn’t possibly have anticipated it. The good news is this: I’m about to learn something.

June 27, 2006 23:29 testing

10 ways to guarantee your presentation is a dismal failure

me@jbrains.ca (J. B. Rainsberger) — Sun, 25 Jun 2006 15:18:17 GMT

Have you ever wondered what makes great presenters great? I do, and while I don’t have the secrets to greatness, I can provide a recipe for disaster. You might not have to do all these things in the same presentation to fail miserably, but certainly if you have the discipline to do them all, only failure can possibly follow.

Show up late. I imagine few things show less respect for an audience than not showing up on time. If you have problems during your presentation, they will typically be less inclined to give you the benefit of the doubt. Some will dismiss you as a bozo, and you might not enjoy that.
Make lame jokes about showing up late. You might think you’re lightening the mood or injective some levity, but subconsciously, you’re probably just trying to deflect responsibility to someone or something else. If you’re late, you’re late—admit it, apologize, then move on.
Prepare, a little. The less you prepare, the less likely you’ll be able to handle problems during your presentation, and the less likely your words will hang together and make sense as a whole.
Assume your equipment will work. I use a Mac for my presentations, and so I usually ask the host whether I should expect any problems connecting to their projector. It is important to distinguish, “No, there will not be any problems” from “I don’t see any reason why there should be a problem.” The first indicates that previous presenters have successfully connected with their Mac, and the second indicates that no-one knows what will happen. Especially in the second case, prepare for the worst to happen.
Don’t have back-up materials. When the worst happens and you can’t use your visual material, you need some kind of back-up plan, whether it’s to ignore the material entirely, draw on a whiteboard or something else.
Let technical problems distract you. When your visuals fail you, it’s back to execute your back-up plan and move forward. If you let the problems distract you, then you won’t be present for your audience and they will notice. Put yourself in the frame of mind of someone that doesn’t have visual equipment at all, that way you won’t be tempted to “resume the normal program” if, by some minor miracle, things work themselves out. Concentrate on your message and do your best to present it.
Try to fix technical problems while continuing to present. Even if your audience somehow doesn’t notice when you’re distracted, they will certainly notice when you half-ignore them. If you really want to solve your technical problems, excuse yourself, take the time to concentrate on fixing the problem, then fix it. If after a minute or two you have no solution, then ignore the visuals and move on. Do not, however, talk to the computer or projector as thought it were the audience. If you’re going to talk to the audience, then give them your full attention.
Make lame jokes to cover your frustration. While I wouldn’t go so far as to say, “Never let ’em see you sweat,” being passive-aggressive in your reaction to your frustration is no good either. Your audience will understand if you’re frustrated, but they want you to get past it and say what you came to say. Making jokes to cover your frustration helps you remain distracted by it, and as I’ve already said here, that keeps your attention divided, and the audience will not appreciate that.
Forget your key premise. What worse outcome from frustration could there be than forgetting your key premise? The audience has already put up with your late arrival, your inability to get over technical problems, and now you leave them wondering just what on earth you were talking about. Can it get any worse?
Just give up. Your audience wants you to succeed. If you let yourself, you can almost feel them pulling for you, in spite of all the problems you’ve gone through in front of them. The audience deserves your best effort, so giving up near the end, rather than collecting yourself and getting over the finish line is a cop out. If you plan to do that, then don’t accept the next invitation to speak.

For direction and suggestions on great presenting, I heartily recommend following the advice of people like Guy Kawasaki and Garr Reynolds, as well as watching presentations from dynamic speakers like Steve Jobs.

June 25, 2006 15:18 xp2006, presenting

Test-Driven J2EE... the apology

me@jbrains.ca (J. B. Rainsberger) — Mon, 19 Jun 2006 05:04:26 GMT

I would like to apologize to those who attended my tutorial at XP 2006. It seems I suffered from food poisoning at breakfast, and it wasn’t until about 30 minutes into my tutorial that I began to feel the full effects. After one day of violent illness and one day of recovery, I’m rejoining the conference today (Monday). I appreciate your understanding and hope that I can make this experience up to you at a later date. If you have any suggestions on what I can do, please e-mail me to let me know (me at jbrains dot info).

June 19, 2006 05:04

Test-Driven J2EE at XP 2006... the presentation

me@jbrains.ca (J. B. Rainsberger) — Sat, 17 Jun 2006 07:51:46 GMT

Click the title of this entry for the presentation slides for Test-Driven J2EE from XP 2006.

June 17, 2006 07:51 agile, speaking, xp2006

Test-Driven J2EE at XP 2006... corrected

me@jbrains.ca (J. B. Rainsberger) — Fri, 16 Jun 2006 23:18:28 GMT

I have uploaded an improved version of the Test-Driven J2EE project in response to a defect I released. (Shame on me!) If you receive this error message when you deploy:

18:25:30,078 ERROR [MainDeployer] Could not create deployment: file:/C:/jboss-4.0.4/server/all/deploy/coffee.war<br>org.jboss.ws.WSException: java.lang.ClassNotFoundException: org.apache.cactus.server.ServletTestRedirector

this means that I left some configuration behind related to Cactus. Since I don’t include Cactus in the project, it cannot deploy properly. You can either change the file conf/coffee.war/web.xml to remove the references to Cactus or download the project archive again (by clicking the title of this entry).

I apologize for the confusion. See you at 9 AM!

June 16, 2006 23:18 xp2006

Live from Oulu

me@jbrains.ca (J. B. Rainsberger) — Fri, 16 Jun 2006 12:20:09 GMT

We have arrived in Oulu, and are now on the hunt for some power adapters to accommodate the plethora of electronics we have brought with us. This is the one part of the trip we’ve done a poor job of planning.

So we are at the hotel. For anyone else attending XP 2006 who has arrived, feel free to e-mail me (me at jbrains dot info) and let me know whether you’re interested in getting together for food or drinks sometime in the next few hours.

June 16, 2006 12:20 xp2006

A complaint about OpenOffice Impress? (Maybe not.)

me@jbrains.ca (J. B. Rainsberger) — Fri, 16 Jun 2006 12:17:02 GMT

I have just spent the past 30 minutes cleaning up about 50 presentation slides. Most of the clean-up was related to re-applying a standard layout to all the slides, something that Open Office’s Impress application doesn’t allow me to do in bulk. This meant clicking on each slide, re-applying the layout, then moving to the next. As I was doing this, I first thought, Why doesn’t Impress make this easier? My second thought was Why do I have so many slides?

I believe it’s too late to fix this for tomorrow, since it’s easier to skip over slides than it is to move that content into a new format for my attendees to use, but I think I need to address this problem before Agile 2006 in July. We’ll see how disciplined I am. (Care to wager?)

June 16, 2006 12:17 speaking, xp2006, presenting

An observation about Helsinki

me@jbrains.ca (J. B. Rainsberger) — Fri, 16 Jun 2006 12:15:48 GMT

After 8 hours aboard a Finnair flight, I’m happy to be in Helsinki. To say the flight was uncomfortable would be a mild understatement, so it’s a good thing I slept through 6 of the 8 hours. I am sitting in an airport cafe, sipping cappuccino while Sarah tours the shops. My first bit of mild culture shock is the proliferation of blond people: after years of living in ethnically-diverse Toronto, I am struck by the relative homogeneity of the people here. Of course, this is entirely a superficial observation, but it strikes me nonetheless. In about 3 hours we will arrive in Oulu. I look forward to reaching the hotel and resting before trying to find fellow conference-goers for a late lunch or some early drinks. In the meantime, I’m working a little on improving the presentation material for Test-Driven J2EE, mostly by shortening it.

June 16, 2006 12:15 people

Test-Driven J2EE at XP 2006

me@jbrains.ca (J. B. Rainsberger) — Thu, 15 Jun 2006 19:12:59 GMT

For those of you attending my Test-Driven J2EE tutorial Saturday morning at XP 2006, here are rough-and-ready instructions for preparing your machine to work. If you don’t bring a laptop with you, don’t worry, you can pair with someone else!

Install Eclipse 3.1.1 (sorry, it has to be that version).
Create a new workspace, just to avoid overwriting any settings you care about.
Under Installed JREs, choose JDK 1.4 (not JDK 1.5).
Install the Web Tools Platform (WTP) from update site http://download.eclipse.org/webtools/updates/, then restart the workbench when prompted to do so.
Install JBoss 4.0.4 from jboss.org.
Install JBoss-IDE 1.5.1 GA All Plugins by unzipping the package, then copying the contents into the plugins and features directories of your Eclipse installation.
Download this Eclipse project, then unzip it to your file system.
Import the project into your workspace, calling the project TestDrivenJ2EE.
Open the project’s properties, choose Packaging configuration, then enable packaging.
Run all the tests in the source folder tests/source. Ignore one warning in XMLTestCase, since this is a defect in either the JUnit test runner or XMLUnit.
Run packaging for the project. (Right-click the project, choose Run packaging.)
Create a JBoss test server through the Debug… menu.
Deploy the project to your new test server.
If this step fails with an error message about ServletTestRedirector, then you have an older version of the Eclipse project. Download it again. See this entry for details.
Start the JBoss server (in Debug mode).
Run all the tests in the source folder livetests/source. All the tests should pass.
Open a browser and go to http://localhost:8080/coffee. You should see a Register link. Try playing around with the application.

If you’re unsure how to perform any of these steps, dive in and read some documentation. If you’re completely unfamiliar with Eclipse, then it might be better to pair with someone else in the tutorial, if you prefer not to learn Eclipse at this point.

See you Saturday morning!

June 15, 2006 19:12

Heading to Finland for XP 2006

me@jbrains.ca (J. B. Rainsberger) — Thu, 15 Jun 2006 16:32:11 GMT

Well, my wife and I are making the final preparations for our flight to Oulu, Finland for XP 2006. This is my first time attending the European XP conference, so I’m looking forward to the new experience. We had such fun traveling to Paris for XP Day France 2006, so I’m hoping for more of the same in beautiful Oulu.

I’ll be presenting Test-Driven J2EE at the conference, as well as an experience report and sitting on a panel discussion about Agile Software and Open Source. I enjoy being so involved in the conference, but I’m mostly looking forward to the after-conference activities: sitting in pubs chatting with colleagues over drinks. To me, this is the real value of these conferences. Many of my fellow attendees agree. What’s more is that I’ll get to meet many members of the European XP community that I only know from the mailing lists. I look forward to meeting you!

I’ll try to chronicle my experience at XP 2006, but I might be too busy doing it to write about it. That’s how it goes!

June 15, 2006 16:32 agile

Ruby: concatenation or interpolation?

me@jbrains.ca (J. B. Rainsberger) — Wed, 07 Jun 2006 22:31:31 GMT

I have a question about Ruby coding standards. As I read more Ruby code, I see a haphazard combination of string concatenation and interpolation, sometimes in the same line of code.

def nice_title
  (title || works[0].nice_title) +
  " (#{publisher.name}, #{year})"
end

(from David A. Black, Ruby on Rails, page 409.)

Wouldn’t this method be better written like so?

def nice_title
  "#{title || works[0].nice_title} (#{publisher.name}, #{year})"
end

This is no slight against David—his book is excellent, and I’ll be reviewing it soon—but it seems odd to mix concatenation and interpolation together like this. If you’re a Ruby programmer and have an opinion on this issue, please click the title of this entry and send me your thoughts.

It boils down to this question: I tend favor interpolation over concatentation. Is there any specific reason not to do this?

June 07, 2006 22:31 ruby, coding standards

That's unacceptable

me@jbrains.ca (J. B. Rainsberger) — Wed, 07 Jun 2006 16:32:48 GMT

I don’t think there are two more useless words in the English language, especially when strung together, as “that’s unacceptable”. One colleague tells me those words are merely a cry for help. The person who utters them is often trying to tell you, “That creates a problem I don’t know how to solve”, but is unable to bring himself to say that.

I am interested in stories about a situation where someone said “That’s unacceptable”, but it turned out all right. I’d like to know how someone in that situation handled those words and turned them into a problem-solving resource or merely helped the speaker admit his underlying problem.

If you have such a story, please send e-mail to unacceptable at jbrains dot info.

June 07, 2006 16:32 people

Annoying personality flaw

me@jbrains.ca (J. B. Rainsberger) — Tue, 06 Jun 2006 17:41:11 GMT

Without getting into all the details and causing any one person too much embarassment, I think the problem is that I’m a Mac user and, as a result, have an annoying personality flaw where I just want things to work.

Thanks to Alan Francis for this one. I think I have the same flaw.

June 06, 2006 17:41 mac

This is why we pair...

me@jbrains.ca (J. B. Rainsberger) — Sat, 03 Jun 2006 19:43:11 GMT

I was flipping through A Guide to Testing the Rails—can I use that metaphor with e-documents?—and I ran across an interesting line of code:

destinations = destinations.collect{|x| approved.collect{|y| (x==y ? x : nil)}}.flatten.compact

It took me a few moments to parse it and begin to understand it. I think someone was in a hurry. Isn’t this just this?

destinations = destinations.select { | x | approved.include?(x) }

I’m not saying the author is a bad programmer. Quite the opposite: even good programmers need to pair to avoid doing things the long way.

June 03, 2006 19:43 ruby, agile

Faking methods in Ruby

me@jbrains.ca (J. B. Rainsberger) — Thu, 01 Jun 2006 22:32:00 GMT

A design technique I use frequently is faking methods: reimplementing a method in a way that makes the current test easy to write. This can be returning a hardcoded answer, throwing a hardcoded exception or causing some other process to occur. Whatever it is, it’s generally simpler than what the production implementation of that collaborator does. When testing an object that collaborates with others, I often fake some of the others’ methods to see how the object under test reacts. This is easy when objects are loosely coupled: faking a method on an interface is as easy as falling out of bed, thanks to JMock.

When the “collaborator” is the object under test itself, though, things become a little more interesting. Frequently I have to test objects that have too many responsibilities, and when that happens, I often have to resort to a technique called Subclass to Test. (I don’t have my copy handy, so I can’t quote the page, but it’s in there.) As good a legacy code technique as that is, I am always nervous when I subclass the class under test, so assuming I can change the code, I usually go through these steps:

Subclass to test [WELC, ???]
Replace inheritance with delegation [Refactoring, 352]
Extract interface (from the new collaborator) [Refactoring, 341]

Now I can fake the interface and all is well. As a result, I am able to move the design one step further in the direction it wants to go: towards being loosely coupled and easy to test. The bad news is that this is quite a bit more involved than simply subclassing to test. While subclassing to test is smelly—I find myself forgetting exactly what I’m testing—it is straightforward, and to be preferred as long as it doesn’t get out of control. (I should trust myself more.)

I found myself wanting to do this while work on my weblog, which you might know is a Rails application. In particular, I wanted to test some special handling of request parameters in my controller: in order to tag my weblog entries with different categories, I have checkboxes for each category, so I can check as many as I want for a particular entry. Based on my limited knowledge of Rails, when submitting a form, I get a hash that looks something like this:

{"categories" => {"0" => "1", "1" => "0", "2" => "0", "3" => "1", ...}}

The keys in the innermost hash are category IDs and the values are “1” for checked and “0” for unchecked. I wanted to convert these into a collection of Category objects, so that I could create the corresponding Tags when I create the Posting. Naturally, I test-drove converting the hash structure into an array of Category objects. Since I don’t know how where classes belong in this brave new world, I put the production code directly in the TestCase class, like so:

class ParseCategoriesForPostingTest < Test::Unit::TestCase
  # Tests omitted for brevity...

  def selected_categories(params)
    params["categories"].reject { | key, value | value == "0" } 
  end
 
  def selected_category_ids(params)
    selected_categories(params).keys.collect { | each | each.to_i }
  end
 
  def categories_chosen(params)
    chosen_ids = selected_category_ids(params)
    Category.find(:all).select { | each | chosen_ids.include?(each.id) }
  end
end

I sense two bad smells: (1) production code among the tests, and (2) duplicating the parameter params. The first of these smells was easy to handle: I moved these methods into the controller, as utility methods.

class PostingsController < ApplicationController
  # Code omitted for brevity...

  # Simplifying method; a bridge to the ugly utility methods
  def categories_chosen
    self.class.categories_chosen(params)
  end
  
  def self.selected_categories(params)
    params["categories"].reject { | key, value | value == "0" }  
  end
  
  def self.selected_category_ids(params)
    selected_categories(params).keys.collect { | each | each.to_i }
  end
  
  def self.categories_chosen(params)
    chosen_ids = selected_category_ids(params)
    Category.find(:all).select { | each | chosen_ids.include?(each.id) }
  end
end

The other smell took a little more thought to handle. In Java, I would introduce a new class called PostingsRequest that wraps the incoming request and interprets the request parameters in a business-friendly way. The new class PostingsRequest would have a method categoriesChosen() that returns the collection of Category objects, just as I want. I could have done this in Ruby, but I wanted to find a more Rubyesque solution. As often happens, I needed to sleep on it. Early in the morning, I had a Rubyish solution: introduce a module called PostingsRequest and mix it in to the PostingsController. The new module would be a home for these utility methods, and they would no longer need to be utility methods.

module PostingsRequest
  def selected_categories
    params["categories"].reject { | key, value | value == "0" }  
  end
  
  def selected_category_ids
    selected_categories.keys.collect { | each | each.to_i }
  end
  
  def categories_chosen
    chosen_ids = selected_category_ids
    Category.find(:all).select { | each | chosen_ids.include?(each.id) }
  end
  
  # Depends on method 'params', returning a hash of request parameters
end

Now, I certainly did not need to introduce a module to do this. I could have simply made these methods instance methods on the controller and be done with it, but it bothers me a little that a Rails controller has this extra responsibility of representing the incoming request parameters (through the method params). As a result, I didn’t want to make things worse by tacking on more responsibilities, so I pushed that out to a module that the controller can mix in.

So how do I test this? It’s easy to test the controller, because it provides the params method, but the module does not define it. In essence, the params method is deferred (in the Eiffel sense—think abstract if you’re a Java programmer). I could define the method to raise “Thou shalt implement me”, but I don’t want to run the risk of accidentally replacing someone else’s well-meaning definition of the method, such as in the case of including multiple modules. I would hate for the order of including modules to matter! (This is part of a larger concern about programming with open classes. I prefer not to do anything that might lead to undue confusion. I’m sure I’ll become more comfortable later.) Then it struck me: thanks to David Black, I know I can implement params with an object method, and differently for each test! Bingo.

class ParseCategoriesForPostingTest < Test::Unit::TestCase
  include PostingsRequest
  
  fixtures :categories
  
  def test_none
    # A crude kind of subclass to test
    def self.params
      {"categories"=>{"1"=>"0", "2"=>"0", "3"=>"0", "4"=>"0", "5"=>"0"}}
    end
    assert_set_equal [], categories_chosen
  end
  
  def test_one
    def self.params
      {"categories"=>{"1"=>"0", "2"=>"1", "3"=>"0", "4"=>"0", "5"=>"0"}}
    end
    assert_set_equal [Category.find(2)], categories_chosen
  end
  
  def test_many
    def self.params
      {"categories"=>{"1"=>"0", "2"=>"1", "3"=>"0", "4"=>"1", "5"=>"1"}}
    end
    assert_set_equal [Category.find(2), Category.find(4), Category.find(5)], categories_chosen
  end

  def test_collect_many_category_ids
    def self.params
      {"categories"=>{"1"=>"0", "2"=>"1", "3"=>"0", "4"=>"1", "5"=>"1"}}
    end
    assert_set_equal [2, 4, 5], selected_category_ids
  end
  
  def test_selected_categories
    def self.params
      {"categories"=>{"1"=>"0", "2"=>"1", "3"=>"0", "4"=>"1", "5"=>"1"}}
    end
    assert_equal({"2"=>"1", "4"=>"1", "5"=>"1"}, selected_categories)
  end
end

Now it’s true that this is essentially Subclass to Test, but I find it much less intrusive in Ruby than I did in Java. Somehow, it’s less frightening, so I’m going to try it for a while to see where it breaks down. Maybe it will; maybe it won’t. One thing is certain: it’s much less work than it is in Java!

I lost my copy of Working Effectively with Legacy Code in the great flood of ‘05. If you have a copy kicking around, I’ll take it off your hands.

June 01, 2006 22:32 rails, ruby, testing, article

Goodbye, ugly URL

me@jbrains.ca (J. B. Rainsberger) — Thu, 01 Jun 2006 20:40:51 GMT

To everyone who has subscribed to my weblog’s feed at a URL specifying port 8728, you can switch to http://www.jbrains.ca/weblog/rss. I apologize for the inconvenience. I don’t suspect port 8728 will move any time soon, but I make no guarantee that you will find the weblog on that port forever.

June 01, 2006 20:40

Ruby annoyance: Hash#reject and Hash#select

me@jbrains.ca (J. B. Rainsberger) — Wed, 31 May 2006 16:52:37 GMT

I love Ruby—I really do.

Now that I have begun doing serious work in Ruby, I am running into things I don’t quite like about the language. This is the first “Ruby Annoyance”, and it’s a small one, but a strange one, because it’s a direct breach of the Principle of Least Surprise. It sure surprises me!

I have a bunch of checkboxes on a web page, and when the user submits the form, I get a hash mapping database IDs to “0” or “1” (for “off” and “on”, respectively). I need to convert this hash to an array of Category objects. To do this, I first convert the hash to an array of category IDs as numbers. After fiddling around for a while, I have code like this:

params["categories"].reject { | key, value | value != "1" }.keys.collect { | each | each.to_i }

So far, so good: remove the hash items whose value isn’t “on”, grab the keys, then convert each to an integer. Very functional programming-esque of me. (Some days I think I get it.) Still, I prefer positive to negative code, so I’d like to replace reject with select, so I try this:

params["categories"].select { | key, value | value == "1" }.keys.collect { | each | each.to_i }

My test fails, with this: Exception: undefined method `keys' for [["2", "1"], ["4", "1"], ["5", "1"]]:Array. Now that is surprising: reject returns a new hash with the offending items removed, but select returns a 2d array?!

As always with this kind of thing, I’m sure someone thought this was a good idea, but since select and reject are supposed to be partitioning functions, shouldn’t their return types be the same? In other words, if I merge the results of select and reject (with the same predicate, of course), I should get back the original hash. I can’t say with authority that this is how Smalltalk behaves, but I’d be surprised if it doesn’t.

So, for now, I shall stick with the double negative “reject all entries whose value is not ‘1’”, in spite of the fact that I abhor it. Using select forces me to traverse a 2d array, rather than sending keys to the subhash.

I’ll stick with the double negative. How annoying.

May 31, 2006 16:52 rails, ruby, article

Welcome to the new weblog!

me@jbrains.ca (J. B. Rainsberger) — Tue, 23 May 2006 04:00:03 GMT

I am proud to announce my new weblog, tentatively titled Can’t stop the learning. After several months of procrastinating and approximately 3 days of work, I have managed to hit version 0.1 of my own weblog software, written on Ruby on Rails. The experience, at times annoying, has nevertheless being mostly positive. This is a very nice platform on which to work.

Old weblog entries will migrate over here as time and desire permit. Until then, use the navigation links to go over to diasparsoftware.com to read my previous weblog.

This software will go through some changes as the days and weeks roll on, so I don’t recommend bookmarking individual entries. Bookmark the weblog instead, as URLs might change underneath you.

Choose the RSS icon in the menu for the new RSS feed.

Thank you to all my faithful readers and to those who created the technology upon which this humble application sits. Great job!

May 23, 2006 04:00

Services

me@jbrains.ca (J. B. Rainsberger) — Sat, 01 Jan 2005 00:00:00 GMT

Training · Coaching · Speaking

My name is J. B. Rainsberger and I provide a variety of services in four main areas: improving individual habits, improving teamwork and improving the flow of value, teaching others to coach.

I work with programmers, testers, business analysts, and product owners to improve their day-to-day work habits. I help programmers sharpen their design skills. I show them a model of simple design that includes rules they can follow to develop a deep understanding of modular design. Armed with this model, programmers build more flexible, easier-to-maintain systems. I help testers find their most effective role in the organization. Rather than simply executing someone else’s test plan, I show testers key techniques and heuristics that help them become better agents of the business. I help business analysts and product owners satisfy their customers more. I teach them how to eliminate unnecessary features from their product plans and how to work effectively with programmers and testers to deliver the most valuable features sooner. I also help individuals in any role improve their overall effectiveness with key personal planning techniques. I help them avoid rework, avoid being stalled and the general feeling of hopelessness that comes with too much work and too little time.

I help teams manage their workload, understand the value of healthy conflict, and take full benefit of their variety of styles, knowledge and perspectives. I use two well-known models of teamwork (Five Dysfunctions and the Wexler-Sibbett model) to help teams develop working agreements, charter projects, understand their role, understand the scope of their responsibility and feel comfortable holding each other to account for fulfilling their responsibilities. The result is a team that works better together and produces better results over time. Sometimes the result includes a re-alignment of people on teams.

I help organizations measure and improve the flow of value at any scale. We can focus on small processes, including promoting features to production, building the software and gathering requirements; or we can look at larger processes, including funding projects, handling support issues and bringing new features to market quickly. I use concepts from the Theory of Constraints to identify the roadblocks to realizing revenue for products and services, then help decide how to measure the problem, what it means to solve the problem, and how much of the problem to solve. I emphasize increasing the flow of value over cutting costs, because there tends to be a much higher ceiling on revenue than the lowest floor on costs.

I help others learn how to teach and coach effectively through role-playing, practice presenting, and discussions about specific situations they encounter. As I learn to act as a more effective instructor and coach, I share what I learn with others. I use techniques described by Edward Tufte and Garr Reynolds to present information effectively. I use ideas from Gerald Weinberg and Virginia Satir to inform my communication style and coaching philosophy. I also find benefit from parts of Appreciative Inquiry, the Dreyfus Model of Skills Acquisition, The Power of Full Engagement, and The Five Dysfunctions of a Team, among others.

I provide these services through a combination of consulting, coaching, and training. You should consider consulting or coaching when you know the symptoms, but not the cure. I will help you decide what results matter, decide how to measure progress towards improving those results, and decide on a plan to achieve those results. You should consider training when you’ve chosen the cure, but don’t know how to administer it.

Tim Gallwey, in The Inner Game of Work points out the difference between coaching and training.

The process for reaching your potential is called coaching. The process for increasing your potential is called training.

I can work with you to outline a consulting or coaching engagement that would benefit you. Among the training I can deliver are courses like these:

Introduction to XP or Agile practices
XP or Agile project kickoff—iteration 1 of your project
Mastering Modular Design with Test-Driven Development
From Concept to Cash: Deliver Software Sooner
Delivering The Minimum Marketable Feature

These are just a few examples. I prefer to work with you directly to design a course that meets your needs, which could include elements of the services I have outlined above.

I offer my services primarily in English, mais je parle aussi assez de français pour pouvoir entendre et répondre aux questions posées en français, y de vez en cuando, será posible de comunicar en español, especialmente si me hablan lentamente.

I look forward to the opportunity to work with you. Please contact me at the email address at the top of this page to find out more. I provide my services through Diaspar Software Services, a Canadian software consulting company.

Training · Coaching · Speaking

January 01, 2005 00:00 training, services, coaching, consulting

Comments on Test-Driven Development training

me@jbrains.ca (J. B. Rainsberger) — Thu, 01 Jan 2004 00:00:00 GMT

Here are some comments from students who have taken my courses on test-driven development and modular design techniques. I have been asked to protect the names of most of the commenters.

Joe, I had the good fortune to spend four days in your TDD course at Obtiva in September (2009) and still hear you saying these words every time I’ve written a line of code since: “Remove duplication and fix bad names”. I scribbled it down as you said it during the course but have only come to realise its importance in the subsequent months. My code and confidence has improved because of it! – J.M.

I think that I’ve learned more in this training class than I have in my entire professional programming career. I thought that was very successful in giving us the information that we need in an easily digestable way. – C.H.

Joe has an amazing grasp on test-driven development and JUnit and has probably the most extensive Java knowledge of any person I have met. I feel that the information and practices that he gave us in the course will be invaluable. – B.O.

The course is definitely an eye-opener, even to those versed in traditional TDD mindset; it gives the opportunity to view TDD from a bit of a different angle, and can only improve upon already learned patterns. – C.S.

Joe’s class was a real eye-opener. I knew we could do things better from a development perspective, but Joe gave me a glimpse of just how much. What I liked most about the class is that it wasn’t presented as a ‘silver bullet’, but a better approach requiring dedication and discipline. – R.M.

January 01, 2004 00:00 training

I have received your request and am working on it

me@jbrains.ca (J. B. Rainsberger) — Thu, 01 Jan 2004 00:00:00 GMT

Thank you for contacting me about engaging my services. Please allow two full business days for a response.

January 01, 2004 00:00

Engaging my services in October 2009

me@jbrains.ca (J. B. Rainsberger) — Thu, 01 Jan 2004 00:00:00 GMT

Thank you for your interest in engaging my services in early October 2009. Please send me a request with this form.

January 01, 2004 00:00

Make your tests work for you: Europe, October 1-2 or 5-6, 2009

me@jbrains.ca (J. B. Rainsberger) — Sat, 01 Jan 2000 00:00:00 GMT

You’ve written dozens, or perhaps hundreds, of tests for your codebase, but you still find bugs.

You’re written hundreds of tests for your codebase, and now nobody will run them because they take 15 minutes to execute.

You’ve written hundreds of tests for your codebase, and now when you try to add one line of code to one of your classes, that causes twelve of your tests to fail. It would take only two minutes to change the code, but two hours to fix the tests.

To cope, you’ve started writing fewer tests. You’ve noticed a rise in defects. You’re worried that all the work you’ve done to write those tests will amount to nothing.

I can help.

My name is J. B. Rainsberger and I specialize in helping groups work past the first obstacle for people who practice test-driven or behavior-driven development and reach their first plateau of achievement. If you have been learning TDD or BDD for several months and have written a few hundred tests, then I can help you work through the problems I’ve seen people in your position have.

When I change data in our test data set, I have to fix a dozen tests for old features.
Our tests get in the way of refactoring: I make one small change and it causes 15 tests to fail.
We find bugs, even though all our tests pass.

I’ve seen many groups have these same problems, and I find the same root cause every time: they do not understand how to interpret these problems as weaknesses in their design. I can teach you how to do that.

Take advantage of working with a world-class practitioner and consultant whose specializes in making your tests work for you without having to pay for travel expenses.

I will find myself in Paris, France in early October, and I would like the opportunity to share my solutions to these problems with you. I can make myself available for one-day or two-day engagements on 1-2 October or 5-6 October. If I can reach you by train in about four hours, then I’d like to work with you. You can show me how your tests have started working against you and I can share the secrets to making them work for you again.

To get started, please visit http://www.jbrains.ca/october2009

January 01, 2000 00:00 rails, coding standards, design, extreme programming

jbrains.ca: Can't stop the learning

Three Steps to a Useful Minimal Feature

Design your own TDD learning experience

Best of... June 15, 2010

Some examples of programming in pairs

Video: Education and Software Craftsmanship

Making decisions doesn't have to be so hard

Some objections

Two goals, two meetings

No silver bullet

Ask why, but never answer

You're probably sabotaging your people's training

Saboteur? You?

I’m going to tell you a story

Turning the first corner

Summoning the courage to try again

Into the abyss once more

And then…?

"Integration Tests Are A Scam" Is A Scam

What sessions do you want to see at Agile 2010?

Using integration tests mindfully: a case study

Not Just Slow: Integration Tests are a Vortex of Doom

The importance of aligning authority with responsibility

Lend your voice and face to Agile India 2010

Introduction to Agile and the Theory of Constraints

Healthy Eating for the Road Warrior... in Toronto

"One of the high points of the whole conference for me"

How test-driven development works (and more!)

Queuing Theory?

Winston Royce, 1970, revisited

Questions about feedback from Agile 2009

Introduction to Agile with the Theory of Constraints

Integration Tests Are A Scam

XP: My Greatest Misses 2000-2009

Click On Macs saved Apple a customer today

But wait, there’s more!

The World's Shortest Article on Behavior-Driven Development, revisited

Times have changed

jbrains Classic: Null as a method parameter

Comments on "Integration Tests Are A Scam" at Agile 2009

jbrains Classic: Contract Tests

When to fake; when to mock

Increase your sphere of influence by focusing on people one at a time

Part 4: Surely we need integration tests for the Mars rover!

The Four Elements of Simple Design

The Code Whisperer: Detecting anemic class hierarchies

Interlude: The Tutorial

Ask first; conclude later

Awesome virtual personal assistant/research needs work

libxml2: Can't upgrade it; can't downgrade it

Design your own TDD course!

An open call to Agile 2010 submitters

Interlude: Basic Correctness

Interpreting inaccurate estimates

Part 3: The risks associated with lengthy tests

The cost of unjustifiable test failures

Integration tests fail unjustifiably more frequently

Nominate someone for the 2009 Gordon Pask Award!

Who is Your Mentor?

About the Gordon Pask Award

Agility is a Social Phenomenon

Gordon Pask—Improved Understanding through Discourse

Three upcoming events

Please vote for the next Gordon Pask Award logo

XP 2009 conference is only one month away!

Code Retreat Reykjavík, May 9, 2009

Catalysts Coding Contest

Part 2: Some Hidden Costs of Integration Tests

Toddlers, novelty, and planning

See the Tigers at the Jays tonight (April 6)

Integrated Tests are a Scam: Part 1

Why I try to communicate in E-Prime

TDD: From the Beginning

Audience

You will learn…

Agenda

Day 1: TDD Bootcamp

Day 2: TDD and Evolutionary Architecture

Day 3: TDD and Modular Enterprise Design

Recommended reading