Last post in the six part series on Stuart Brand 1998 BBC documentary about architectural design. In this final episode Brand examines the differing rates of change applied to the: site, structure, skin, services, space plan, and stuff of any building. The insight Brand offers could apply to any long lived construction where people interact. I can think of several enterprise applications I’ve known where remarkable metamorphosis has taken place over the years. Maybe one day the journey taken by Google, Ebay or Facebook will be documented in a similar way; though perhaps we need a hundred years or more for that to be truly fascinating.

• Part 1
• Part 2
• Part 3
• Part 4
• Part 5
• Part 6

The penultimate part of Stuart Brands 1997 six part series for the BBC documenting buildings and the way they behave over time. Many Amazon reviewers of the accompanying book note the parallels with many aspects of software or system design which is my reason for including it here. Part five deals with maintenance and decay – unquestionably also a software problem. The solutions for buildings is not the same for software but the concepts are; and Brands commentary is as interesting as ever.

• Part 1
• Part 2
• Part 3
• Part 4
• Part 5
• Part 6

Part four of the six part “How Buildings Learn” BBC series. Concentrating on urban planning this episode felt less relevant to software than some of the others. I still found it interesting and found myself comparing Brands point of view to certain kinds of Enterprise Architecture I’ve encountered. I’d love to know what you think about the series; if you have time please leave me a comment.

• Part 1
• Part 2
• Part 3
• Part 4
• Part 5
• Part 6

Adopting software change right from the start of the software development lifecycle is the chief reason the agile movement came about. In the third of the six part BBC TV series entitled “How Buildings Learn” first screen in 1998, Stuart Brand why building for change has been such an important ingredient of successful architecture over the long term.

The software road is gridlocked with balls of mud that failed to adapt to change fast enough to survive. While this is a fascinating documentary about architecture; Brand describes a design perspective with a far broader appeal.

• Part 1
• Part 2
• Part 3
• Part 4
• Part 5
• Part 6

Part two of Stuart Brands six part BBC series (and book) entitled “How Buildings Learn” points out how cheap “low road” buildings house creative people all over the world. They attract creative inhabitants purely because they are cheap and adaptable. Brand offers an alternate view of modern architecture that can be applied to other fields of design including software.

Modularity, extensibility and rich integration API’s and all desirable software traits. They provide an answer to adaptability and change in modern software applications. On the other hand “Low Road” to me has a more subtle meaning surrounding individual technology. It feels analogous to intermediate technology as used in developing countries or the related to the reason REST is gaining traction over SOAP outside the enterprise. Low Road technology to me should be easily grasped and accessible with common tools and understanding; in the same way when applied to buildings the construction techniques are largely low tech. and traditional. Parts three to six will follow in upcoming posts.

• Part 1
• Part 2
• Part 3
• Part 4
• Part 5
• Part 6

Can buildings teach us anything about software development? They’ve been around a lot longer, they come in every shape and size, and some last longer than others. All traits shared by software. Stuart Brand wrote a book and TV series called “How Building Learn”. Whatever you think of his observations they make excellent viewing for any student of design. Software or otherwise.

The six part series, screened by the BBC in 1998, documents Brands basic thesis – successful buildings that survive over time are built for change. Christopher Alexander, the inspiration behind the modern-day Software Design Patterns movement, features in several episodes expressing his unconventional views and approach to architecture.

Stuart Brand seems to have time on his mind a lot; he is a founder of the Long Now Foundation and a past TED speaker on the subject.

Drawing analogies between civil engineering and software development is popular; but should be treated with caution. Its natural and fun however. I’ll make subsequent posts about the other five episodes. Enjoy.

• Part 1
• Part 2
• Part 3
• Part 4
• Part 5
• Part 6

I recently wrote about the list of design principles I’d compiled. The observation and point I tried to make was the absence of inspirational design values within the software industry.

Software products are a big part of our industry so why should we not take inspiration from mainstream product design.

My nomination is Dieter Rams the German born industrial designer famous for his work with the Braun in the 60′s and 70′s and the Vitsoe shelving system. He has been sighted many times as an influence for Jonathan Ive of Apple fame and is notable for his Ten Principle of Good Design listed below. For those wishing to become true disciples a poster, fit for the trendiest design office is available.

Dieter Rams – 10 Principles of Good Design

Good Design is Innovative

The possibilities for innovation are not, by any means, exhausted. Technological development is always offering new opportunities for innovative design. But innovative design always develops in tandem with innovative technology, and can never be an end in itself

Good design makes a product useful.

A product is bought to be used. It has to satisfy certain criteria, not only functional, but also psychological and aesthetic. Good design emphasises the usefulness of a product whilst disregarding anything that could possibly detract from it.

Good design is aesthetic.

The aesthetic quality of a product is integral to its usefulness because products we use every day affect our person and our well-being. But only well-executed objects can be beautiful.

Good design makes a product understandable.

It clarifies the product’s structure. Better still, it can make the product talk. At best, it is self-explanatory.

Good design is unobtrusive.

Products fulfilling a purpose are like tools. They are neither decorative objects nor works of art. Their design should therefore be both neutral and restrained, to leave room for the user’s self-expression.

Good design is honest.

It does not make a product more innovative, powerful or valuable than it really is. It does not attempt to manipulate the consumer with promises that cannot be kept.

Good design is long-lasting.

It avoids being fashionable and therefore never appears antiquated. Unlike fashionable design, it lasts many years – even in today’s throwaway society.

Good design is thorough down to the last detail.

Nothing must be arbitrary or left to chance. Care and accuracy in the design process show respect towards the consumer.

Good design is environmentally friendly.

Design makes an important contribution to the preservation of the environment. It conserves resources and minimises physical and visual pollution throughout the lifecycle of the product.

Good design is as little design as possible.

Less, but better; because it concentrates on the essential aspects, and the products are not burdened with non-essentials.

I’ve read a lot of software development books over the years, many of them dealing specifically with software design. As part of writing something else, I recently had cause to compile a list of some of the design principles published within them. In doing so I realised just how many principles and guidelines are out there competing for the attention of developers.

Here’s my list:

General Guidance

1. GRASP
2. SOLID
3. Law of Demeter
4. Pragmatic Programmers Tips
5. Design Patterns
6. Anti-patterns
7. Unix Programming Notes
8. Algorithms in General
9. Coding Standards in General
10. Domain-driven design
11. Architectural patterns
12. Principles of User Interface Design
13. Bruce Tognazzini’s First Principles of Interaction Design
14. The Agile Manifesto
15. Lean Software Principles
16. Peter Principle
17. Principle of Least Astonishment
18. Richard Gabriel’s Worse is Better

Vendor Specific Guidance

1. Windows User Experience Design Principles
2. Design Principles for Windows 7
3. IBM Design principles
4. Google’s Ten Design Principles

This is NOT a definitive list  I very quickly gave up any aspiration to that effect. By all means post any further suggestions.

The observation I made however, when compiling the list, was how the majority of the principles and guidelines are either mostly or completely focused on engineering. They seem to vaguely form a topless pyramid with the base providing the most directly prescriptive help and those above more general guidelines of a more theoretical nature.

The topless nature of the pyramid indicating that the software industry seems devoid of apparitional guidelines of highest order. Principles more concerned with the product nature of software applications and how we connect to them. In part two of this post I’ll make my suggestion.