DesignDelta.com

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 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.

I mentioned in a previous post I like to capture the audio for certain events, like training, when delivered by an industry expert. They’re always well practiced and concise communicators. They’re evangelism pitch worth studying.

Selling ideas and influencing people is an important part of any design role. I’ve found it very useful to refer back to voice recordings I’ve made when I’m trying to find the best way to communicate a concept.

It took me a few tries before hitting on the simplest, no effort, way to capture high quality audio in a typical training room environment so I thought it worth sharing here.

My requirements were that, it be simple, low hassle, good quality and discreet. By discreet I don’t mean secret. It’s polite and desirable to get permission. What I mean by discreet, is not looking like an outside broadcast team. No mike stands, no mixing boxes and minimal cables.

My journey evolved thus:

First Attempt – Use My Laptop

Logic would say this must work – surly? You can certainly make it work but, it’s not effortless. It’s not a primary use case right! The first problem is the microphone (the built in one). Its small, cheap, pointing the wrong way and if your typing while you’re listening the clicking will drive you mad later. Forget it. I tried several external microphones, the best of which came with a fairly high end Sony tape recorder. Things improved, but not acceptably. The recommended route at this point is an external sound interface and a decent quality microphone. A sound interface is a combined external sound card and microphone pre amplifier and plugs in via your USB port. I never got that far. I baulked at spending money on more hardware as I had other driver based issues. Admittedly I was using Vista on a Sony laptop at the time but the intermittent unreliability just defeated me. I’ve no idea why this would be so, just one minute it worked the next it didn’t. Since I tried all this, reasonably priced, good quality USB microphones have appeared. This may help since microphone quality is key.

If you’re determined to use a laptop windows comes with its own sound recorder. Audacity however is the de-facto open source application and has far more functionality. The nail in the coffin for using your laptop comes with battery life. If you can guarantee you’ll be sat next to a power outlet fine. I couldn’t.

To summarise; using your laptop is viable if you buy some hardware, don’t mind the cables, can guarantee power and are careful with your software settings. For my requirements there was just too much to go wrong.

Second Attempt – Use My Phone

Now I come to write this I don’t know why I ever thought using a phone might work. For taking short dictations fine. For semi serious sound recording don’t waste your time. All the problems stated for laptops are more apparent to phones. The main points being the microphone just isn’t up to it and battery will be flat in no time. I did experiment with some downloaded Smartphone recording applications (I was using Windows Mobile) but they we’re all unreliable. Forget it.

Third Attempt – Use a Dedicated Device

The remaining option is a stand-alone solid state recording device. No cable clutter, no device drivers and no software to learn. The marketplace starts with voice note taking recorders as used by doctors and architects then rises smoothly to top end, multi channel, solid state sound studios. The transition from dictation machine to entry level sound recorder happens with two machines being repeatedly recommended. The Edirol R-09HR or the Zoom H2. I chose the Zoom as it was the cheaper. It has performed superbly.

It came with a small table stand and an interview style handle, both of which screws into the base. Standing the unit on my desk it pick up everything, including questions from the delegates, very clearly. It is very easy to use and when plugged into a laptop via a USB cable appears as a storage device making downloads effortless. The display could be lager and proper buttons would be nice but those are minor points. The only slight issue I had was battery life. I managed about seven hours recording time on a set of batteries. Just make sure you’ve got some spares.

In December I did some training and I’m now a badge holding Certified SCRUM Master. Would I recommend it – yes. After spending the past four years within a large SCRUM department, I felt I had a good understanding of it. I did. However the experience with Mike Cohn, a true master of all things SCRUM, was still enlightening and very worthwhile. If you get the chance I strongly recommend it. Listening to the other delegates discussing war stories was an education in its self and everyone went home with proper planning poker cards – very professional.

In recent years my strategy for professional development has been to solidly pursue the trainer not the training company. It’s a strategy I strongly recommend. In 2008 I travelled to Sweden for a week’s Domain Driven Design immersion with Eric Evans. I’d read his book twice before but still came home re-evaluating what I thought I knew. Talking face to face with a true thought leader is so valuable.

The other thing I did prior to my SCRUM Master week was invest in a way to record the classroom sessions for my personal re-consumption. I’ve found, from experience, once back in the office finding the best way to communicate certain concepts can be challenging. Being able to revisit the ‘pitch’ surrounding a particular topic, as delivered by an expert advocate, is very useful. Finding the best way to make this type of recording took a little evolution and is something I intend to cover soon.