Foundations
Software and buildings. Like any analogy I can only go so far before jumping that line into nonsense. Hopefully what I’ve written here is sufficiently handwaving without going too far back the other way to being pointless. Anyway…
With a bridge or a skyrise the physical laws such as gravity mean that for the life of the building you can’t really change the foundations. Changing the foundations generally means a new building.
Software construction is amorphous in comparison. The underlying code can be refactored and rearchitected whilst the software itself is still considered the same thing. Change the UI though, and you’ve probably got a new piece (or version) of software.
Having meetings standing-up aside, software is still often approached like bridge building. In fear of it “falling down” the architecture for the software is given utmost importance from inception right down to the code level where Christopher Alexander’s Pattern Language work has been somehow morphed into implementation guides and class diagrams.
Yet, with software it seems to me that the most physical part of the system is the user. Just like gravity will make a poorly constructed bridge fail, bad software will fail primarily with the user. Essentially, the user is the primary constraint.
Could it be argued that doing software development and not starting with the user is like building a bridge and not starting with gravity?
Thanks Pat, I love your analogy that the user is the most “physical part of the software” - the gravity.
Thought you would find this interview between Kent Beck (Extreme Programmer) & Alan Cooper (UX designer) interesting. At one point the anlogy of software development to architecture comes up & interestingly it’s Cooper arguing for the upfront user research/design/”architecture” period to make sure that there isn’t uneccassary rebuilding whereas the programmer wants to get started straight away because “programming gives you information”. It’s a long interview the excerpt below is the relevent bit:
As a programmer I can change the code and I can pay off technical debt…
It seems like the hardest thing to change is the user. I don’t think this indicates a need to do all the interaction design up front but I do think it means that understanding the user should probably be the place to start. Those of you with much more design experience than I have would probably have more to say on that.
User Centred Engineering?
Unfortunately, many programmers don’t think that way at all; in their minds the code is an ends unto itself. This is great in terms of quality control and job satisfaction, because they are passionate about making their product (the code) the best it can be (the art of code yadda yadda).
Of course, the code is merely a means to an ends. As is the user interface, the graphic design, the copywriting etc. So ultimately it all comes back to satisfying a need, which might be a user need. But this doesn’t need to be user-centred per se, as you could also argue that satisfying the user need is thus fulfilling a business goal. Either way there is a higher purpose.
This is why it’s so important that an undertaking have clear, holistic vision at the top. It’s ok for the bridge builders to place each brick perfectly, but someone needs to make sure the bridge spans the river and can be driven across (did I pass that line Patrick mentioned?).
Much of the time this is not the case. Take most big IT projects, they shouldn’t be an “IT project” at all, just because it involves technology does not make it the responsibility of the IT dept. The project should be business-driven and driven by the business. Otherwise you get the techies spinning their wheels creating beautiful junk.
Sorry, this has strayed from the original conversation a little. So to pull it back on track: yes you should understand the “gravity” before you build but also why you’re building the bridge in the first place! And appoint an overseer that is removed from the brick level construction.
A related link: Alan Cooper being interviewd on the Similarities Between Interaction Designers and Agile Programmers. There is a video with a transcript (click the little plusses to read Alan’s responses)
Of course, we don’t want an escalator to nowhere.
Coders who care about the quality of their work would be exercising thinking-in-action (if I may borrow from Dewey) and if you asked them to “build a bridge” then “spanning something” and “can be crossed” are implicit and you would get what you asked for.
Telling the same coders that they’re creating an enterprise whatsit is an entirely different story. If nobody has a clear idea of what an enterprise whatsit is then why be surprised when you get a half-working enterprise whosit instead?
If only a programmer would see what his excellent software is doing in the real world. I always invited the programmers to sit in on a usability test.
This is the best way to cure the “My program is always right” syndrome. Seeing a real person suffering on the precious work is hard for them. But it will create a better sence for future software development. Less 50 stories high building to redesign when confronted with an extra 50 stories to build.
You’re right Pat, and I would like to work with such coders :)
A related link: Alan Cooper being interviewd on the <a href=”http://www.infoq.com/interviews/Interaction-Design-Alan-Cooper;jsessionid=444207C9CF4244422BA8738702B2E28A#” rel=”nofollow”>Similarities Between Interaction Designers and Agile Programmers</a>. There is a video with a transcript (click the little plusses to read Alan’s responses)