[Op Ed] Lawmakers Could Learn A Lot From Software Developers

  39 Flares Twitter 6   "”> Facebook 29   Google+ 4   LinkedIn 0   Email   Email” friend< a>”> 39 Flares ×

The United States is built on the foundation set by the Constitution and Bill of Rights – a combined fourteen pages of text if put into a modern word document. Now, 225 years later, the Code of Laws of the United States is more than 200,000 printed pages of additions by generations of lawmakers – and that only accounts for federal law, not state and local. Unfortunately, just like with software, if lines of code are added while the architectural organization degrades, an ever-increasing amount of time and resources will be required to make the system function.

Good developers will always look for the most efficient solutions, keeping utilization of system resources as a high priority. Legislators, conversely, tend to be influenced more heavily by external factors than the effect of their work on overall system efficiency. As a result, an increasing web of interconnected laws make updates arduous and resource-heavy. Between 1942 and 2009, the number of bills passed by US Congressional sessions has decreased by roughly 50% while the cumulative length of bills passed has increased by 350%, according to Slate Magazine’s analysis of data from the Senate Library.

Design for scale

Large code bases and data sets are not the problem – the issue is with mismanagement of additions and feature updates. Google, for example, still manages to deliver billions of search results in a fraction of a second, even though there are some 200 times as many websites as there were ten years ago. Users can even do a virtual walkthrough of most of the developed world with negligible load time on a broadband connection.

US legislation tends to be more like iTunes – a patchwork infrastructure that has turned a once-great advancement into a bloated conglomeration of useful features slowed by unnecessary and outdated additions built up over time. Bills 1,000 or more pages in length are not out of the ordinary, requiring vast amounts of processing power in the form of overworked interns and other congressional staff. In fact, lawmakers are often incentivized to make legislation more convoluted to help hide pork barrel spending that favors constituent groups and voting blocs.

Foresight required

Congress could learn from the foresight required to be a good developer. Complex tax laws in the US require citizens to dedicate significant amounts of time to preparations of their tax returns, as well as a level of expertise that is often insurmountable for those unable to afford professional assistance. In effect, these loopholes that reduce government income by $900 billion annually are similar to software failures. Developers have to foresee what could go wrong with software, catching errors and closing security holes to manage user experience and system integrity. Since the government lacks competition, the priority placed on user experience is inherently reduced.

Certainly not to be underestimated is the difficulty and complexity of managing the largest economic and military power in the history of the world. When a government makes laws, they can’t test the updated systems before releasing the new version – the only feedback loop comes from real world interactions, often in the form of critical errors. If legislation was written more like a software system, with higher priority placed on modular design and reduction of inter-dependencies across systems, for example, issues that arise after deployment could be more easily updated.

Communication begets efficiency

Good development teams will also place a high priority on commenting code, or leaving short notes in standard human language about what each piece of the code does and/or how it works. This makes onboarding new team members easier, as well as review of the code much faster when updating. A dependable, non-partisan overview of bills could similarly make legislation more digestible for current and incoming lawmakers, as well as the general public.

The disconnect between development best practices and legislative realities may stem from the fact that 45 of 100 US Senate seats are held by lawyers and just one by an engineer – a trend that has persisted throughout Congressional sessions. We may already be far too tangled in the web that’s been created over more than two centuries to ever find our way out, but if we’re going to keep writing new code we might as well try to learn from those who already do it well.

  39 Flares Twitter 6   "”> Facebook 29   Google+ 4   LinkedIn 0   Email   Email” friend< a>”> 39 Flares ×

About the author  ⁄ Jonathan Stacke

9 Comments

  • Reply
    rbit
    July 22, 2013

    Great article! You may want to check your math though. The US is 237 (2013 – 1776) years old ;)

    • Reply
      Jonathan Stacke Author
      July 22, 2013

      Thank you. The Declaration of Independence was signed in 1776, but the US Constitution was not ratified until 1788.

      • Reply
        maus
        July 22, 2013

        So you’re saying that the years between 1776 and 1788 were filed with scope bombs?

        • Reply
          Gerard
          July 23, 2013

          Actually, version 1.0 (The Articles of Confederation) was rolled out to production in 1777, although it wasn’t formally approved until 1981 because of some quibbling between the stake holders.

          By 1787, it was clear that there were some serious defects (such as protectionist trade barriers between the states, inability to pass navigation laws, Shay’s rebellion, requirement of unanimity for amendment, etc.), and a committee was formed to create a major patch (or service pack, maybe).

          The committee very early on decided that, considering the scope of the problems, it was better to throw out the thing entirely and start over with version 2.0. Work was completed in September 1987, formally approved June 1988, and rolled out March 4, 1789.

  • Reply
    Kyle
    July 22, 2013

    It’s interesting to view law making as patches to software. I wonder if the future politicians will be ex-coders gone fed.

    • Reply
      Jess
      July 22, 2013

      Agreed. Definitely an interesting analogy of a code base that drives a system. Unfortunately with all the politics involved there’s little chance of meaningful structural oversight ever really being implemented. There’s probably only one engineer because he’s the only one who could tolerate it.

  • Reply
    Rassah
    July 22, 2013

    “Google, for example, still manages to deliver billions of search results in a fraction of a second, even though there are some 200 times as many websites as there were ten years ago.”

    I think it’s more than 200

  • Reply
    Thon Brocket
    July 23, 2013

    Interesting. I think a systems approach provides a lot of insight.

    My own take – not directly related but in the yard, so to speak – is that there’s a fundamental design flaW in the system architecture: we elect legislators and allow them to legislate AND to tax. This leads directly to the corrupt bargain between politicians and electorate -”Elect me, and I promise to deliver more Free Stuff from the Gubmint” – and the spiralling disasters now afflicting all Western economies.

    Perhaps we could fix it by changing the system architecture; by constituting separate legislatures to legislate, and to raise taxes required to implement the taxation. Assembly “L” passes laws, but can’t tax to implement them – they have to get the funding from Assembly “T”, who cannot vote on legislation. That’s a fundamental realignment of politicians’ motives at election time.

Leave a Comment

74 Flares Twitter 47 Facebook 17 Google+ 8 LinkedIn 2 Email -- 74 Flares ×