How good are you at limiting red time? .i.e. apply limiting WIP (Work-In-Progress) concept to Programming and Product Development.
What is Red Time?
- During Test Driven Development and Refactoring, time taken to fix compilation errors and/or failing tests.
- While Programming, time taken to get the logic right for a sub-set of the problem.
- While Deploying, downtime experienced by users
- While Integrating, time spent fixing broken builds
- While Planning and Designing, time spent before the user can use the first mini-version of the product
- And so on…
Basically time spent outside the safe, manageable state.
Let it be planning, programming or deploying, a growing group of practitioners have learned how to effectively reduce red time.
For example, there are many:
- Refactoring Strategies which can help you reduce your red time by keeping you in a state where you can take really safe steps to ensure the tests are always running.
- Zero-Downtime Deployment which helps you deploy new versions of the product without your customers experiencing any downtime.
- Continuous Deployment which helps you get a change made to code straight to your customers as efficiently as possible
- Lean Start-up techniques which helps validate business hypothesis in a safe, rapid and lean manner.
- And so on…
I highly recommend watching Joshua Kerievsky’s video on Limited Red Society to gain his insights.
Over the years we’ve realized that it always helps to have simple tools to visualize your red time. Visualization helps you understand what’s happening better. And that helps in proactively finding ways to minimize red time.