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?

  • 2
    In my view it's not OK to purposefully ship buggy code. It's OK to ship a MVP that doesn't include all of the features you eventually want to have, get feedback and iterate, but note the V. Field research is one thing, treating your customers as QA another. An analogy related to boats would be a colander: it has the rough shape of a boat but sinks, and your (now wet) customers will not be happy about that. – jonrsharpe Jul 14 '17 at 10:03
  • 2
    To put it another way: the product can fail fast, but the software should do what you say it does. – jonrsharpe Jul 14 '17 at 10:06
  • How do they handle regressions? Do they do automated testing? – Euphoric Jul 14 '17 at 10:37
  • The most hilarious part of people who don't understand why CI/CD is superior is that software that goes through a long winded and bureaucratic release process is often buggy as well when it gets to production. Anyway there are copious examples of industry real-world research that shows the benefit of the CI/CD model. Why do people still advocate for a development process that was created to deal with the business case around shipping software on floppies?? – RibaldEddie Jul 14 '17 at 15:39
  • 2
    Fail-fast means exactly what it says. Fail as soon as possible, ideally while still on a dev's PC, not when it goes through QA, and definitely not when deployed to production. – Eternal21 Jul 14 '17 at 15:45

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.


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).

  • 2
    The question was not about TTM, but about fail-fast method in deployment, wasn't it? – Gangnus Jul 14 '17 at 10:38
  • Any analogy you can describe? – user127379 Jul 14 '17 at 10:45
  • @Gangnus: what made me think of TTM is “speed is most important for them” in the question, but yes, it may be that my answer covers a broader scope than the question. – Arseni Mourzenko Jul 14 '17 at 10:48
  • wow so good answer to a bad question. +1 – BЈовић Jul 14 '17 at 11:49

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.

  • I love it. How many software companies have you worked in where they had a very conventional waterfall-esque release process, planned by an army of PMP certified PMs and a QA team and an Ops team? One of my early jobs was as a junior dev on the "architecture" team and after all of that process, developers STILL had plenty of bugs to fix on prod! Bugs don't disappear because of process alone. But some processes are better suited to solving the actual problem. And CI/CD is one of them. – RibaldEddie Jul 14 '17 at 16:24

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.