• Shortcuts : 'n' next unread feed - 'p' previous unread feed • Styles : 1 2

» Publishers, Monetize your RSS feeds with FeedShow:  More infos  (Show/Hide Ads)

Date: Tuesday, 20 Sep 2011 01:32

As many of my pair programming partners could tell you, I have the annoying habit of saying “Stop thinking” during refactoring. I’ve always known this isn’t exactly what I meant, because I can’t mean it literally, but I’ve never had a better explanation of what I meant until now. So, apologies y’all, here’s what I wished I had said.

One of the challenges of refactoring is succession–how to slice the work of a refactoring into safe steps and how to order those steps. The two factors complicating succession in refactoring are efficiency and uncertainty. Working in safe steps it’s imperative to take those steps as quickly as possible to achieve overall efficiency. At the same time, refactorings are frequently uncertain–”I think I can move this field over there, but I’m not sure”–and going down a dead-end at high speed is not actually efficient.

Inexperienced responsive designers can get in a state where they try to move quickly on refactorings that are unlikely to work out, get burned, then move slowly and cautiously on refactorings that are sure to pay off. Sometimes they will make real progress, but go try a risky refactoring before reaching a stable-but-incomplete state. Thinking of refactorings as horizontal and vertical is a heuristic for turning this situation around–eliminating risk quickly and exploiting proven opportunities efficiently.

The other day I was in the middle of a big refactoring when I recognized the difference between horizontal and vertical refactorings and realized that the code we were working on would make a good example (good examples are by far the hardest part of explaining design). The code in question selected a subset of menu items for inclusion in a user interface. The original code was ten if statements in a row. Some of the conditions were similar, but none were identical. Our first step was to extract 10 Choice objects, each of which had an isValid method and a widget method.


if (...choice 1 valid...) {
if (...choice 2 valid...) {


$choices = array(new Choice1(), new Choice2(), ...);
foreach ($choices as $each)
  if ($each->isValid())

After we had done this, we noticed that the isValid methods had feature envy. Each of them extracted data from an A and a B and used that data to determine whether the choice would be added.

Choice pulls data from A and B

Choice1 isValid() {
  $data1 = $this->a->data1;
  $data2 = $this->a->data2;
  $data3 = $this->a->b->data3;
  $data4 = $this->a->b->data4;
  return ...some expression of data1-4...;

We wanted to move the logic to the data.

Choice calls A which calls B

Choice1 isValid() {
  return $this->a->isChoice1Valid();
A isChoice1Valid() {
  return ...some expression of data1-2 && $this-b->isChoice1Valid();


Which Choice should we work on first? Should we move logic to A first and then B, or B first and then A? How much do we work on one Choice before moving to the next? What about other refactoring opportunities we see as we go along? These are the kinds of succession questions that make refactoring an art.

Since we only suspected that it would be possible to move the isValid methods to A, it didn’t matter much which Choice we started with. The first question to answer was, “Can we move logic to A?” We picked Choice. The refactoring worked, so we had code that looked like:

Choice calls A which gets data from B

A isChoice1Valid() {
  $data3 = $this->b->data3;
  $data4 = $this->b->data4;
  return ...some expression of data1-4...;

Again we had a succession decision. Do we move part of the logic along to B or do we go on to the next Choice? I pushed for a change of direction, to go on to the next Choice. I had a couple of reasons:

  • The code was already clearly cleaner and I wanted to realize that value if possible by refactoring all of the Choices.
  • One of the other Choices might still be a problem, and the further we went with our current line of refactoring, the more time we would waste if we hit a dead end and had to backtrack.

The first refactoring (move a method to A) is a vertical refactoring. I think of it as moving a method or field up or down the call stack, hence the “vertical” tag. The phase of refactoring where we repeat our success with a bunch of siblings is horizontal, by contrast, because there is no clear ordering between, in our case, the different Choices.

Because we knew that moving the method into A could work, while we were refactoring the other Choices we paid attention to optimization. We tried to come up with creative ways to accomplish the same refactoring safely, but with fewer steps by composing various smaller refactorings in different ways. By putting our heads down and getting through the other nine Choices, we got them done quickly and validated that none of them contained hidden complexities that would invalidate our plan.

Doing the same thing ten times in a row is boring. Half way through my partner started getting good ideas about how to move some of the functionality to B. That’s when I told him to stop thinking. I don’t actually want him to stop thinking, I just wanted him to stay focused on what we were doing. There’s no sense pounding a piton in half way then stopping because you see where you want to pound the next one in.

As it turned out, by the time we were done moving logic to A, we were tired enough that resting was our most productive activity. However, we had code in a consistent state (all the implementations of isValid simply delegated to A) and we knew exactly what we wanted to do next.


Not all refactorings require horizontal phases. If you have one big ugly method, you create a Method Object for it, and break the method into tidy shiny pieces, you may be working vertically the whole time. However, when you have multiple callers to refactor or multiple implementors to refactor, it’s time to begin paying attention to going back and forth between vertical and horizontal, keeping the two separate, and staying aware of how deep to push the vertical refactorings.

Keeping an index card next to my computer helps me stay focused. When I see the opportunity for a vertical refactoring in the midst of a horizontal phase (or vice versa) I jot the idea down on the card and get back to what I was doing. This allows me to efficiently finish one job before moving onto the next, while at the same time not losing any good ideas. At its best, this process feels like meditation, where you stay aware of your breath and don’t get caught in the spiral of your own thoughts.

Author: "admin" Tags: "Uncategorized"
Comments Send by mail Print  Save  Delicious 
Date: Monday, 29 Aug 2011 19:30

September 2014

To Whom It May Concern,

I am writing this letter of recommendation on behalf of Kent Beck. He has been here for three years in a complicated role and we have been satisfied with his performance, so I will take a moment to describe what he has done and what he has done for us.

The basic constraint we faced three years ago was that exploding business opportunities demanded more engineering capacity than we could easily provide through hiring. We brought Kent on board with the premise that he would help our existing and new engineers be more effective as a team. He has enhanced our ability to grow and prosper while hiring at a sane pace.

Kent began by working on product features. This established credibility with the engineers and gave him a solid understanding of our codebase. He wasn’t able to work independently on our most complicated code, but he found small features that contributed and worked with teams on bigger features. He has continued working on features off and on the whole time he has been here.

Over time he shifted much of his programming to tool building. The tools he started have become an integral part of how we work. We also grew comfortable moving him to “hot spot” teams that had performance, reliability, or teamwork problems. He was generally successful at helping these teams get back on track.

At first we weren’t sure about his work-from-home policy. In the end it clearly kept him from getting as much done as he would have had he been on site every day, but it wasn’t an insurmountable problem. He visited HQ frequently enough to maintain key relationships and meet new engineers.

When he asked that research & publication on software design be part of his official duties, we were frankly skeptical. His research has turned into one of the most valuable of his activities. Our engineers have had early access to revolutionary design ideas and design-savvy recruits have been attracted by our public sponsorship of Kent’s blog, video series, and recently-published book. His research also drove much of the tool building I mentioned earlier.

Kent is not always the easiest employee to manage. His short attention span means that sometimes you will need to remind him to finish tasks. If he suddenly stops communicating, he has almost certainly gone down a rat hole and would benefit from a firm reminder to stay connected with the goals of the company. His compensation didn’t really fit into our existing structure, but he was flexible about making that part of the relationship work.

The biggest impact of Kent’s presence has been his personal relationships with individual engineers. Kent has spent thousands of hours pair programming remotely. Engineers he pairs with regularly show a marked improvement in programming skill, engineering intuition, and sometimes interpersonal skills. I am a good example. I came here full of ideas and energy but frustrated that no one would listen to me. From working with Kent I learned leadership skills, patience, and empathy, culminating in my recent promotion to director of development.

I understand Kent’s desire to move on, and I wish him well. If you are building an engineering culture focused on skill, responsibility and accountability, I recommend that you consider him for a position.



I used the above as an exercise to help try to understand the connection between what I would like to do and what others might see as valuable. My needs are:

  • Predictability. After 15 years as a consultant, I am willing to trade some freedom for a more predictable employer and income. I don’t mind (actually I prefer) that the work itself be varied, but the stress of variability has been amplified by having two kids in college at the same time (& for several more years).
  • Belonging. I have really appreciated feeling part of a team for the last eight months & didn’t know how much I missed it as a consultant.
  • Purpose. I’ve been working since I was 18 to improve the work of programmers, but I also crave a larger sense of purpose. I’d like to be able to answer the question, “Improved programming toward what social goal?”
Author: "admin" Tags: "Uncategorized"
Comments Send by mail Print  Save  Delicious 
Date: Friday, 19 Nov 2010 19:57

Saros (pronounced “zar-ose”, btw) is a set of extensions to Eclipse to support real-time collaboration. It is a research prototype at the moment, and as such has some rough edges. In 15 or 20 years, most programs will be written through real-time collaboration, so for me it’s worth a bit of pain today to experience the future.

This post describes what I learned from the Saros team about what is required to get started successfully. Unfortunately all the lessons are in the form of arcane magic (that is, I can’t explain to you why they work), but fortunately they do work.

Use Jabber.Org

Initially David Saff and I tried to use gmail.com as our Jabber server. For mysterious reasons, that doesn’t work. Sign up for an account at Jabber.org instead.

Preload Projects

When one person shares a project, the other people in the session theoretically don’t need to have the project. However, Saros is slow at transferring whole projects. Instead, make sure that you have both checked out and imported the same version of the project before you start. Then, when you accept the invitation to share, make sure you select “Share existing project” instead of “Create new project”.

HTTP Proxy Magic

If you are using Mac OS X, you need to trick Eclipse into not using HTTP proxies. Select Eclipse>>Preferences>>Network Connections. Change from “Active Provider>>Direct” to one of the other settings. Press “Apply”. Select “Active Provider>>Direct”. Press “OK”.

You only need to do this once per Eclipse installation. Don’t you just love computers?


…to Lutz Prechelt, Karl Beecher, and Björn Kahlert for their help.

Author: "admin" Tags: "Programming"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 09 Nov 2010 18:24

The other night Cynthia and I were having drinks in the Tower Bar of the Hotel Hafen in Hamburg (highly recommend for the view if not the service) with Henning Wolf and Arne Roock of it-agile when I casually mentioned that test-driven development was kanban for code. Arne teaches kanban but the connection wasn’t obvious to him, so I sketched my idea (see napkin above). He seemed to understand (he kept nodding, anyway), but I thought it prudent to follow up with a post to make sure I’d thought the whole thing through. Arne, this one’s for you.


The goal of kanban is to increase the value of a production process. Kanban increases the feedback in production by limiting the amount of work in progress at any one time. Without the “safety” of inventory, troublesome process steps and connections between steps have nowhere to hide. With better feedback, the steps can be optimized (or eliminated) and their connections improved. The result is higher throughput and lower latency and variance.

Kanban works by only producing on the basis of demonstrated need. While one finished product is being assembled, upstream steps are producing the parts for the next finished product, timed to arrive just as they are about to be used. When a kanban system is humming, it produces a steady stream of finished products with a short gap between the receipt of an order and its fulfillment. When it isn’t humming, the source of the dischord is likely to be clear.

Test-driven Development

Test-driven development (TDD) is an alternative programming workflow where features are divided into a series of automated tests. The tests are chosen so that satisfying the spirit of all the tests implies that the feature as a whole works correctly. The cycle goes like this:

  1. Write the next test (while several tests may be outlined, only one is written at a time)
  2. In pessimistic languages, add enough stubs so the test compiles. It should fail when run.
  3. Refactor, if necessary, to prepare for the implementation.
  4. Change the logic of the system so the test passes.
  5. Refactor to eliminate duplication and other excess complexity

Repeat until no more of the tests implied by the feature would fail. Then the feature is complete.

The Analogy

If TDD is kanban for code:

  • What is the product?
  • What is the kanban card?
  • What are the production steps?
  • How does demand flow backward and products flow forward?
  • What are the feedback loops?

The product of software development is two-fold:

  • The behavior of the system
  • The options for extending and modifying that behavior in the future

As difficult as it can be to precisely specify and validate the behavior of the system, it is even harder to measure a system’s option value. Finding the right balance between these two goals is one of the big challenges of development, especially as different phases of the business cycle require different proportions. I’ll describe in a moment how TDD addresses this balance, both in theory and in practice.

The tests are the kanban cards in this system. Each one is a request for a change of behavior. “Please change the system so if the customer is a smoker the premium is 12% higher”. This will require changes to the logic of the system. It may also require changes to the structure of the system so the change to the logic is easier to make correctly and efficiently.

The post-success refactoring commonly emphasized in descriptions of TDD isn’t explicitly called for by the tests. It is work done for future benefit. If the future happens to be the next test and implementing it is easy because of cleanup done after the last test was satisfied, then the payoff is immediate. From the kanban perspective, though, post-success refactoring is over-production, the worst of the seven wastes of the Toyota Production System. Still, most TDDers, myself included, clean up after a test is passing as a matter of habit.

The behavior and options are the product, the test is the kanban card, so that makes the production steps the changes to the logic and the changes to the structure of the system. In TDD, these changes are not begun until a test is failing. The changes flow forward into the product, as demonstrated by the passing test, and the lack of collateral damage is demonstrated when all previous tests also pass.

Feedback loops fuel kanban. In TDD, the programmer gets feedback in seconds about whether the logic implied by the test is the logic he writes. He also gets feedback about whether the design supports the logic changes based on how hard or easy those changes are to get right.


This isn’t the whole story of development. Post-success refactoring doesn’t fit into this picture but is a common practice. Is this just because of our still-evolving understanding of TDD, or is it more like the preventative maintenance needed to keep kanban systems running smoothly? Should some or all of it be deferred until immediately before it is needed? What about other valuable software development activities like automation, tool building, and exploration?

We could also pull back and look at development at a larger scale and see the features as kanban cards, each one “pulling” a collection of tests into the system, triggering coding. From even further back, a process like Customer Development can be seen as “pulling” demand for features.

In any case, TDD is kanban for code:

  • Product = behavior and options
  • Kanban card = test
  • Production step = coding and refactoring
  • Feedback = effort and test results

Arne, how does that work for you?

Author: "admin" Tags: "Programming"
Comments Send by mail Print  Save  Delicious 
Date: Friday, 05 Nov 2010 23:21

As part of a recent advanced TDD course, we took a careful look at a simple stack implementation TDD-style. Here are the decisions that went into designing and implementing the stack. First, the specification decisions:

  • Stack is an object
  • Name is “Stack”
  • There is an operation to add an element
  • It is called “push”
  • It takes a parameter
  • The type of the parameter is the same as the type of the stack
  • Stack has a type parameter
  • There is an operation to remove elements
  • Its name is “pop”
  • Its return value is the same as the type of the stack
  • Elements are ordered LIFO

Here are the implementation decisions:

  • Store the elements in a List
  • Type of the list is the same as the type of the stack
  • Implementation type is ArrayList
  • Add/remove elements at the beginning of the list

Here’s the exercise: start with any decision above & TDD, then another, and another. Pay attention to how frequently you can reach a green test. Pay attention to which sequences of decisions actually make sense.

What we found was that of the 15! permutations of decisions, many of them worked just fine and could be used for different purposes.

Author: "admin" Tags: "Programming"
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 28 Oct 2010 23:29

I wrote the following in response to a question about the Lean Startup practice of Minimum Viable Product.

The straightforward interpretation of MVP is a product that is built to gain feedback rather than built to maximize sales. I find it helpful to extend the idea. Here’s my interpretation:

  • “Minimum” is a reminder to invest as little as possible to get the next burning question answered or assumption validated.
  • “Viable” is a reminder to build enough to answer that question.
  • “Product” is a reminder to work from particulars.

MVP to me means “what I need to make in order to learn something valuable”. At first this can be as simple as a phrase: “we’ll cross StackOverflow with Twitter” (Quora). If you say your phrase to five people who ought to be interested if your assumptions are accurate and they all respond enthusiastically, then you’ve learned something valuable. Sharpie sketches on index cards could be a next step. Again, show them to people who you think “ought” to be interested and their reactions will give you valuable feedback. A wireframe might be your next step. Then a working but emaciated product. Then adding and/or deleting features.

The goal at each step is gathering feedback fast and cheap. You’re not trying to invest in these increments, you’re trying to avoid investing until you are more certain that a payoff is likely. You stick with a level of investment as long as it is providing valuable feedback, then move on (either forward or back, depending on the feedback). For example, I’ve seen people stick with wireframing long after it has ceased to provide feedback, which is just as wasteful as skipping wireframing if it can validate a hypothesis more cheaply than real code.

I call these steps “Informative Increments”, of which the MVP=barely-but-informatively-functioning-prototype is a special case. Unfortunately, neither the phrase itself nor the acronym can compete with MVP. The principle remains, though: while decisions are risky, make them & validate them as cheaply as possible to preserve capital for the (nearly) inevitable iterations.

The temptation in StartupLand is to try to make something good enough to survive. The paradox of the MVP is that by making a series of products which aren’t good enough to survive but are good enough to inform, you increase your chance of eventual success.

Author: "admin" Tags: "Startups"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 26 Oct 2010 16:55

The premise of my recent Software G Forces talk is that deployment cycles are shrinking, and that what constitutes effective software development at one cycle (say annual deployments) can be fatal at another (like daily deployment). Each transition–annual->quarterly->monthly->weekly->daily->hourly–requires a different approach to development. Everyone can find their current deployment cycle in the sequence above and everyone is under pressure to shrink the cycle.

Almost everyone. I gave a workshop based on the G Forces model in Israel recently and one workgroup made it clear that their current deployment cycle was just fine. As a followup, someone else asked the fundamental question, “Why should we deploy more frequently?” My inspiration for the talk was my long-standing observation that cycles are shrinking, but I never really thought about why, so I didn’t have a good answer. This post, then, gives me a chance to think about why to shrink deployment cycles. (I’ll be giving the talk in Hamburg on Thursday, November 4, 2010 if you’d like to see it live.)


The obvious reason to deploy more frequently is to get a jump on the competition. If you are in a head-t0-head competition where features matter and you can bring them out faster, you should win. If the villain gets ahead, you can rapidly catch up. If they get behind, you can keep them from catching up. Analogies to the OODA loop come to mind.

When I tried to come up with examples of such competition, though, I had a hard time finding any recently. The days of word processors competing on feature lists is long gone, resulting as it does in bloat and complexity. One recent example is Bing versus Google. Even there, the struggle is more to learn about user behavior more quickly than the competition, not a strict feature battle. It would be an advantage if one of them could deploy weekly and the other only monthly, but the winner still would be the one who understood users best.


A lesson I learned from my officemate at Oregon, David Meyer (now a director at Cisco), is that as systems grow in complexity, every element is potentially coupled to every other element. This suggests that systems be made as simple as possible to keep that N^2 from blowing up too far, and it suggests that changes be made one at a time. If any change can potentially affect any part of the system, then introducing two changes at once is much more complicated to debug than introducing one change. Was the problem change A? Change B? Some interaction of A and B? Or was it just a coincidence? Introducing one change at a time keeps the cost of maintenance in check.

At the same time, systems need to grow rapidly. You need many changes but you can only introduce one change at a time. One way to reconcile the conflicting needs is to reduce the cycle time. If you can change a system in tiny, safe steps but you can make those steps extremely quickly, then it can look from the outside like you are making big changes.

Timothy Fitz, formerly of IMVU, told a story that brought this lesson home to me. The discipline they came to was that as soon as they said to themselves, “That change couldn’t possibly break anything,” they deployed immediately. If you weren’t at least a little worried, why would you even say that? By making the overhead of deployment vanishingly small, they could create value with every deployment. Either the deployment was fine, in which case the engineer regained confidence, or the deployment broke, in which case the engineer learned something about the sensitivities of the system.


In Toyota Production System, Taiichi Ohno makes an analogy between inventory and water in a river. By lowering the water level in the river (reducing inventory), you can uncover previously hidden rocks (identify bottlenecks). Undeployed software is inventory. By deploying in smaller batches, you can identify bottlenecks in your software process.

Startups have a vital need to eliminate waste. Because many of the assumptions on which a startup are based are likely to prove false, most startups need to iterate to be successful. If the team can learn to learn from each iteration and can make those iterations short and cheap, then the whole enterprise has a greater chance of succeeding overall. Startups have the initial advantage of no code and no customers, so establishing a rapid deployment rhythm is relatively easy, although maintaining that rhythm through growth can be a challenge.


The final reason I thought of for accelerating the deployment cycle is the adventure. Especially if someone claims it is impossible, establishing a rapid rhythm is simply fun and satisfying. Don’t underestimate the role of fun in driving innovation.


There are my reasons for accelerating deployment: responding to (or staying ahead of) competition, scaling safely, identifying waste, and fun. My next post will look take a more abstract look at how accelerating deployment works, through its effects on latency, throughput, and variance.

Commercial plug–the switching costs between tools becomes more significant as the deployment cycle shrinks. That’s why JUnit Max runs tests automatically and displays test results right in the source code.

Author: "admin" Tags: "Responsible Development, Startups"
Comments Send by mail Print  Save  Delicious 
Date: Saturday, 09 Oct 2010 07:54

The0retico asked for a list of my favorite tech-oriented podcasts. Since I listen every day while I do farm chores, I have ample time. Here is my list (oh, the picture above is my quintessential geek picture, from an outstanding, but non-tech-related, book):

  • Entrepreneurial Thought Leaders — Guest speakers to Steve Blank’s entrepreneurship class at Stanford. Most enduring quote: M.C. Hammer, “It’s all about the analytics.”
  • Hanselminutes — Sometimes spins off into Microsoft minutiae, but often interesting in general. Most memorable episode: building the ultimate developer machine.
  • History of Rome — Nothing tech about it, but just absolutely brilliant stories. Deserves a Pulitzer.
  • IT Conversations — Wide variety of tech topics, many interesting.
  • The Changelog — Geeky conversations about open source.
  • Software Engineering Radio — The Big Daddy, and not just because I finally got interviewed. A little too much modeling for my taste, but everyone is entitled to an obsession.
  • This Developer’s Life — A recent find, but shaping up nicely. No particular point but to provide a setting for storytelling.

And finally, my favorite music for programming:

Please feel free to point me to new casts in the comments.

Author: "admin" Tags: "Programming"
Comments Send by mail Print  Save  Delicious 
Date: Monday, 13 Sep 2010 18:17

In preparing to relaunch JUnit Max, I’ve been try to articulate exactly why it is worth the price. I’m still conflicted about charging for Max, although realistically if I had no chance to be paid for it I couldn’t afford to work on it. If I’m going to charge money, though, I’d like to know that Max is worth it.

For me this isn’t an issue. I run tests all the time and I appreciate the time savings and additional focus Max gives me. Of course, I had to give up the things that the time I spent implementing Max could have brought, but that’s a sunk cost for me. I simply like programming more when I have Max, which is a big part of my motivation in the re-launch.

If you’re out there with $100 in your pocket, though, I can imagine that you need convincing. If you’re going to ask someone else for the $100, then they need convincing. So, does Max make economic sense?

Here’s an envelope calculation based entirely on time savings. I’ll take the JUnit unit tests as a baseline. They take about 10 seconds to run. While we’re programming we run them ~50 times per hour. Scaling this up to a full-time job, we would be spending 10 seconds/run * 50 runs/hour * 1000 programming hours/year = 139 hours/year waiting for tests to finish. At $200/hour, your employer is paying $27,000 for you to wait for test results.

With Max, wait times are reduced because of test prioritization. With the JUnit test suite we get results in 2 seconds instead of 10. Even if the savings were only 50%, though, Max would still be worth $13,000/year (and the savings on longer-running tests suites will be larger than the 80% we get for the JUnit tests). In other words, Max pays for itself roughly every two working days.

And that doesn’t count all the times I stay focused on programming because it’s only two seconds instead of getting distracted during a 10-second or 30-second pause and not getting anything done for several minutes. I can only conclude that at $100/year Max is seriously underpriced. My conscience is assuaged.

Author: "admin" Tags: "JUnit Max, Startups"
Comments Send by mail Print  Save  Delicious 
Date: Friday, 09 Jul 2010 04:12

The survey I’ve been writing about (raw results here) was intended to give us speakers at the continuous deployment webinar (Timothy Fitz, Jez Humble, and myself) some background on the attendees. I’ve saved the best (most informative) question for last: what practices do attendees use in software development. Here is the data:

What practices do people use?

Some thoughts:

  • Business-based operations metrics. One of the key insights of continuous deployment is using business-oriented metrics to monitor operations instead of the more natural (for programmers, anyway) technical metrics. If you expect 50 sign-ups per minute and the rate suddenly dips to 20/minute after a deployment, it’s time to roll back. The practice is not in common use.
  • Kanban versus iterations. Iterations still dominate, even though the additional flexibility of kanban is a better match for continuous deployment.
  • Pair programming. For all the complaints I hear about pair programming, I would have expected this number to be lower than 25%.
  • Test-driven development. 50% is higher than I would have expected. Adoption of TDD is excellent preparation for teams wishing to deploy more frequently (see my commercial screencasts for more details).
  • Continuous integration. I expected this number to be higher. CI was the first practice from Extreme Programming to spread widely, but, at least among this audience, it is not pervasive.
  • More than 75% of teams test manually before deployment. This is a sensible practice until the defect rate is brought down and the operations infrastructure made robust in the face of errors, but I expect the number to drop as teams mature in their application of continuous deployment.

Change generally happens on a time scale of decades. Mass production and then lean production each took upwards of fifty years to become widespread. I don’t mean to be overconfident, but the picture above (skewed as it is by selection bias) paints a picture of software development that is substantially different than common practice twenty or even ten years ago. There’s still a long way to go until software development pours out the stream of value it is capable of, but we’re making progress.

Commercial plugs: Check out my series of screencasts on intermediate-level test-driven development, $25 for four episodes. If you run unit tests for Java in Eclipse, check out JUnit Max, the continuous testing plugin, $50/year until August 1, 2010.

Author: "admin" Tags: "Responsible Development"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 07 Jul 2010 14:11

Today’s question is, “How often do you commit code changes to the shared repository?”

One of the essential practices of continuous deployment is that everyone stays very close to the mainline, typically by checking progress into HEAD frequently. This requires developers to be careful to only make changes that are safe and to only reveal functionality when it is ready for real users. The change of task sequence this requires is an acquired skill, but once mastered results in a low-risk development style.

The data shows that many projects are checking in very frequently:

The question needs followup, as it doesn’t ask whether there is a single mainline that people continually integrate with, and which direction the integration goes.

Tomorrow is the final question of the survey, which asks which practices folks are applying.

Commercial plugs: Check out my new series of screencasts on intermediate test-driven development. If you run unit tests for Java in Eclipse, check out JUnit Max, the continuous testing plugin.

Props to Chartpart.com for the lovely front end for Google Charts.

Author: "admin" Tags: "Responsible Development"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 06 Jul 2010 15:37

Running functional tests generally takes longer than running unit tests, so as expected, most people run unit tests more frequently than they run functional tests:

How often do you unit test?

I was a bit surprised at how many people are running tests on every change, but that’s good news for JUnit Max, which shaves seconds off the delay waiting for feedback from tests. If those delays happen a hundred times a day, the cumulative effect of a tool like Max can be substantial. I’m not sure what to make of the teams that run unit tests daily or weekly. I’d like to talk to such a team to understand more about their process.

Unit testing wasn’t explicitly addressed by any of the presenters at the Continuous Deployment webinar, I think because unit testing is assumed when you’re deploying on a short cycle. I don’t recall who said it first, but the model I use is that the defects leaving any stage are proportional to the defects entering that stage. No matter how good your functional tests are, defects leaving the programmer’s desk need to be rare if the software is always going to be ready to deploy.

Author: "admin" Tags: "Responsible Development"
Comments Send by mail Print  Save  Delicious 
Date: Monday, 05 Jul 2010 16:08

Following up on the continuous deployment survey question about frequency of deployment, the question for today is, “How often do you run functional tests?” Here is the data:

How often do you run functional tests?

What I take from this is that there are a considerable number (~30%) of people using continuous integration in the poll audience. The ~10% of people who have brought functional testing into the inner loop of coding is also a bit surprising, although we do it to great effect while developing JUnit. Another surprise to me is seeing that the majority of these projects get feedback from functional tests every day.

All the panelists (Jez Humble, Timothy Fitz and I) agreed on how essential automated functional testing is to applying continuous deployment. I think of it as a stack of filters, each removing defects–personal habits, social processes (like pair programming or reviews), unit tests, and functional tests. If the functionality flowing from the whole stack is high enough quality, then continuous deployment is possible.

Manual testing has a place in projects applying continuous deployment, just not on the critical path to deployment. It might seem like a big step to remove that last human “sanity check” before deployment. If it seems like a big step, then you’re likely not ready. Keep working on the filters to improve the deployability (is that a word?) of each one’s output. When you heard someone say, “Why are we checking this by hand? We never find anything,” then you’re ready.

Next question: how often do folks run their unit tests?

Commercial plugs: Check out my new series of screencasts on intermediate test-driven development. If you run unit tests for Java in Eclipse, check out JUnit Max, the continuous testing plugin.

Author: "admin" Tags: "Responsible Development"
Comments Send by mail Print  Save  Delicious 
Date: Saturday, 03 Jul 2010 00:41

In conjunction with the Leaders of Agile webinar on Continuous Deployment I hosted yesterday for SD Times, I ran a poll asking attendees about various of their development activities. I’ll be posting a short piece about each question, the answers we got, and the webinar material that connects with that question.

My co-presenters were Timothy Fitz of IMVU and Jez Humble of ThoughtWorks. Timothy talked about continuous deployment in a large web/client application with ~50 developers while Jez covered CD for IT applications. Both made a nice contrast to my experiences with CD for individual or pair projects, and immediately addressed the “sure, but it won’t scale” objection. My thanks to Timothy, Jez, and Alan Zeichick of SD Times for their work setting up and delivering the webinar. (I’ll post here when a recording is available.)

For the poll, the questions were posted two days before the webinar. We had ~200 responses out of the 1100 registrants and 430 attendees. Beware of extrapolating too far from the data because the poll suffers from both selection bias and an amateur question author (me). However, the responses do provide some idea of how at least a slice of our industry works.

The first question I will cover from the poll is, “How often do you deploy to production?” That’s the fundamental measure of continuous deployment, at least as narrowly viewed (more about that later). Here’s the raw data:

How Often Do You Deploy

Deployment cycle starts with the orange slice for annual deployment at the bottom right. Going clockwise from there, the three biggest slices (quarterly, monthly, weekly) take up most of the chart. Completing the circle, there are almost as many people deploying on every commit as deploying annually, so continuous deployment already has significant traction.

One of the surprises of the webinar was Jez Humble’s flexibility with regards to how far towards real deployment Continuous Delivery (his phrase and the title of his forthcoming book) needs to go. His strategy is to take the rapid iteration that is made possible in development by Extreme Programming and gradually extend it down the deployment pipeline, even if that stops short of real actual live deployment with real actual live users. My general preference is to work the other way around. I like to get the whole team–business, development, and operations–working with the same rhythm, then gradually increase that rhythm. There’s no right or wrong approach, it’s just interesting to see the contrast.

Next question: how often do you run functional tests?

Commercial plugs: Check out my new series of screencasts on intermediate test-driven development. If you run unit tests for Java in Eclipse, check out JUnit Max, the continuous testing plugin.

Author: "admin" Tags: "Responsible Development"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 01 Jun 2010 14:54

I usually just tweet my book reviews, but this one required more explanation.

XIX Olympiad

I was seven in 1968 when the Mexico City Olympics rolled around. They were the first sporting event I devoted myself to completely. I had been happy earlier that year when the first Super Bowl was played, proving once and for all the superiority of what is now the NFC, but with the Olympics I fell in love.

I bought the whole Avery Brundage/Chariots of Fire line: amateurs competing only for the glory of sport and the honor of their nation. I was happy to US athletes do well, but I was happier to see an athlete surpass his own limitations. Bob Beamon’s jump was remarkable not because he was American, but because it was such a remarkable performance. It was possible for people to become gods, if only for a moment.

Tommie Smith & John Carlos brought a discordant note to my proceedings with their medal stand protest. My father was outraged but I understood that they had a legitimate complaint and no better way to speak of it. Still, sport was supposed to be about sport, right?

By the closing ceremony/party my discomfort was washed away in a music-powered dancing unification of all humanity. Sport was the highest and best in us.

1968 was a confusing time to be seven: body counts on the nightly news, “duck and cover” drills at school (and we lived on the Moffett Field final approach, so this was an immediate, if futile, concern), hippies, and anti-war protests. At seven I had the intellectual capacity to understand a surprising amount of this, but no emotional tools with which to deal with it personally. Don’t worry, in sport I had a perfect refuge.

XX Olympiad

Four years later I couldn’t wait for Munich to start. At first everything was as I hoped it would be. There was even a rare note of international harmony in the house because my rabidly anti-communist father, then 140 kg, idolized Alexiev. There was Dave Wottle’s incredible kick–zero to hero on the final straight. Bruce Jenner, local boy making good on the biggest stage in the world.

Then came the reports of the massacre. All day we sat glued to the TV, stunned. I was eleven at the time, so my emotions were a violent tempest in an extremely small tea pot. Bitterly furious at the Palestinians, terrified for the hostages, utterly baffled at why someone would do this to sport, to me, blindly hopeful when the choppers took off, inconsolable when it became clear that everyone was dead.

The lasting emotion was rage, rage that someone would violently pervert sport to suit their own needs. In sport I had a refuge where the world made sense and that had been ripped from my hands and smashed on the floor. I was ready to drink blood.

Psychologists tell us that when a trauma happens, people often aren’t prepared to deal with the intensity of emotions in the moment, so they bottle it up. When this happens, emotional development pauses. The theory is that by working through those stored emotions later in a safe environment, emotional development can continue. I fell like I’ve experienced a bit of this effect thanks to the book Vengeance.


Vengeance tells the story of an Israeli hit squad put together to assassinate eleven high-ranking Palestinians involved in terrorism, one for each dead Israeli athlete. By the end of the book this attempt to balance the books has wrought a terrible vengence of its own on the surviving members of the team. In the end, the author/protaganist is estranged even from his own country.

Debate raged when the book came out: fact or fiction? good or evil? I won’t address any of these questions here. I also don’t intend to debate the ethics of the actions described or the preceding events. What I’d like to highlight here is what the book did for me.

While I was reading Vengeance, that furious little eleven-year-old that I’d put in a box was able to come out and read along. I got my wish–kill those responsible with my own two (borrowed) hands. What happens then? The human cost to the protaganists is horrifying, along with the effects on those close to the murdered. Yes, vengeance is physically possible, but at the end what has been achieved? I felt those long-ago emotions again and was able to let them go.

In the months since reading Vengeance, I’ve noticed that I am able to read about and think about Middle Eastern politics without the same surges of rage that I used to experience. I can see that both sides have unmet needs. I can see that many of their actions will not lead to those needs being met. At the same time I can have compassion for those making those decisions. If I was filled with rage for 38 years for something that happened five thousand miles away, how much more difficult must it be to move past personal experiences of terror, grief, and rage?

I’m sadder and wiser (I hope) in my view of sports now. Sport can’t solve problems, but, at its best, it can remind us that we can solve our problems, we can overcome. Shalom. Salam.

Author: "admin" Tags: "Social Commentary"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 12 May 2010 18:08

Since many of the readers of this blog weren’t around for some of my earlier writing, I will occasionally mix in popular articles I wrote some time ago. The plus for me is that I don’t have to spend so much time writing. The minus is that I cringe to see the thought errors in my earlier work. I wouldn’t write this way now, but rather than bowlderize my own history I’ll present it as is, binary thinking, exaggeration, and all.

This piece one entitled “One Team”, about the evolution of my thinking about software development teams. It was initially published in July of 2001. It was interesting to me to re-read it in light of Steve Blank’s Customer Development and the Problem Team in Lean Startups.

Stupid Mistake

The biggest error in Extreme Programming Explained is the implicit assumption that you have a technical team serving a single customer.

The lonely customer orbits a team of programmers

I had this picture in my mind because of two experiences. At a mutual fund company I had a customer who had been a customer service representative for seven years, a supervisor and trainer for three years, and then threatened to quit if the crummy old system wasn’t replaced. At a large manufacturing company I had a customer who had run a finance department for years, knew all the ins, outs and exceptions, and was willing to work very hard to keep up with the programmers.

The picture of a single person feeding expectations to a whole team of programmers is seductive. You don’t have to worry so much about disagreement in detail, and political disagreements are even rarer. You don’t have to worry about finding the appropriate expert to answer a question.

Don’t get me wrong. If you can find that one person who knows the whole domain, is willing to make quick decisions and fix them later, can speak to you both concretely and abstractly, and can put up with a room full of nerds you are likely to be successful. First, though, such folks are understandably rare. Second, this picture seems to exclude many people who now dedicate their talents to software development, like analysts, testers, and modelers.

It Gets Worse

The problem is compounded in XP Explained (and subsequent writings and conversations) by referring to the programmers when using the phrase “the team,” as in “the customer speaks to the team with one voice.” This usage always bothered me, but I didn’t know what to do about it.

Cracks Appear

The first inkling I had that “the team” shouldn’t mean just programmers came out of my experiences at Evant Solutions (evant.net). We (I’m a sometime coach and stock holder) have about ten programmers on (what we’ll call for nearly the last time) the team. But the product, a demand chain management tool for retailers, requires specialized knowledge of many different aspects of retailing. No one customer has sufficient knowledge or perspective to guide the programmers in implementing the whole system.

“The customer” consists of six product managers. One (I’ll call him “Jim” because that’s his name) is the uber-product manager, overseeing the competitive vision of the entire product. Working with him are five product managers specializing in aspects of retailing: assortment planning, purchase orders, inventory, and some other stuff I don’t understand even that well (contact Evant for useful details).

Evant chose a three week iteration, curiously beginning on Tuesday (Jim says, “Planning sucks and Monday sucks, why put them together?”) On Tuesday, the product managers present their stories to the programmers for tasking and estimation. Sometimes one product manager dominates the iteration, sometimes the stories are spread around, and sometimes they are shared. Curious. Even curiouser is the frequent appearance of fresh bruises and bandages on the product managers at the iteration planning meeting.

A Team Is Formed

What gives? Jim says,

The short of it is that we hold a pre-planning meeting before each cycle to discuss which use cases we want to attack. Usually, we have a theme/focus to each cycle that is provided by our clients (i.e., incorporating feedback from XYZ Inc. regarding planning) that makes the discussion around which use cases to select somewhat “non-toxic.” Although our process is very collaborative and democratic, my “uber” nature does make it easy to “break the tie” when we have competing requests.1

Regardless of Monday’s disagreements, Tuesday morning the customer team presents their story choices to the development team with one voice. It is as if they agree, at least as far as the programmers can tell.

Stranger in a Strange Land

The second crack in my model of the lone customer orbiting “the team” came during a visit to Japan in April 2001. The Extreme Hour is an exercise invented by Peter Merel to simulate the dialog used to choose scope in an XP project. A group of eight people is split into four developers who draw pictures of a coffee maker, two customers who write stories about a coffee maker, and two testers who verify that the coffeemaker as drawn satisfies the stories.

For ten minutes the customers write stories and the developers estimate how long they will take to draw. Then comes the interesting part. In five minutes the customers have to choose which stories will go into the first release of the coffee maker based on the estimates on the stories and the developers’ estimate of their overall speed.

I say interesting, because the choosing phase always takes too long, at least a minute or two. The customers disagree on the relative priorities of the stories, they argue with the developers over estimates and speed, and they are reluctant to make a final decision until absolutely compelled to do so.

I gave a private XP lecture to a group of 20 programmers from Technologic Arts, the sponsor of my trip. The first phase of the exercise went as expected—they wrote a bunch of stories. The second phase was interesting.

Instead of six or seven minutes to pick the stories for the initial release, each of the teams was done in two minutes. Strange, but after all these were bright folks who had been studying XP for a while.

The next day I gave an all-day lecture to 200 programmers and project managers. My hosts (hi Marika and Yoshi!) insisted we could run the Extreme Hour with the whole group. I was unconvinced, but it was their show, so what the heck.

The attendees were sitting four to a table, four tables across. The easiest way to form the teams was to have every other row turn around. The backward-facing attendees were the customers and the forward-facing attendees were the developers (we skipped the testers for simplicity).

The first ten minutes went better than I expected. We had them work on a tea maker (although my translators told me later they would have preferred coffee since there are two words for tea and they didn’t know which one I meant). Every team wrote plenty of stories (with a little prompting). We were ready for the first release plan.

In a giant room, with 200 people who had never tried the exercise before, giving instructions through simultaneous translators (who were excellent, but still), the entire room, all 25 teams, had their release plan finished in, you guessed it, two minutes.

Westerners hearing this story often comment, “Sure. Japan is a hierarchical society. The senior customer decided and the others followed.” Au contraire, my ethnocentric friend. In the conversations I watched, every customer talked about the same amount. Body language was similar in the whole customer team. Without knowing Japanese I can’t tell for sure, but I’m guessing the four customers simply formed a team faster than I could recognize and got on with working together. Yoshihide Nagase comments,

Japan has many hierarchical styles. Software development in Japan is hierarchical, too. But manufacturing development (such as in Toyota, Sony, Epson and so on) uses small teams. Maybe attendees of your XP seminar here felt like these small teams, not the usual Japanese Software Engineering way.

The Last Straw

My identification of “the team” with “the programmers” finally died when I had the chance to visit a testing conference and a modeling conference in quick succession. In both places the primary question was, “I’d like to try this. Where do I fit into the XP picture?” As long as the XP picture contains a lone customer orbiting a team of programmers, the answer is “nowhere.” I know that many of the skills and attitudes of modelers and testers would be a huge asset on my teams. If they are right, then my XP picture must be wrong.

One Team

What if we redrew the picture to reflect what happens at Evant, and what I observed in Japan?

One Team

The new picture reminds me of American football teams. The offensive and defensive teams have different skills, values, and perspectives but they share a single goal, winning the game.

Where do our good testers and modelers fit in? On the Business team. Helping scout, write, slice, dice, and verify are everyone whose lives will be affected by the scope and quality of the released software:

  • Analysts
  • Representative users
  • Testers
  • Marketers
  • Customer support
  • Sales
  • Modelers
  • Interface designers that watch what real users do and help “pave the paths”
  • Business strategists

Their jobs are different than they have been in the past. No longer can any one of these groups grab a phase to themselves, either before development starts or after it finishes.

Looked at from Here

Once I shifted to viewing one team, some problems I had been wrestling with for months came into focus. Martin Fowler reported a team at Thoughtworks where the programmers brought their workload and stress level under control with the Planning Game, but only at the expense of overloading the analysts. Analysts need liberation, too. ThoughtWorks has since been using teams of analysts and QA in its larger XP projects for a year or so now with reasonable success http://martinfowler.com/articles/planningXpIteration.html.

Another problem that came into focus for me was the growth of the customer team on the C3 project, XP’s spawning ground. At first there was only one customer. After a few months another payroll expert joined the team to help prepare test data. A few months later a third payroll expert joined. The One Team picture explains this. As the business sponsors discover how responsive the development team could be they chose to increase their business investment.

Far from being the norm, perhaps the original “one customer/many programmer” picture is weird. A picture with the teams more nearly balanced in size may be more healthy.

But Wait, There’s More

Our happy little family would be complete, if only we didn’t want to get paid. And if we always got along. And probably eleven other impossible things before breakfast.

I spoke at the University of Oregon CS commencement this year. One of my old professors, Andrzej Proskurowksi, heard the XP story and likened the picture above to a two-legged stool. And he’s absolutely right. There are questions that are outside of the scope of the people on the team as we’ve drawn it so far.

  • How does the project get started?
  • How is investment increased, reduced, or terminated?
  • How are disagreements resolved that aren’t handled by business and development?
  • How are relative priorities set between this team and all the other projects that need doing?

I would love to have a better name for the team that answers these questions. The only one I can think of threatens to unstopper the bottle into which we have just so laboriously stuffed the Demons Control, Hierarchy, and Certainty. But, my failings as a thinker being what they are, I’ll just have to call this, for the moment, the Management Team.

But I really mean “team”, not “manager” and certainly not “roomful of hens squabbling over too few grains of corn.” To scale XP practices to the next size of organization (up to about 150), the members of the management team must work together to solve problems at the scale of the whole organization, typically by breaking them into bite-sized chunks that can be chewed and swallowed by individual teams.

Being on the management team is no easy ride. XP Management is not there to Make Decisions, and certainly not there to Fix Things. Managers are there primarily to notice when the words and the deeds don’t match, to market and sell the achievements of the teams, and to make sure there aren’t obviously better ways to spend money.

In redrawing the picture, I’m forced to switch metaphors. If I draw three circles, whichever one ends up on top will think it’s in charge. If two are on top, whichever one ends up on the bottom will think it’s being oppressed. Circles just won’t cut it. However, Andrzej’s suggestion has merit:

Aalto Stool

I like this picture. First, the three legs are equal partners. Without the support of any one team, the stool collapses. Second, it’s an Aalto design, and I’m a big Aalto fan. Third, imagining the stool in use, the three sub-teams have to work together to withstand the pressure from the …, well, from above.

Making the Shift

I’ve been using “the team” to mean the whole team for a week or so now. Old habits die hard, but it’s starting to feel natural. If you want to try it, talk about “the team” to mean customers, programmers, and managers. Talk about the customer team, the development or programming team, and those clueless suits (just kidding, talk about the management team) when you need to discuss narrower concerns. Give it a week and see how it goes.

Some Predictions

Where will it end? I’m reminded of engineering driven startups, where engineers often form 80-90% of the employees. As these firms grow and mature, the proportion of engineers drops to something like 10-15%.

Will we see this as XP teams mature? Will we ever see a customer team of 10 marketers, domain experts, representative users, sales people, analysts, testers, and usability engineers feed stories and acceptance tests to 4 programmers with 3 managers? What would happen if there was such a team?


The division of the One Team into three sub-teams smells of taylorist division of labor. I can imagine someone reading this and saying, “Oh, I have to decide once and for all whether I’m a manager or a customer.” In practice, people move between the teams, sometimes even iteration-to-iteration. And once the team is clicking, the artificially hard divisions blur, and rightly so.

However, the social contract of work is different between the members of One XP Team. Before you can begin messing with the roles you have to get used to how they are different. Then you can begin experimenting while working together towards the ultimate goal: getting as much of the most valuable stuff done as possible by a given date.

Sidebar: Customer Team at Thoughtworks

Martin Fowler writes:

At ThoughtWorks the notion of “one team” makes a lot of sense. We often staff projects with our own analysts, who are often business experts. Indeed in some business sectors our analysts are more familiar with the specialized domain than our clients. QA is also obviously an agent of the customer, as indeed it was in the early days at C3.

Our largest XP-ish project has a full team of analysts and a full QA team—all as part of the overall project team. The analysts need to collaborate to present the stories with one voice to the programmers. They’re also a mixed bunch combining both business experts with pure analysts.

They’ve recently set out some of their conclusions about making the customer team work.

  • They’ve missed having some kind of “big picture” to act as a road map
  • They’ve found it hard to divide up functionality into suitable story-sized chunks
  • They’ve found it frustrating to not give an indication to developers of which direction future function is likely to go
  • They’ve found that specialized analysts are better at looking at the thorny details of exceptional cases – in other projects testers have reported a similar phenomenon.

The danger with an analyst group is always that they can end up being a communication barrier rather than a communication enabler. The notion of the single business expert customer helps prevent that, but I don’t think there’s any way to structurally avoid a barrier. The key lies in the attitude of the people involved. Particularly on the customer side of the team you have to build the roles around the people – not the other way around.

Certainly the programmer-centric attitude of XP has caused frustration. Part of XP’s guiding mission is to heal the rift between business and technology. For this to work we need to better understand the various aspects of the customer team. In many ways it’s a more complex team than the developer team. It’s also one where the techniques are less developed.

1 Jim Bahrenburg, personal communication, 22 June 2001.

Author: "admin" Tags: "Uncategorized"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 04 May 2010 21:31

Once again I’ve managed to stir up unexpected trouble on Twitter. Twitter for me is just an inflammatory blog post waiting to happen, I just don’t know which tweet is going to set off the storm.

Here’s what happened this time. I read Michael S. Malone’s piece berating the tech press for covering Apple softly. Until I read this, I wasn’t too upset about iPhoneGate, but Mike’s article framed the situation differently for me: as a free speech issue.

Since my point seemed to be widely misunderstood on Twitter, I will say right up front that I am not commenting on the behavior of Gizmodo or the gentleman who found the phone and subsequently sold it. I would like to think that in the same situation I would return the phone to Apple, although I would certainly be tempted to post some pictures just because I think Apple’s paranoia deserves tweaking whenever possible. Not returning the phone to its (obviously) rightful owner was wrong, but it’s an everyday kind of wrong and it doesn’t affect my life so I’m not going to get too upset about it.

What bothers me is Apple’s reaction. Without knowing the details of the activities that went on, from up here in southern Oregon it looks like Apple enlisted the police to make an example of Gizmodo. If I had lost a hardware prototype and I called the San Mateo police or the REACT group or the Superior Court judge, there’s no way they would have reacted in the way they did. Apple got special treatment because they are large. That’s wrong.

I’ve learned to look for the intent behind behavior that I don’t understand. What could Apple’s intent have been in having Mr. Chen’s house searched in the manner it was? The explanation that makes sense to me is that they wanted to intimidate anyone who was thinking about writing about Apple “secrets”. The course of justice doesn’t demand what they caused to happen. They were looking for effect, is how I read it.

Here’s where it starts to affect my life–what if I figure out something about Apple next “big thing”, purely legitimately? Am I going to write about it? Well, if it’s me I probably will because 1) I’m clueless about what’s going to upset people (obviously) and 2) I hate people telling me what to do. I’d certainly think about it, though. What if Apple took umbrage at what I wrote? Josephine County sheriffs would be battering down my door in no time, and there’s nothing I could do about it. I don’t like that feeling.

My conclusion is that Apple has read too many of its own press releases and thinks the world should run for its benefit. I expect more boorish behavior and increasing alienation from the needs of customers and developers. That’s too bad, because I like my Apple products.

Author: "admin" Tags: "Social Commentary"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 28 Apr 2010 14:03

I’ve spent maybe a quarter of my career doing user interface design and implementation. One skill I was proud of was my ability to take in a variety of constraints on the UI and produce a design to satisfy them. It takes a while, though, and if I’m going to be honest with myself the success rate isn’t that great. That skill, the single blinding flash of design insight, I discovered yesterday, is no longer essential. Iteration is the new inspiration.

One of the fundamental changes driving lean startups is the incredible reduction in the capital required to deliver the first iterations of a product. Capital is still required to fuel growth, but finding out if you have a market and pivoting when you discover you don’t, is one or two orders of magnitude cheaper than it used to be.

I had previously experienced this efficiency in programming (open source tools) and deployment (AppEngine). Yesterday I got a taste of it in user interface design. Back in the day, developers (those with design and/or programming skills) would argue endlessly about designs. Along came usability labs, with mirrored walls, video taping, and real users (gasp) invited in. Watching someone fumble with your perfectly logical UI design was always an education, but it was expensive, both in terms of capital and time.

Enter Speed

Yesterday I started using two services, UserTesting.com and fivesecondtest.com, that bring the same capital- and time-efficiency to UI design that open source tools brought to programming. Rather than work extremely hard getting the design right, then failing if you guess wrong, it is now quick and cheap to iterate. Have a crazy idea? Test it. Three alternatives? Test them.

At the Startup Lessons Learned conference Siqi Chen of Zynga recommended UserTesting.com. UserTesting.com is the online version of the usability labs of old. For $39 you get a 15 minute screen cast of a real user using your system while thinking aloud. Problems in flow are glaringly apparent. ($39 is approximately the cost of a ten minute argument between two designers, and in my experience arguments can last a lot longer than ten minutes.)

Granted, you don’t get everything out of UserTesting.com that you get out of a usability lab, but it’s quick and it’s cheap. I can see iterating a design several times a day with UserTesting.com. By the time you’d rounded up a subject for a usability lab session you could already have the results from UserTesting.com.

Fivesecondtest.com becomes useful earlier in the design cycle. Given a screenshot, users are asked what they remember about it or they are asked to click on notable sections of the screen. You can pay to have customized tests, asking particular questions, for example. Since it works on screen shots, you can iterate much faster with fivesecondtest than you can with UserTesting. It’s a tradeoff between fidelity and speed. For a quick, “is this too cluttered?” kind of question, fivesecondtest is ideal.

You Still Have to Design

Neither of these services substitute for building real, person-to-person, in-depth relationships with real customers. And you still have to have the ideas to test in the first place. Rapid iteration with lousy ideas will result in a lousy interface. However, user interface inspiration just got rollerskates.

You could use these services to produce a similar quality of design compared to what you are producing now, but in less time and at less cost. I’m more interested in spending a little more time and money than that, and trying out crazy UI ideas. Crazy ideas that just happen to work provide pizzaz, differentiation, and extend the lead you have on competitors.

Note to Programmers

If you are working with a designer who begins using these services, you are going to have to up your game. You need to find ways to provide testable variations of your application much faster than you do today. That will require better designs to effectively separate the parts of the system that change from the parts that don’t, better coordination and communication to keep track of the variations, and better tools to support the whole process. You will also need to be disciplined about removing the traces of failed experiments, lest your code begin to resemble a Hollywood backlot.

Author: "admin" Tags: "Startups"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 27 Apr 2010 05:01

I had this idea while I was sitting in the Startup Lessons Learned conference. You definitely don’t want to try this. It’s a crazy idea. And you don’t want to hire me to come facilitate. That would be piling madness on madness. Here’s what you don’t want to do:

Get the whole team in a conference room Monday morning. Choose a feature you are going to add. Have one person come up to the one machine in the room. Write one line of code. Deploy.

If you can’t deploy, erase that line of code and write a different line of code first. Deploy.

Once the deployment is done, write another line of code. Deploy.

About this time some of the rest of the team is going to be bored watching all the manual steps in the deployment. Have them go off and automate the most tedious, boring, or error-prone step. Bring the automation back to the conference room and start using it.

By about Wednesday you’ll be feeling pretty good about your ability to deploy (even if you aren’t feeling so good about progress working one line at a time). You’ll likely make a mistake. Roll back manually. Split off a team to be able to roll back automatically.

At some point you’re likely to need to change some existing code. If you don’t have automated tests for the current behavior, split off a team to write a test before changing the code.

By Friday afternoon you may not have made much progress on your feature (but you may be pleasantly surprised), but you will understand deployment much better than you do now. You will also understand how to slice development more finely and rearrange the pieces. You will also understand the value of automation.

But don’t do this. It’s a crazy idea. Never work. Forget it. Sorry to waste your time.

Author: "admin" Tags: "Programming, Responsible Development"
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 15 Apr 2010 22:42

Learn Measure Build Cycle

In preparing for Startup Lessons Learned next Friday I took a page full of notes during a conversation Eric Ries and I had about my keynote. I will wait for the conference to unleash the Big Message, but here is a smaller lesson that I found interesting.

Ordinarily we talk about the Build/Measure/Learn cycle (as in these slides from Ash Maurya, another SLL speaker). When Eric and I were talking, I realized that the loop is backwards.

From a programmer’s perspective, the loop is certainly correct. You write a program. You watch how someone uses the program. You learn something that you use to improve the program. I have had this experience many times. I have an idea for a program, I write it, I learn something.

Contrast that with the Lean principle of Pull: avoid the waste of overproduction by only creating based on demonstrated need. The customer orders a product, then you build it and deliver it. If that takes too long, make it take less long, don’t pile up a bunch of inventory in hopes that someone will buy it some day. Being able to instantly deliver a product no one wants is false economy.

I am working on two products right now that contrast nicely with respect to which way the loop runs. One product is a set of narrated screencasts illustrating test-driven development. For this product I’m running the loop forwards. I made a screencast, I saw how many people watched the unedited excerpt, I learned something about how many people are interested and how effective Twitter is as a marketing tool. Yes I learned something but now I’m at a bit of a loss. I’m not even sure what else I need to learn. I’ll make a couple more screencasts and then make the whole series available for sale. I hope they do well, but because I’m running the loop forwards I don’t expect to learn more about my audience until the casts are out there.

Contrast that with my other project, a poker-related game. Yes, I “primed the pump” with a very simple version of the game, but I’m now in a learning directed loop, running the cycle backwards. I start with an assumption, for example that I can make the game sticky. If the game is sticky, then people playing it will play several game per session and come back for multiple sessions. Now, what do I need to build to make it stickier?

The feeling is completely different between the two projects. With the screencasts I feel a bit lost. Yes, I know people are interested and I’ll sell quite a few units. However, I have no idea how to improve their value short of getting them out there and incorporating what people say into the next series of casts. It feels a bit like writing a book or the bad old days of writing a program for a year before trying to sell it.

Running the loop the other way, pulling the “build” from the needs of the learning, is much more energizing. I know why I am building when I build. I don’t create anything just grins. Programming’s still joyful, but it also has purpose. I know when to stop–when I’m ready to learn.

Here’s an exercise, gentle reader. Explain how to run the learning loop backwards for screencasts. One of the constraints is that people will only make one transaction per series, at least the way they are sold now.

Author: "admin" Tags: "Startups"
Comments Send by mail Print  Save  Delicious 
Next page
» You can also retrieve older items : Read
» © All content and copyrights belong to their respective authors.«
» © FeedShow - Online RSS Feeds Reader