Engineers in shipping mode

In this blog, Think Radio’s Dominik Ostrowski talks us through what the TEDI-London students had to consider in their 24-hour design sprint.

What does “shipping mode” mean?

Being technically correct – it means putting a (usually electronic) device into a state ready to be sent to the customer – so when they rip off the cellophane, they’re met with the “welcome” screen.

However it is also very widely used to describe the (sometimes last-minute and panicked!) state of the engineers as they fix-up the last design details of the product – immediately prior to it going into mass production or public release.

Perhaps one of the few times nowadays you actually still see old fashioned, dead-tree paper being passed around the office is the final sign-off. Often each engineer involved with the project must personally sign their name to a statement like “I know of no remaining defects that should prevent, or of any other reason why this product should not be released to mass production”. They can easily run to 200 or more signatures.

It is literally the very last sanity-check before a very expensive next step is taken (that could, at worst, result in only some very expensive paper-weights being manufactured).

So why the explanation of shipping-mode?

Because it may closely parallel the final hours and minutes of the 24-hour team exercise right at the start of TEDI-London Summer School.

It’s always rushed.

It’s impossible to check and test everything.

But – usually – everything is close-enough to correct that a successful product rolls off the production line.

There’s usually several distinct phases to shipping-mode.

1. The feature-freeze.
2. The fix-ups.
3. Testing the release candidate.
4. A go/no-go decision.
5. If things aren’t good enough – going back to step 1 or 2.

The Feature Freeze

What’s in and what’s out. Is each feature sufficiently stable and functional that it is worthy of inclusion?

Some features will get the chop at this stage – but may appear in upgrades or later products.

There’s usually at least a few days warning of the moment of feature-freeze – and a strict rule that no new features will be added by anyone, unless testing shows that it must be added.

The fix-ups

Every part may work on its own – but they may not all work well together.

This is where as many as possible of the bugs, inconsistencies and unintentional side-effects should get fixed.

And sometimes in a not-terribly-elegant way.

This where issue-tracking systems prove their worth.

Usually there’s some sort of triage into “critical/show-stoppers”, “serious” and “minor”.

With constant updates on the status of each one into “fixed” (once it’s confirmed by testing), “open” (not fixed), and “not going to be fixed” (the customer will have to live with it).

Sometimes a difficult issue may cycle around each of these states several times.

The objective here is to “make it work” – not to do the design that which you wish you had designed in the first place, based on what you now know (that’s for the next version of the product).

Testing, testing, testing

There’s a saying that you cannot have too much. A typical figure might be 25-50% of the overall effort.

That’s testing by professional test-engineers (because they’re very experienced at finding weak-spots), testing by the designers (because they know where some of the weak-spots might be), and consumer testing (because the consumers will do odd, nonsensical things that the engineers would never do).

It’s often the case that everyone in the company is expected to participate in testing – particularly once there’s consensus that it’s now “good enough” to be a release candidate.

The decision

The decision-matrix/criteria for the go/no-go decision should be made in advance, should be repeatable and unambiguous, and NOT made-up on the fly to evaluate the release candidate!

And finally – if things aren’t good enough – it should mean going around the loop again.In practice – well sometimes you find all of stages 1 to 4 are happening at once!

Does this sound somewhat reminiscent of the last part of your first 24 hour sprint at TEDI-London Summer School?

Think Radio is about audience interaction through smartwatch-like devices that they are given at live (or live-streamed) events. Think Radio is an early-stage start-up technology company, looking to develop as a workers-co-operative structure rather than the classic investment for equity model.

Founder Dominik Ostrowski has spent many years in numerous technology companies learning what makes a great gadget. Gadgets that need no instruction manual, that are easy and fun to use, do exactly what you hope they will do easily and are never frustrating to use. He holds a Chartered Engineer and Electronics PhD from Imperial College London with most of his career spent in technology start-up-companies.