Lean Principles and Software Architecture: The Waste of Information Transformation

This is the third in a series of posts about Lean principles and software architecture by Nanette Brown.

Read first post, Lean Principles and Software Architecture: Categories of Waste.

Read second post, The Waste of Waiting.

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.

– Nanette Brown, SEI


One response to “Lean Principles and Software Architecture: The Waste of Information Transformation

  1. I love the idea of inviting people other than software engineers to collaborate with us to improve our systems development processes. We need systems thinkers who can see the big picture and are not afraid to ask “why?” But to be effective, these people must be comfortable enough with technology that they are not intimidated by it or those who build it. If they are intimidated, they will struggle between the extremes of deferring to our “wisdom” and being obstinate to prove they have some control. Neither extremes are the thoughtful partnership we require to serve our business.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s