When you’re a manufacturing engineer (I was) working in the software development world (I am), you try to draw similarities between what you currently do and what you previously did.
You notice a few buzzwords like Agile and Six Sigma popping up. Sometimes where they do belong, sometimes where they don’t. And this hints that there is a comparison waiting to be found.
They both have types of engineers. True. They’re both building things. True again - probably also why they both have engineers. And they both involve planning, quality checks and rapidly improving technologies. All true.
So are we saying that software development is like manufacturing?
No.
But nor is software engineering like assembling a watch, or playing tennis, or teaching a language. It’s also not anything like driving a tractor.
What makes them so different?
Manufacturing is about designing and creating a product and then replicating it, over and over again. It’s about the process of copying, and ironing out efficiencies over time.
Software development is about creating entirely new things. And about complex algorithms and clever logic. It’s not about repetition - and if it is where you are, go find yourself a new job.
Many product teams start with a minimalist prototype of their app or website and add features with each iteration. Building a prototype television to see how the buttons look is ridiculous, but in the software world, it makes sense.
There’s no denying that manufacturing and software development are worlds apart. But the concept of quality and catching issues before they’re in the hands of consumers or users is extremely important for sustainable growth in both.
With this in mind, I’ve reframed the question:
Knowing what manufacturing does to build quality products, what can we learn?
In reality, it should have been this all along. And as you’re reading an article written by someone in quality assurance, you may have guessed that this is where we’d end up.
Manufacturing has had a 200-year head-start, so there will undoubtedly be many lessons to be learnt.
Quality, Speed, Cost and Flexibility
The first of these is the intrinsic link and delicate balance between quality, speed, cost and flexibility. Change one and the others follow suit.
You want something manufactured cheaply and quickly? Chances are it’ll be poor quality, scrappy even - think flip flops that last roughly 1.5 days on holiday.
You want the flexibility to switch out components, customised for each order? Then you’ll be paying for this luxury - like [something expensive and customisable] vs. [something cheap and non-customisable].
Similarly, in software development, if you push for releasing quickly or cutting costs by cutting out the QA phase, you’re going to have a bad time. The details of how bad this time will be will come later. But it’s along the lines of bad reviews and app crashes.
Project Management Learnings
When you really look at it, project management techniques in software development aren't all that different from those developed for manufacturing. In fact, there are already many manufacturing techniques that have made their way into software development.
Agile
Agile is used to describe the top-down approach where processes are in place to iterate quickly in response to changing customer or market needs.
Combining this with theories of knowledge management, Scrum was developed. And so named for the huddles in Rugby that require quick decisions based on even quicker assessments of competitor tactics.
As software development moved towards frequent releases and iterative design, Agile and Scrum worked their way into the industry.
And if there’s any doubt that this philosophy has been adopted, adapted and further developed for the software industry, I recommend you check out The Agile Manifesto.
Kanban
First developed on the Toyota production line, Kanban is used to regulate the supply of raw materials through a production line. By using physical instruction cards the system tracks movement and usage.
As with most things in software, it has transcended its physical form; holding on to the concept of a card progressing through different stages. And finding a Kanban board is as easy as freezing your computer using IE8. Which, trust me, is pretty easy.
Think Trello, JIRA, and GitHub, to name a few.
Getting Back to the Quality Discussion
Six Sigma
As far as I know, Six Sigma is one of the more prevalent manufacturing philosophies to make it into software development. Putting aside the statistics - because the concept of defects per million products built doesn’t particularly apply here. And also because there’s little enjoyment in statistics.
The idea is that quality is a driving factor for each step of the manufacturing process, from design to production. And when there are things like Test Driven Development, Unit Testing and Integration Testing, the influence is spelled out for us.
Concepts that Haven’t Yet Been Stolen
Or at least they’ve been stolen subtly, and renamed to something cool; maybe with some konsonants switched up or some vowels removd.
And while Six Sigma has infiltrated the industry, there are still loads of other quality-related concepts that we can learn from.
Those manufacturers haven’t just been twiddling their thumbs for 200 years, after all.
Lean Manufacturing
Lean manufacturing is all about eliminating waste. Toyota came up with 7 handy ways to categorise this waste. Or Muda, if you’re Japanese, or a true Toyota fan.
The most relevant of these are waste caused by:
Motion - making people do more work than the need to; creating too many or over-complicating features
Waiting - for the piece of the puzzle that your colleague is currently working on; or for the app that you’ve developed to come back after being sent to QA
Defects - the time and cost to reverse the damage caused and prevent it from happening again
Total Quality Management
Total Quality Management is the idea that quality needs to be in every aspect of the business. And every member of staff must be committed to maintaining high standards and improving processes, products and culture in all areas of the company’s operations. That’s right Susan in accounting, you too. Just kidding, we don’t have a Susan. Or an accounting department.
This highlights the effect that quality has on more than just the product and tech departments. It affects marketing and sales and the ability to bring in new customers. It affects account management and the ability to retain customers. And it even affects HR as over time people lose morale working on something their users aren’t happy with.
One of the more interesting ideas that I think the software development world can benefit from, is the idea of the cost of quality. Or more specifically the cost of poor quality.
In manufacturing, it’s been broken down into:
internal failure costs - costs associated with defects found before the customer receives the product or service
external failure costs - costs associated with defects found after the customer receives the product or service
appraisal costs - costs incurred to determine the degree of conformance to quality requirements
prevention costs - costs incurred to keep failure and appraisal costs to a minimum
And in manufacturing, they have the luxury of knowing exactly how much revenue they’ve lost.
They can say things like ‘The machine stopped for 50 minutes’ or ‘We lost out on making 200 potential pens.
Aren’t they lucky.
In software it’s not that easy. Which is probably why there isn’t much time spent on understanding the cost of poor quality.
And in fact, not all of these are unnecessary or even preventable costs. Above all, the main cost, however, is external failure cost.
For a software company, especially in the B2C realm, this is likely the most harmful. In the age of speedy bashtagging, scathing app reviews and widespread internet rants, there are few other types of shaming that compare with internet shaming.
It can lead to loss of users and loss of income. It can harm your reputation and prevent you from bringing in new users. And for apps and websites that rely on word of mouth and organic growth, it will significantly affect your coefficient of virality.
So what can we actually learn?
Even thieves can’t steal everything. They get tired of lives of crime. So instead of stealing philosophies on quality, let’s find relevance in the seemingly irrelevant.
Working together - Combining Different Types of Labour
In the age of programming and artificial intelligence - there are robots everywhere. Which has fueled a widespread fear of annihilating humans from the manufacturing world. What used to be a largely manual industry is rapidly being conquered by robots and automation.
Or so we think.
If you look more closely, factory lines are more diverse and blended than ever before.
They’ve got static robotic arms. They’ve got standing people. They’ve got people on wheels. They’ve even got mobile robots with advanced sensors that can work alongside people.
It’s not about replacing people with robots. It’s about freeing the people up so that they can work on the tasks that better suit their skillset. And giving the robots the menial and repetitive tasks.
This isn’t to say that jobs haven’t been replaced - I can’t comment on this. And there is no escaping this fear. But right now, there is most definitely a place for humans in manufacturing.
With the rise of automation testing, this point is extremely relevant to the software world. What we once thought was a one-size-fits-all solution for every QA, is now a slice of a wider QA pizza.
Where automation adds speed and alleviates repetition, it removes flexibility and requires maintenance. And it has limitations, just as manual QA has limitations.
So what we should be learning here, is that automation isn’t the answer to everything. It is the answer to somethings. And combining manual and automation testing to maximise on their individual skills is where the true strength in QA lies.
Being clever to create synergy
As proud as I am that we’re all accepting the addition of our automated friends. There’s more to it than just tolerance. That’s not how progression works.
We have to embrace the change, maximise on our differences and feed into each other to create synergy.
So let’s take another page out of manufacturing’s book.
There’s a concept in manufacturing called Industrial Symbiosis. And what this really involves is using the waste of one manufacturing process as the input of another manufacturing process. Anything from steam to sand to biomass.
There are whole industrial compounds setup to facilitate this type of ecosystem - the most famous being Kalundborg in Denmark. And it’s popularity is only increasing as more companies strive to reduce their environmental footprint.
Before you claim that this is completely unrelated to the software world, think of it as more of an illustrative example.
Cast your mind back to the previous point about automation and manual testing. If they are used as two distinct QA strategies, when used properly and for their respective strengths they will no doubt produce great results.
But the key takeaway here is the concept of using the output of one process as the input of another. And in this case, using the output from the different types of testing to feed into each other and create a synergy of QA.
To automate what can be automated from manual testing. To learn from automation and feed that into manual testing. And to create the most comprehensive QA strategy.
Maximising growth
In manufacturing, like most other industries, you want to increase the efficiency of your process as much as possible.
There’s a calculation called Overall Equipment Efficiency that is a key indicator of how well the process is doing. It looks at the process’s performance and takes into account all the losses. Things like downtime, speed losses and defects.
It highlights just how reliant the industry is on the physical machines which are subject to so many external influences. So it makes sense that there is modelling and statistics and a great deal of planning that goes into determining their maintenance schedule.
And what it really comes down to is whether you’re going to spend time and money stopping the machines before they break on the off chance that it could prevent a potential issue or wait until it breaks. So you only stop when you absolutely have to.
The idea of Reactive vs. Proactive.
The lesson here isn’t about maintenance. But about the idea of taking proactive measures.
QA is reactive. You build an app or website and then you test. There probably is an argument somewhere that it’s actually proactive because you test before you release. But the bugs are there waiting to be found. It’s reactive.
But what if you could prevent some of them from happening. What if you could understand your potential users and their devices and their unique use cases. And then factor this into design and development.
In theory, it’s a great idea. In practice, it’s mostly relevant when you’re looking to expand into new markets and countries. You don’t want to launch your website, and then find out that people can’t sign up because you require a surname in a country where a significant number of people don’t have surnames. That could happen, and it has happened.
If you’re panicking now, I recommend looking into naming conventions in Indonesia.
You don’t want to spend weeks perfectly translating your app into a new language, and then find out that in fact, no one will be able to understand it because their phones don’t conform to international font-rendering standards. That could happen, and it has happened. Spend sometime reading up about the Unicode vs. Zawgyi battle in Myanmar.
For sustainable growth you need to keep finding new users. And to do this, you’ll need to keep opening your app up to new markets and new countries.
I also spend most of my time understanding how people all over the world use apps differently. So forgive me if I’m biased.
But biased or not, you should still spend some time thinking about how you can incorporate proactively understanding new users into your flow.
