Agile programming Week 05 52m Eliminating Code Waste with Lean Principles

In Lean Software Development, value is defined strictly from the customer's perspective as delivering working, usable software. Anything that consumes time, effort, or resources without directly contributing to that value is classified as Muda (Japanese for waste). In Week 05 of the SWE6301 curriculum, Lean thinking provides the underlying "why" behind many Agile rules, placing heavy emphasis on simplicity—defined as "maximizing the amount of work not done". It also highlights Robert Martin's First Law of Documentation ("produce no document unless its need is immediate and significant"), showing that writing excessive paperwork or over-engineering code creates unnecessary waste. The 7 Wastes of Software Development (Muda) The module materials and reading sources adapt the classic seven manufacturing wastes to software development as follows: 1. Partially Done Work (Inventory) Work that is only partially completed, such as uncommitted local code branches, unintegrated features, unverified specs, or untested software. Unfinished work provides zero immediate value, risks becoming obsolete if requirements change, and clogs the development pipeline by inflating Work-in-Progress (WIP) and lowering overall throughput (as expressed by Little's Law). 2. Extra Features (Overproduction / Gold-Plating) Developing functionality or infrastructure that was never requested by the customer or prioritized in the backlog. As Eric Ries noted, "building something nobody wants is the ultimate form of waste". Extra features add unneeded complexity, requiring continuous testing, maintenance, and documentation. 3. Relearning (Knowledge Waste) Time spent rediscovering information or re-learning code logic that was once known but lost due to team silos, forgotten context, or poor knowledge sharing. Causes include hard-to-find documentation, outdated onboarding materials, or lack of peer collaboration. 4. Handoffs (Transportation) Passing work sequentially from one specialist or team to another (e.g., from business analyst to developer, or developer to QA/ops). Each handoff risks losing tacit knowledge, causing miscommunication, and placing work into waiting queues. 5. Task Switching (Motion) Frequent context switching between multiple projects, tasks, or unexpected meetings. Interruptions incur a steep cognitive penalty—taking 15–20 minutes to regain deep focus—which undermines productivity and code quality. 6. Delays (Waiting) Idle time where work sits waiting for code reviews, pull request approvals, stakeholder decisions, or external dependencies. Delays slow overall flow and delay the feedback loops needed to correct course. 7. Defects (Rework) Bugs or quality flaws requiring diagnosis, fixing, re-testing, and redeployment. The longer a defect sits undetected, the more expensive and time-consuming it becomes to fix. Structural & Technical Waste: Design Smells and Software Rot Week 05 explicitly connects operational waste to internal code quality and Technical Debt. Unclean code leads to "software rot" and distinct design smells that slow down development speed: Rigidity: Code that is hard to change because a single modification forces a cascade of secondary changes. Fragility: Code that breaks easily in unrelated modules whenever a change is made. Immobility & Viscosity: Tangled code that cannot be reused, forcing developers to "reinvent the wheel" or use quick "hacks" rather than proper design. Opacity & Needless Complexity: Code that is hard to read or carries the "weight of unused design elements" (e.g., complex class hierarchies built "just in case" for hypothetical future requirements). Core Agile Practices for Eliminating Waste To prevent software rot and eliminate Muda continuously, Week 05 emphasizes four primary practices: Build Quality In via TDD: Practicing the Red-Green-Refactor cycle ensures that developers only write code required to satisfy failing tests, catching bugs immediately and preventing defect rework. The "Boy Scout Rule": Always leaving the code cleaner than you found it by performing micro-refactorings to eliminate repetitive logic and improve variable expressiveness. YAGNI ("You Aren't Going to Need It") & Deferring Commitment: Avoiding premature architectural abstractions and keeping design decisions simple until real requirements force a change. Limiting Work-in-Progress (WIP) & Waste Audits: Adopting a "stop starting, start finishing" discipline on Kanban boards and running periodic Waste Audits to prune uncalled functions, unused imports, and unneeded infrastructure.