An introduction to the practice of civic technology.
December 4, 2011 by an unknown author
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
November 30, 2014 by Evan Miller
Design your product to integrate with the tools your users use and the processes they follow. Have your application import the product of applications that are already in use. Have it export into formats that are familiar and practical. —Tomas
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.
February 17, 2015 by Indi Young
Indi Young draws the important distinction between casual conversation and journalism from the art of active listening to build empathy. She outlines the value of this approach and strategies you can practice to better surface core motivations, mental models, and factors driving behaviors. - Colleen
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 6, 2015 by Erika Hall
In her characteristically witty style, Erika Hall lays out some insightful rules of thumb for remote teams – assigning a client-side herder, guiding clients on how to participate at each stage in the design process, cultivating frequent conversation during and between meetings, and more. -Colleen
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
July 14, 2015 by Madeline Ashby
Madeline's story beautifully illustrates the power of being on the front lines. Designers should actively seek out ways to expose themselves to the intricicies of needs and motivations across current and potential customers. -Colleen
October 1, 2014 by Amy Wagner
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
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.
June 19, 2013 by James Hague
May 12, 2015 by Matt Edgar
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
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
December 22, 2014 by Adam Greenfield
The “smart city” sales pitch is a sham and the discussions that officials in your cities will want to have about it are a distraction. Focus on real people's needs and you'll get to where you need to be. We don't build software with big top down plans anymore, and there are lessons here for urban planners as well as some fantasic examples of creative projects. Former Fellow Lou Huang described it as iterative placemaking. —Andrew
September 12, 2013 by Kris Galet
October 8, 2014 by Ben Balter
A high-level overview of legal issues related to open-source software development, written for government attorneys. May be useful when making a case to a city’s or county’s legal department. —Tomas
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.
May 6th, 2015 by Andy Weismann
January 12, 2015 by Andrew Zaleski
A survey of the current state of city-level open data efforts. Some highlights: 1. People will resist opening access to data that could hurt or embarrass them. Even a mandate from the Mayor's office may not budge the status quo. 2. If there is no clear user need motivating the release of a data set, it's likely to sit unused and ineffective. 3. Outreach to underrepresented residents is critical to understanding user needs. 4. A mature civic tech community can drive the release and effective use of open data. —Tomas
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
August 7, 2014 by Alice Bartlett
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 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
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.
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