I’ve read early drafts, and this is an important book for government and the general civic technology community.

From Jason:

In my book, I explore what it means to be an open source city using Raleigh, North Carolina as an example. I highlight the elements of the open source culture there and provide insight into Raleigh’s government policies and economic development in order to create a guide for other cities who want to or are currently pursuing an open source city brand.

Whether it’s $5 or $500, please take the time to contribute and help Jason get this book published.

I’ve been thinking a lot about the importance of a more structured approach to community with respect to the civic technology movement, which is why I picked up Brad Feld’s ‘Startup Communities: Building an Entrepreneurial Ecosystem in Your City.’

Feld, a successful entrepreneur and venture capitalist, brings a huge dose of humility to his writing and genuinely seems to live up to his “give more than you get” mantra. He’s the founder of TechStars and is a big influence on Boulder’s emergence as a hub of technology entrepreneurs and startups, having organized regular meetups of various kinds to bring the community together.

I loved this book and spent the final pages reading it as I walked through SFO after just getting off a cross-country flight. Feld’s advice is comprehensive, concise and inspiring.

One relevant aspect of the book is a dedicated chapter on government, “Contrasts Between Entrepreneurs and Government,” that highlights the obvious differences between the two, and essentially designates government’s role more as a “feeder,” rather than leader, in fostering startup communities (a feeder encourages others to be part of the community).

His assessment is representative of how most entrepreneurs, especially civic entrepreneurs, see government:

Entrepreneurs often focus on the micro, that is, specific things that need to get done or will have impact. In contrast, government focuses on the macro. When I talk to leaders in government, they use words like global, macroeconomic, policy, innovation, and economic development. These are not words that entrepreneurs use; entrepreneurs talk about lean, startup, product, and people.

And here’s one that nails the traditional approach to government innovation:

Government is an instigator of feeder control. Although this happens at a federal, state, and local level, it’s most obvious at a state level. A new governor is elected. After the typical six-month settling-in process, he and the recently appointed head of economic development declare that innovation is a key driver of economic growth for the state and they convene an “innovation council.” This innovation council takes another six months to get going while it recruits the appropriate high-profile members. It then creates a set of high-profile public events to spread innovation across the state.

While other chapters include commentary and advice from others, the government one simply identified the obvious problems (which is a great first step, but I finished the chapter wanting ideas and solutions as was provided in others).

Feld has a great deal to offer the nascent civic technology community (especially civic startups), and I hope he follows up at some point on specific ideas and advice for government. His long-range approach to building community is aligned with the pace the public sector moves, and he would be instrumental in helping move the needle on the changes happening in government.

While there are a few semi-formal, regular civic technology communities emerging, like what we’ve started with CivicMeet and what Code for America is doing with CfA Brigade, there’s still not a heavy focus on building core communities beyond the hacker set.

For those in the civic technology community, having more leaders focused on bringing people together with regularity is much-needed and will be key as the movement goes forward. Feld’s book can help us get there.

Whether you’re in government or generally interested in building community, I highly recommend ‘Startup Communities.’

Watch the book’s trailer:

Startup Communities Book Trailer – Brad Feld from Simplifilm on Vimeo.

There’s been a great deal of discussion around the value of civic apps contests, and now there’s a book for that.

Civic Apps Competition Handbook, written by Kate Eyler-Werve and Virginia Carlson and published by O’Reilly Media, doesn’t focus on the debate, but does provide a great guide to anyone interested in organizing one.

I highly recommend open government advocates and public servants, and anyone else interested in how open source and crowdsourcing can and are impacting government and democracy, read this. While it skews towards a focus on millennials and borrows a number of examples from the sustainability movement, which may not resonate with some, it gives great insight into real-world case studies of how technology is being leveraged to better connect government with citizens. Its narrative approach is a great companion to O’Reilly’s more deep-dive book Open Government (which I also highly recommend).

Buy it on Amazon or visit the book’s Website for more information.

Here’s an interview with author Jared Duval:

Even when the impact of poverty or violence is clearly visible, providers and government funders often use opaque processes or confidentiality rules to hide poor performance. Increasingly, social media tools allow individuals to mobilize their fellow citizens in a way that grabs the attention of government and service elites. Imagine citizens virtually marching on city hall. We saw this when Ashton Kutcher and Kevin Rose asked their two million Twitter followers to demand a response from elected officials about ending malaria.

These tools not only change how advocacy efforts occur but also fundamentally democratize news gathering and reporting, following a trend of devolving control over information from authoritative experts to citizens. Social media will continue to produce opportunities for creatively constructing a new model of citizen participation. Paula Ellis, the John S. and James L. Knight Foundation’s vice president for strategic initiatives, a member of our executive session, and a former reporter, suggests the upside of this lack of boundary between citizen and journalist. Ellis prefers the wisdom of the crowds because, “I’m never sure that the arbiter of value, whoever it is, is acting in my self-interest or the self-interest of people I care about.”

Alberto Ibargüen, a former publisher of the Knight-owned Miami Herald, who today serves as the foundation’s president and CEO, points to the Knight Community Information Challenge as a key example of the foundation’s focus. The Challenge provides $ 4M a year in grants to community foundations to “find creative uses of media and technology to help keep communities informed and their citizens engaged.” An engaged citizenry, according to Ibargüen, needs to be able to pursue what he calls “their own true interests.” The way Ibargüen and Ellis think about the role of community in nominating problems and fashioning solutions closely parallels Brian Gallagher’s rethinking of the role of United Way—using community learning to transform how we solve community problems.

However, we add another step—activating citizens who will pressure funders to redirect underperforming resources toward higher-value solutions. Such pressure comes, for example, when community-based reporters or bloggers comb government data, make sense of them, and broadcast the information to force change. Thus, mobilizing citizen demand for transformative social progress via social media requires access to performance and financial data, plus an engaged community that will post reactions to programmatic involvement.

In the absence of a consumer market for social services, community leaders need to more effectively capture and organize citizen feedback. I am reminded of a visit some time ago to a group of mothers in an orientation room at the pay-for-performance job trainer AmericaWorks in New York. I asked the thirty women present to raise their hands if they thought the city welfare department had helped them. After a little laughter, just two people responded affirmatively. Today, texting, Twitter, and other 2.0 tools would allow that room full of people needing help to digitally “blow the whistle.”

Dominic Campbell, a leading proponent of using 2.0 tools to promote third sector involvement, contributed to my understanding of the potential of social media when he filled a small conference room above a London café with social technologists. Among the varying approaches to engagement they shared with me, one simple application best illustrated how citizen interest could be amplified. AccessCity encourages London residents to travel the city and post pictures, text messages, and “tweets” about the worst public spaces in the city for persons with disabilities. This interactivity allows citizens to spot a public problem and demand a solution at the same time. The site uses mashup software that requires no new hardware; citizens use their own cell phones equipped with cameras and video recorders. According to AccessCity organizers, the site “shows that what meets the needs of official accessibility targets does not necessarily meet the needs of the people using the city on a daily basis.”

Ben Hecht is an experienced civic entrepreneur who now leads Living Cities, a coalition of some of the nation’s largest philanthropic foundations and financial institutions. Hecht argues that the Internet’s potential to “wholesale social change” will supplement philanthropy’s capacity to drive social progress. The sector must, however, provide the legitimacy and financial capital to create space for both experimentation and the growth of civic entrepreneurial efforts that leverage social media.

Former Ashoka fellow Steven Clift provides another example. His e-democracy.org has fifteen years of experience engaging the public online. Because most online efforts fail owing to lack of participation, e-democracy.org invests heavily in outreach and recruitment. And, consistent with what we found earlier, Clift first engages people on their close-to-home interests in neighborhood-based “Issues Forums”—the most successful of which daily engages 10 percent of all residents in one Minneapolis neighborhood.

Similarly, Ellis approaches her work at Knight with the assumption that community engagement relies on an emotional attachment to place; on information and the meaning you assign to that information; and on opportunities to participate. But Ellis wants more evidence and a tangible understanding of community engagement. Is a more engaged community going to do better? What makes a community more engaged? She searches for what civic and community leaders can do to engage more citizens in improving their communities and, by extension, their lives in a measurable way.

While we explore above options for emulating market pressure for constructive change, we also consider how organizations can better communicate information to alert and activate citizens. However, the very information fragmentation that many complain about carries with it great promise. Because the public agenda is so much more difficult to shape now, change in any system must enjoy broad networks of support. And it must have the support of those whose lives will be most affected. According to Ellis:

“Too often ‘experts’ believe they have the rational answer founded on evidence. They ask the public to trust them. They miss the ‘wisdom of the crowd’ and solutions flounder because they lack a true empathetic understanding of each stakeholder’s perspective. To thrive in these times of rapid change, we need the time and talents of all citizens. We need to create more pathways for their engagement. We live in a time of de-institutionalization. The time is ripe for a citizen–centered agenda.”

From Open Government: Collaboration, Transparency, and Participation in Practice edited by Daniel Lathrop and Laurel Ruma, ISBN 978-0-596-80435-0. Copyright © 2010 O’Reilly Media, Inc. All rights reserved. Used with permission.

Looking back over the history of the United States, it is not just remarkable to see how 13 former colonies of the British Empire could come together to form what became the longest continuously functioning government in recorded history, but it is also incredible that such a durable government was set up as a republic. Until the United States, history records few examples of even moderately successful republics, and even those moderate successes were aided by factors external to the specific system of government employed. How, then, did the framers of the U.S. Constitution succeed in creating a republican-style government where so many had failed?

Simply put, by good design.

When looking back through the Constitution and the Federalist Papers, we can observe that the founders took many novel approaches in crafting the structure of the United States. Indeed, Alexander Hamilton went so far as to describe these approaches as based on the new “science of politics.”^* The Constitution was the embodiment of this new science and served as a lightweight framework, providing enough prescription to ensure basic stability in the republic, but little more, so as to enable the government to adapt over time and thus ensure the longevity of that stability.

In many ways, the framers of the Constitution were like the software designers of today. Modern software design deals with the complexities of creating systems composed of innumerable components that must be stable, reliable, efficient, and adaptable over time. A language has emerged over the past several years to capture and describe both practices to follow and practices to avoid when designing software. These are known as patterns and antipatterns. This chapter will explore known software design patterns and antipatterns in context of the U.S. Constitution and will hopefully encourage further application of software design principles as a metaphor for describing and modeling the complex dynamics of government in the future.

The Articles of Confederation and the Stovepipe Antipattern

Software design patterns and antipatterns can be classified by the general type of problem they describe or solve. Patterns in a category known as enterprise architecture make a good place to begin exploring the connection between the worlds of government and software, as they tend to be concerned more with the management of overall systems than with lines of code. What follows is an exploration into how the Articles of Confederation, the first constitution of the United States, represents a classic example of an antipattern known as the enterprise stovepipe. From that comparison, we will explore strategies for overcoming an enterprise stovepipe and will then see how the Constitution is in fact a historical illustration of those strategies.

NOTE

An antipattern is much like a regular pattern in that it describes observable phenomena that tend to occur with some frequency. However, antipatterns go further to define specific types of patterns which generally yield negative outcomes. Put another way, an antipattern describes a pattern that should be stopped.

The First Constitution

Drafted during the early part of the American Revolution, the Articles of Confederation became the first constitution for the new confederacy of 13 states. Though the original draft of the Articles provided for a strong federal government, the sentiments of the time resulting from the war for independence from Great Britain ultimately yielded a governmental structure that consisted of a loose confederation of independent states, bound together by a “firm league of friendship.”^† While the Articles did provide provision for a federal government, the language used to define its goals was undermined by the language used to describe the constraints on its ability to achieve those goals. For example, in describing the role and ability of the federal government to assess and levy taxes on the states to provide for the cost of war, including the recently fought Revolutionary War, Article 7 establishes the following:

All charges of war, and all other expenses that shall be incurred for the common defense or general welfare, and allowed by the United States in Congress assembled, shall be defrayed out of a common treasury, which shall be supplied by the several states, in proportion to the value of all land within each state, granted to or surveyed for any Person, as such land and the buildings and improvements thereon shall be estimated according to such mode as the united states in congress assembled, shall from time to time direct and appoint. The taxes for paying that proportion shall be laid and levied by the authority and direction of the legislatures of the several states within the time agreed upon by the united states in congress assembled.^‡

The problem in the preceding example is simply that while the federal government is charged with a responsibility, its ability to fulfill that responsibility is up to the sole discretion of the various state legislatures. This example is representative of a more general pattern that can be seen throughout the 12 Articles. Moreover, history shows that the federal government established under the Articles was simply ignored by the states, resulting in an embarrassingly long delay in accepting the Treaty of Paris and the inability of the federal Congress to pay back debts accumulated during the Revolutionary War, including payment to soldiers of the Continental Army.

The Stovepipe Antipattern

From a software architect’s perspective, the Articles of Confederation created a governmental system that is best represented by an antipattern known as a stovepipe enterprise.^§ This term derives from the metaphor of the exhaust pipes that sit atop a potbellied, wood-burning stove. Because burning wood releases byproducts that corrode metal, these exhaust pipes would require constant patching, and this patching would generally use whatever material was on hand, ultimately resulting in a chaotic patchwork of fixes.

In software architecture, a stovepipe enterprise is formed as the result of multiple application development efforts that are conducted in isolation from one another. This development approach yields a patchwork of systems built using different development methods and different technologies, and many times having overlapping or competing functionality (see Figure 5-1).

As a result, any form of integration, whether it is integrating individual systems within an enterprise or integrating with systems external to an enterprise, is difficult or altogether impossible.

Internal integration is equivalent to navigating a minefield of systems with similar terms representing different concepts, or multiple terms for the same concept. Additionally, many such systems in a stovepipe enterprise provide many of the same business processes, but use completely different rules in accomplishing those processes. Therefore, integrating one system within a stovepipe enterprise to any other system requires, at the very minimum, finding the correct system with which to integrate, resolving differences in technology, resolving differences in terminology, and ensuring that both systems have a sufficient level of understanding about the internal processes of each other.

If you multiply these consequences by the total number of systems that must generally integrate in even the most trivial-sized enterprise, you can see that the net result of a stovepipe enterprise is at best an extremely high cost of maintenance. More realistically, however, the likely result is that automated integration will not be attempted at an enterprise level, and more costly manual integration tactics will prevail. Additionally, the lack of a single interface point for external integration may inadvertently lend itself to an environment where individual systems begin integrating outside the enterprise, effectively broadening the enterprise stovepipe to a multienterprise stovepipe. In this context, the stovepipe antipattern can bring with it the unintended consequence of tying the entire enterprise to expectations set by one of its parts.

Order from Chaos: The Standards Reference Model

The core problem behind a stovepipe enterprise is that there is effectively no underlying framework to provide basic guidance around integrating systems in an enterprise. Put another way, there is no architecture. Each system attached to the stovepipe is designed independently of, and evolves separately from, the other systems in the enterprise. The solution for reversing this antipattern is found in both laying down a common set of standards around how applications are to be constructed and integrated, and creating a set of core infrastructure components to provide determinism across systems in terms of management and integration, as well as to provide consistency for integrating with external enterprises. In software architecture terms, this solution is known as a standards reference model (see Table 5-1).

As should be evident, the standards reference model is composed of multiple levels of standards based on relevant organizational scope, and it proceeds from abstract to concrete. This is an important point to note, because in any sizable organization, failure to establish proper scope boundaries when attempting to solve a stovepipe antipattern can result in another antipattern known as the blob, whereby a single entity evolves to assume a large set of responsibilities outside of those to which it was originally purposed.

NOTE

A blob or god class is the result of a poorly maintained software system where a single unit of program code grows to assume responsibility—in part or in whole— for nearly every aspect of system behavior. The result is that this unit of code becomes large and brittle (a change to one section can have dire unintended consequences to other sections), and the system does not evolve.

Some of the various scopes commonly associated with a standards reference model include the enterprise scope, the system family scope, and the system scope. To prevent the creation of an inflexible architecture, each scope must balance flexibility with prescription. For example, it is generally unreasonable to assert a code or system-scope directive at the enterprise scope, since such an assertion would be dependent on far too many additional predicates relating to hardware, operating systems, and various other tools. Rather, many times at this scope, the appropriate standard is simply to identify the possible standards that are available for use by various system families, and define a process for augmenting that list. As one proceeds from the enterprise scope to the specific system scope, the various standards can become incrementally more concrete, since at those lower scopes, there is also much more known about the objects of those standards. This scoped approach enables the standards reference model, and the order that follows suit, to scale to very large enterprises.

The Constitution As a Standards Reference Model

By the time of the Philadelphia Convention in 1787, the delegates along with the majority of the leaders of the time were well aware of the consequences from the lack of strong union under the Articles of Confederation. However, there was a great deal of debate surrounding the available alternate forms of governance. The fundamental problem was one of how to create a stronger, more permanent union between the states and provide for the welfare of all citizens while not putting the fundamental principles of liberty and self-governance at risk. Many at the time argued that a move toward a stronger central government, which had initially been written into the Articles of Confederation and later removed, was seen as an inevitable path toward the form of despotism over which the war for independence from Great Britain was fought. On the other hand, structuring the government as a single republic was also seen by many, including Federalists such as Alexander Hamilton, as simply an alternate path toward despotism. In arguing for the government laid out in the Constitution, Hamilton acknowledged that throughout history, many famous republics “were continually agitated, and at the rapid succession of revolutions, by which they were kept in a state of perpetual vibration, between the extremes of tyranny and anarchy.”^‖ Hamilton is referring here to the historical example referenced by many opponents of the proposed constitution of the ancient Greek and Roman republics. Such governments were ultimately unable to prosecute an effective government or control the rise and growth of internal factions. Additionally, a more general criticism of republican government in that day came from men such as Montesquieu, who argued that a traditional republican form of government could remain effective within only a small populace.

The framers argued ardently that such prior models could overcome their historical limitations thanks to significant improvements such as the “regular distribution of power into distinct departments—the introduction of legislative balances and checks—the institution of courts composed of judges, holding their offices during good behavior—the representation of the people in the legislature by deputies of their own election.”^# These were the elements that greatly shaped the U.S. Constitution and created a framework for the establishment of a confederated republic with a federal government strong enough to carry out the duties for which it was established, but engineered in such a way as to prevent a majority or minority faction from subverting the general welfare.

The confederated republican government codified in the Constitution and argued for in the Federalist Papers is similar in nature to a standards reference model. Similarly, it proceeds from the abstract definition of goals to the establishment of the various components of the federal government as well as their relationship to one another and to the state legislatures. In reference model terms, it establishes itself as the core set of standards against which all concrete standards are evaluated. It then proceeds to define more concrete participants of the systems— specifically, the three branches of the federal government. Additionally, it defines in concrete terms the relationships that the branches are to have with one another and with the states (see Table 5-2).

Like a standards reference model, the Constitution provided a unifying vision and a common set of rules by which other acts of legislation could be evaluated. Additionally, it defined the fundamental interoperability points between the various principalities that had a role to play in government, but then deferred to those principalities to the determination, promulgation, and interpretation of those responsibilities. As a framework, these lightweight qualities are what enabled the United States to reach the geographic scale that it did and even survive near collapse in the face of secession nearly 100 years later.

Continued Maintenance: The Blob and Confederacy

While the stovepipe antipattern represents just one high-level example, you can hopefully see at this point that many of the patterns that have emerged in software design have applicability in the structuring and maintenance of government. Looking into the future, another antipattern worth investigating is known as the blob or the god class.

The Blob

One of the most widely used paradigms in designing software is known as object orientation. At a very high level, this approach describes the organization of source code into discrete units called classes whose purpose is to encapsulate related data and behaviors for a given abstraction.

For example, were one to model the U.S. governmental structure using an object-oriented approach, the resultant classes might look something like Figure 5-2.

One of the benefits of using the paradigm—and much of the reason for its popularity in designing modern systems—is that it naturally breaks up complexity into manageable units of code which can be verified and maintained independently without causing a ripple effect throughout the entire system. As we can observe, this was certainly an expected benefit that would result from the Constitution’s design of a confederated republican government, as Hamilton articulates by quoting Montesquieu:

Should a popular insurrection happen, in one of the confederate States, the others are able to quell it. Should abuses creep into one part, they are reformed by those that remain sound. The State may be destroyed on one side, and not on the other; the confederacy may be dissolved, and the confederates preserve their sovereignty.^*

As with any endeavor, a great set of tools or paradigms does not by itself yield a well-designed system. In the world of object-oriented design, constant effort must be exerted to ensure that the classes defined most accurately represent the abstractions that they are meant to describe and that the system’s code is most appropriately divided among the classes in accordance with previously defined goals such as independent testing and maintainability. Should the software designer become lax in this effort, an antipattern known as the blob or the god class can emerge.

The blob antipattern is generally the result of a system designed using object-oriented tools, but without the discipline of object-oriented thinking. It reveals itself in a design “where one class monopolizes the processing….”^† Looking at this antipattern in terms of responsibilities, the blob class assumes a significant majority of the responsibilities in the system, and generally relegates the other classes to dependent supporters.

The problems inherent in this type of system are many, and all stem from the fact that nearly every capability that the system supports is tightly associated at the code level—a term in software design known as coupling—with every other capability in the system. Therefore, any change to one capability requires modifying the blob class, which would then impact every other capability for which the blob has assumed responsibility. This creates a situation that is inefficient at best due to the amount of energy that must be exerted to manage changes or new capabilities. At worst, it dramatically increases the likelihood that changes to the blob will unintentionally break a seemingly unrelated part of the system.

The solution for keeping an object-oriented system from devolving into a blob antipattern is constant expenditure of effort to ensure that all system logic meets two basic criteria: high cohesion and low coupling. High cohesion describes ensuring that all code that is logically related is physically grouped together in the same class. This enables a discrete area of functionality in a system to be more comprehensible, and more importantly, testable. Low coupling describes the removal of as many dependencies as possible between the aforementioned cohesive units. This enables each unit to evolve independently while significantly reducing the risk that the evolution of one unit will unintentionally cause the failure of another. Additionally, it has the added benefit of enabling the designer to more confidently evaluate the efficiency of each unit without the distraction of the efficiency or inefficiency of related units.

The blob and government

The blob antipattern many times develops when a system is relatively small in size. The entire system can be known in whole, and so the necessity of solid design is less obvious than in large systems, where the sheer number of capabilities provided makes such principles a necessity. The framers of the Constitution also understood these principles in context of the size and scope of government. For example, in articulating how an extensive republic is more beneficial to guarding the public interest, James Madison argues that by extending the sphere:^‡

…you take in a greater variety of parties and interests; you make it less probable that a majority of the whole will have a common motive to invade the rights of other citizens; or if such a common motive exists, it will be more difficult for all who feel it to discover their own strength, and to act in unison with each other. Besides other impediments, it may be remarked, that where there is a consciousness of unjust or dishonorable purposes, communication is always checked by distrust, in proportion to the number whose concurrence is necessary.

Madison argues here that the size of the union was one of the very things that would shield it from the rise of despotism at the hands of any group of citizens, whether they are in the majority or the minority. On this point, I believe that additional reflection is warranted. Madison seems to define size predominantly in terms of geography, and as such, the difficulty that he describes in specific groups being able to discover their own strength seems to be somewhat predicated on the geographic disbursement and isolation of the various members.

In the present age, we live in a society where access to any person or any piece of information is never more than a few button or mouse clicks away. Size, according to its utility as described by Madison, cannot be measured in square miles or even number of people, but in the speed with which individuals can connect with one another. And by this definition, the sphere has in effect grown smaller. This increases the risk of the blob antipattern developing in government by way of the blurring and sometimes outright dissolution of the scope boundaries established explicitly in the Constitution and implicitly as envisioned in the Federalist Papers. A governmental blob can take many forms; however, media and the press can serve as a good indicator for where the concerns of citizens are most closely placed. And this indicator is not encouraging as we are witnessing the continued decline of local news outlets due to either consolidation or outright closure. This places the responsibility of all news—and by association, all perceived concerns of government—to national news organizations, who as a product of seeing a high return on investment for each news story they pursue, will naturally focus their attentions at the federal scope. A shift in the focus of the citizenry from an inherently local to federal scope, coupled with a smaller society as a result of advances in technology, creates an environment where it becomes easier for political factions to mobilize and where their effects can be far more reaching and destructive.

Conclusion

While this chapter is not intended to provide comprehensive treatment of republican government and Constitutional history, nor a complete catalog of software design patterns, it has hopefully demonstrated that there is a strong correlation between the two, and has effectively put forth software design as a new metaphor for exploring the dynamics of government. Further, as we are currently in a period of widespread reform efforts, the lessons and mitigation paths described in antipatterns, such as the blob, can help to ensure that reform efforts continue to yield a sustainable and maintainable republic.

The next logical step, and the subject of future research, will include taking aspects of the U.S. governmental system and actually modeling them in software. Such an endeavor will more concretely demonstrate the patterns outlined in this chapter, along with many others. More importantly, however, it will create an executable model that can be modified and tested based on the application of new patterns. As the evolution of technology continues to change some of the fundamental dynamics of our society, it is likely that the very same technology will be necessary to enable our government to evolve as well.

===

* Federalist 9.

† Articles of Confederation, Article III.

‡ Articles of Confederation, Article VIII.

† AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (Wiley, 1998).

‖ Federalist 9.

# Ibid.

* Ibid.

§ AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (Wiley, 1998).

‡ Federalist 10.

The federal government should fire me. Like the thousands of other contractors who develop software for government agencies, I am slow, overpaid, and out of touch with the needs of my customers. And I’m keeping the government from innovating.

In recent years, the government has become almost completely dependent upon contractors for information technology (IT). So deep is this dependency that the government has found itself in a position that may shock those in the tech industry: it has no programmers of its own; code is almost entirely outsourced. Government leaders clearly consider IT an ancillary function that can be offloaded for someone else to worry about.

But they should worry. Because while they were pushing the responsibility for IT into the margins, the role of IT became increasingly central to every agency’s business. Computing might have been ancillary 20 years ago, when the only computers were the mainframes in the basement. Average employees never had to worry about them. But today, a computer is on the desk of every civil servant. Those servants rely on their computers to do their jobs effectively. Every day, they encounter new problems that could be quickly solved with a bit of web savvy, were there only a programmer there to help.

And they desperately do need help. Imagine not having Google to quickly find information; no Facebook or LinkedIn to find new colleagues; no instant messaging to communicate with those colleagues once you found them. Imagine having to ask for permission every time you wanted to publish content online, instead of being able to do it quickly and easily with a wiki or weblog. This is the state of computing in the federal government.

SIDEBAR

On top of keeping the government from innovating, the dependence on contractors hurts the country in much more tangible ways. In February 2003, a few weeks into my job as an intelligence analyst with the Department of Defense (DoD), the Federal Republic of Yugoslavia officially changed its name to Serbia and Montenegro. My job was to maintain an enormous database of facilities in Eastern Europe, including labeling each one with a country name. But the tool we used didn’t have an option for “Serbia and Montenegro,” so on the day of the name change, I emailed the contract officer in charge of the database with a simple request: “This country changed its name. Could you please update the tool to reflect this?”

Doing so would have taken a computer programmer less than five minutes. But instead, he used that time to respond to my email:

“We’ll consider it for the next version.”

In other words, his current contract—written months prior—didn’t account for changes in the geopolitical landscape, so there was no paperwork explicitly authorizing him to make this change. To do it, he would have to wait until the contract was renewed (months or years from now) and the government allotted funds for this five-minute job. It wasn’t his fault; he was no doubt aware of how easy it was to make this change. But doing it without permission from either his boss or the government would spell trouble. Yugoslavia didn’t exist anymore. Except inside our office, where we had to wait for a contract to make it so.

The government can no longer afford to outsource IT. It is core to the government’s business. If the government intends to do IT right, it should wean itself from outsiders like me and start doing the job itself.

What’s so wrong with contractors? Nothing, really; the problem is the processes they have given rise to. The pervading philosophy is that government is slow, inefficient, and incapable of quickly adapting to change, while private companies do things better, faster, and cheaper. In many cases, this is true; the government is by no means a well-oiled machine. But software is one thing that contracts do not speed up. Software developed under contract is much slower and much more expensive than any other form of software development still in practice. Here is how the typical IT contract evolves:

1. A low-level government employee complains to her boss about a problem. This could be anything from a bug in an existing piece of software to a gaping hole in her agency’s IT security. The boss has no programmers on hand to solve the problem, so he dismisses it.

2. More and more people complain about the problem until it gets attention from higher levels. But even thinking about a solution is expensive—months of paperwork must come before a contract is awarded and someone finally starts writing code—so the problem remains unsolved.

3. The problem leads to a calamity—a website is hacked, classified information is stolen, or electronic voting booths break down on Election Day—and leaders are finally motivated to solve the problem.

4. Procurement officers write a list of requirements for the ideal solution. Because they have little direct experience with the problem, they survey the workforce to get a sense of what’s needed.

5. The workforce’s version of the problem is condensed into a document called a Request for Proposals, or RFP. The RFP is then distributed to potential bidders, who will respond with a proposed solution and a bid based entirely on the contents of the RFP. Contractors cannot go directly to the users, the people who know the problem best. The RFP is therefore an indirect, highly edited communiqué from the user to the contractor, a substitute for the invaluable direct interaction between user and coder that guides any successful software product. But it’s too late: contractors are from here on out trying to solve what they believe the problem to be, not the problem that really is.

6. The contract is awarded. Months or years after the problem was first noticed, the first line of code is written. Over the coming months, the winning bidder will develop the solution off-site, hidden from the eventual users who could be providing valuable feedback.

7. The solution is delivered. Because the target users had such a small part in the development process, the solution falls short. It is hard to use and comes with an 80-page manual.

It should now be clear why the government is so far behind the times: it isn’t allowed to solve its own problems, relying instead on people who do not understand them. Two glaring faults doom the contracting process to failure. First, the development process is vastly different from that of today’s most popular software. Modern web applications are persistently watching their users and adjusting their code to make it faster and more user-friendly. Adventurous users can begin using these applications before they’re even finished, giving the developers invaluable insight into their users’ preferences. Without this constant feedback, the developers risk spending years on a product in private, only to reveal it to the public and find that nobody wants to use it. Such products are so common in government that they have earned their own moniker, named for their eternal home: shelfware.

Second, the paperwork required to simply start coding takes time and money. So, to even consider solutions, the problem has to be severe enough to justify months of bureaucracy. Why go through all that trouble just for a problem that would take a week to solve? The logic makes the taxpayer ill: the bureaucracy actually wants high price tags. The result is an organization full of easy problems that get no attention until they are big, expensive, and ready to boil over.

Tipping Point: The Extinction of Pencils

One such problem that may soon boil over is the terrorist watch list. For years, the list—created to monitor suspected terrorists and keep them from flying on commercial airliners—had inconvenienced innocent travelers. The problems were evident, but they weren’t bad enough to justify asking for help.

Then a toddler was kept from boarding a flight. Then a senator. At some point, this problem crossed the threshold, and the government issued an RFP for an improved database to manage the list. The $500 million contract was awarded to Boeing and a smaller company. After months of development, a congressional investigation discovered that the soon-to-be-deployed database could not perform basic searches for names, and was missing huge stores of valuable data. The National Counterterrorism Center had spent half a billion dollars on a tool that, while certainly complex, could not do things that you and I do every day from our home computers.

Why so much money for something that seems so simple? This frame of mind—that technology projects should be big, expensive, and time-consuming—has honest beginnings. Twenty years ago, computing was a niche. The government used computers to encrypt the president’s phone calls, simulate nuclear blasts, and predict the weather. The government paid private companies lots of money to build very complex systems. That’s OK, because tasks such as these required lots of computing power, so the biggest, baddest, most expensive system was usually the best. It didn’t matter that these systems were hard to use, because the only people using them were computer scientists. The builder of the system understood the user—the builder and user may have even worked side by side—and if the user ever needed the system to do something it couldn’t, that user probably had the skills to tweak the system. Computers were left to the computer people. Everyone else still used pencils.

But computing is now everywhere. Computers long ago fit on our desktops. Now they fit in our palms. But the government still acts like computers fill basements, and if you could sit down at a government desktop, this outdated mindset would be immediately apparent: on the screen would be websites reminiscent of the mid-1990s, without any of the web-based productivity and collaboration tools that define today’s Web. Expensive supercomputers still matter. But so do cheap, light web applications. Small, unassuming tools can change the way an organization does business. Such tools are commonplace online, but they do not get a second look from a government that expects and needs its technology to be expensive. Meanwhile, independent developers are at their keyboards, proving themselves willing to help a government that, as we’ll see, is slowly opening its arms to them.

Competition Is Critical to Any Ecosystem

One of the reasons the Web has better tools than the government is competition.

Take airfare as an example. There are countless websites that help you buy plane tickets, each of them constantly improving their tools and layouts to make you happier. And if you aren’t happy with those sites, you’re free to start your own business and compete with them. But when the government contracts new software, it gets only one product out of it. Instead of many choices, users have only two: use this tool, or use nothing.

Web developers know that the first attempt at an innovation almost never works, and that it takes many attempts before someone gets it right. For every Facebook, there are countless Friendsters. Given one chance, you’ll likely end up with one of the latter. If the government wants better software, it has to start creating and acquiring more software.

In the past year, two promising government projects have chipped away at this problem. Washington, D.C.’s Apps for Democracy competition let independent developers build web applications for a shot at prize money. The D.C. government’s $50,000 investment bought it 40 tools in 30 days. The District got to keep every contribution but only paid for the really good ones.

Meanwhile, the U.S. Intelligence Community is becoming an unexpected leader in engaging everyday developers. To provide more analytic tools to their workforce, they have released BRIDGE, an open development platform akin to Facebook’s: now, any software developer can build a tool and provide it to intelligence analysts. If the analysts like it, the government buys it. If it’s junk, your tax dollars are saved.

This approach worked for Facebook: it gained 30,000 new tools in two years, and got other people to do all the work. Most of these new tools fall into the junk category, but many others are invaluable. The community finds the good ones and makes them more visible. It is the same principle that governs our economy: we buy the dish soap that works, and the bad ones go away. We should expect the same practice from our government, whose very job is the promotion of market economies and democracy. Apps for Democracy and BRIDGE are a welcome departure from contract-based software.

But while these projects are giving government employees more options, they haven’t filled in all the gaps. Who will maintain software that was built not by a global firm, but by an independent developer who is juggling multiple projects?

And what about user feedback? Neither of these projects addresses the fact that government software is built by people unfamiliar with government users. Apps for Democracy produced useful tools for D.C. residents, but little for D.C. employees. And applications on the Intelligence Community platform are hobbled by the world’s biggest firewall: intelligence analysts use these tools on a top-secret network that doesn’t allow them to communicate with the outside world. As long as the government keeps developers outside its walls, those developers have no hope of solving the government’s technology problems. The civil service needs an infusion of technical talent. The civil service needs intel techs.

Creating a Developer Corps

Decades ago, the intel tech (also known as “mission support” at some agencies) was a specialist in the Intelligence Community who helped analysts with now-defunct technologies: setting up the light table to look at satellite imagery, making mimeographs, and so on. Unlike today’s tech support staff who sit in the basement or in Bombay, these experts sat among the analysts and were solely dedicated to the analysts’ mission. And because they were government employees, they were at the analysts’ disposal whenever help was needed.

But then personal computers arrived. Software made the intel techs’ tools obsolete. The light tables vanished. The intel techs soon followed. It is the opposite of what should have happened: IT’s role in intelligence analysis—and every other government function—has grown tremendously, while the government’s in-house technical talent has dwindled. Government employees’ need for technical help has never been greater, but there is nobody there to help them.

If they still existed, today’s intel techs would be developers. They would be deploying web applications for new needs the moment they arose. They would mash up data and make it easier for both civil servants and private citizens to consume. They would do the things that contractors do today, only immediately—no paperwork necessary—and with users at their side. The intel tech must be resurrected for the Internet age. The government must hire web developers and embed them in the federal bureaucracy.

The government needs to hire the people who have been fueling the web application boom for the past 10 years. They are young programmers who created revolutionary tools from their dorm rooms, and they are small firms with virtual offices who stumbled upon a new way of doing business. The trouble is, most of these people are not compatible with government culture. They like working from p.m. to a.m. They don’t like ties. They seek venture capital, not pay grade bumps. Are they supposed to move from one coast to another and indefinitely trade in their lifestyles for something completely different, not knowing when they would return to their old lives? That is asking too much.

But what if these in-house developers weren’t standard government hires on entry-level salaries? What if their time in the government wasn’t a career, but a mission akin to a term in the Peace Corps or Teach For America? A program marketed and structured as a temporary “time abroad” would let developers help their country without giving up their careers and identities.

Now is the perfect time for such a program. Silicon Valley’s interest in D.C. has never been as great as it is now. Technology icons are encouraging developers to quit creating banal tools and instead put their energy into things that matter. And it’s working: several prominent Internet entrepreneurs have become full-time civil servants. Many more have contributed software tools to programs such as Apps for Democracy and BRIDGE. Apps for America‡—a federal take on Apps for Democracy sponsored by the nonprofit Sunlight Foundation— received 34 submissions during its first iteration, and 46 more on the second. Geeks want to help government. The government just has to give them the right invitation.

Like the Peace Corps and Teach For America, terms in the Developer Corps would have a time limit. Whether this limit is six months or six years, I do not know. But a limit of some kind is important. First, it will be easier for developers to make the leap if they know they will eventually return to their current careers.

Second, being detached from an agency’s pay scale and career plan will give the participants the freedom to experiment and—more importantly—to fail. Failure is a key part of innovation. Technology firms know this, and their employees are used to working in atmospheres that encourage failure. If they don’t try new things, they’ll be killed by their competition.

Not so in government. Unlike private companies, a government—at least ours—is relatively safe from competition, and thus doesn’t feel the need to be constantly reinventing itself. Things are fine how they are. The populace views failed government projects as little more than a waste of taxpayer dollars. No career-conscious government employee wants to take on such a risk. So, to succeed, the Developer Corps’ participants must have the same freedom to fail that they did in their former jobs. The knowledge that their terms will end on a set date will quell the fear of failure that plagues the average government employee.

The greatest threat to this program is lack of permission. If red tape keeps developers from being productive, they will end up wasting their time fixing printer jams instead of writing code.

Developers work quickly. They can implement ideas within hours of conceiving them, continuously deploying, checking, modifying, and redeploying their code dozens, hundreds, thousands of times along the way. Doing this never requires anyone’s approval. But within each government agency are multiple offices that must vet code before it is deployed: system administrators, information security officers, lawyers, and so forth.

Developers will never get anything done with such thick bureaucratic walls between them and their work. Wasting their talent is the fastest way to destroy the corp’s reputation. They must be given authority to code what they please. Not all agencies will grant this authority. Such agencies must not be allowed to participate in the Developer Corps. (Participants in restrictive environments would never get anything done anyway, so there is no harm in barring uncooperative agencies.)

Finally, this program should take a page from a new organization called Code for America (http://codeforamerica.org). CFA recruits coders to work with government offices for set terms, but at the municipal level instead of federal. About to enter its inaugural iteration, CFA’s participants will work with their respective governments remotely from a shared space in California. This communal coding environment will let participants enjoy networking events, guest speakers, and the creative energy generated by each other’s ideas.

The federal program I’ve proposed in this chapter should incorporate a similar communal environment. While coders will spend their days at their respective government agencies, group housing will let them discuss their work over dinner and drinks, allowing the creative process to continue after hours. And select days could be dedicated to meetings with government leaders and tech luminaries, visits to other agencies, and networking. Such events will help ensure a D.C. term is a boost to a coder’s career instead of diversion from it.

Conclusion

Our government agencies need the ability to develop their own software. Keeping them from doing so prevents them from providing vital services that we all pay for. No story makes the case for this capability better than that of Jim Gray.

Gray was a technology pioneer who, during a sailing trip in early 2007, disappeared off the coast of San Francisco. The Coast Guard searched for him for three days and could not find him. They called off their search.

But a group of determined people kept looking. They had imagery satellites take fresh pictures of a swatch of sea outside the San Francisco Bay. If Gray was out there, he and his boat were now on film. But they were left with hundreds of photos, each big enough to cover a wall. A handful of people could never review the images in time to save Gray. So, a team of software developers converted those large photos into lots of smaller ones, which were then posted to a website where the public could review them. Clicking on a possible sighting sent a report to a flight crew, which then searched the area in question. Noticing that the images were blurry, another team of programmers contributed code that automatically sharpened the images. The entire system was created from scratch in just a few days. And it was done without any help from the government.

This effort was coordinated entirely by private citizens with the help of publicly available technology. Though he was never found, Gray inspired the largest collaborative search party in history. Twelve thousand private citizens reviewed more than half a million images. It is an amazing story of teamwork and ingenuity. Inspiring. Soul-stirring.

But also frustrating: why didn’t our government do this the moment Gray was reported missing?

It is tempting to use this story as a case for more self-governance: if the public can do it and the government can’t, why not go with it? Instead of equipping the government to do what private citizens already can, let’s just do their jobs for them from our home computers.

The Web has made it simple to form ad hoc groups and coordinate their actions, and we will continue to see cases where such groups fill the government’s shoes. But such cases will not be the norm. Our populace cannot govern itself just yet. There are too many critical functions that we cannot yet take over. We do not have battleships. We cannot run elections. Some private citizens guard our borders, but that doesn’t mean they should.

We will need a formal government for the foreseeable future. Our government should be at least as capable as a quickly organized group of virtual volunteers. It will certainly have the budget for it.

If Gov 2.0 is the public servant Sisyphean task du jour, then If We Can Put a Man on the Moon … Getting Big Things Done in Government is the stocking stuffer of the season.

Authors William D. Eggers and John O’Leary wrote ‘If We Can Put a Man on the Moon …’ to answer one question:

What happens if you look at large government undertakings from a process perspective?

With ‘If We Can Put a Man on the Moon …,’ Eggers and O’Leary offer a neatly packaged game plan for confronting big idea execution ‘traps,’ complete with examples of large-scale change successes. Heroes range from Transportation Safety Administration’s Idea Factory blog and ‘Evolution of Security’ Web site to bureaucrats like NASA’s James Webb and the lesser-known Dwight Ink.

Not since Reinventing Government has there been a book (I’ve read) that addresses reform with real-world solutions and inspiration that large-scale government change, local or federal, can actually occur.

If We Can Put a Man on the Moon … restores that hope.

More ‘If We Can Put a Man on the Moon … ‘

Gov 2.0 Radio interview with authors:

Video interview:

Favorite excerpts

General:

There are too many big challenges out there. Finding and nurturing good policy ideas should no longer be considered the job of the public sector alone.

If our government is to reclaim a reputation for competency … We will need a political culture that values and honors the capable management of public undertakings; a political culture that values the public servants who tell the unpleasant truths to the political masters. We don’t have enough of either today.

Citizen feedback and collaboration:

Through the ‘Evolution of Security’ Web site, airline passengers have an opportunity to dialogue with bloggers from TSA — not PR flacks but real people with full-time jobs on the front lines of airport security; people like TSA blogger Jay, a former high school football coach who is now a federal security directory. “The blog is intended to bridge the gap with people who have legitimate issues with the TSA,” Jay blogged. “There’s no doubt some people have had a bad experience with the TSA. Our job is to fix what’s broken, but hey let’s face it — security is a tough business. There’s an old saying, ‘Security is a great thing … until it applies to me.’” The Evolution of Security site offers TSA employees a chance to educate the public, to explain why taking your shoes off may not be as silly as it seems.

Internal feedback and collaboration:

TSA has forty-three thousand workers on the front line. They have ideas about how both they and TSA headquarters could do their work better. TSA created an internal Web site called “Idea Factory” that uses a wiki platform to allow TSA management to tap into that pool of wisdom. The Idea Factory has become kind of a supersized brainstorming session where TSA’s leadership can put out questions to the organization: “How can we improve morale?” “How can we improve the check-in process?” “What should our new uniforms look like?” The Idea Factory allows leadership to get unfiltered, unsolicited ideas from the front lines. No doubt some of these ideas make TSA management a tad uncomfortable. It’s worth it. Six months after launching the Idea Factory, more than twenty TSA policies had been changed in response to employee suggestions.

Find critics:

Another lesson from California is that lawmakers involved in transformational change need to actively seek out critics. If none can be found, dissenting voices need to be created for the very purpose of exposing possible design flaws.

Understand culture:

A mismatch between culture and mission can undermine transformational efforts. Similar mismatches can occur, for example, when social workers and others in the helping professions are asked to be ‘enforcers,’ in essence turning in their clients. Think twice before asking an organization to work outside its cultural zone.

Success:

The journey to success is a single process with a single result. It involves a series of phases, often performed by different people, but it is a single process. Initiatives in the public sector are particularly vulnerable to being undermined by a failure to see the whole process. Great results can be delivered only if the pieces work together: designers and implementers, politicians and bureaucrats, government agencies and private contractors.

On Democracy:

In a democracy, each of us contributes to creating our future. The media’s focus on those at the top of the power pyramid often makes it seem as though leadership is the province of the chosen few. No doubt those in positions of power can make a big impact. But so can you.

Democracy is not a spectator sport. All of the participants in democratic government–elected leaders, those who work in the public sector, and citizens–play a role in creating the future. The goal of this book is to advance the art and practice of public sector management, particularly on large undertakings. Our hope is that no matter who your are, there will be something of benefit to you as together we engage in the democratic process.

Preview chapters include ‘Disrupting Washington’s Golden Rule’ by Ellen S. Miller and ‘Visualizing Policy and Politicians’ by Fernanda Viégas and Martin Wattenberg.

• Download free preview chapters
• Pre-order

From the publisher:

This collection of essays, interviews, and case studies provides a multi-faceted and nonpartisan account of government as it becomes more transparent, collaborative, and participatory. Each chapter expresses the views of its prominent author, and the book as a whole offers a persuasive argument for transparency and interactivity in government at all levels. As a handbook for advocates of openness and e-government, Open Government provides a valuable mosaic of opinions from leading politicians, journalists, programmers, professors, and visionaries, making it a must-read, particularly in light of current events and technologies.

Topics include:

• The beautiful vision: seamless access to government information that is remixable, meaningful citizen interaction with government officials, and improved government effectiveness through realtime data analysis and visualization
• Transparency in the U.S. and abroad: solutions to bureaucratic indifference as well as government procurement biased towards proprietary, closed-source vendors
• Open, semantic government using Web 2.0 technologies: mashing up government data, knowledge management via wiki, and the open source approach to government
• Government 2.0 agenda for public participation: reforming government procurement, mandating the use of open standards, and bringing citizens into the government process

A new book, State of the eUnion: Government 2.0 and Onwards, is now available free for download. The book, a compilation of essays from 34 Gov 2.0 thought leaders, will soon be available in print through Amazon and elsewhere.

• Free PDF download: State of the eUnion: Government 2.0 and Onwards
• Radio interview with publisher John Gotze on Federal News Radio

From the publisher:

“In many ways, eGovernment has come of age. The use of IT and digital media is today part of everything government does, so the ‘e’ is becoming obsolete. ‘eGovernment is just Government,’ as the saying goes, but it is important to realise that the ‘e’ has changed government forever, and will keep doing so, and hence we now talk about Government 2.0, ” said John Gotze.

The book’s contributors touch on a number of different subjects, all related to making government work better. Some deal with getting government data out into the open, breaking down data silos. Others focus on how to interact with the public through interactive websites. Still others discuss how to facilitate organizational change that will open up government.

Contributors:

• Richard Allan, Facebook
• Kim Normann Andersen, Copenhagen Business School
• Tony Bovaird, Birmingham
 University
• Lee Bryant, HeadShift
• Joanne Caddy, OECD
• Stephen Collins, AcidLabs
• Dan Doney, US 
Office 
of 
the 
Director 
of 
National
 Intelligence
• James Downe, Cardiff 
University
• Mark Drapeau, National
 Defense
 University
• Bengt Feil, TuTech
 Innovation
• Dave Fletcher, State of Utah
• Michael Friis, Folkets
 Ting
• Matt Leighninger, Deliberative
 Democracy
 Consortium
• Lawrence Lessig, Harvard
 Law
 School
• Rolf Lührs, TuTech
 Innovation
• Elke Löffler, Governance 
International
• Rony Medaglia, Copenhagen Business School
• Philipp S. Müller, Center
 for
 Public
 Management
 and 
Governance
• David Osimo, Tech4i2
• Tim O’Reilly, O’Reilly Inc.
• Tommy Dejbjerg Pedersen, Geekhouse
• Chris Potts, Dominic Barrow
• Steve Radick, Booz
 Allen
 Hamilton
• Harald Rathmann, TuTech
 Innovation
• Steve Ressler, GovLoop
• Alexandra Samuel, Social
Signal
• W. David Stephenson, Stephenson Strategies
• Hanne Sørum, The
 Norwegian
 School
 of
 Information
 Technology
• Ariel Waldman, Spacehack.org
• David Weinberger, Harvard
 Berkman
 Center
 for
 Internet
 & Society
• Olov Östberg, Mid
 Sweden
 University