2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- January 27, 2016
- Rants
A large part of the success of the lean manufacturing movement was its call to eliminate waste. Deming introduced the concept that waste in manufacturing came from excessive inventory. Inventory was considered waste because it tied up capital and required that it be kept in storage until it was ultimately sold.
But what is waste in software? Unlike physical goods, software has no mass so it doesn’t need to take up space, and it doesn’t wear out. So does lean manufacturing concepts really apply to the software construction process?
In software, waste is defined as any work that has begun but is not yet completed. We define work in progress as waste for two main reasons. First, like inventory, work in progress is unused while under development and therefore no value is being derived from it. It’s like unused inventory, it is not yet realizing positive cash flow.
There’s another reason that unfinished work is considered waste in software development, and that has to do with tasks switching. It can take a lot of effort to come up to speed on a particular task, and when developers are asked to work on multiple projects at the same time there is a required ramp up time where the developer is re-familiarizing herself with the task and is not yet productive. This ramp up time can be quite significant when developers are asked to juggle several projects. It’s far more efficient to take a project from start to finish as quickly as possible. Not only does this eliminate the ramp up time required on task switching but it also keeps us focused on delivering, as quickly as possible, value for the one feature we’re working on. Rapid delivery means rapid feedback, which means we’re not wasting our time working on tasks that aren’t needed.
Until a feature is coded, integrated, tested and delivered, it is not providing value to a user. The sooner a feature can provide value to a user the better.
Until a feature is tested and integrated into a system it is not considered done. All the work that sits in a queue waiting for quality assurance to test it is considered waste. Any change to a system that requires additional QA effort turns existing code into waste until it is tested.
The way to eliminate this waste is to automate the process of verifying release candidates. Test-first development allows developers to create an automated suite of tests to validate release candidates so when the system is changed it can be verified with a keystroke.
Previous Post: « Why Nine Practices?
Next Post: Discussing Metrics that Matter »