Liquid Requirements
February 6th, 2006[ Software Development ]
Another good link courtesy of Joel. The article is about a software developer attending a course on lean construction management since the so-called ‘old trades’ have it all figured out.
“What are you doing here?” they asked.
They were construction foremen, superintendents and project managers attending a course in construction planning from the Lean Construction Institute (LCI). Indeed, what was I doing there?
I started to explain: “In software development, we are told we should manage our projects like construction projects, where a building is designed at the start, cost and schedule are predictable, and customers get what they expect.
”Silence. “You’re kidding, right?” “No, honest, that’s what we’re told.””In my construction class, the idea of “freeze the design” meets the same fate as “follow the master schedule.” Laughter. Not only is freezing the design impossible, but given the long building times in construction, attempting to do so is sure to make the real customer – the people who move into the building – unhappy with the result.”
During the look-ahead period, incomplete designs are identified and arrangements are made to fill in the blanks. In the same way that lack of materials is the biggest cause of construction delay, lack of requirements is the biggest cause of design delay. The ‘Last Planner’ system pulls in requirements just as it pulls in materials, and LCI recognizes that designs done as late as possible are often the best. In fact, they recommend that design decisions be made at the ‘Last Responsible Moment’ even as materials arrive ‘Just in Time’.
The above quote reminds me of most traditional software processes and their attempts to delude people into thinking that certain elements are frozen. There are stages such as code-freeze, featured-freeze, etc. While these processes are certainly well thought out and battle-hardened they are also troubling in the possibilities they ignore. The reality that we prove to ourselves time and time again is that code, requirements, features, etc are never frozen.
Why is this a problem? Let’s look at requirements since the issue is similar on all fronts. Developers are often asked to adhere to requirements that no longer make sense. The process of implementation continually clears an initially muddied picture. We learn a ton through the act of writing the actual code.
The concept of freezing requirements places a developer in a difficult spot. They have to either admit that the requirements they wrote were ‘wrong’ and correct them given current information and understanding, or stand their ground and argue that their original requirements were sound. The latter most likely involving deluding themselves or ignoring the reality of this new context. To be clear, what I’m talking about here are requirements that were valid when they were written and have been invalidated over time. Invalid requirements are still invalid requirements and I’m not talking about a process of correcting poorly crafted work.
Forcing developers to admit that their requirements were incorrect in this style of environment is toxic to that individual. As a programmer, not being able to write valid requirements means you may not be capable of designing software, which means you’re nothing more than a code jockey. This makes little sense. The original requirements were valid in the context they were written. That context has changed so it’s reasonable to assess whether the requirements should change.
The reality is that requirements are never frozen. Should we willy-nilly change requirements day in and day out? Obviously not or we won’t finish anything. If, however, we embrace this reality and drag it out of the developer’s closet then we can look to leveraging it to improve our work. Construction’s adoption of the idea that “design decisions be made at the ‘Last Responsible Moment’” is a good example of facing these types of realities.
The alternative is having a developer spend their valuable time and energy forcing the square peg of an out of date requirement into the round hole of an implementation phase. This wasted energy cannot be underestimated. You now have a developer using their creative energies to write code to invalid requirements.
None of this line of thought negates the need to craft the most accurate requirements possible at any point in the design, including the beginning. What’s being suggested here is that we should strive to make developers comfortable with the fact that the requirements they write can become invalid during the implementation process. That’s a reality we wish to deal with straight on, and it is in no way a failure on their part. This last part is the key. Developer’s must understand that a requirement that changes, or becomes invalid during the implementation process, is not a bad thing or a failing. Address the changes, learn from them and move on.