The Tom McCall Waterfront Park is attractive and popular. It's a great location. Portlanders consider it quintessential Portland (though I favor the Boise River Greenbelt, Washington Park, and the South Park Blocks as far as urban green spaces go).
Barry Johnson is a writer for The Oregonian, a newspaper. His Waterfront Park: A balancing plan discusses a common problem with a use of a lovely public space in downtown Portland: big festivals on the waterfront limit the usability of the park for the rest of the year.
You probably don't care about my opinion on parks (and perhaps less so for Barry Johnson's), but his column has a gem of a paragraph. Given that festivals bring in money, that Oregon has an unsustainable tax base, that schools are out of money again, that unemployment here is ... brisk, and given that the city council has plenty of other pressing concerns, not limited to a pending recall of the mayor and controversial decisions to rename streets and relocate a professional sports arena, why bother rethinking a park maintenance policy? From the column:
In the great order of things, this might seem like a small problem. But one way to look at a city is as a collection of thousands of small problems which are small opportunities to make things better. When we successfully apply our ingenuity to one small problem, it points the way toward other improvements. In this way, our city gradually gets better, and at some undefinable point it actually becomes great.
That's also true of software design and development:
- The easier for users to do the right thing, they less likely they'll do the wrong thing.
- The more artificial bottlenecks you remove through profiling and optimization, the more apparent are actual bottlenecks.
- The fewer spurious warnings generated at compile time or run time, the easier it is to identify useful warnings.
- The faster and more effective your test suite, the more frequently you can run it.
- The fewer obstacles to getting feedback from users, the better you can design your software to meet their needs.
- The cleaner your code and better its design, the fewer nasty hacks you need to work around infelicities.
- The more expressive your language (whether in builtins or abstraction possibilities), the more precision you have available to solve specific problems.
Unlike software, many minor city improvements are obvious and immediately available. When the Park Department mows the grass in the park by my house, I can enjoy the park the same day. When they approve the budget to install automatic sprinklers, I can enjoy the improved flora within a week of installation. Not all improvements fall into this category -- but many do. (Every time I pick up a discarded wrapper and put it in the garbage can, the park is a little prettier for the next person.)
These are the kinds of little improvements that build on each other. I don't mind if I can't produce a big, earth-shaking change every time I release a new version of my software. I care that every time it's even a little bit better I can give it to users so that their software can be a little bit better and they can identify the next little thing that could be a little bit better.
Next time I'll talk about how frequent but minor improvements produce major benefits.
