7 Wastes in Software Development

If you've ever been exposed to Lean Manufacturing, you've probably heard of the 7 wastes. Let's start with the opposite of waste: value. Value-adding activities are ones that directly transform products into something the customer wants to buy. So then how do we define waste? There are a lot of definitions, but my personal favorite is this one: any activity that can be eliminated without impacting the quality of the final product to the customer. The classic 'what the customer is willing to pay for' is confusing since the customer pays for everything. If you're in business and the customers are buying your product, they are clearly willing to pay for whatever waste is present in your business. But a good business understands that wasteful activity creates opportunities for competitors to provide very similar products with similar (or even better) quality at lower cost. To minimize those opportunities, you need to minimize wasteful activities.

Luckily, there are only 7 of them. Some people will define an 8th waste - waste of human creativity. While you are doing wasteful stuff, you aren't doing something that could better use your intellectual horsepower. I also find this confusing since it in and of itself doesn't define a waste activity. Let's stick with the 7 - they are:

But how do these apply to software development? If you're developing software for your company or managing a software development team, you should be aware that wasteful activity creates opportunities for competitors (as previously mentioned). Waste slows down the development process and adds cost/time. It will take you longer to get new features and products in the hands of your users. It will cost you more, and you will have to charge more to make up for this. And once a competitor can come in and provide similar (or better) product at a lower cost, you're playing catch up.

Here are some of the ways the 7 wastes apply to software development:

1. Defects. Pretty obvious. These are bugs in your software that cause errors, crashes, or poor performance. But this can also be 'defective' requirements. If the requirements are just wrong, you end up wasting a lot of time writing worthless code. What's really difficult is when different coders have different styles. When there is a defect and the naming conventions aren't standard, file locations are all over the place, coding styles are completely different, it makes it difficult to troubleshoot. There are some things that require real innovation - naming convention shouldn't be one of them. Ruby on Rails has a simple idea - convention over configuration. Conventions (i.e., standardization) makes troubleshooting and bug fixing substantially easier. It also minimizes a lot of the mundane code and decisions. This specific example could also be considering extra processing and/or over production.
2. Over Production. Writing features no one is asking for, writing more code than what is required (inefficient coding), making systems too complicated with more screens/options/settings than what is needed.
3. Waiting. Having to wait on approvals, paperwork, mgmt decisions, waiting in meetings, and waiting for clarification from product managers all soak up engineers' time and effort. Waiting on release cycles is a complex one. Some companies are going to a constant release cycle (think Google Chrome) and this has proven to be exceptionally good at providing value. The days of yearly releases are slowly coming to an end. Another really common wasteful activity is waiting on the computer. Slow, out-of-date computer systems and hardware are frustrating to use and wasteful for the engineer. As inexpensive as this is nowadays, there's really no good excuse for this.
4. Transportation. It is wasteful to have software engineers walk from place to place, putting them too far from hardware, isolating them in offices where they have to get up all the time to collaborate. But even designing offices where the restrooms are really far away, the break rooms are in different buildings, and setting up department silos is wasteful. It works way better for the engineer to have a convenient place to work and collaborate. Companies have had great success at putting together multi-discipline teams and co-locating them for easy collaboration.
5. Inventory. This one is a big one. Having a ton of projects in the queue or a ton of emails in your inbox that need to read/responded to is extremely wasteful. It creates a ton of other waste. Fixing this is difficult since today's culture creates tons of projects in large queues and tons of email traffic. Creating a bunch of features that then go and get tested in batch is also an inventory step. You want to minimize this. Create a feature or make a small change, then test. If there is a bug, it's far easier to fix when you've only changed a few lines of code versus hundreds. Today's testing features make this easier than ever.
6. Motion. If the workstation and work space is designed where the engineer spends a lot of time moving things around, clicking around complicated screens, switching between systems, having multiple computers to accomplish various tasks - this is wasteful. If you have 15 different systems to manage your software development life cycle (SDLC), this requires engineers to constantly switch between these different systems. You might use Git, Jira, Bootcamp, Outlook, Excel, Word for documentation, Sublime for actual work, database management programs, GoToMeeting, XTerm, network drives, Dropbox, ERP systems, and so on. Basically, the business gets complicated as it grows. This creates waste as engineers need to learn and navigate all these systems.
7. Extra Processing. Refactoring is a great example of this. Sometimes we write code that works fine, but the code itself isn't all that great. Functions are repeated in multiple places and the code gets cumbersome to manage. So we refactor with the DRY mentality in mind (don't repeat yourself). But we also have to spend extra processing time dealing with shifting priorities, applications that require a lot of maintenance and hand-holding, deployments that require steps to be repeated over and over for every install. A step that is extra processing that's really difficult to eliminate is testing. Testing is an extra process that is done to ensure code works bug free and as expected - it's a critical step to delivering good code; however, testing can be largely automated nowadays. If the software is written with testing in mind, you can significantly minimize the testing phase while providing better quality software. Unit testing is a good example of this (i.e., PHPUnit, Minitest in Rails, python's unittest).

Having the engineers focus on the value adding side - writing code that works and adding features that users will actually use - make for a better work environment, faster SDLC, and a better customer experience. Engineers don't want to sit in meetings, walk from place to place, deal with confusing or unclear requirements, deal with complicated systems, or have to look at a backlog of 40 constantly shifting priorities.

What's emerged out of this are things like Agile software development where features are provided constantly to customers and engineers receive priorities on an as needed basis (JIT). By providing priorities and requirements only when needed, you avoid the large backlogs and confusing direction. Sprints, as they are called, are designed to provide enough direction for a short period of time in a clear, concise manner. This allows for shifting priorities, changes, etc... without impacting the engineers. It also makes testing go smoother and you roll out features more frequently to your customers. Basically, you're trying to minimize the 'concept to launch' value stream while still providing high quality code and great user experiences.

How do you manage your software development teams and how do you ensure your teams are focused on the value creating portion of their jobs?