Random Software Success...
A bit ago, I was talking about Chapter 7 of The Inmates Are Running The Asylum. I had put down the book for a bit, because of my last disagreement with the book, and have decided to keep reading; I think the good stuff is still to be had.
In Chapter 8, I strongly agree with some portions, and I completely disagree with other portions. I find it very generalized as a topic, and you would surely see a different picture of software developers after reading this chapter than many of the developers I have come across.
Before starting, I want to point out again that Alan Cooper is the father of VisualBasic. Although he will probably argue that the entire application has undergone some major changes since he worked with it, I think some of the basic premises of VisualBasic come from him, such as the Wizards.
With this in mind, Alan starts the chapter off by describing how developers love to reuse software that has already been written, especially that on someone else's budget. The reuse that he is talking about, however, is not software reuse in the sense of abstracting code into public functions to share functionality or using libraries. No, what Alan is specifically talking about is reusing portions of user interfaces, and specifically using them in the wrong cases.
His major point is that developers will choose the user interface route that is easiest to develop. For example, prior to J2SE 1.2, there was no way to implement Drag and Drop functionality; I am sure that you could have probably done something with JNI, however, this would have been platform specific and more work than the current scheme. Because of this, many Java applications did not use it until 1.2 came out.
On the other hand, almost every application has a confirmation dialog box, and Alan absolutely hates these. He finds them overly used because they are so easy to generate, such as MessageBox under Windows or JOptionPane in Java.
While he has his points, it would seem to me that he is complaining about developers that are doing the interface design themselves instead of having an expert do this. In this regard, I would think that the interface designer would have to contribute to the coding standard in how to handle particular situations and really be a part of the development team. Alan makes developers seem like monsters, and this team spirit cannot exist, saying that developers take interaction design as a suggestion, but I still think that if the company's culture insists on interaction design activity within a team, it will happen.
But my point in previously mentioning that he is the creator of VisualBasic is that he has provided a tool to put developers in control of creating user interfaces. As my Usability Has Not Caught On article discusses, developers use computers a lot, and so they feel that they know user interface design very well, and in some cases, some are very talented in this area. On the other hand, there are some developers who would prefer not to do any user interface design, and be primarily at the core of the software, and I see this as being software specialties, where developers cannot possibility know everything about every topic.
Even the experienced. Alan mentions that more experienced developers are allowed to take the more complex part of the software, and to compensate for this, the junior developers get the support calls. Surely there exist developers to this nature, but in general, some developers are more inclined to helping support problems than others, just as some developers are more apt to resolve their own IT issues than others. I see this as being more of an individual factor than something that can be generalized like this. When I think of my current employer, most of the more senior people are more involved with technical support than the juniors.
Of course, of with all Alan's exaggerations and generalizations, he is trying to make a point. If you continue his discussion regarding the senior developer, the only support calls that senior developers will receive will be with truly expert users. The other major party involved in software is sales, which generally deals with novice users. As such, Alan's point is that our visions of our users is not necessarily accurate. In other words, it is like the the old story of the elephant.
There are several sentences in this section that were just not right, such as source code that is almost never read; its funny, but Code Reading by Diomidis Spinellis seems to say that we spend more time reading code than writing it. As far as being mostly a solo sport, this is partially correct, but merge reviews make it less of a solo sport in my opinion, as does Pair Programming (although not as popular). The entire chocolate bribery story is completely absurd also, as I am sure it works with more people than just developers.
Alan insists that we still build software as we did in the 1970's. While portions of his discussions make sense, such as the lack of interaction design in most applications, his argument that most applications are written to be nice to the Processor instead of the users is a little far fetched. I think the discussion that Alan is trying to have here is that while the application is idle, the application could be doing some analysis of what the user may want to do next or something to this nature, as he discusses more in depth in About Face. He should have come out and just said this though.
One of the points that Alan makes is that all computer software works in the same way because developers all come from the same “culture.” I am not sure where Alan is coming from here, but in reality, the tools we used to create the software is very similar, and in fact, this is one of those things that the early Windows and MacOS boxes got us, viz. consistency in widgets. These experiences all influence our designs, and so yes, I suppose that perhaps we share in a common experience, but I do not see interaction designers as really being vastly different in this regard. You will still have your excellent interaction designer, and well, the bottom of the barrel.
Microsoft takes a lot of heat in almost any topic, and Alan says that if you have ever used a Microsoft application, you will know that they focus very little on interaction design and more on programming. I am not sure that I fully agree with this; while they are not perfect, I know that they do focus on some interaction design. For example, an article in the May issue of Dr. Dobbs by Steven Clarke entitled “Measuring API Usability” discusses how Microsoft applies usability to its API's, the interview with Virgina Howlett (creator of the Verdana font) discusses how designers worked with developers to create Windows 95 and various other products, and the list goes on. Of course, Alan would quickly point out that when Microsoft uses the word “designer”, they mean interface design (one who creates an aesthetic looking interface), whereas he means interaction designer (one who defines the user interaction with the software). As one who indicates this, though, I would have assumed that he would have paid more attention to his choice of words where he says that developers who do their own design leads to bad design; here, he is not taking about Software Design, but rather user interface design.
Of course, managers are at fault for bad interaction design. Some managers decide that the developers can do all of the all-inclusive-design all by themselves, and occasionally managers force developers to implement things in ways that are to the manager's own benefit. An example of the latter one that Alan uses is that in one of the organizations he worked for, the manager could not type, so he required the interface to be mostly driven by a mouse. This self-referential design really causes problems; in order to properly create the software, we need to know what the perspective client wants, not what developers, sales people, marketing, managers, etc. want.
In other cases, some managers want developers to start developing the software, and then bring in an interaction designer, and, Alan notes, this idea usually comes from a manager that was a developer. This is not ideal, and is like the security argument, where security must be built in from the start, and so must usability. Sometimes software developer this way will become a hit, and in other times it will not.
At any rate, Alan continues by stating the Microsoft creates small teams that work on a specific product, and leaves them essentially alone to produce. This culture has been reproduced at many other organizations, under the assumption that this culture breeds success, but this is not necessarily the truth. Alan compares this to the 19th century physicians who were unsure of malaria's source. It was believed that it was just floating around, striking completely randomly.
And so is our software. Sometimes successful. Sometimes not. Design will help software be more successful, more often.