How to dance like Shiva

It was 1994. I worked for Motorola in Bangalore. I was part of the team that had helped Bangalore operations to become SEI CMM Level 5 ahead of any other company in the world. Other businesses in Motorola were also quite impressed with this landmark.

Motorola was primarily a hardware company in those days and they also made mobile phones, pagers, modems. Do you recall your first mobile phone? It was probably a Motorola. 

Singapore was the Asia-Pacific hub for the pagers & mobile phone business. At that time they were quite unhappy with software related issues they were facing.  80% of the field complaints were related to software, in one way or another. 

Motorola offered me a 2 year stint in Singapore, to help fix software side things. I had about 10 years of experience by then.

I landed up in Singapore. Expectation on me from the beginning was to test all the software and prevent any defects escaping to the field. They expected it to be like testing hardware through sampling. 

How was I going to convince them otherwise? Just sampling based testing, using checklists to test etc. are not effective in software testing.

When I pointed this out to my boss, he said he had solved his problem by bringing me onboard. It was now up to me to figure out how to reduce software related problems.

We sold our phones & pagers through phone carrier companies. Daily, complaints streamed in from them. Every morning before coming to work, I would shiver to think what new fires were in store for me that day. It was stressful, but I kept going - perhaps because of my daily meditation practice. 

My first breakthrough came when they began to see software as not just one big ball of wax. I had insisted we dig deeper, rather than just pointing and accusing finger at software in general.

Embedded software ran the phones. Engineering software ran the factory. It tracked versions, models, and variants across the product line. The IT systems carried the Customer Order processing. Customization software - on a PC -  was sent over to customer locations, but we managed it.

 Slowly, they started to point and say where they saw a particular problem.

Once we knew the specifics, I started interacting with software engineers from across these different groups. They were happy to talk to someone who understood their pain. They fixed what they could fix. They were also happy, they had something of a voice to reach out to senior management through the Quality Function.

In management meetings, bosses would often tell me, “Software is so easy to change. Why the big fuss?”

My next challenge was to convince them that ease of making changes was actually the culprit. So many versions and variants floated around. Multiplied across models and customization - the complexity became exponential. It was not getting managed. Thus the chaos.

To make matters worse, they measured the Product Management team on how many new features they introduced. Guess what they would do at the drop of a hat?

I suspected that most of the minor features never got used. But the bolt-on additions created complex defect prone code. Of course, I had no data to prove it.

One day I chanced to speak to my boss’s boss. 

I said, “Hardware is the body, but the software is like the Soul. When phone models and batches change, the software remains unchanged. It has to be tended differently from the body.

Just like bad karma accumulates over lifetimes and catches up with you, short-sighted quick-fixes catch up with you. They make the code very complex and error prone. 

He was a practising Buddhist. He resonated with this. So he invited me to speak in his boss’s staff meeting. This was as senior as you could get in Motorola, Singapore.

I explained my intent to the august gathering and asked permission for a survey to better understand the nature of the defects that were accumulating.

We got the permission. 

We camped in a carrier company for the next few weeks. We interviewed. We conducted a survey. Our findings were revealing. Only 10% to 15% features and options were actually used. The rest - unused.

However, they introduced complexity in the whole software ecosystem - the embedded software in the phone, IT software, factory software and Field programming software. Keeping all of them in sync and maintaining the integrity of all the applications was a humongous task every time we introduce any change.

This complexity was the source of defects.

When all the stakeholders saw this big picture and the cause & effect relationships, they realised that the systemic change needed was in simplifying things. This triggered a global initiative called complexity reduction program.

We began to refactor code to simplify it. We dropped unused features.

Things changed dramatically after that. Software defects almost disappeared. They asked me to stay on for some more time and contribute further towards software excellence. 

On a personal front, India beckoned me every day to come back, for spiritual reasons. So I landed back in Bangalore after one more year of this adventure.

---

First published on https://www.linkedin.com/pulse/how-dance-like-shiva-brij-sethi/