Scope Creep & Elon’s Space Roadsterby@steadygreen
259 reads

Scope Creep & Elon’s Space Roadster

by Praveen KrishnanFebruary 12th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Of course, you’ve heard that Elon Musk and SpaceX launched a Tesla <a href="" target="_blank">Roadster</a> on top of the Falcon Heavy rocket.

Company Mentioned

Mention Thumbnail
featured image - Scope Creep & Elon’s Space Roadster
Praveen Krishnan HackerNoon profile picture

A car in space

Of course, you’ve heard that Elon Musk and SpaceX launched a Tesla Roadster on top of the Falcon Heavy rocket.

So, why the roadster?

Normally, when rockets are tested, they are loaded with mass simulators to mimic the weight of a real payload. You don’t want an expensive satellite to blow up in the test so you send a dummy.

A mass simulator. How boring is that?

Elon Musk decided that he does not want to be ‘boring’ (see how I did that), so he decided to send something fun and really absurd up in to orbit.

A decidedly not boring mass simulator

Ok, What has this got to do with Scope Creep?

Imagine the requests Elon and team must’ve fielded for the roadster when it became clear they were going to send a car with a mannequin towards Mars:

We are going all the way there, so why don’t we add a video camera inside Starman to provide a human POV as we float in space!!


Since you are sending this car anyway, it would be great to add a sensor to track and report back on effects of radiation on paint, leather and rubber!

or this,

Why don’t we put a few sensors there to keep track of wear and tear on the spacesuit! This is a golden opportunity!

After all, you are sending a car with a spacesuit up there. Think of the possibilities!

Every one of these requests is relatively small with seemingly large benefits, when contrasted with the overall scope.

These requests are also classic cases of scope creep.

Let’s take for example, adding a camera for a Starman POV.

Let’s “throw in” a camera inside Starman!

Implementation begins and here’s how the story plays out:

The Starman Cam is delayed.

We got the cam. But wait, the camera is not adhering to the mannequin.

We need a new adhesive that can withstand 10Gs. The supplier is back-ordered 6 months!

We can’t get a power line through the suit to the camera and transmitter, so let’s add a battery pack to the mannequin.

The mannequin needs a re-design to accommodate the camera battery pack.

The camera team is requesting 10 tickets for the launch stand.

Screw this. Let’s just send a concrete block instead!

I’m assuming Elon & Co. deftly swatted away these requests.

Tying it together

You will see a lot of this type of ‘let’s do one more thing’ in software projects. I definitely have over the years.

You will be presented small feature add-ons that will be tantalizingly useful, revenue generators, customer happiness creators & NPS busters.

The temptation is to throw them in, like putting tiny pebbles in between big rocks.

In most cases, these “pebbles” will add several variables into your delivery equation. Complexity and uncertainty grow exponentially in every step of your development cycle.

What’s helped me catch these scope creeps is the following:

Ask myself & others: given that X was never in scope earlier, what has changed now that X is so desperately needed in this release?

Keeping in mind the overall goals of the release: what’s in it for our customers and what’s in it for us, the business.

Mentally walking the feature through every step of my development process and estimating the cost: design, coding, unit testing, QA testing, documentation, bug fixes, marketing etc.

So, beware of creepy features!

Gratuitous SpaceX image.

P.S: I can’t say definitively if Starman does not have some of the features I stated above but Elon didn’t give any indication that there was any data coming back from Starman or the roadster.