Lean Principles and Software Architecture: The Waste of Information Transformation
In Lean production, the waste of transportation and the waste of motion refer to the unnecessary, non-value-added movement of parts and material and people and equipment. While software development inevitably involves a certain amount of movement of people and equipment, information is the primary entity that moves or flows throughout the development process. Therefore, the mapping of the wastes of transportation and motion to software development might best be characterized as the “waste of information transformation.”
In software development, information is constantly being transformed. The end user’s mental model of the system as a set of capabilities is transformed to the architect’s mental model of system structure and the developer’s mental model of components, interfaces, and algorithms and the tester’s mental model of test strategies and test cases. These mental models are in turn transformed into human-readable artifacts (such as user stories or architecture diagrams or test cases) and machine-readable artifacts (such as code and automated test suites). The question is, What is the most effective way to transform the information? Which transformations add value and which add waste?
One approach to reducing the waste of information transformation is through tooling. Model-driven development is intended to automate (or semi-automate) the transformation of architecture and design models into executable code. Agile tools such as Fitnesse are intended to reduce waste in the transformation of requirements knowledge into executable test cases. Reducing waste in human-to-human and artifact-to-human communications, however, is a little less straightforward.
Agile software development challenges the value traditionally assigned to written artifacts (including formal models). Taken as a whole, the first three values of the Agile manifesto advocate ongoing conversations and collaboration as the key to discovering and elaborating requirements and working software as the ultimate embodiment of this knowledge.
In many ways, I agree with this stance. We have all seen the bloated and obtuse specifications that result from attempting to use a written document to capture each and every requirement at a highly detailed level of granularity. The waste of information transformation can be seen both in the effort invested to construct the documents and in the effort invested to extract information from the documents.
And yet knowledge based on verbal communications is ephemeral, often ambiguous, and subject to erosion. Misinterpreting or omitting requirements due to lack of rigor is a waste. So is the loss of knowledge over time and space (in the case of distributed development) that can result from over-reliance on informal methods. When specification techniques rely heavily on verbal communications and tacit knowledge, the Agile practice of rapid transformation of knowledge to validated code becomes critical to avoiding the waste of information loss.
Software processes and practices have traditionally been designed by software engineers. More recently with the increased influence of Lean principles, we have begun to borrow from manufacturing and operations experts. Perhaps it’s time for knowledge engineers and social and cognitive psychologists to make a contribution as well and help us software types design practices that avoid the waste of information transformation.
Read the first post in the series, Lean Principles and Software Architecture: Categories of Waste.
Read the second post in the series, Lean Principles and Software Architecture: The Waste of Waiting.