Interface Driven Architecture, by Hal Helms

Notes from Hal Helm’s talk on Interface Driven at Frameworks 2007. The biggest complaint that users have with software is that it doesn’t work that way they want it to. We’re programmers not designers after all, so spending time on the interface isn’t our area of expertise. When we talk about Frank Lloyd Wright buildings we associate it with magnificent houses that he architected. We know he didn’t lay a brick of the foundation but is credited with the fabrication process. The same can be true for the software industry where the architecture is the key trait. Rather than attempting to create entire buildings by ourselves, Hal argues for the benefit of being an expert architect then letting the lower bidder (typically outsourcing) handle building the application. Great easy to understand metaphor. Putting a user in front of the interface and letting them navigate around is extremely important. Although we might know what the system needs to do, we don’t know how the users will use the software. We should instead start with the interface and iterate through the development with user feedback, making sure it behaves in a way the users want before proceeding. The uses should be engages in the software, being asked to perform some action. If users are not engaged the feedback will not be anywhere near as useful. With interface driven architecture we do all of this before worrying about the database or the model or anything like that in the back end. No matter how smart the developer is, only the client will know how the user will use the software. Hal goes into a few examples in the differences businesses use for interacting with the user. For instance, Walmart offers cheap prices and offers little to no help or support for their users within the store. Nordstroms on the other hand has a huge staff that’s helpful to the users and provides services at no additional cost to the user. Hal describes these as high touch companies . Using an example of an architect again, he describes the process for dealing with a client to learn what they want, with emphasis that the architect doesn’t trust the client; they could change at any time. Rather than asking a full set of questions outright, he asks broad questions that won’t change, such as lifestyle, whether to prepare for kids in the house or parents. He leaves out the details and sketches the house. The client comes back saying he doesn’t like stucco. The next sketch has brick instead, and is more what the client is looking for. The key here is that clients can’t tell you what they want until they see what they want. Clients get to make changes themselves and see them in the next iteration. We aren’t using our coding skills to earn our pay here, we’re using this approach and acting as an intermediary between the programmers and client. If our job is to deliver software, not to write code, it’s a matter of finding the cheapest source to outsource to.

Good companies concentrate on one thing and only one. – Hal Helms