The seven principles of Lean Software Development; eliminating waste, creating knowledge, respecting people, building quality in, deliver fast, optimizing the whole, and to defer commitment are concise principals that appeal to many developers and managers, as they are pivotal in achieving delivery of high quality software systems on time.
These principles have a foundation in Lean Manufacturing that had been very successful throughout the 20th Century, which delivered customer value and popularized Toyota's turnaround in the 1980's. So it may not be a surprise that Lean has moved into software development and appears, so far, to be quite successful.
However those new to Lean may perceive some of the practices involved non-intuitive and sometimes contradictory to Lean principles, in particular:
- Ceasing Inspections (contradictory to creating knowledge) - for example ‘If we stop code reviews how can we understand how to improve the code and where we are making mistakes?
- Deferring Commitment (contradictory to Eliminating Waste) - ‘If we leave decisions to the last minute, we will have people sitting around not working!'
- Knowledge Sharing (non-intuitive to a successful product) - ‘If we share our issues with the customer they will lose confidence in our ability to produce a successful product!' or ‘If we share ideas outside of the organization someone will copy our idea and we will lose the intellectual property and the advantage of time to market!'
By investigating these three points it can be shown that these practices are indeed beneficial to the organization by driving quality within the development group and increasing customer satisfaction in the software industry.
"Cease Inspections" does not mean stop all code reviews. Code reviews are useful and create knowledge. What this concept is telling us is to eliminate large reviews at the end of a development phase.Large reviews invariably lead to bugs being found, but at the expense ofdelaying the project, in some cases up to several weeks or months.
Code reviews need to be performed at a level where waste can be eliminated (another of the seven Lean Software principles). By having frequent reviews, any bugs or improvements discovered can be discussed with the owner of the code. This continual feedback allows the developer to be in the correct mental context to refactor and fix the code faster than if several weeks have passed since he last touched that part of the code base.
By implementing continuous integration with unit tests (and integration tests where possible) and integrating tools such as static code analyzers, dependency analyzers and code coverage software, the mundane parts of Code Inspections that are subject to human error are eliminated leaving the more expensive resource (the Reviewer) to concentrate on the core business domain that these tools are not [yet] intelligent enough to investigate.
By not using the tools available, reviews become de-motivating, overly complex and time consuming (again, waste). These reviews then often simply fade into oblivion, leading to a necessary large review at the end of the project. By only having this large final review many bugs and some feature ambiguity will arise, leading to rework that either extends the time to delivery of the solution or eats into other processes such as User Acceptance Testing. This is precisely what we are trying to avoid. COMMENT1
Another practice that can provide continuous, real-time inspection is pair programming. The code is continually inspected by at least one other person and therefore defect rates are lower and design decisions are questioned at code-time (Build Quality In). Communication is enhanced and more team members share knowledge of the system thus creating knowledge.