An introduction to the pracitice of civic technology.
April, 1997 by Ron Carlson
January 6, 2013 by Mike Bracken
I had the pleasure of working for Mike, at GDS, before I joined Code for America. When this man says "the strategy is delivery" he really means it. Above all else, there is a critical need to create better services for our users and we should never let anything stand in the way, be that policy or politics. - Frances
August 23, 2010 by Tom Preston-Werner
Tom Preston-Werner’s 2010 advice on development driven by clearly-defined ideas saved in a README. - mike.
Lawrence Kesteloot, June 1, 2014
Code for America’s fellowship specializes in the delivery of alpha-stage apps to government partners. A typical fellowship app should top out at 2,000 lines of code. Lawrence Kesteloot explains why. -mike.
August 7, 2014 by Ben Frain
CSS is the worst. It’s the weakest part of the front-end webstack, and it will save you pain later if you have some coping strategies in your back pocket. Future-you will be thankful. - Frances
October 21, 2013 by Ben Darlow
Yo, don’t be dogmatic about markup and stylesheet syntax. Scroll to the bottom for some bare-bones guidelines on writing CSS well without swearing fealty to a particular methodology. - mike
November 13, 2012 by Mike Davies
Davies offers a heavily-opinionated take on client-side applications. A rule of thumb to remember for apps written while at CfA is that Internet Explorer 8 compatibility will be a requirement sooner or later. If you can skip script-based approaches and client-side loading complexity in favor of simple 1990s-age web techniques, do it. -mike.
July 9, 2013 by Drew Crawford
This is an article about mobile web apps, but we’re including it here because it’s also an article about the core complexity of interactive development with Javascript. Government partners are an especially difficult consumer of web apps written with client-side code, because they frequently use browsers as old as Internet Explorer 8. Do not attempt a browser upgrade campaign with your city. Instead, assume that your front-end interactive development will be harder than you estimate and degrade gracefully to plain HTML and server-side processes where you can. For another take on this topic, watch Alice Bartlett’s talk at EpicFEL 2014, “Burn Your Select Tags” (search for it on Youtube). -mike.
June 4, 2014 by Eric Jiang
Eric Jiang offers a caustic take on the weaknesses of Node.js. While Code for America encourages quick-turnaround experiments with a variety of languages and tools, we've found Node.js to be especially lacking in two important areas: the Node ecosystem is too reliant on quickly-changing conventions, and government partners don’t know how to cope with server-side Javascript.
When in doubt:
- Write code
- Not too much
- Mostly procedural
-mike
November 11, 2013 by Sarah Mei
We’re including this article to clarify why you should in fact never use MongoDB. Mongo’s strengths are typically described as its free-form, schema-free nature, but as you’ll learn from Sarah Mei’s essay this is also a serious weakness for your application. If you believe that you need an unstructured, key-value store for your application look into PostgreSQL’s JSON column store. -mike.
March 19, 2012 by Peter Krantz
This piece may provide useful argument fodder for your conversations with partner governments. The decision to open government data is often assumed to be identical to the decision to adopt swishy new web platform features, but see Albuquerque’s open data portal for an example of a high-quality static file data site.
See also Paul Ramsey’s What's so hard about that download? for a developer’s take. - mike.
December 2, 2012 by Paul Ramsey
Developer experience. Actually a pretty huge deal - while the author might not call it that, this is a detailed UX teardown of the data access process of one of the more advanced North American local governments. We need to figure out how to affect this, which isn't easy. - Cyd
October 12, 2011 by Steve Yegge
Steve Yegge’s platform rant was an instant classic when it leaked in 2011. Code for America fellowship projects aren’t expected to be platforms as part of the normal first-year experience, but it’s worth understanding what the ramp from fellowship prototypes to products and platforms looks like. - mike
January 6, 2011 by Paul Ford
This is as good a description as I've ever seen of the gulf that people have to cross to truly understand the impact of the internet on their business. Most of our government partners start the year on the far side of it, and finding ways to get them over it is critical work for fellowship teams. By and large, we've seen showing it work much better than saying it, as you might expect - but it's good to really ground yourself in what "it" is. - Cyd
April 22, 2013 by Dan Milstein
Dan Milstein offers one of the strongest justifications for agile and lean software development, grounded in Daniel Kahneman’s psychology text “Thinking Fast and Slow”. In short: no one knows how to estimate software because writing code is identical to learning, so it’s best to use an approach that’s suited for unknown timescales and outcomes.
“No Deadlines For You! Software Dev Without Estimates, Specs or Other Lies” is an excellent follow-up post to this one. - mike
Atul Gawande, July 29, 2013
One of the most profound things I’ve ever read about how substantial innovations actually get traction (or don’t). It made me realize all over again the critical role that the Fellows play in the project of transforming government. Even when it feels rough, even when it feels like you’re making no progress (there will be some times like that), you’ll be doing the great and difficult work described in this piece. By being present, as friendly, trustworthy people who are there to help, you’ll be changing minds bit by bit, the entire year. - Cyd
June 19, 2013 by James Hague
June 9, 2014 by Molly McLeod
2014 Fellow Molly McLeod did a 1/2-hour unsolicited redesign of a government form that ended up on the front page of Reddit. Afterward, she reflected on good practice for crtiquing design in the government space. Extra good news: Molly is joining the CfA staff and will be around to geek out about this and all design-related topics. - Cyd
Richard Pope, 27 Jul 2014
This is far from the only way to start a project, but it’s a pretty darn decent sequence to take as a baseline. The critical thing is getting past the beautiful-soap-bubble idea stage as quickly as possible. I like the piece because Richard doesn’t just set that as a principle, he says exactly how he does it. - Cyd
October 6, 2009 by Dana Chisnell
An oldie but a goodie on one of the most basic and powerful practices of user-centered design. If you’ve never run a usability test or user research, this is a great overview of something we encourage every fellow to get involved in. If you’re already a pro, it’s still worth a re-read. By the way, Dana Chisnell has done a ton of this work in ballot design and other civic spheres. She recently joined USDS and I’ll be very surprised if we don’t see her at CfA HQ sometime in 2015.
As a follow up, Smart Chicago has done tremendous work on how to recruit participants across neighborhoods and socio-economic classes, to make sure civic apps get tested and work for everyone. They wrote a book about it, available at http://www.cutgroupbook.org. - Cyd
July 18, 2014 by Ben Terrett
I like to think that we’re similarly bullshit-free in the way we do design at CfA. We certainly strive to be. Fast, light, and flexible are the watchwords, and as Ben says, if it doesn’t work, we’ll change it. - Cyd
July 9, 2014 by Leisa Reichelt
One thing you will quickly discover is that as bad as public-facing government technology can be, the internal tools used by public servants are often much worse. Often bad to the point of abusiveness, to be honest. Leisa Reichelt, the head of UX for Gov.UK, talks here about an experience she had where she came to grips with how hard a customer service person was working to paper over the shortcomings of the systems she worked with. Imagine how well she could help her clients if she wasn’t spending all her energy on clever and insane workarounds. You’ll meet a lot of dedicated public servants in February, and thinking about how you can help them be great at their jobs will be really important. - Cyd
April 23, 2014 by Mills Baker
Mills Baker writes a critical call-to-action laying a lot of responsibility at the feet of designers in this piece. Design is fundamentally central to everything we’re producing in the world and it’s where the rubber meets the road in the service/user interaction. When it comes to the business of delivering public services in particular, it’s not a ball we can afford to drop or step back from, and we must always, always, keep the users’ needs central to everything we do or risk failure. - Frances
June 4, 2014 by Nick Kokonas
There’s a really interesting phenomenon where something that has been online for a few years suddenly gets a revolutionary re-thinking. Our first attempts to bring a thing (weather forecasts, ticketing, whatever) into the digital space almost necessarily copy the old model, and it’s not until people have been using an online version for some time that someone realizes “hey, these are false constraints, we could do this completely differently”. It happened to weather a while ago and this article is about it happening to restaurant reservations. This means a couple of things - 1) look out for opportunities to make these shifts; 2) any time you bring things online you’re doing a critical, absolutely required step to actually making them better. - Cyd
Jake Solomon, January 5 2014
This is a terrific piece by 2013 Fellow Jake Solomon about his experience observing clients at the Food Stamps office in SF. It’s natural to get outraged by the conditions described here, but we include it partly to ask a more interesting question than “is this inexcusable?” (“yes”). The question is, what are the conditions affecting government organizations and public servants that lead them to accept such things as matters of course? (Of note, Jake didn’t join us as a UX person or a researcher; he just did this, with encouragement from me and his teammate Marc Hebert, and wrote about it.) - Cyd
November 19, 2013 by Clay Shirky
We'll hear more from the Healthcare dot gov team later this year, but this is a good elucidation of the management problem (it was just one among many). Testing & failure are some of the most sensitive issues with our partners, especially as the CfA Fellowship is a significant expense, requiring city council approval and oversight. And yet, there are tremendous risks to leaving these out of the conversation, as illustrated here. We've talked about this already in city onboarding, but nodding along to principles and learning to actually work this way are different things, and the latter is legitimately very very hard. We ask you to take a strong stand on the right way to work, while also holding a lot of empathy for the real reasons it may be hard for your partners. - Cyd
July 12, 2014 by Mike Byrne
Mike “Good Mike” Byrne has insights into government procurement that span his years at the Consumer Finance Protection Bureau, his input into the White House Open Data Policy, his time at the FCC, and his service to the State of California. He also happens to be a bike nerd with a keen understanding of how simplicity can win for government technology. - mike
March 17, 2014 by Dave Guarino
This article is by a 2013 Fellow and describes what the main technical challenge inside government technology is right now. It’s not sexy, it’s not scalable, it’s not easy. ETL inside of your City hall is boring inglorious work, yet it is the job for right now. It’s up to you to get it right so those that come after you can do the fun work with ease. -Andrew
Winter, 2012 by Bruno Latour
"The environment is what appeared when unwanted consequences came back to haunt the originators of such actions.” Code for America’s environment is the world of government digital needs. We don’t want to replace it as modernists, or fearfully turn and run. The changes we make to this environment will need to be adopted and sustained into the future.
For transit geeks, Bruno Latour’s “Aramis” (1993) is an excellent book-length mystery story of a failed Parisian personal rapid transportation system. - mike
July 22, 2013 by Noah Veltman
February 18, 2014 by Dan Hon
There are two worlds adjacent to government where code and design literacy is a hot topic: academic digital humanities and journalism. Here’s a report from the current status of the learn-to-code debate in the latter. -mike.
July 29, 2014 by Bill Dollins
Government technology is an awkward combination of large and small. Enormous procurement contracts for millions of dollars in software mask systemic issues while tiny offices on shoestring budgets develop creative approaches to problems they can’t buy their way out of. GIS entrepreneur Bill Dollins talks about his history in food service to describe some of the differences between fast and slow operations. - mike.
February 18, 2014 by Dan Hon
Code for America's Dan Hon starts to ask the hard questions in this edition of his newsletter. Why are Governments not trying harder to improve their services? -Frances
April 11, 2014 by Lisa Scott
Jargon: it’s a problem. Read on for GOV.UK’s take on banned jargon. - mike
July 22, 2014 via Alice Bartlett
November 6, 2014 by Maija Palmer
The Financial Times is a big anti-jargon campaigner. They normally do an end-of-year competition to find the worst examples. Here's a good example of jargon where simple language is clearer and can be undestood by everyone. Some of these examples, like "Digital Transformation" are still good shorthand for what we're trying to achieve - but still need to be explained. Remember: read over what you've written, and ask yourself: did I actually say what I meant? -- Dan
Who is Russell Davies and how has he managed to get an entire section of articles to himself? That’s a good question. He works for the Government Digital Service in the UK and is the man to blame for the “simpler, clear, faster” slogan along with finding appropriate language to help civic servants understand their problem domain better and fulfil their remit. He rather modestly describes his job as “words and powerpoint”, but he has set the underlying tone for GDS’ work in an incredible way.
Russell has an eye for the pointless. The time wasting. The complicated. He says little, but what he does say is simple and clear. Almost everything he writes is on-point and he is articluating the problems in government design in the best way I have seen. Here’s a selection of some of his articles. - Frances
February 8, 2014 by Russell Davies
June 15, 2014 by Russell Davies
October 9, 2013 by Russell Davies
July 4, 2014 by Russell Davies
March 18, 2014 by Russell Davies
May 1, 2013 by Austin Carr
This super fun article details a relentless quest for innovation in something that doesn’t matter very much at all. The number of times the team bounces back from adversity, from failure, from total irrelevance, is astounding. May we all be this tenacious in pursuing better government and government technology!
Also, for what happens when Taco Bell attempts to innovate in mobile apps, see The Chipotlification of American Fast Food by Adam Chandler http://www.theatlantic.com/business/archive/2014/10/the-chipotlification-of-american-fast-food/382167/. - Cyd