He tries to string together two different points: 1. The language used for describing a change in a legislative document is verbose and difficult to understand

He tries to string together two different points: 1. The language used for describing a change in a legislative document is verbose and difficult to understand. A simple "diff" of the two documents would be a substantial improvement 2. Because a developer tool (diff) might be useful in one specific aspect of legislation, other development methodologies might also be useful. Specifically, the short time to release, fast iteration strategy should be considered for legislation. The author has a good point in #1. In this century, we should be using tools that make our lives easier. Maybe not the exact diff tool, although that would be an improvement - but any move away from a prose describing the changes down to the last comma is probably a good move. Point #2 fails to hold water in many respects. First, the particular utility of a tool like diff has little implication of the end methodology that should be used. Second, even if everyone decided that lawmaking should be more like software building, the "fast iteration" methodology is not necessarily the correct choice. Just because that may be a good way of building web-based software, if you are building software for a space-station, a medical device, or a nuclear reactor, this is rarely the accepted practice. Perhaps law-making is more like developing these forms of mission-critical software systems, rather than web search software.