Introduction

Introduction: This book is about trials and tribulations of Sustaining Engineering - a discipline that has been selling software even when customers were withdrawing. It comes with perspectives from being in the trenches of the day-to-day battles in the Sustaining engineer’s profession. Although there are different levels of expertise and widely-varying scope of practice, this book intends to provide an interesting read to one and all in software industry. There are several engineers responsible for building software products of varying size, reach and market and their paths intersect at a customer’s acceptance of the software, which often results in a shared wisdom for both the buyers and sellers. In this book, you may find some such learning and some technical in nature. The narration elaborates on the software industry’s paradigm, principles, methodology and timelines wherever they are impacted or influenced by this practice. Although it is not a prerequisite to be aware of software engineering parlance, this book does celebrate a specialty. And in this rat race, this book may reflect on those that blur into the blind spots. While other books have treated this subject under a bigger and more comprehensive topic of software quality assurance, this book attempts to describe the product feedback cycle. Moreover, this book is presented in the format that first introduces the craft, describes a few stories, delves into the engineering, describes the influences to software, and enumerates investigation techniques and translations to resolutions. Sustaining engineering is about software products that are being maintained hence ‘sustaining’ in the deployments with customers where they provide feedback with their usage. The company that makes the software product is focused on innovations and improved valued additions that come in waves of software releases to markets. These releases are often versioned to indicate which is older and which is newer. The older versions are upgraded to the newer on existing systems or the newer versions are installed on newer systems. As the software maker focuses on the next release, sustaining engineers focus on maintaining the existing released versions. The typical rule of thumb for how many versions to maintain is usually determined based on the usages by customers. Some companies maintain all their product versions as far back as the earliest as long as there are customers who have purchased them and want to actively use them. Some companies can choose to discontinue the maintenance on select older versions so long as both the customers and the company have an agreed exit strategy. Usually, the customers may be eased into newer versions. There are several factors that play out in to the extent of maintenance engaged by a software maker such as revenue, customer base, market segment, costs, resources, media, etc. and it is not uncommon to find two or three versions being maintained. Sustaining is all about this art and science of maintaining released software versions and often engages with customers throughout their usages. It is interesting to note that customers can run into issues of their own accord with any of these versions and not just when the software maker has put out a release the customer wants to use. That is why software sales and sustaining are both ongoing commitments for a software maker while being fundamentally different. In business, as customers and software makers engage, there is often a funny and cheeky practice that could be mentioned in a lighter vein. Software makers who suffer from quality often have more maintenance that incurs a lot of costs. One way to address this is to pass it on to customers! Customers may be ready to pay a price but often demand a price from the maker for not putting the defects in the first place! This conversation could have different connotations if the size of the customer or the maker were skewed. For example, this could imply negotiations or coercions, pricing, penalties and differentiation. Sustaining engineers often engage with customer cases. Such cases become an interesting insight into software itself. The first case is intended to give you a perspective but it may not be solely representative of the book. That is why this book is a collection of such descriptions.