The Top 10 Wastes of Software Development: The Other Side of R&D Effectiveness - Weekly Sharing

Image Source: Wikipedia

" Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software" is a (2007) Random House literary nonfiction book by Salon.com editor and journalist Scott Rosenberg. It documents the workers of Mitch Kapor's Open Source Applications Foundation as they struggled with collaboration and the software development task of building the open-source calendar application Chandler.

I read this book more than ten years ago. At that time, I was still working at Cisco, and I felt that the R & D team's mistakes could be seen in this book.

Mitchell Kapor, the designer of Lotus 1-2-3, set up the Open Source Application Foundation (OSAF) after leaving Lotus. He recruited a group of brilliant programmers and developed the so-called revolutionary next-generation personal information management system—Chandler. It seems that this team does not lack money, technology, and experience, but it can not release seemingly simple software. Six years later, Chandler barely struggled to release version 0.7, spending millions of dollars, but finally failed, dreaming in code.

During the six-year marathon, the project members made a series of mistakes, which led to more dead than alive in the promising project. For example, the members of the Chandler project decided to use P2P architecture to share calendars, but they did not try their best to design relevant algorithms or protocols. Instead, they spent a lot of time discussing Chandler's interface, which lasted for several months. Finally, the P2P architecture was completely abandoned, a great waste. It is common in software development to do something like this and then be overthrown.

We will discuss the opposite side of software efficiency, the "waste" that causes low software effectiveness. Waste can be divided into:

Direct waste: unnecessary development cost or waste that people can feel directly, such as (code that no one uses, code that is commented out, features that are never used, over-testing, etc.)
Indirect waste: the development cost that is not directly visible, such as the additional cost caused by poor quality, code complexity, and low communication efficiency.

Whether it is a direct or indirect cost here, I do not look at the causes but the results. I summarize it as the top ten wastes.

The 10th Waste: The Work Done is not Effective Promptly

For example, the written code is not submitted to the code base in time for construction and is still in the developer's local machine. The tested functions have not yet been delivered to users, which means that the tested functions are still in the company's inventory, and no benefits have been generated.

The 9th Waste: Switching Between Different Roles or Tasks

For example, one person participates in multiple projects and needs to switch between different tasks. He needs to be familiar with too many business and project backgrounds and often switches his thinking and virtual workspace, which will cause a lot of time waste.

The 8th Waste: Unnecessary Handover in Software

The handover of tasks in software naturally increases learning costs and the cost of communication. Although handovers are inevitable in daily software development, unnecessary handovers or excessive handovers can lead to waste. For example：

The employee turnover rate is relatively high (e.g., higher than 20%), and the work handover between seniors and newcomers.
The handover between developers and testers, such as development and testing, are two relatively independent teams;
The handover of software from development to deployment (this cost is low if effective DevOps is implemented).

The 7th Waste: Overwork (Out of Range)

Working without an accurate understanding of the scope of the project or task because of a lack of effective processes, documentation, consistency requirements, etc. Team members work out of scope or fail to do it just right, including over-managing, over-testing, writing too much documentation, over-communicating (too many meetings), etc.

The 6th Waste: Waiting

Many people wait for other people's work. For example, the team's communication and collaboration are not active enough, waiting for others to find them; development and testing do not work well together, testing waiting for the development to submit a new version; various links are not well connected, there will be waiting in the middle. Even if a team or a job has waiting, such as not doing continuous testing, there will be waiting in the middle. Sometimes the test environment is not ready to do testing, and there will be waiting.

The 5th Waste: Repeat Mistakes

Team members did not conduct root cause analysis, so we should suit the remedy to the case. Some team members don't make mistakes, but others do it again; some teams don't make mistakes, but others do it again. Mistakes can be of all kinds, including poor planning, wrong version of the documentation, etc.

The 4th Waste: Reinvent the Wheel

There are already open source or mature commercial tools on the market, but instead of directly using them or buying tools, etc. Team members develop these tools themselves.

The 3th Waste: Rework

The lack of uniform specifications, complex systems, and weak personnel capabilities lead to poor quality and many defects, resulting in the redesign and rewriting of code, all of which are reworked. Excessive code refactoring and regression testing are classified as waste from rework.

The 2th Waste: Useless Functions and Codes

According to some statistics, useless functions and code, similar to "overproduction," as many as 2/3 of the functions in existing software applications are almost or never used, including code that is not used, code that is commented out, etc.