Bugs that turned out to be expensive
Some of you may recognize the picture above, of a moth taped to a log book in September 1947. The moth was found in one of the relays of Harvard's Mark II. Although the word "bug" to describe a software fault had been in common use among engineers for some decades, this story is often mistakenly quoted as the origin of the word. If you're an engineer, you will agree that every system has software bugs. It's impossible to design and bring out a perfect software product. Fundamentally, the world itself is imprecise and unpredictable, and all software systems interface to the real world in one way or another. Some of these bugs may lie dormant and never see the light of day. Some others may occasionally arise and disappear without serious consequences. Some others, when they become active, cause catastrophes. It's the last of these that deserves our attention.
An anecdote is in order. India's Income Tax Department has a Excel file where you can enter your income details. The macros in the file will calculate the tax that you have to pay. Some years ago I used this software and submitted my tax returns. Many months later I got a notice to pay pending tax of ₹ 1! Clearly, a rounding-off error somewhere: macros in Excel did not agree with IT Department's enterprise software. Although this bug did not cause any serious damage either to me or to the government's coffers, history gives us far more spectacular failures due to software.
A Case Study from Personal Experience
Exactly a year ago I was approached by a friend to design and develop a web application. I don't take up projects unless I like the idea and see a potential opportunity in the market for such a product. His idea was novel. A quick survey showed that no similar products were out there. Ones that did something similar came from the background of generic ERP and CRM systems. They were not in any sense a web app the way he had conceived it. They were heavy and not user friendly.
We knew from the start that the focus had to be on user experience. The rules of design in this space are quite simple: keep it simple and eliminate clutter; present high-level summaries; make important items easily accessible; don't use fancy terms; keep navigation and structure intuitive.
A Method for Root Cause Analysis
Engineers are basically problem solvers but this is not really told to students when they enter college. Instead they are taught engineering mathematics, theoretical problem solving techniques, principles of engineering design, use of computer-aided tools, and many more such disciplines. No doubt these are all important and relevant but without the right high-level perspective to engineering, it is easy for students and young engineers to get lost in the details.
If engineers are problem solvers, what ought to be the approach to problem solving? I am sure each one of us has his/her own approach, something we have learnt from others or assimilated through years of practice and experience. In today's post I would like to share one such approach that had its beginnings amongst engineers at Toyota, Japan.It is called 5 Whys.
Examples, Tools, Practices
This is a continuation of an earlier article where I introduced Product Line Engineering (PLE) as a new engineering discipline. The idea is that it makes more sense to manage a line of products rather than a single one. There are many examples of this already happening in today's world.
General Motors does not develop individual cars. They have about 300 hierarchical subsystems and thousands of variant features. When these are combined in sensible ways, they end up with tens of thousands of product variants. In other words, each car is not built as a separate engineering artifact. Rather, they use common customizable building blocks to define and assemble a car. They do not develop but derive cars from such building blocks.
A better way to make products
The year was 1908 when Henry Ford's Model T was first offered for sale. By the 1920s, Ford had perfected the manufacturing process, producing more than a million cars a year. Parts were interchangeable. The assembly line was streamlined in a way never done before. Workers specialized in tasks assigned to them. Production efficiency was at its historical highest. But there was a problem lurking in the background.
Ford offered only one model. The colour was black. Customers could not have anything else. This was an opportunity for competitors like General Motors to enter the market that had been dominated by Ford. In the late 1920s when Ford realized this, he encountered another problem. The production line was so specialized for Model T that it took six months to just change the line to handle the new Model A. Even so, it took two years for Model A to achieve better production efficiency.
Insights from an IBM Symposium in Bangalore
Engineering in its traditional forms were really civil, mechanical and electrical. It took a long time for software to be considered seriously and it was only in the 1960s that the beginnings of software engineering took shape. Today we are used to complex software projects. The need for software engineering cannot be doubted by any serious engineer who is committed to delivering value and quality to his customers.
Now there is a shift happening, or has already happened. Software engineering still exists but there is an increasing emphasis on systems engineering. While the former looks only at software, the latter takes a more holistic view of the system.
India is on the verge of an innovation wave
The IEDF website has been up and running for a while now and I have been tasked to start off the blog section. The aim of this post is to establish the Indian context in which design is becoming more and more important with every passing year. If India has to become competitive on a global scale, it is mainly design that will save the day.