Archives

timoni.org: a blog of design and discussion
  • Categories

  • March 28, 2008

    Notes on “An Insurgence of Quality”

    Last Tuesday I went to see Alan Cooper speak at at IxDA SF’s monthly meetup. His talk was a repeat of the keynote he gave at IxDA Interaction 08, “An Insurgence of Quality,” and deals with the trials of making high-quality software nowadays. According to Cooper, interaction designers are the ones to “lead the way out of the chaotic world of misdirected, misdesigned, and mismanaged products to a world where high quality and high tech go hand in hand.” Strong words, but if you’re frustrated with the quality of the software being produced at your office, you’ll find the situations he describes familiar— and his solution inspiring.

    The talk got a lot of buzz during and after the conference, and I was excited to see Cooper in the flesh. He didn’t disappoint. Here’s the notes I took on the talk. If you find them interesting, I highly recommend watching the video of the keynote; he’s a good speaker, and it’s easier to follow his points during his presentation.

    The Key Differences of the
    Post-Industrial Product Environment

    • Best to market trumps first to market.
    • Quality is more important than efficiency. (Compare earlier, innovative hard-disk MP3 players versus the iPod. See also the Newton versus the Palm Pilot.)
    • It’s not what your software does, but how it *behaves* that relates to quality. Innovation is thus given a lower priority.
    • In this field, with resources otherwise being plentiful, we have nothing but time to get the product right.
    • The industrial world lowered production costs to make money. The post-industrial world raises quality to make money.
    • Conventional methods of business accounting aren’t applicable to software. The days of quantifiable accounting are over.

    A Little Bit About
    Programmers and Software

    • Programmers are craftsmen. As craftsmen, they work to a quality line, NOT a deadline.
    • Software is not industrial. It is not a product that has a direct correlation between quantity and value.
    • Because it is both a craft and a replicatable product, software has both elements of pre-industrial (ie craftsmanship) and post-industrial products.
    • Programmers do not respect authority, only ability.
    • There is programmer calculus: “We have two different opinions. You have one vote. I, being smarter and more well-informed, have two votes.”
    • Programmers are quick to adapt when it makes sense.

    A Little about Business Types

    • Managers are trained to focus on efficiency, product goals, and deadlines: these are byproducts of the industrial era.
    • …Unfortunately for everyone, really, none of these benchmarks can be accurately applied to software development.
    • Senior executives are essentially in denial about the fact that software can’t be mapped to industrial benchmarks. Mid-level executives are generally just trying to cope.
    • It is essentially useless to try explain this to business people. Much like programmers are a specific type of person, so too the type of person who does business stuff is…well, a business person.

    How Business Types
    Are At Odds with Quality Software Production

    • Business types have an artificial sense of urgency, which leads to wastefulness. Cooper specifically mentioned it “drives him nuts” to see products that are pushed to market as soon as possible with the idea in mind that that flaws will be fixed later:
    • “Once you build a hack company, you’re going to get a hacked products from then on. It’s impossible to ask people to hack together something and then reevaluate the product immediately after with a fresh set of eyes.”

    • In the production of physical products, the material used to design the concept product is different than the materials used to make the final product. It’s easy to differentiate between a clay model of a car and a final, metal-and-glass version. But software is code whether it’s in the design stage or the final stage. This is confusing to executives.
    • Management is focused on the production of the software as opposed to the potential revenue. The question is continually, “How can we maximize cost effectiveness now?” versus “How will the quality of our product increase revenue later?”
    • It’s genuinely impossible to answer a lot of simple business questions when it comes to software. For example, with estimating deadlines: “Writing software is like walking through a minefield. It’s really fast to get through…as long as you don’t step on any mines.”
    • Executives are focused on putting out new features quickly, because “tech moves fast.” However, user goals change very slowly. There’s not really a need to “move fast.”

    What can be done to right a wrong?

    • Forget trying to wait on executives. Change can only come through a bottom-up battle.
    • Use an interaction designer and a program designer to ease the gap between executives and quality.
    • It is the responsibility of the IX designer and the program designer to free up the programmer to create quality products:
      • IX designers should have a detailed, written plan (this is effectively the “clay model car”) to show executives and make things clear for programmers.
      • IX designers need to have educated reasons for everything they outline. If they don’t, programmers won’t agree to it (see the “programmer’s calculus” below).
      • IX designers need to have outlined everything completely from the beginning to the end of the project. If they don’t, the result will be lost time and wasted code.
      • Program designers are the ones to take that extra day to estimate how long it will genuinely take to create something.
    • IX designers should try to enlist the programmers to create quality products without the consent of management. “You have the power to make quality products, even though you may not have the power to get approval.”

    Other Fun Tidbits

    • As programmers, it’s your job to create successful products, not necessarily to innovate. This is because innovation comes naturally to the field. It’s the byproduct, not the goal.
    • It’s a classic programming conceit to “plan to throw one away.” Keep in mind that business types have changed this to mean “the first, crappy 1.0 version is the one we’ll throw away.”
    • “Companies can be achieving stellar results in efficiency while otherwise failing completely.”
    • “We are the ones to lead the insurgency, and the time is now.”

    Currently