For about six years, this blue Univega Sportour harvested from the dumpster across 17th Street was my primary get-around bike:
In October, I was riding to work on the first day of the Bart strike. The F Transbay bus had no room on the front rack, so I took the Caltrans bike shuttle instead. I used to do this every day, typically sharing the van with fourteen other riders. Many of them tend to be messengers and other working cyclists, and I was out of practice. Someone scolded me for putting my bike into the wrong spot on the trailer, and my already off-kilter morning was thrown further out of balance. The bike shuttle no longer stopped at the Transbay terminal, and instead let us off at the foot of Harrison. I rode east, through a city confused by extra traffic and new patterns. Hours later, I heard how the whole city seemed to be more on-edge than usual, stress building up in the face of Bart riders forced to find other means of getting around.
As I crossed 7th Street, I was struck from the left by a taxicab and thrown 20 feet to the ground. I was taken to the emergency room at SF General, while the police took the bike to my office. It spent the next several months in the basement of Code for America as my back and shoulder healed so I could ride again. The Univega was a true trash treasure, and I wanted to salvage the parts I had added to it over time.
The frame was a total loss. The wheels were twisted out of shape, though the hubs were fine. The handlebars could be bent back, the stem was fine, the seat survived, the brake looked good, and I had some hope for the cranks.
A few weeks of bike shopping turned up this bright green Motobecane in Berkeley:
I’d never worked on a French bike before, and wasn’t sure entirely what to expect. It looked like any other steel bike boom frame, but when I got to work and stripped it down to the frame, I found a few important differences.
The brake hole on this frame wasn’t wide enough for a recessed mounting, typical of newer bikes and my existing brake. I looked at buying some nutted-mount caliper brakes, and briefly considered drilling out the back of the fork crown to make room for the wider bolt. I gave up on using the caliper front brake from the Univega and instead cleaned up the center-pull brakes that came with the Motobecane. I got most of the gunk off and put them back on as I had received them, but found that the adjustment of a center-pull brake is a serious pain. There’s a tool called a “third hand” you can use to make this easier; I didn’t get one.
The dimensions of the spindle holding the cranks turned out to be important. My older cranks were made for a longer spindle, and when I first assembled everything and tightened the cranks on, they would not turn. Oops. I pulled apart the bottom bracket from the Univega to see if I could salvage parts, but they weren’t transferrable to the new bike. I did a bit of research on bottom brackets, and learned that French frames are different from other frames. The difference is not always apparent by sight. I ended up buying a complete, sealed, French-threaded bottom bracket from Velo Orange, along with the tool to install it.
Finally, when I added my old cranks to the new frame I realized that they were slightly bent from the accident. It wasn’t visually obvious, but felt completely wrong when riding. So, I had to buy a new set of Sakae cranks with a neat-looking tornado shape. Cool, but the overall costs really added up.
One of the fun initial steps of building this bike was the chance to make wheels from parts. My friend Adam is a bicycle mechanic, and taught me how to build traditional spoked wheels on a truing stand. I’d never done this before, but with his direction even the one that I mostly built turned out great. Actually, I couldn’t have done half this stuff without regularly asking Adam for help. From him I learned that 1.375” looks a lot like 35mm, 24 threads-per-inch looks a lot like 1mm spacing, stems come in 22mm and 22.2mm diameters, and slightly-bent cranks go in the recycling with the beer bottles.
Now I own this great bike, and a bag of spare parts for the Bike Kitchen:
We released the new Code for America website on Friday, and now it is live.
We’ve been using this project as a testbed for new content management and design process ideas that we think might be helpful to our government partners. In conversations with cities, I’ve learned that no one is ever happy with their content management system, and no one ever thinks they have control over their own presence. Meanwhile, GOV.UK has shown off the importance and value of working on the website first, and the central role it plays in government presence. “Website” is such an uncompelling word, but a site is the default digital front door for any government. This makes city sites interesting to Code for America.
One of the great joys of this project lay in playing the role of the client, something new for me. At Stamen I spent nine years on the other side of the table, and here we got to commission Brighton’s Clearleft and Colorado’s Dojo4 agencies to do visual design and front-end code. Clearleft’s pattern deliverables are the special-special that made the final work so strong. Jon Aizlewood’s introduction to the concept convinced me to contact Clearleft. Jeremy Keith’s interest in design systems kicked off the process, and Anna Debenham’s fucking rock star delivery brought it all home.
Clearleft has publicized their copy of the patterns, while we’ve taken it one step further by hosting our stylesheets directly from the pattern library. We have a far-flung, increasingly-worldwide Brigade program with sites of their own to run, and I’m excited to have a normal website redesign process result in a shareable public utility for the future sites created by our local communities.
I’m currently procrastinating on a blog post detailing the way we blended Github, Jekyll, Google Docs, and Wordpress to create a heterogenous CMS for the site. If you find any typos, bugs, or problems on the site, send us a pull request via Github with a fix.
This Nishiki Colorado is the seventh bicycle I’ve owned in my life (I’m not counting the blown-plastic bigwheel I rode in Ansonia, CT in 1982). In an effort to further stave off car ownership, I’ve outfitted it as a cargo bike using an Xtracycle FreeRadical X1:
I mostly use it for food shopping. With the cargo bags on either side, I can move a four-bag load of groceries the 2.3 mile distance between my house and the grocery store.
The conversion was relatively simple.
The Nishiki Colorado base came from Craigslist, where late 80s/early 90s mountain bikes are currently easy to find. This one was $90, in excellent condition. I had expected to get a beater bike and just use the frame, but the components on the bike were all in great shape. The wheels did require a bit of spoke adjustment, something that I chose to learn to do myself instead of asking a bike store to quickly do it. I bought the FreeRadical at Tip Top, a bike store near my house in North Oakland, for $500.
The FreeRadical extension attaches to the frame at three points: one bolt attaches near the kickstand mounting plate just behind the bottom bracket, and two additional bolts fit into the dropouts where the wheel normally connects. The connection is strong and stiff, and makes a single extra-long frame for the bike as a whole. The cargo extension has its own additional dropouts, and the rear wheel attaches to those about 18” back from where it would normally sit. Xtracycle includes detailed instructions and there are a few adjustments for different types of base bikes.
There were three challenging steps to completing the connection to the rear wheel: moving the rear brake, moving the rear derailleur, and lengthening the chain.
The FreeRadical requires a linear-pull brake, different from the center-pull cantilever brakes that might typically come with this kind of bike. The linear-pull has to be bought separately, and uses a slightly different length of cable to engage the brake. The bike store advised me to get a new brake lever to account for the difference in length, but I found that the “mushy” feel with the old lever was tolerable so I left it alone.
The rear derailleur is a fiddly part, and since it’s so much further to the back of this bike I also had to use an extra-long cable to attach it. The longer cables are usually marketed to tandem bike owners, and Tip Top had it included with the FreeRadical in the box. Adjusting a derailleur can be a pain, but fortunately the ones produced in past ~25 years are relatively standard and easy to work with. Once I had it all connected and set the high and low limits, it took about fifteen minutes of riding up and down the street with a screwdriver in my hand, stopping every few feet to adjust the derailleur indexing until it all clicked into place.
Lengthening the chain requires a bike chain tool, and you have to buy two normal-length chains and connect them end-to-end.
Here’s what the bike looked like when I first brought it home:
I’m happy with the goofy blue & yellow color, and I’m glad that the new brake and derailleur placement still let me keep the color-matched blue cable housings up at the front. I’ve taken it on BART once, and I didn’t attempt to move it up the stairs and used the station elevators instead. I got a few weird looks and comments on the bike.
Following a tip from Jason Kottke, we’ve been watching the six-part BBC series How Buildings Learn, narrated by Stewart Brand and based on his book. The third part, Built For Change, should be required viewing for any designer or developer. It’s rich with advice now quietly part of the software canon. This includes several cameos from architect Christopher Alexander, famous to the software world as the inspiration for the concept of design patterns. What’s most interesting here is the explicit relationship between longevity and lean, repair-like methods.
“All buildings are predictions; all predictions are wrong.”
On San Francisco’s numerous victorians, including the famous painted ladies: “Right angles, flat walls, and simple pitched roofs make them easy to adapt and maintain.”
Montréal’s McGill University Next Home project is an example of homes designed for modification. They’re fairly standard-looking row houses, “easily modified, customized as finances allow … easily adaptible, flexible, and most all affordable.” Each building is sold half-finished, with new owners expected to finish parts of the house beyond the core living area:
Once you get comfortable with the idea that a building is never really finished, then it comes naturally to build for flexibility. For instance, in a new building you can have some areas that are left half-completed, the way attics used to be.
Professor Avi Friedman, on revisiting the homes:
5,000 homes have been built in Montréal since the idea was first introduced. When we came back to the homes three years later, to our surprise and joy we found that 92% of all the buyers changed, modified, improved the homes.
The theme of architects returning to a completed project, to check on how it’s been used and learn from its post-construction history, is one that Brand returns to many times. Lots of congruence with standard software UX practice there.
Most buildings that are designed by architects to look radical, wind up pretty conservative. A better approach is to start conservative and sensible, and then let the building become radical by being responsive.
The episode finishes up with architect John Abrams talking about his company’s fascinating practice of meticulously documenting every home they construct in photographs, prior to finishing. The photos show plumbing, framing, electrical, and other construction details prior to the addition of drywall:
We started this process years ago. What happens is, we take those photographs, put them in a book, and that book stays with the house. Presumably forever. It becomes very useful to the carpenters and tradespeople, but then it increases in value over time … there’s this document, it’s like x-ray vision into the walls.
“A building is not something you finish, a building is something you start.”
Nolan Caudill extended an invitation to come speak at the Urban Airship Morning Liftoff Speaker Series last week, and I was happy to have the chance to put into words and pictures some of what I’ve been working on at Code for America. Our amazing class of 2014 fellows just started, and we’ve been rushing to fill their heads with stuff before sending them off to their city residencies for the month of February. I’m so excited about the current class; it’s the first time I’ve been here for the full year (I joined in May of last year).
The notes below are a partial summary of my talk from Friday morning. I adapted some elements from my November keynote at Citycamp Oakland, and some thoughts that I previously put into my keynote at TransportationCamp West.
Coding with government is special. Government operates at longer time scales than startups, and remembers a time when information technology used to mean paper.
Paper is easy to mock. Jon Stewart has been taking the Veterans Administration to task for months now, about their massive backlog of outstanding medical claims. The floor under these boxes is supposedly having structural problems:
Paper is easy to mock, but it takes people with hearts and brains to move it around, and often the human processes around paper form communities of practice to get things done better and more effectively than simply computerizing everything.
A useful question, then, is how our current code and technology choices at CfA might better preserve what’s good about the old while still introducing the innovation of the new?
Three important technical goals can help: resiliency to environments and expectations, error-friendliness for developers and users, and sustainability for makers and caretakers.
I’m thinking of resiliency to two factors: environments, and expectations. I love this photo of Carlos Valenciano shutting down Kansas City’s IBM mainframe, the same one that he turned on almost two decades ago:
The technology environments used by local governments are changing, from heavy mainframes to smaller, more nimble systems, often open source like the work we do at CfA. This year’s project with Louisville, the Jail Population Management Dashboard, was developed with portability across environments in mind. Shaunak, Marcin, and Laura developed a supple and gorgeous visualization environment, and backed it with a conservative, cleanly-documented backend layer written in PHP and SQL Server. Those are two decidedly un-sexy technologies, but the bright seam between front-end and back-end allowed Denver to adapt the dashboard to their own purposes with their own compliant backend. Resiliency.
Adapting to new expectations means riding the border between commerce and culture. I’m not yet comfortable with the right wording here, but CfA has benefited greatly from the positive perception of helpful techies planning civic hackathons. Can this perception last? Or isn’t it our mission to work on stuff that matters so we can push the work to the unsexy societal gaps where needs are unaddressed?
Error-friendliness is term I’ve borrowed from Ezio Manzini’s paper on suboptimality: “low specialisation or ‘suboptimality’, regarding a certain purpose, is a strategic valuable property for biological organisms, summoned to confront themselves, in time, with potential environmental changes.” Developer error friendliness is permission to deliver work that’s suboptimal in strategic ways that allow it to be touched, tweaked, and modified piecemeal over time. The enemy here is premature efficiency: the Don’t Repeat Yourself or Convention Over Configuration principles, when taken to extremes, are two ways in which we rob ourselves of clues to intent in code.
David Edgerton’s Shock Of The Old offers additional hints:
As the British naval officer in charge of ship construction and maintenance in the 1920’s put it: “repair work has no connection with mass-production.”
City information technology is more like repair work than mass-production. Code that addresses user needs must be fit to those needs, and there’s rarely a mass-market product to be found that can do this without adjustment and tweaks. This similarity to repair is an advantage: the approach is more craft-like, more custom, and therefore carries with it more opportunities for learning in the agile/lean sense. For what it’s worth, this is also a summary of what I think went wrong with the 2013 relaunch of Healthcare.gov: a commodity-style purchasing mentality applied to a totally new service, with no opportunity for experimentation and learning hiding in that massive price tag.
User error-friendliness is a related concept. Try searching for a birth certificate in our Oakland public records application RecordTrac, and you’ll be immediately pointed toward the County of Alameda's Clerk-Recorder's Office (510-272-6362 or acgov.org/auditor/clerk) for this commonly-encountered mistake. Small-scale, repair-like moves continually nudging users toward the things they actually want.
Sustainability is about who can modify a system, and who can verify that it’s working. Github and “learn to code” are necessary but not sufficient answers to this problem, and it’s not enough for us to simply throw code over the fence when we’re done. Care must be taken that README documents say the right things to the right audiences, that basic architectural principles of the web are honored, and that we’re not landing anyone in hot water by delivering indecipherable weird (a.k.a. “Node for America”).
We’ve built some minimalist instance monitoring services and adapted a repository testing app to help make this last part a reality, and we’ve got a full plate of work planned for this year to help our fellows do their best work.