Since December 2010, I’ve been working for the federal government. It occupies most of my time and creative energy, so my post volume here–my personal site–has been low. It will probably continue to be low for the duration of my tenure. One day, this site will have a pulse again, but for now, don’t expect much…
I just watched Paul Graham’s keynote from PyCon, where he asks developers to replace email, among other things.
His talk inspired me to write about a product idea that I’ve been baking for about three years. Since the night I had the idea, I’ve wanted to realize it, and I’ve been through a few false starts. But I’ve never gotten around to it for real. The worst part is, I really, REALLY need this product, because I think it would make life a lot easier for me. I decided that if I shared the idea with everyone, one of two things would happen:
So I challenge you to read the below and build this. Here’s the idea:
Tasket (I’m told I need a new name) is two lists: a to-do list to which others can add items (Incoming tasks), and a list of things you have asked others to do (Outgoing tasks). When you add an item to someone’s Incoming tasks list, the item is also added to your Outgoing list.
That’s the idea. Pretty simple.
Why let people edit your to-do list? Because they already do, many times a day. They just make it extremely difficult for you to manage that list. Every time you get an email, a phone call, or a hallway request, you are being asked to do something for someone else. They are adding items to your to-do list. But it’s your job to collate all of those tasks and put them into an organized list. That’s not fair. You’re doing work for the benefit of other people. The least they could do is make it easy for you. Let them add the item directly to your to-do list.
At the same time, unless you’re a hermit, your own list of incoming tasks is inherently incomplete. We are all waiting on other people to do things for us as well, and many of the things on our own to-do lists cannot be done until someone else does something for us; we have dependencies. I have never seen a to-do list specifically for tracking such outgoing tasks. Tasket accomplishes this while simultaneously building your own to-do list without extra effort.
That’s it. Please make this. I really need it.
I have some screenshots of early prototypes. Maybe I’ll post them eventually. If you want to make this with me, just write to me. Let’s get started.
The below essay appeared in The Guardian on January 26, 2010, in advance of Apple’s public announcement of the iPad.
On Wednesday, Apple is expected to unveil a product that will be, among other things, a competitor to Amazon’s Kindle. That will be a crucial test for Apple, and for society. If the company lives up to its reputation for revolutionizing media, this new product and its successors will one day replace physical books. The test for Apple is in whether they try to control what we read. The test for society is whether we let them.
Continue reading
In the coming weeks, O’Reilly Media will publish Open Government, a collection of new essays on how technology can make DC more transparent and efficient. Today, O’Reilly released a preview (PDF) of the book that features the first eight chapters. My chapter is included; its entire text is below.
—–
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.
UPDATE: Given the events of the past day, I feel it’s worth referring back to my post from last February in which I discuss how intelligence failures are normally dealt with, and propose a more common sense solution. BRIDGE, the program I discuss below, would have provided a model for doing some of the things I recommended.
Back in October, the Director of National Intelligence killed a program called BRIDGE. (I’ve written about BRIDGE before.) As such a vocal advocate of BRIDGE with a financial interest in its success, my bias is clear, but for whatever that biased opinion is worth, BRIDGE’s death was the biggest government IT failure of 2009.
The cause of BRIDGE’s death is the most frustrating aspect of it, and it’s a reminder of what makes government innovation so logistically difficult: BRIDGE wasn’t deemed a failure or a waste or a PR risk. Technically, it wasn’t even killed; it was just put on ice. Following the presidential transition, new priorities were made at the top levels of the bureaucracy. These priorities had nothing to do with BRIDGE in particular, or any other tech-related goals. BRIDGE just got lost in the shuffle along with countless other programs that deserve attention.
It was a casualty of a paradox of government bureaucracy: in government, change comes very, very slowly. It takes a really long time for something to happen, and nothing ever happens without a lot of deliberation. Everything is slow. Everything, that is, except for its hatchet. The government can end large swaths of projects with breathtaking speed.
I used the word “hatchet” deliberately. Many programs are killed not because they were hand-picked as faulty, but rather as a simple result of changes in government administration. This happens at least once every four years, and even more given all the agency directors, cabinet secretaries, deputy secretaries, under secretaries, assistant secretaries, and principal deputy assistant secretaries whose routine replacement can cause not-so-routine changes to the way their staff do business. I stayed at the same desk throughout my three years at the Department of Defense. In that time, six different people sat in my boss’s chair, and my office’s name and mission changed twice.
New government executives come and go. Each new one sees things a bit differently than their predecessor and orders a change in strategy. Whether those changes are for better or worse, they’re changes, and they’re enough to nip any promising project in the bud. That promising project probably took two years of paperwork to get off the ground, but it’s gone in an instant. Later, someone will realize there’s a need for it…and the process begins again. The slow start/fast hatchet paradox makes it extremely difficult to succeed with technology projects that take a few years to bear fruit. They can barely get going before simple bureaucratic machinations force them to stop. That is the reason for BRIDGE’s demise.
The official word on BRIDGE came in October:
Thank you for participating in the BRIDGE experiment…We are working on an updated concept which we hope to launch in the near future under a new name. We would like to see all of you back as we move to a more permanent infrastructure. As soon as we have a launch dateand URL we will post it at http://about.bridge-ic.net/.
BRIDGE died before its first birthday, long before the “next model” deserved any thought. From my seat as a BRIDGE developer, even the first BRIDGE hadn’t been fully fleshed out before it got the axe; some of the technical specs were still undefined. When will this next model be live? The provided link is dead, if that’s any clue. (Remember: quick to kill, slow to start: there’s no time for the previous project to transition to the new one, which probably won’t be announced for quite some time.) As far as I know, the next model still lacks an executive agency–an entity of the Intelligence Community like the NSA or CIA willing to oversee the project. This will be a hard sell, given that it’s not apparent how an individual agency would benefit more from BRIDGE 2′s success than its partner agencies would.
But there is benefit. Major recognition awaits the people who champion this project and guide it to success. BRIDGE and A-Space (a sort of private, classified instance of BRIDGE) are a lot more than a platform for intelligence analysis and information sharing. They are a model for software development that could change the entire government procurement process. Traditionally, the government has bought software–and many other products–through a buy first, evaluate later model that doles out excess money for poor work. BRIDGE provided a way to change that, creating a market for software tools that any developer could contribute to. I’ve detailed the mechanics of BRIDGE in the past, so I won’t reiterate them here.
BRIDGE’s and A-Space’s incredible potential has also been their major fault: the real benefit and genius of these programs has been hard to explain to non-techies, and while government executives have sung their praises to the press, those praises don’t really get to the heart of what these programs are about. (Nor does Wikipedia’s A-Space entry.). They are not simply “MySpace for spies.” They are so much more. If you are an agency CTO frustrated by the insane way you buy software, consider a new and better way. Adopt the next iteration of BRIDGE. While the technical details will be hard to explain to your bosses, the results–better performance and huge savings–should speak for themselves when it comes time for your performance review.
Thanks to Lewis Shepherd for his guidance on this.
NOTE: I don’t normally write personal stories here, but I think this may help someone. It might even get the NYPD to stop taking advantage of people. In its own way, this story is about government efficacy and information sharing, so it’s not totally out of place on my site.
I just moved to a Brooklyn brownstone. Right outside my door is a curb cut at an intersection. People park there. Then they get towed and fined about $400. But this shouldn’t happen, because this particular curb cut is at a T-intersection, and there is no crosswalk painted on the road. This makes it a legal parking spot. The law was changed last year. Look, see?
Maybe you found this post because you’re one of the poor schmucks who had their car towed. I wish you luck in recovering it. In the meantime, don’t worry: while you can’t recover the time you’ll spend at the tow pound, you can get your money back. But the burden of proof is on you, so you have to make your case effectively. I think I can help you do that.
My own car was towed from a similar spot in August. I put together a pretty detailed package of evidence to make my case. I’m posting it here for you to borrow. You’re free to copy and edit the letter to make it fit your own circumstances. The pictures, of course, will have to be original–unless you were towed from the exact same spot I was.
My package had five things: the ticket; a copy of my tow pound receipt; a copy of the DOT Web page I linked to above, with appropriate portions highlighted; a letter stating my case; and four pictures of the intersection in question.
1: The ticket. When I finally got to mine, it had been sitting on my windshield for three days and was completely illegible. However, the summons number was on the tow pound receipt, and that’s the only important piece of information you need here. You must still include the ticket with any response, however.
2: The tow pound receipt.
3: The DOT Web page. It felt so good to come home with my car, jump on the computer and read those words:
Parking is now permitted at those “T” Intersections where the adjacent (major) street is not marked with a crosswalk and not controlled by all-way stop signs or traffic signals, even if there is a curb cut at that location.
The only sweeter words were the ones that preceded them:
These locations have caused confusion in the past, as they were not clearly delineated as spaces for pedestrians or cars.
HA! So DOT acknowledges that it’s confusing, changes the law, and yet NYPD Traffic still enforces the old one. Print out a copy of this page. Highlight the paragraphs in the “Parking and Curb Cuts” section.
4: The letter. Download mine in Word format. Edit it to reflect your own situation and sign it.
5: The pictures. My pictures include some handiwork that, while not essential, will probably strengthen your case: I superimposed the DOT’s drawing on my photos to provide the traffic judge with some perspective. Also, I got closeup photos of the address, in order to prove that the intersection in the photograph is indeed the intersection at issue:
Image 1
Image 2
Image 3
Image 4
These enhancements require some decent photo editing skills. If you don’t have the right software, they can probably help you at a copy center. Enhancements or no, print your pictures in full color.
Now what?
Now that you have everything, what should you do with it? I’m not sure. I requested a hearing by mail, sent in my package, and waited. It’s two months later, and I’m still waiting. In the meantime, my fine has been raised $10 because I “failed to respond.” In other words, the people in the “Have people paid their tickets?” office received it (I have a certified mail receipt to prove it) but never told the people in the “Let’s fine people for not paying their tickets” office. If you go the hearing-by-mail route, prepare for this. Use certified mail.
In the course of sorting this out, I was told by city personnel that I shouldn’t bother with hearing-by-mail, and should just walk in to court in the morning. It’s low traffic and fast. I plan on doing this soon.
Good luck to everyone.
UPDATE: I went to the Brooklyn finance office on Joralemon to sort this out. After about 15 minutes of waiting, I saw an adjudicator. The job of the adjudicator is to offer you a reduced fine. If you refuse, you get to see a judge. I explained my case to the adjudicator and showed him pictures. He then typed a few keys on his computer and said with a smile, “That’s dismissed!” He was fully aware that T-intersections are legal spots.
The ticket was now taken care of, but he could not refund the tow fine. That requires a separate form (which you can find here) and a copy of your tow receipt.
I wrote to the Department of Transportation about this coordination failure. Their response:
We have been informed of instances where police officers or traffic enforcement agents may not be aware of the rules change and have issued summonses for parking at T-intersections where parking is now legal. We are working with the Police Department to ensure that all of its personnel are aware of the rules change, and with the Department of Finance, which adjudicates summonses, to ensure that summonses that may have been issued in error are properly adjudicated.
Ah, bureaucracy.
Yesterday, I asked some friends a question:
Let’s say you want to become an authority on something but have no academic training or prior experience. The first thing you do is _______.
I got a good response, so I thought I’d post them here:
I think it’s interesting that only one person mentioned anything about school. My question was not hypothetical, so I wonder if more people would have recommended schooling had I mentioned the subject at hand: transhumanism, from a philosophical and anthropological perspective. The most popular recommendation was to find a mentor, and that’s something I am going to start doing soon. So if you have thoughts about where to go, please share them.
Also, if anyone wants to refine their answers (or give them for the first time), please comment below or reply to my original tweet.
Around this time yesterday, I, along with countless others, tried to bring down the Web sites of Iran’s information and justice ministries, and state-sponsored media outlets. The idea was to silence the pro-Ahmadenijad, anti-dissent messages coming from these outlets, and in so doing, strengthen the opposition protests in Tehran.
You didn’t have to be computer smart to take part: a developer in San Francisco had set up a push-button tool that would, upon your click, immediately start bombarding 10 Web sites with requests. I clicked Start, and in the 10 little boxes below, I could see the pages load and reload. About half of them were already down.
This was exhilarating. The goal was to promote democracy, and I could actually watch as it happened. Empowering.
But there’s more to it than that. I’m conflicted about the virtue of this idea. I’m still trying to sort out my thoughts about what happened, but I know that we will be talking about yesterday morning for years to come. We turned our collective power and outrage into a serious weapon that we could use at our will, without ever having to feel the consequences. Network warfare became available to the general public. That is frightening. Here is how my thinking evolved throughout the day:
For comments, see the original post on Personal Democracy Forum.
In the aftermath of Thursday’s virtual White House town hall, most of us in the tech-politics arena have been pondering one question: How do we improve upon this system to create a better virtual democracy experience? The conversation usually comes back to the problem exemplified by the marijuana questions, which were far and away the most popular questions asked of the president. Some thoughts:
To the tech-politics gurus bemoaning the marijuana questions:
“The marijuana people” did not “game” the system. They didn’t “sabotage” it. They didn’t get advanced notice. There is no (public) evidence of astroturfing or systems exploitation. They played fair. “Sabotage” is shouting from the back of a room during a Senate testimony. All these people did was show up at the polls. It’s the same thing you and I do every other November: they voted. If that’s sabotage, then senior citizens are incredibly cunning saboteurs. It’s fine to look for better ways of building this system. But stop equating fervent yet fair participation with cheating. I see the marijuana questions as a huge success, in two regards.
First, people participated. Yes, marijuana was #1 and #2 in the energy category, and this was caused by disproportionate enthusiasm for Open For Questions. But instead of bemoaning the marijuana questions and figuring out ways to silence them, we should be thinking about why the other more topical questions fared so poorly by comparison. Those questions have constituencies. But those constituencies didn’t turn out. Why? I don’t know, but I’m pretty sure pot smokers aren’t the reason. I’m ashamed that our first reaction has been to blame enthusiasm when we should be celebrating it and trying to generate more. It’s fair to recommend improvements to the system that will make it more representative of public interests. But it’s not fair to blame the people for being vocal.
Second, I don’t know about you, but I’m tired of people asking how the president is going to “bring back jobs from overseas” or “why we don’t have a better health care system.” He’s gotten those questions for the last two years. He knows the answers like the back of his hand, and so do we. The entire point of Web-based interaction with the president is to see something that we otherwise never would. We have wanted this for so long, and now that the medium has finally created that unique opportunity, we’re calling it a problem. The marijuana questions were the only questions that could have taught us something new about the president’s thinking. Outcome: he laughed them off, and now, so are we.
To Macon Phillips and Bev Godwin:
Open For Questions wasn’t perfect, but I’m glad you’re experimenting. Know this: too much participation was not your problem. You want participation. Your problem was lack of participation from a broad base of the populace. That, and a dearth of intriguing questions that inspire interesting answers. For the next iteration, please do not think of ways to–ahem–weed out questions that might embarrass you. Instead, think of ways to create the unexpected. That is the only reason to try new things.
For comments, see the original post on Personal Democracy Forum.
The below is a chapter I wrote for Threats In the Age of Obama (Amazon), recently published by Nimble Books. The book is divided into two portions: one set of chapters on future threats, and another set on ideas for dealing with them. My chapter–in the latter section–focused on information technology solutions.
___
What is the perfect information technology solution to coming national security threats?
There isn’t one solution to multiple threats. Rather than searching for a single solution, our national security community should adapt its IT procurement strategy to develop many solutions, each addressing a specific threat at the lowest possible cost.
The existing strategy is as follows: after being caught off guard by an unforeseen crisis–a terrorist attack, an outbreak of violence, a surprise nuclear test–we reflect on our failure and identify a single cause. Maybe we didn’t have enough information. Maybe we had too much information and couldn’t sort through it all. Or maybe we had the right information but we didn’t collaborate.
After pinpointing the cause we spend years–and tens of millions of dollars–trying to develop a handful of Perfect Software Tools to remedy the deficiency. Much of that time and money is spent on procurement bureaucracy: the first line of code is written after months of identifying requirements, issuing RFPs, waiting for bids, and awarding contracts.
This is an outdated strategy for two reasons. First, unforseen crises are rarely the fault of a single deficiency. Fixing one problem while ignoring others is the equivalent of inviting strategic surprise. (UPDATE: To clarify, solutions based on single failures will only solve identical failures; they won’t solve different scenarios. The job of intelligence is foresight, not reaction.) Second, the economics of innovation demand that creating a few tools will almost never solve our problem. After all, the vast majority of innovations fail. For every Google and Wikipedia there are hundreds of failed search engines and online communities. High-dollar attempts at the Perfect Tool puts all of our eggs into a basket that will almost certainly fail us.
If failure is so likely how do we ever build useful tools? By building more of them. And in order to do that, the price of each attempt must fall drastically. Instead of spending $10 million on one tool, spend it on a thousand. The most valuable lesson for government IT decision makers is that real innovation requires experimenting with many different options.
A much lower cost per product is not as unrealistic as it may seem. Modern software need not be expensive; in fact, it is getting cheaper and cheaper to create increasingly advanced systems. The Web has made this possible because it is a free market for innovation, defined by a few qualities:
Compare these qualities to government information technology:
That’s not to say that our systems haven’t come a long way in the last few years. We now have wikis, blogs, link sharing tools, and all the other basics associated with the “Web 2.0″ brand. But we still rely on an outdated, inefficient system for procuring our software. Our systems have recently begun looking like the Web. Now it’s time to start innovating like the Web, too. With recession-induced budget cuts on the way, it is the perfect time to justify a more cost-effective strategy. Here are three ways we can start.
Let analysts solve their own problems. Problems are best understood by those who experience them first hand. Many of the Web’s best tools were not intended to be products; rather, their creators built them simply to solve their own problems. Basecamp, the Web’s most popular project management tool, was created by a small Web development firm to help its remote staff collaborate. It proved so useful that the firm, 37Signals, quit creating Web sites and made the Basecamp suite its sole product. Based on the Web model, intelligence officers would ideally write their own software. But that’s a tall order: few officers know how to write software and few have the time to commit to construction.
The solution is to hire Web programmers and embed them in analysis cells. By working as analysts, they’ll understand our IT needs better than any outside contractor ever could. Give these developer-analysts the permission to write and deploy their own code, so that they may test various tools with their colleagues. Those colleagues would provide frequent, unfiltered feedback, a vital aspect of software development that is absent from the government procurement process.
Give independent Web developers a shot. Developer-analysts wouldn’t be the only people with good ideas for new software. Small companies and independent developers have created thousands of Web-based productivity tools that would instantly help intelligence officers do their jobs better: To-do lists, journals, calendars, Gantt chart generators, people directories, mapping tools, timeline builders, concept mappers, and more.
But right now, most small companies and individuals can’t compete for government contracts. Their products are too simple to justify the cost of the bidding process–not just for the developers, but probably for the government as well. Why spend several months acquiring something that takes only a few days to build? As a result, government networks don’t benefit from the tools that make the Web so powerful.
We need to make opportunities for outside developers to get involved. For inspiration, look to Vivek Kundra, the Chief Technology Officer of the Washington, DC government. In an October 2008 contest called Apps For Democracy he procured 40 Web applications from dozens of solo developers and small firms. And he did it in 30 days on a $50,000 budget. He avoided the standard procurement route, which would have cost over $2 million and taken more than a year. Instead, he sponsored a contest that awarded small cash prizes to the best entries. Among the best tools were a carpool coordinator, a bike route mapper, and a neighborhood data visualizer.
The DC government probably never would have thought to request these tools, let alone issue RFPs for them. The entrants–DC residents and everyday programmers–had their own good ideas. Given the chance to realize them, they did.
The national security community should do the same thing. Thousands of Americans would respond with worthwhile contributions. Intelligence officers could team up with developers to help them better understand our needs. Officers with programming experience might even submit their own applications–a digital version of the DNI’s Galileo Awards. In the end, we would have hundreds of tools at a very small cost. If the contest yielded just one useful application, the return on investment would be no less than that of the average mega-contract.
Open our eyes to Open Source Software. Even better than cheap software is free software. Many of the Web’s best software is “open source,” meaning anyone can download it at no cost. Most government networks are already running some open source products. Apache was created by volunteers and now powers over half of all Web servers, including Intelink. MediaWiki–the software that runs Wikipedia and Intellipedia–is also an open source project.
Open source software is useful because it is infinitely customizable. Anyone may modify an open source package to fit their precise needs. The government, on the other hand, too often reinvents the wheel: we pay exhorbitant prices for proprietary tools when a few modifications to existing open source products would suffice. The FBI wasted over $200 million on SAIC’s ultimately scrapped Virtual Case File, a content management system that would have done much the same thing as WordPress, the popular Weblogging software. In an attempt to fix the terrorist watch list, Lockheed Martin has spent $500 million on a database that cannot search for names. Anyone who has built a Web site with the open source MySQL database language knows what a shameful waste that is.
The Web is full of successful open source projects that would immediately prove useful to national security officers. Why aren’t they more abundant on government networks?
Many believe that open source software poses a security risk because anyone may view and contribute to the code. This transparency actually makes the code more secure: for malicious code to make its way into an application, it would have to be approved by the project managers and evade the watchful eyes of hundreds of honest contributors. Should a user have any concerns about portions of the code, he may always remove them from his own copy. Proprietary code, on the other hand, can never be modified by the user.
In the long term, open source software is not completely without cost. It takes time and money to maintain. But the initial investment of simply trying it is minimal. While custom solutions can take years to complete, open source packages literally take minutes to deploy. Instead of seeing them as inferior alternatives, they should be the first place we look to fill our software needs.
–
The defense industry used to set the standard for information technology. The military was using the Internet and e-mail decades before the general public first heard of them. Today technology transfer works in reverse. New information tools are created by and for the public; bureaucracies catch on years later.
What can we learn from this? Should we try to get our edge back? No. It’s not a bad thing that outsiders have gotten so good at software development. The only problem is our own refusal to adopt their superior innovation model, choosing instead to stick with our bureaucratic process. The Web’s lesson for us is twofold:
Becoming comfortable with experimentation is the best thing we can do to prepare for any threat, and here’s why: In order to be truly prepared, the available solutions must outnumber the problems. Otherwise, we’ll have sunk our resources into a handful of tools that address some threats and ignore the rest. And that is not preparation. It is gambling.
