Here at digital urban, we are enthused to announce that the first episode of The Global Lab podcast from CASA is now available on iTunes.

The Global Lab is a podcast about cities, global connectivity and the…

Cities as Software

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.

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

Cities as Software

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.

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

Prompted by the final space shuttle launch of Atlantis, I thought I would have another look at two line elements (TLEs). These are coded lines of data that describe the orbital dynamics of a space vehicle. The last time I looked at this was when I was working on a GPS tracking project and we wanted […]