Design & Functionality

Enterprise web applications typically favour functionality over design. Traditionally it’s functionality that wins bids particularly when the software is judged by the amount of checkboxes ticked on a tender document.

What is the cost of ignoring good design? Whilst managers may be satisfied that the chosen software can do what is needed his users may get frustrated with with time wasting user interfaces. This can make a big difference to their working lives, their health, happiness and general attitude to the organisation. The hidden cost of this moral sapping software can be vast.

Things are changing with our customers. Design seems to be making a come back. How can we satisfy the desire for design and functionality and still keep up with our competitors?

1. By getting closer to our customer we understand how our products are used and the pain points they encounter. We can spend time improving the design of these specific areas
2. By understanding our customer we understand what functionality is really needed, debunking many of our assumpotions. Reducing the time spent on redundant functionality gives us more time for good design
3. Incredible new technologies such as jquery allow us to include features such as drag and drop and speed up development of more sophisticated user interfaces

What is so great about open source software?

1. The developers who write it are passionate about solving the problem because its generally a problem for them.
2. It requires creativity to solve a problem in the limited time available. This leads to innovative design.
3. The software tends to be focused on solving one problem really well, not being all things to all men.
4. With no marketing budget the software needs to speak for itself
5. The developer is completely free to do things the right way not the quick way
6. Pier pressure keeps coding standards way higher than you would normally expect
7. It has really cool names like Git and Gimp!

You talk he smells

I’ve been watching Sketches of Frank Gehry. If you’ve not heard of him, Gehry is an architect who creates really radical buildings such as the titanium covered Guggenheim Museum in Bilbao above. His creative process appears to start with sketches followed by models created in cardboard that get refined and refined until he is happy. It seems similar to creating 3d prototypes in software development as opposed to 2D specifications in documents. Interestingly Gehry is renowned for his projects coming in on budget. I wonder if this is because the reality of the design  and its problems are ironed out in the prototype rather than during the building’s construction.

When asked how Gehry works with his clients a client said “You talk he smells”. I like this as an idea for a way to gather requirements. Rather than ask the product owner directly what they want (when they really don’t know) its best to just talk and “sniff” out the requirements.

A Pattern Language

Scrum has its origins in Organizational Patterns of Agile Software Development which has in turn has its origins in A Pattern Language by Christopher Alexander. A Pattern Language is full of patterns about towns, buildings and construction. In the towns section one pattern really stands out to a Scrummaster and must surely have been an influence in Scrum.

“80 Self-Governing Workshops and Offices” states “A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole. He can only understand the whole and be responsible for the whole when the work which happens in society, all of it, is undertaken by people small self-governing groups; groups small enough to give people understanding through face-to-face contact, and autonomous enough to let the workers themselves govern their own affairs” page 399.

Craftsmanship

Over the weekend I read an article about craftsmanship written by Richard Sennett. He makes the point that true craftsmanship is about collaboration not competition and that modern teaching methods do not recognise this. In the days of guilds of master craftsman apprentices would spend years learning by osmosis. Perhaps the learning we experience in a Scrum is not that different to the way stone masons learnt their trade hundreds of years ago. After all many of the best developers do not have computer science degrees and learn through the huge swathes of information available on the Internet and from their peers. Could agile with its focus on high quality and design be turning  developers  into modern day craftsman?