Here’s a topic that I have been planning to write about for quite a while now, and I thought a new year is probably a good reason to start penning it down.

Software Engineering has naturally evolved since the time the first programs were written. And so have the expectations of its consumers. Today’s world expects everything to be digital. We use our smart phones to read news, to talk to our friends and family, and to perform most of our day-to-day chores. As consumers, we expect good websites, apps and technology enablement from all businesses. (I am going to focus on websites and apps but the same principles can be applied to any software)

This expectation has 3 constituents that define our happiness (or our perception of quality):

  1. All features we have seen elsewhere must exist (feature parity with competition)
  2. It must be easy and quick to use (customer centricity)
  3. Everything must work without flaws (bug free software)

I have often defined bugs as “deviations in a software’s behavior against stated or unstated expectations”. (Even if no one said they expect a software to work in a certain way, if it does not, they will still be disappointed and will still call it a quality issue).

This in turn puts a lot of pressure on businesses and their IT teams (I intentionally draw a difference between the two. We will address it later). The businesses want to deliver to all facets of the customers’ expectations, while managing the cost of delivering them. And the IT teams are flooded with requests, often overwhelmed with conflicting priorities coming from various stakeholders.

This makes software engineering much more complex than any other trade - a seemingly impossible scenario. It is only natural then that most IT teams do not deliver to the expectations of their business teams.

At the same time, my experience with various large scale IT teams showed a less than 60% time spent by developers on coding features. Even worse, many traditional organizations (businesses for which software is not the core product) have about 50% of team members than are in “overhead” roles - managers, coordinators, etc. - people that are not directly involved in writing the software on a daily basis. So, while there is an ever-increasing expectation of faster delivery, the actual effort spent on delivering the software is about 30-40%.

Let’s look at 2 exhibits I found on the internet.

[Exhibit 1]

[Exhibit 2]

The numbers may be different per organization, but we know that the reality is not far off for most of them. So, it naturally begs a question - can we fix this? How do we maximize the software delivery, and cater to our customers’ needs?

In this 3-part blog series, I intend to share my perspectives on the various tenets for this topic.

We will explore the following:

These blogs will follow in the coming days, and I look forward to hearing your reflections and experiences.