Moving fast and breaking things is a disaster

Software bugs cost the U.S. economy an estimated $59.5 billion each year, and more than half of that cost is shouldered by the end-user, according to a 2002 study from the National Institute of Standards and Technology.

The Standish Group’s Software Chaos report states that the software performance success rate is about 30 percent, and runaway and failed projects are common.

These statistics may sound surprising but think of the issues which a user faces today when from first thing in the morning is listening to music to booking cabs at the end of the day. During this entire process, no user can strongly bet that he or she has never faced glitches that have caused them financial losses or mental trauma.

The issue today is by some motto’s flowing in the market like 10X innovation, moving fast, and breaking things. The issue is not with the motto but with the blind adoption of these slogans by most software or tech startups. People have put them into a mold where they feel that if companies who came up with these slogans have succeeded; so does it works with us.

But that is a myth. The CEOs need to understand that every industry has is its own sensitivity and impact. For a networking site, this may not matter as their industry is not having much financial impact or any human life is involved.
But on other hand, a startup that is involved in specs manufacturing does have a good amount of human factors involved. In such industries, if speed is being concentrated more the quality will go down for sure and so does the experience. Even for networking sites, we have known cases where their ads or filtering methods were so improper that it lead to sabotage of an entire election process

Now engineers may argue that speed does not mean less quality but if we refer to the statistics above and use our experience and simple logic we do know speed will compromise on quality.
Speed will cause lesser design efforts, less design based on edge cases, and less effort on testing even if we devise the smartest of smartest testing methods.

Now let's explore the industries where the scale of building things are at a mega level and analyze how they do

1. Vaccine industry: The covid year 2020 proves this fact more than anything else. The companies might have accelerated their process yet the trials of all phases were done in the required manner and there was no skip. The second thing to achieve higher efficacy it took them at least one year of effort. In many cases, one year of efforts has also resulted in 74 % efficacy and some concerns.

2. Building of bridges: Number of bridges that broke vs the number of software bugs. There is too much difference. But what should stun software engineers like us are building a bridge involves so many components it includes logistics, project management, design, materials, weather-related challenges, geography and topology, human skills, etc. Yet when created they are perfectly tested, robust, able to deal with edge cases like having the bandwidth to accommodate heavy vehicles occasionally. But on the same hand, our integration test suite may be red much more times which may involve 10 components.

3. Building satellites and vehicles: How often does your vehicle need maintenance and how often does your code needs a patch. In my experience companies that have often tried moving very fast release buggy software which later needs patch after patch to rectify. Same with satellites; the computation there is so perfect that things on which we do not have visibility as such yet with data and right calculation we run things with utmost precision and handle edge cases. Whereas in our software engineering we do have a debugger at our doorstep.

The thing is in our software engineering for a lot of the domains we do have the luxury to have bugs as the max possible impact is revenue loss and no human loss. But based on that we are creating bad culture.

Also, we need to understand the higher need to spend time on the design and testing rather than on the coding.
Else it will be a very common assumption in few years amongst the public that software means buggy and less trustable.
We need to be more collaborative in our approach rather than hyper-competitive

Software Engineer by profession
Boxer by passion.


Productivity Engineer at Narvar . Data Science enthusiast. Boxer by passion