Twenty Things about Software Design
I've been thinking a lot about previous jobs and about the interaction design class I'm putting together. These are a few conclusions I've reached over the past few years, from working on different products in different domains at altogether too many companies: Here are Twenty Things I Think about Software Design.
Post Perma-Link |
3 Comments:
Interesting comments, and I have a few replies.
You shift back and forth between talking about software design and talking about UI design. While clearly the training for these two activities is different, do you believe that people with a capacity for one have the capacity for the other?
I haven't done much UI design. I've heard people say that the best designs are done with pretty much no coding -- all of the decisions should be made on paper design or simple mock-ups. How do you feel about that?
On the other hand, lots of software turns out best when the design and coding goes on in a spiral or waterfall or whatever -- have a rough design, start coding and see what works and what doesn't. "Being brave" means, often, coding in the face of no design. This is the XP way to many people. Does it have any place in UI design?
More on the above. A good code development environment supports "being brave" -- If I can refactor code, move it into new utility packages, split and join classes, inline and outline code, and undo each of those easily if I don't like how it works, I can experiment with hundreds of design choices while coding. Perhaps that is why designing and coding at the same time works well. Are the tools for UI design equally fluid? Does it matter?
Point 6: I went to PhD school with someone who had a masters in music composition. He said that for him, coding and music composition are not annologous, they are the exact same thing, using the exact same part of his brain. "You have to understand how the music flows, what the overall shape of the piece is, when themes are repeated and what parts of the orchestra are going to be carrying what feelings. And in the end, you have to sit doown and put every single note and rest on a piece of paper." His observation is the best way I have ever found to tell non-technical people what it is that I do. And so to your point 7: If it people don't like how it sounds, they're right.
It's interresting to me that music composition is often a solitary practice, while software rarely is. Groups of musicians jam and produce, often, beautiful work that doesn't get written down. I would be interested to know more about those instances when music is composed in collaboration, rather than, say, discovered. Perhaps this spirit of jamming is part of what XP is trying to bring in to programming.
Point 10: Sometimes, while hacking in the middle of the night, an engineer discovers a great way to improve the planned implementation, and the consensus design is at risk. Your test of a good process, of good team players, and probably of good design is how this gets addressed.
Point 11: Wasting Time on Foolishness (such as, filing bugs on implementation not to spec) Wait a sec -- the spec is a living document. If some part of the implementation isn't to spec, there's a bug in one or the other, and it needs to be fixed, doesn't it? If you don't file a bug, how do you keep track of places where the spec and implementation differ? What's the process?
Point 18: What does cogent thoughtful response look like? Often with software, I offer and hear nothing more coherent than "I like design A better than design B". People I respect tend to agree, so good people liking is a good sign, but even good people can't articulate what they like or don't about a design. This can be learned. What is a good vocabulary for comparing designs, both in UI and code?
Thanks for the twenty things!
Hey Barry,
Great comments. I wish this silly comment form were bigger, and I bet you did too.
Yeah, I did mix software design and UI design, because they do shade into each other, and sometimes one person does both. There are still some things that are the same and some things that are different. It was easier to make it mixed than to qualify everything. I agree it got confused in places.
Paper mockups: Yeah, most UI design is done as abstract screen designs before you start building, because this is just more efficient. This is true with most coding too, in any big project. You want to start with a design and then build it after you're sure it supports all the tasks you're trying to support. It's one of those aspects of design that definitely cuts across many design domains -- plan it before you construct it.
As for the XP/iterative method: yeah, I do believe in iteration and iterative design/development. I personally want to work with prototypes as soon as possible, but this is usually a schedule issue. There's some complex tradeoff function that is determined by how "good" the prototype is at being dirty and modifiable, how flexible the programmers are, and how closely the design(ers) is/are tied into iterations on the prototype -- and there's another function for the process that involves lots of up front design validation with paper and screen mockups before building what you're pretty sure is going to have to be IT, modulo small tweaks on small details. That second design process is more traditional UI/waterfall inspired, despite the big talk about it being iterative (in practice, you don't get to scrap and start over in that model).
IMO, "important" or new domain products, products with high uncertainty attached and big risk should take the first path of design -- do the iteration stages with working prototypes and get it really right -- rather than the more traditional paper design followed by immediate commitment to a single direction.
Yep on the good development environment and "being brave" -- the best UI coders are working like that, and it's easier to make bigger changes. The ones who aren't are blocking the design effort, and sometimes it's just not their fault. I work in an environment with some fairly iffy tools, and I bleed for them sometimes; but the products also suffer as a result of what we can't do easily. This is probably point 21, which I can't believe I left out: Good GUI tools are critical to good design process.
You're also right about the Great Way to Improve things that came in the middle of the night. Of course, I don't consider that a challenge to the design process, I consider it a plus of a good team :-) I had one of these recently, and it made my week.
Point 11 and spec bugs: Of course you're right! But if there's a tremendous amount of deviation from spec, and a lot of time wasted on chasing that down or making someone conform, it's silliness. A certain amount is necessary and healthy. To the degree that the spec doesn't stay up to date, the communal understanding of what we did and how we did it is risked. It's also extremely normal for the design to change during development -- but if the designer isn't involved or aware, when it's something big that's at issue, then things are Broken. My Adobe team suffered from this daily.
Point 18: could take another essay, but it's one reason I suggest hiring requires multiple people to review design work, which reduces the difficulty of being sure of the design skills of the interviewee.
I especially like #19: "Good design is an emergent property of good teams." That's always been my experience.
PS: There is also a good discussion of current design approaches at O'Reilly Radar, on the theme of "designing from the outside in." (In case you haven't seen it.)
http://radar.oreilly.com/archives/2005/04/designing_from.html
Post a Comment
<< Home