Shipping Software

  • Article

Many years ago I was invited to give a guest lecture at the University of British Columbia and today I happened to be looking through some material from that time and I was reminded of the talk.  My notes are just point form slides and there's supposed to be explaination, examples, exceptions, that go with each point but even without the discussion it's still kind of interesting so here it is for your enjoyment, entertainment, or both :)

Shipping Software

There are a lot of surprises, expect things to go wrong

  • Leave room for bumps along the way
  • Both time and design flexibility are a must

Get a good understanding of how your team will work together

  • Program Management - the users advocate
  • Development - keeping things simple
  • Quality Assurance - knowing and predicting the quality

Hard decisions are part of the process

  • When things are going well, there will be tension between your various goals

Design

Understand the problem you need to solve

  • Bound the problem as soon as you can
  • You'll know you've done this when it's clear what you're not doing

Understand your customer:

  • You can't know your problem without knowing your customer
  • Beware of taking too much advice from your customers

Don't over-engineer things:

  • Sometimes designed in limits are a good thing
  • Invest equally in all the areas of your product,
  • Building software is kind of like building a chain, don't make just one strong link
  • e.g. how big is a “customer ID” and what are the ramifications of that choice? 

Process

Everybody should know how decisions get made

  • Who gets a vote and who breaks ties

Some (arbitrary?) choices need to be made

  • Coding and documentation conventions are plentiful but important
  • They're often about style (like naming conventions, and formatting conventions)
  • Sometimes they're about process (like how source control is going to happen, or how often code reviews happen)

Some guidelines need to be set

  • These will reflect the design philosophy of the product
  • Probably not about style
  • e.g. choosing an OOP approach, or a certain EH mechanism, or a certain memory management strategy
  • sets the “mood” for the codebase

Quality

Quality Metrics

  • You can't know things are going well unless you can measure your quality
  • e.g. bug arrival rate, %lines changed, MTTF, etc.

Quality happens in different ways

  • Measured success against solving your problem
  • Designed in quality criteria

Recognize Quality Trade-offs

  • A classic trade-off that often isn't recognized is where stability is traded off for completeness

Triage

Probably the biggest surprise to both customers and engineers

Each part of the team plays a critical role

Triage is how you ship with the right bugs (you can't find and fix all the bugs, get used to it)

  • Severity vs. Priority
  • Categorization
  • Risk assessment

Shipping

Define your “Ship Cycle” very early on

  • Working backwards from when you plan to ship (I call it constraint based scheduling) is often a very useful exercise

“Ship Mode”

  • Loosely, it's when stabilization is everyone's top priority

Ship Criteria

  • Which of your quality metrics do you use to decide to ship?
  • e.g. bugs from beta sites

Success

There's no formula for success but there are lots of recipes for failure

  • Constant redirection
  • Lack of understanding of the problem
  • Too many decisions by committee
  • Not enough infrastructure to let things run themselves

Keep your wits about you

  • Remember why you are doing things the way you are
  • Don't be afraid to break your own rules when it's appropriate