I think the knee-jerk reaction is because it feels like unit testing is getting singled out. Some people are tired of defending unit tests as a useful thing. All you need is one article saying that unit tests are not important (we all SHOULD know they’re not the most important) and we go back to write some code and throw it over the wall to QA.
I think Jeff could have listed tons of things that are less important than having a usable product. Separation of concerns, source control, backups, lots of monitors, a nifty keyboard, encryption, etc. They’re all important, but don’t bring money to the coffers quite as directly as having a good usable product. I, for one, have never been near a shop that obsessed about unit testing as much as say - which version control system to use.
I think the point Alan Cooper’s trying to make is that, essentially, those interaction designers are being marginalized when they’re dealing primarily with the developers during implementation.
Success means you’re thinking about this stuff before the product exists: think Jobs and Ives.
I have respect for agile methods, but it appears that the most well-designed products had the most effort put into their design before coding begins. Who’d have thunk?
In the majority of products, though, you’re not going to have the level of detail in the spec that excellence demands (pity–but that’s life). Because of this, it’ll still be necessary for the designer to be extremely accessible to the developer for the myriad of tiny decisions that always come up.
Unit testing tends to be black and white: f(3,4) == 5. It either passes or fails. Simple for a coder to understand, implement, and produce a report of results.
UAT / user interaction design tends to be more complicated, harder to put your finger on, given to personal preference and irrational debates. The kinds of troubles many programmers feel they already have enough of and not difficult to see why it’s commonly avoided…
This is exactly why presentation should be separated from implementation. UIL with Motif is great for this, because in many cases you don’t even have to recompile the application when GUI changes are made. Let the Software Engineers do their work on the implementation, and let the GUI and usability experts and “interaction designers” do their thing on the GUI.
I agree with the faction that says this post is off-target, in that User Interaction is generally not in the typical programmer’s purview - most of us write the server code behind the app, and there is different group responsible for the UI.
That said, I point to the management as the primary problem - they decide to skimp on UI design, tell the UI developers to slap up some screens, and think that the app is done (This applies to commercial software, mainly - OSS guys, developers are the mgmt).
I work in QA, but this looks like apples and oranges to me. Both kinds of testing are critical. UAT and Unit tests. To that I’d add the ones that most developers hate, integration testing via the GUI.
[Begin off topic rant]
Yeah, integration testing is messy, and difficult to understand, difficult to automate and high-maintenance if you don’t know what you’re doing (I’d say over 90% of companies don’t). Moreover, the results are often difficult to untangle.
The only problem is, that, after human testing, most of our bugs are found after the code is integrated and tested with a GUI-based automated testing system. Oops!
Some developers think you can fix all bugs with unit tests and “integration” testing consisting of basic unit tests. Good luck with that. I don’t know any experienced QA professionals who believe this. I certainly don’t.
I should admit I myself sometimes “marshal the solution to the problems”. I need to pay more respect to users/business analysts.
However I don’t think this has too much to do with unit test or code coverage. Actually if I replaced “unit test” with “refactoring” or “code review” in your post, it would still make sense. Don’t you think?
I think I got your idea. Just the keyword “unit test” may be too sensitive.
You should check out Harold Thimbleby’s book “Press On: Principles of Interaction Programming.” He makes the case that programmers can play an important role in the usability of a product. He says that it’s not enough to just polish the user-facing features – for a truly usable product, you also need make sure you get the engineering right.
Again, an apples oranges dichotomy; those are far too common on Jeff’s blog and are starting to chip at his credibility.
Great interfaces will make the product easy to use, good testing will maintain the functional stability that supports that usability. Why these two ideas that are so different and involve different skills and personnel are even contrasted is just beyond me.
Please Jeff, if two ideas are not mutually exclusive, could you not draw them up into a mutually-exclusive conditional statement ? That’s not only a basic tenet of programming, it’s also a fundamental element of proper argumentation.
I gave my wife your recommended reading list as part of my Christmas list and she was kind enough to get me “The Inmates are Running the Asylum.” It was my first introduction to Alan Cooper and completely changed my perspective on how I do my job as a software engineer and de facto designer (but not a very good one). Thanks for the recommendation.
I think it’s a mistake to portray software engineers as resistant to good interaction design. We all want our hard work to get used. The trouble with interaction design is that it requires the organization as a whole, especially including upper management, to have some clue about good software engineering practices. Good interaction design is a higher order activity which depends on requirements and use cases, in other words it requires an organization which knows how to decide what it will build. Unfortunately, most organizations can’t get past a juvenile emotional need for instant gratification, and since the time required for good interaction design defers that, it’s seen as an obstacle rather than a tool. Production of code becomes the only emotionally justifiable activity among engineers whose management and culture care about little other than the ship date and can’t understand why rushing makes things later. So don’t blame the engineers. We just work here.
Actually, the guy you’re quoting agrees with me. I should have read the transcript before posting. He writes:
“Then you enlist programmers: you tell them you will fight for quality if they implement your designs. You can say to them, ‘I will go to management and fight to get you the resources to determine how much its going to cost and how you are going to accomplish these problems, if when you build it, you will follow my specifications.’ I believe programmers have been waiting for someone to make this deal, and I’m convinced management won’t make this deal. You’re giving them what they want: the ability to be great craftsmen.”
This is almost exactly right. My only quibble with it is that it’s not a three-way deal. Engineering would be more than happy to implement good interaction design if only Management understood its value. The deal needs to be between Design and Management, and Engineering can chime in briefly if necessary with “what that Design guy said.”
What is an “unit test”? Seriously, we don’t use them where I work and they are’t used in web development. You should see the user interface for the application I’m working on. For example, the scheduling form has three rows of buttons labeled “S20”,“S16”,“A00” etc which are the codes for vehicles. The main window form is just a menu on the left and a huge image on the right with a bad aspect radio. No other information is ever displayed in this large screen area.
I’ve never met an Interactive Designer, or wait… maybe all my managers are interactive designers. However I think they don’t measure what clients want.
Now unit tests are great, you know exactly what percent pass and what fails.
When I start seeing actual numbers from an Interactive Designer, such as whar % of users can solve their test cases. Then we’ll become great friends!
Anyways one of my hobbies is to imagine I know how to design useful stuff. So normally when I make some small internal app, I’ll write a short guide and let someone around the office try it while I remain in silence and take notes of their actions. Normally by the third iteraction I can find a good balance, but unfortunately not enough to get good solid numbers. But the point of iterating is a strong point for an agile development.
Two or three comments noted that Unit Testing is no substitute for User Acceptance Testing and that both are equally important.
They missed the point entirely. Both are worthless if the interaction design sucks. (Any Lotus Notes user can testify to that - http://lotusnotessucks.4t.com/index.html)
And because Interaction Designers are so rare in the wild, every developer that develops any kind of user interface must strive to become a better interaction designer, knowing that they represent a conflict of interests. And every Business Analyst the designs user interfaces has all the more responcibility to excel at great interaction design.
