Beta

Cities as Software

Betaville · An open-source multiplayer environment for real cities · BxmC (2010)
[ source ]

Undoubtedly, the city is always in beta. The miscibility of concepts in urban planning and software development has been evident for several decades. This interchange is most pronounced in Christopher Alexander’s A Pattern Language, an unwitting boundary object of a book that resonated with the nascent object-oriented software community of the 1980s – ‘smalltalkers’ looking for new means of building modular systems.

In an age of ubicomp and real-time civic information we can only expect this mingling of paradigms to intensify. There is a feeling that the tangled history of these two fields — peaking in the systems planning heyday of the sixties, with the proliferation of cybernetic control rooms and the chimeric utopia of a perfectly ‘balanced’ social order — is set to enter a new phase in which they assume a more complex relationship.

Let us define software development as a process of structured systems design focused on minimising a range of costs – namely development, maintenance, growth and usability.

Urban planning is inextricably bound to similar costs – constructing, maintaining, using and growing the city are the chief costs to planners and citizens.

A range of strategies are used in software development to minimise these costs, from principles like orthogonality and compactness, to decoupling and cohesion, modularity and scope-creep, to methodologies like use cases and A/B testing. Importantly, any tendency to create a monolithic plan (see: Mega, Beautification) is countered by these principles.

What would an urban scale A/B test look like? I don’t think I’ve ever seen one in action. I’d like to be able to sign up as a TfL beta tester though.

Some of these software principles are borrowed from the broader field of systems design and already pervade the design of cities. Take for instance decoupling, a guiding principle in multi-modal transport networks – improving resilience, fault tolerance and reducing maintenance. From the small scale (the parts in a train) to the urban scale (the design of entire networks), this is an engineering principle which shapes our environment.

Design Patterns · Analogy in reverse: Christopher Alexander’s town planning book (left) had a direct influence on design patterns in Object-Oriented software, most notably the ‘Gang of Four’ book (right).
[ source ]

As networked citizens, we all have a legitimate claim to act as designers and developers of our urban realm. Whilst there is general agreement that modern planning tools need to scale for inclusivity, it’s not clear what best practices are required to aid consensus-driven planning to deliver. As such, there is an increasing interest in software development methodologies as urban planning goes collaborative.

Agile methodologies haven’t infiltrated urban planning, a discipline which contains projects of the requisite scope and complexity. Agile software practitioners have understood that projects of this nature demand an incremental, test-driven methodology for cost minimisation.

Iterative and collaborative design are complementary, as at each increment various stakeholders (read: residents, council members) are consulted. These methods do not map easily to the policy maze and institutional hierarchies that currently make up the apparatus of urban planning.

Betaville introduces the concept of version history via a wiki-like interface, but other methodologies worth exploring in planning are decentralised version control (ie. Git) for more complex read/write planning systems, and REST API design for public urban resources.

Cities are highly non-deterministic social systems. At most scales and resolutions, a city is orders of magnitude more complex than any software to date. Any branch of systems design is only applicable within severe limits. Attempts to ‘control’ the organic mechanisms of society seem anachronistic in the same way any attempt to control the whole of the web seems absurd: Because we have a new found appreciation for self-organised order. This shift in planning towards the stimulation of forms of activity that benefit long-term goals (densification, mixed-use zones, public transport uptake etc), rather than prescriptive practices is already widespread.

Perhaps though, software development has something substantial to offer the design of the urban realm in a network society: An appreciation of modes of networked group cooperation in the service of a complex functioning whole.

Issue tracking, infrastructural A/B tests, more accessible public changelogs, comprehensive APIs, and shorter, more inclusive iterations might be logical next steps for cities looking to lead the way towards more participative planning practices.

See Also: Mega, Data, Cybernetics, Instant City, Beautification, Civic, Publics

Continue reading »

Oyster

Oyster Flowprint · Visualisation of trips using London’s RFID Oyster Card on the London Underground network · Anil Bawa-Cavia (2010)
[ source ]

This Oyster flowprint visualises trips made using London’s RFID transport card on the London Underground on a typical weekday. Each trail is an individual passenger making a trip, tapping their card at an origin and destination. The actual routes taken are inferred using a simple shortest path algorithm. The animation uses a 5% sample of passengers on the network made available as a Transport for London Data Feed.

Activity on the network is charted along the bottom of the graphic. The double-humped dynamics typical of commuting are evident, and these constitute the characteristic signature of the living city. Twice a day the flowprint expands and contracts, sending its tendrils deep into North London; the diurnal ‘pulse’ of the city in action.

Synchronisation of travel during the morning rush hour, with a steep ramp in activity peaking at 8:40AM, is much greater than during the afternoon, which sees a much broader peak in activity, with people leaving work at a range of times. The afternoon rush hour doesn’t subside until after 7pm, evidence perhaps of Londoner’s love of an after-work pint.

See Also: Flowprint, Boris, PRT, Network, QR, Data, Real Time, Isochronic

Continue reading »