Analogy for fail-fast "speedy" development?

Question

Someone told me that speed is most important for them, so they deploy whatever (to production I assume), fix, redeploy/continuous release and so on. I can't remember exactly, but my takeaway impression is that he thinks it's ok to ship buggy code, if you fail-fast etc.

Is this a "fail-fast" method and what is a good analogy for it, if appropriate, using a house or boat?

Answer 1

Time-to-market (TTM) is indeed an important factor for many businesses, especially startups. When it comes to software products, TTM translates into continuous integration and continuous deployment. The idea here is not that you ship buggy code, but that you ship fully working software on very regular basis. Although the frequency varies from team to team, it is not unusual for some companies and teams to ship several times per day, which makes a big difference compared to teams where a feature could be shipped six months to a few years later after being requested by the product owner.

In a context of continuous deployment, in order to prevent buggy code from hitting the production, teams are using extensive automated testing. Instead of spending six months developing a feature and then handling it to the quality assurance department for an eight months test-fix-test phase, those teams write tests at the same time they write code. Those tests run on every commit, and if any of thousands of tests fail, the product is not deployed on production servers, and developers are informed that they broke the build.

Note that TTM also translates in a marketing (and not technical) approach which consists of saying that it is more important to ship an often incomplete and imperfect product now, and see how actual users will use it, what would they like, and where would they encounter difficulties. Based on this feedback, the product is then adapted to the needs of the customers. Recently (i.e. for the past twenty years), this approach became successful, and is found to be efficient in a context of startups, compared to an ordinary approach consisting of doing market research and lots of studies prior to product development.

Analogy

You asked for house/boat analogies, so here they are.

Continuous integration.

Imagine you're building a boat. You may spend a few months building it, then you put it in water, and notice that there are some engineering and construction flaws. You need to fix them before you can use the boat.

Instead, you may constantly be testing how your boat performs by putting it in water on daily basis. When you do an engineering or construction mistake, you'll have a feedback within a day showing that the change you did to the boat during this or the previous day caused an issue.

This may not apply well for a boat, since those things may not float well if they are half built (for instance if they are not painted yet). For software products, however, even a tiny feature of a product which is not yet built can already be tested, making software products ideal candidates for continuous integration.

TTM in marketing.

Imagine you're building a house. You may spend a few months building it and then showing it to the owner, just to learn that he wanted a swimming pool on the other side of the garden, and that he expected two more windows, and a different roof.

Or you may let the owner access the construction site once per week in order to receive very fast feedback, when it is still not overly expensive to do some changes.

Here again, the analogy is not perfect, because (1) the owner cannot live in the house which is not yet built (while users can start using a software product which lacks half of its features), and because (2) structural changes will be extremely expensive to perform once the construction started (which is often not the case for software products which were built correctly).

Answer 2

CI/CD is indeed a fail-fast approach. I take slight issue with this:

"he thinks it's ok to ship buggy code"

I suspect what he actually means, is that it is known that the software may have defects but deploying it quickly means that issues will be found, reported and fixed far faster than traditional methods.

Part of the problem with legacy approaches is software functions thought they knew what the customer wanted and shipped it months/years after it was specced only to find it wasn't actually what the customer wanted at all.

The sooner you can put something in front of a customer and gather critique, the sooner you can start fixing issues and stop wasting development time on dead ends.

Part of the agile ethos borrows from wabi-sabi where it is understood from the off that software is imperfect, impermanent and incomplete. As with anything that is created, it doesn't necessarily have to be the best in class to deliver value.

As for an analogy, what is really being created here is a prototype.

Answer 3

It could be understood and done in style "give user slightly alive something and let him test that for us". And that way is really very dangerous and bad practically in any way.

The analogy could be: Cargo-cult. When wild tribes after a US base moved away in 1945 built a model of a plane of sticks and leaves and thought that its spirit will bring them prosperity. The main problem: they do not know what this thing is for and really don't want to know. They have their own ideas and are happy with them. It is a simulation of work.

But if the target was:

• to give him a piece of real work as fast as possible, already supported for invisible for user but helpful for authors tools such as automated testing and logging.
• if that piece already gives user some undestanding about how the whole future product will be worked with
• to repair problems and add further features with as fast reaction as it is possible, with product remaining solid and sound

then it is very good way in REAL agile style.

Analogy for that case is: A client has ordered a new model of some technical machine.

1. He gets pictures how that machine could work.
2. He gets an armchair of the driver.
3. He gets the armchair with all levels and controls faces around it
4. He gets carrosery with wheels and motor and simplified driver place for movement only, without special apparature controls - to check how it moves
5. The real work places is mounted on the carrosery .... And so on. - up to the ready product.

And on every stage the work could be solidly checked and the client and the producer can correct former mistakes.