What does Simplicity mean when it comes to software?

Our geek bookclub at Talis has been reading 37Signals Getting Real. It’s interesting text that contains for the most part a common sense advice with which we as a group can relate to. But one of the things thats been grating on my mind for a while now is the notion that simplicity sells, and by simplicity im referring to a lack of features. Unfortunatly whilst I was drafting this entry Joel got there first 😉 ( LiveWriter is excellent for offline editing of blog entries, unfortunatly it doesnt stop you getting pipped to the post!)

Anyway its well worth reading Joel’s post, I think hes absolutely right in pointing out that a lack of features isnt what made the iPod or BaseCamp such a success but the fact that amongst other attributes both these products were built to correspond to a user model that resulted in a high degree of usability. To my mind the problem we face in this industry is that in order to build useable systems we need to accept that we can only do that by understanding the users mental model, we can no longer afford to build software solutions as simply the delivery of a set of discrete requirements and leave usability as something we can bolt on at the end when we’ve got the rest of the system working. We have to understand our users and put them first.

Programmers are generally bad at user interface design?

Was intrigued when I read James O’ Coplien latest blog entry: The interface is the Program, and it ain’t Agile. Coplien discusses, quite correctly I believe, the fact that historically developers have tended to be very bad at building good user interfaces. Coplien discusses this in the context of Agile development groups and how usability is rarely captured as a story because stories in themselves are generally short-term goals that you want to achieve in the space of an iteration or even a sprint. Therefore because Agile teams are rapidly making changes to their application its hard to be able to do the focussed studies and analysis that is required in order to gain an understanding of how useable the application your building is. Fundementally programmers are not User Interface designers – Coplien attributes this to several reasons, which include the fact that university courses on software engineering have often done little more than pay lip service to HCI or User Interface Design, its often a topic that undergraduates are only ever given the most basic of introductions to.

I want to expand a little on what Coplien has covered so well …

I’ve been fortunate enough to have worked closely with Alan Dix and Russell Beale, the authors of Human Computer Interaction. I do class myself as a developer but I have had a strong interest in HCI, and user interface design and its an area I’ve been interested in and reading around for the best part of a decade. In that time I’ve often had to work in teams where its apparent that other developers dont either understand the need for HCI, or even how to begin to think about it.

In my own experience this comes from the fact that programmers tend to focus on the mechanics of building an interface, getting the right framework, and then designing around the limitations of the toolset they have picked. Invariably they tend to spend tonnes of time just focusing on getting the UI to work and this UI is designed from the perspective of satisfying the flows defined in requirements documents or design docs like Use Cases. You can contrast this with people trying to use the user interface, who dont care how it was built, or what the limitations in the underlying technologies were, these people just want something they can use. To me its this emphasis that seperates a working interface from a “good” user interface. Good User Interface are designed around the user, unfortunatly most user interfaces tend to be designed around building something that satisfies a series of discrete requirements.

I dont think it’s fair to simply say that programmers arent capable and can’t do good UI design, the truth is that on most software projects, and in most teams, it just isnt their emphasis.

In order to improve things developers need to be taught the importance of user interface design. Our development group at Talis is a great example of this. As a team we know we need get better at understanding how to build user interfaces. One of the activities we undertook recently was to get everyone to read Spolsky’s User Interface Design for Programmers as part of our geek book club. It’s an excellent text that introduces programmers to key concepts in user interface design.

However as more and more applications are being delivered over the web developers should take the time to read Jakob Nielsen’s seminal text Designing Web Usability – The practice of Simplicity. Bruce Tognazzini’s TOG on Interface, might be a little dated but its still an incredibly good text and has a great section on conceptual models.

Most importantly though: one of the things our group has realised is that User Interface Design and User Interaction Design are specialised skills, and whilst its important that developers should be encouraged to learn more about this area, its vitally important that organisations recruit people with these specialised skills into their teams. To that end Talis is openly recruiting for individuals who specialise in HCI/User Interface Design, so if you think you fit the bill and its an area your passionate about, and you’d like to work for an organisation that takes this very seriously then check out the job spec here and send your CV along with a covering letter to team.talent@talis.com.

Providing estimates for building software

James Shore is currently working on his book – The Art of Agile Development. For a while now Shore has been posting up pre-publication review chapters from this upcoming book. The latest section up for review covers the topic of Estimation, and its well worth reading.

This chapter really resonates with me since parts of it pretty much describe the approach to estimation we follow in our development group at Talis. We estimate how much effort it would take to complete indiviual stories. Our iterations last a week. At the beginning of each week we total up our velocity for the previous week, for example 16, and then select 16 units worth of work for the coming iteration. If we repeatedly hit our target over the course of a couple of iterations then as a group we might pick more than our velocity for the following iteration. All the members of the development team take participate in the estimation, this ensures that everyone is “bought-into” the plan. This approach leads to better communication and can help clarify requirements it also engenders greater trust within the team.

Gordon Ramsay could teach software engineers a thing or two?

Rob and I took a coffee break from refactoring some code yesterday and he asked me if I had watched Ramsay’s Kitchen Nightmares the night before, which I had! We commented on how formulaic the show is – each episode Ramsay turns up at the door of an ailing restaurant, and helps get them back on track and making money by empowering and motivating the cooks, using fresh ingredients, coming up with a simple less complicated menu, keeping management out of the kitchen and in the front where they belong, and above all putting the customer first!! Rob then said something along the lines of “You know when you think about it its not too different to the problems that many other software engineering firms face“. That’s when the penny dropped …

As a metaphor this should sound familiar to anyone working on a large ( even not so large ) software project. Your coders are the equivalent of your kitchen brigade, guys and girls who have to deliver, without them you cant serve anything to your customers. Your ingredients are API’s, frameworks, and technologies. Your complicated menu’s are over analysed, over designed, and over complicated software architectures; and lets not forget your restaurant managers are the same as your project managers, who generally know sod all about writing code, they promise your customers everything under the sun, generally work their brigade to death to deliver to unrealistic time frames and have a penchant for blaming the coders when it all goes tits up!

Worst of all the customer rarely gets what he or she actually ordered, because so many software company’s still persist on following dated project management and development methodologies trying to gather requirements up front, do exhaustive analysis and design then coding, and finally delivering a system 12 months later to a customer who’s requirements have now changed.

Did I sound bitter then? It’s probably because I realise that I’ve spent the better part of a decade working for the kinds of software companies where this kind of thing is considered the norm. Sadly for many company’s it still is the norm!

So lets apply the Ramsay formula to this. How do you turn teams that are building software in the manner above around?

Firstly, you have to empower your brigade. In the past I’ve worked in places where the job of most developers is simply to “fill-in-the-blanks”… in other words just implement method stubs that are generated by a design tool that the architects use. This creates hierarchical divisions within teams, and is generally extremely de-motivating. Like a cook who has given up using his imagination, has no passion, and has given up thinking creatively and has been reduced to doing little more than reheating pre-cooked frozen hash.

In order to empower the team, they need to OWN the code collectively. It doesn’t belong to one person, it belongs to everyone. As a team they’re passionate about it. You have to be break people out of the traditional thinking that I wrote this class so people have to check with me if they want to change it!

We need “fresh” ingredients. Yes we should re-use software but only if its appropriate. How many times have you worked on software projects where the architecture isn’t based on whether its the right technology or tool for the job, but is based on other factors like the company you work for has a cool licensing agreement with a vendor and wants to use their technology because they don’t have to fork out for something more appropriate? This, using a square-peg to fill a round hole approach, in variably leads to difficulties.

Have “simpler menus”! We need to get rid of up-front complicated over-architected designs, and over analysing solutions – which are a product of old-style waterfall approaches. Teams need to be moving towards iterative, agile development methodologies. These processes engage the customers who are able to provide feedback on the product at the end of each iteration so this approach to developing software encourages customers to change their requirements if and when they want to which means that when you finally deliver … your actually giving them what they want! And this squarely puts the customer first!

Keep management out of the kitchen. If your the kind of organisation willing to invest in bringing a smart bunch of technical people together, then trust them to do their job. They don’t need project managers standing over their shoulders asking them for an hourly update on their progress. This kind of Orwellian micro-management is culturally ingrained into some large software companies and in my opinion it is very, very damaging. It fosters resentment, encourages bullying and totally de-motivates developers because of the perpetual monkey on their backs!

I am so glad im not working for an organisation that suffers from these problems, and perhaps if you are then maybe you should consider a change?

Buildix – KNOPPIX Based Linux Distro

Heard about this on a Google tech talk, its a linux distro distributed as an rpm or VM ( which I have downloaded ), it provides a pre configured install of CruiseControl, Trac and Subversion …

Martin Fowler mentions it on his site, obviously hes recommending it because of his involvement with thoughtworks. Nevertheless its a great idea, based around shortening iteration zero.

There’s a good blog by one of the “authors” describing why they made this, which is well worth reading.

I’ve found it easy to use and configure and it gives a great head start to project teams trying to get continuous integration environments set up.