Software Development in Total Quality Organizations

Introduction

Who is empowered in an organization to meet the needs of the internal or external customers and why? For purposes of this post, a software company will be the organization in question, and the process of developing new software will be considered.

In multi-phase processes like adding a new feature to a software product, the customers will change according to the phase, and the person most responsible for meeting customer needs will also change. We will call this person the “meeter-of-needs.”

We begin with the description of the phases involved in creating a new software feature. A table listing the customer and customer needs at each phase is presented. We conclude by describing the factors that increase overall completion time and some ways of decreasing that time.

Creating a New Software Feature

Consider the situation where a new feature is to be introduced into an established software product. Assume the software product primarily has external users (customers). The steps to accomplish implementing a new feature can be organized into the following phases: feature definition phase, development phase, testing phase, deployment phase, and post-deployment phase. Here, “deployment phase” means making the new feature available to external users.

The feature definition phase starts when someone has an idea for a new feature. This idea usually does not come from external customers but rather from internal personnel (subject matter experts (SMEs), developers, QA testers, or managers). This phase is usually short, taking just long enough for functionality to be specified. Developers are the ones who will find exceptional situations (called “corner cases”) and will work with SMEs to determine how the feature should behave in the corner cases. For minor features, no cost estimates are needed. The developer will provide an extremely rough estimate for time needed to implement the feature. Note: there is no reliable way of accurately determining this length of time.

In the development phase, the developer writes code that implements the new feature. This phase also includes something called “local testing,” which is where the developer tests his code on his own computer or on a computer called a “development server.” A good software developer will test not only the expected use cases but also the corner cases. If necessary, he will also do performance measurements, to determine how fast the new software runs and whether it consumes an unnecessarily large amount of memory. If problems are found, the developer will fix them.

Larger software companies, where bureaucracy is deemed acceptable, will then perform a code review, which involves other developers reviewing the code and providing feedback to the original developer. Automated testing scripts in the form of “unit tests” may have to be written by the developer. This usually requires the delivery time estimate to be tripled.

Next, the code will be deployed on what is called a “QA server.” This is the server on which the QA tester or staff will perform their own tests. If any problems are found, QA would describe the problem directly to the developer, who must then fix the bugs. The QA phase restarts. The act of deploying the new software is performed by a “dev-ops” person, which is a title for system administrator.

Finally, the code is deployed to the “production server” by the dev-ops engineer so that external customers can use the feature. Sometimes, the feature is released to only a subset of all customers, called “super users,” and they will use the feature before it is released for widespread use. If any bugs are found, they are reported though customer support, and QA will formalize these as bug reports. The developer will fix them, and the code will then be re-tested.

Table of Customers and Meeter-of-Needs

Phase	End-of-Phase Deliverable	Involved People	Meeter-of-Needa	Customer
Feature Definition	Feature specification	All relevant people (manager, devs, SME, QA)	Manager	Developer
Development	Functional software running on QA server	Developer and dev-ops engineer	Developer and dev-ops engineer	QA
Testing	Go/no-go decision plus bug-reports if no-go	QA, developer, and maybe dev-ops engineer	QA	Dev-ops engineer (go) or developer (no-go)
Deployment	Software running on production server	Dev-ops engineer	Dev-ops engineer	External customers (end users)
Post-Deployment	Bug reports	End users, customer support, QA	QA	Developer

Conclusion

As shown with the use of multiple quality checks, as well as the opportunities to improve software quality, companies following this process are certainly focused on meeting customer needs and continual improvement (Goetsch & Davis, 2021). The “process” described here is part of what is sometimes called “cowboy programming” (Siqueria, 2023). This has been shown to work even in large software companies, at least among high-performing software teams (West, 2007). Cowboy programmers are often dismissed by other types of developers, which cowboys refer to as “stodgy dilettantes.”

The Herd Quitter by C. M. Russell, 1897

In low-bureaucracy companies, this entire process from conception to widespread release will take two or three days. Otherwise, the process could take weeks or months. Sources for this delay include reliance on so-called “agile methodology” (Martin, 2008), the presence of irrelevant people in the process, absolute requirements for unit test scripts, and incorrect feature definition. Also adding to the time are situations when developers who fix bugs are different from the original developer.

One way of minimizing the time is for developers and QA testers to work closely together, especially during the testing phase. In that way, bug reports can be communicated directly to the individual responsible for fixing them. Another way to minimize the overall time is for developers to get involved in the feature development phase. This eliminates the need for the developer to get repeated clarification from SMEs. To minimize completion time in general, minimize the number of people involved – include only needed personnel, but no fewer.

References

Goetsch, D. L. & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9^th ed.). Pearson.

Martin, R. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Pearson.

Siqueria, S. (2023, 5 June). Cowboy coding style. https://dev.to/sarahcssiqueira/cowboy-coding-style-3d9l

West, M. (2007, 3 January). What is cowboy programming? https://cowboyprogramming.com/2007/01/03/what-is-cowboy-programming/