Initiating Iniative

Chris, does the developer see the problem? If he doesn't, he's not going to want coaching.

If you want to help him see the problems, maybe it's time to do a quick retrospective with him. (See Esther Derby and Diana Larsen's book, _Agile Retrospectives: Making Good Teams Great_ for how to structure a short retro.)

Once he decides he wants to change, you'll have a lot more options. But if he doesn't see the problem, you can't coach.

On the other hand, you can give him feedback. "You wanna talk about what happened last week with blatz feature?" (wait for a yes answer.) "When you do the feature development like that (be more specific than I am here), you do develop what people ask for--but not what they need. That affects me (in this way). Would you like to discuss how we can solve this?"

Well, maybe not all the time, but...

Suppose you have two distinct functional units in your product, and a task that requires the use of both of these units. A good coder will likely make a UI that addresses each of these functional units separately. It'll be neat, it'll be tidy, but it'll make that task that involves both units really difficult to perform.

It's hardly a coincidence that the developer of the bad UI is based with the coders and the developer of the good UI is based with the customer. One developer has lunch with the customer and listens to them talk about their tasks, and the other developer has lunch with the coders and learns about the internals of the code.

"The user" doesn't know his job in some cases as well as a truly qualified developer, and "the user" consists of multiple stakeholders.

"The user" has her own self-interest and will often fail to serve "the customer", in the typical corporation, as in the case in banking where "the user" shits all over the small-volume customer, and demands the programmers ignore the needs of that customer.

Listening to bull at lunch is a great road to failure in a system where the REAL "business rules" are set not by some "user" but by the law and generally accepted accounting principles. This "listening" is a form of indoctrination in the *schlamperei*, the going along to get along, that creates subcorporate feifdoms which then are allowed to damage, in the long term, the overall health of the corporation.

Furthermore, this argument makes absolutely no sense for a product like Norton Internet Protection or any commercial product which is intended to have thousands of users.

There's really no way of "following" such a diverse set of users and doing some sort of common denominator. Instead, the technology needs to dictate to the user.

But, failure to acknowledge this simple truth, and the resultant appointment, apparently, of "UI specialists" who are secretly regarded as failed coders, resulted in a complete lack of integration of the UI of Norton with its internals.

I have a tendency to agree with Edward on this one. I think that the kind of UI failure that Steve talks about is normally the result of not properly analyzing the flow of information through the system or not actually identifying a useful workflow. In either case, the programmer has dropped the ball.

My personal experience is that whenever I've done a good job figuring out where the data is coming from, who owns and/or manages the data, how the data needs to be processed, and how that data is used to support decisions, I've also created UIs that were effective and efficient.

You may be thinking that that kind of analysis is not the programmers' job, and I would disagree with that, too. Programmers, again in my experience, have exceptional analytical skills compared to most of the people they support. Even when the 'users' have comparable (or even superior) analytical skills, the programmer's relationship with the process and data is so different that it is common to gain new insight. Failing to take advantage of their unique skills and unique position is nothing other than sub-standard performance.

I should have offered something a little more helpful to Chris other than a diagnosis of the problem. If I were trying to fix the problem, and I was obligated to keep the same team in the same physical arrangement, I'd want to try to leverage this developer's bookish qualities and point him at some reading that might help him see where he's gone off-track. For example, there's a great article in this month's Dr. Dobb's on Green Threads. The techniques described there for improving workflow would really help him see things from the user's perspective, rather than what appears to me to be a complete fixation on the implementation. As further enticement, if he applies those techniques he'll have another buzzword to add to his resume.

I misspoke when I said that good developers necessarily make bad UI developers. I don't think it's really so, but I think a good UI designer needs to think about the UI design without sparing much thought to how the application is designed. I've worked with several good UI designers who don't know how to code at all, and they have frequently totally reworked my proposed UI's for the better. Only rarely have my insights as a developer been of any use in improving upon their work.

I completely reject Edward's stand that programmers should tell users how to use their product. Obviously, you can't write a custom UI for each one, and UI choices that are great for one user may not be good for another. However, users often have good and novel ideas about how to use the product and you'll blind yourself to these ideas if you shut the customer out of the design process.

If you want evidence of the truth of my claim, just read Chris' post again - it's the developer who sits with the customer who's putting out a product the customer likes. The other developer might be brilliant, and he might have a really clever scheme for his UI, but his users hate it, and that's really the bottom line.

Thanks to all for helpful comments.

I'd add one point to the discussion: in my experience most developers don't have an accurate perception of how good they are at UI design.

I learnt this lesson for myself when I had a testing role on a project I was not coding for. I could see the usability issues much more clearly than usual, and help find fixes for them. Unfortunately when I returned to a coding role all my normal blindspots returned.

For this reason, I don't agree with Edward's conclusion. But one aspect of what he says chimes with my experience. The knowledge about the application domain which I most need is not the explicit knowledge which my users can explain to me, but the tacit knowledge that is bound up in their practices.

Now I lead a team, I guess this leaves a question: how to help developers recognise UI design a special skill?

Consider that the real agenda in UI design is to hide information and separate people into what another poster shows are "roles", and this shows that although there is a "skill" called UI design, it is a negative skill: the skillful ability to not think of things that the user doesn't consider, and to make one's own purview a proper subset of the user's concerns.

A programmer's worldview can and does in some instances encompass and exceed that of the end user as a superset. However, in corporations, he has to keep this a secret.

Thus in many instances "progress reports" are deliberately coded by negatively skilled UI "specialists" to show a bogus progress towards a goal that is unrelated to the execution of the underlying algorithm.

In general, when you are engaged in the typical synchronous loop, you are processing n "entities" where n is known, and a simple bar shows progress if you solve the equation for its length

length/maxLength = entitiesProcessed/entities

and refresh it synchronously or asynchronously.

If on the other hand you are waiting for an asynchronous event, your code could today show brief cartoons, Three Stooges shorts, or Girls Gone Wild episodes from YouTube, interleaved by some sort of sensible information as to what is being waited for, public interest spots on dental flossing, and remindes to plug the peripheral in.

But, if the UI 'specialists' have been told they have a real, positive skill, they may not even know what entities or entityCount are being processed or waited for in the kernel: they may not know what event is being waited for. All they are taught to care about is a visual and in too many cases they deliberately neglect the needs of power users in favor of a lowest common denominator user who goes out for a smoke during a long process.

This is the origin of the Irritating Progress Report that Hangs My Goddamn Screen for Hours.

There is in fine a distinction between positive skill, such as machine tool crafting, computer programming, and engineering drawing, and the more artificial and negative skills manufactured by negative needs for information hiding and "efficiency" considered as generating excessive profits in a corporation.

We cross in other words a boundary when we go from "being a programmer" to "being a UI design specialist" or "being a data base administrator".

The programmer has the skill to do the UI design *in principle* in the sense that his capability as a programmer and as a human being for insight into a genuine human and genuine organizational NEED is unbounded for larger and larger x. His insight into the problem can (like Euclid's insight) generate the user interface, whether that's a Web page or a drawing in the sand!

But, once you enter the corporate precinct, a form of private property which nonetheless accomodates a subset of the general public, usually in the form of employees, a new and essentially negative partitioning of skills, and new negative skills emerge that have more to do with a (genuine) need for efficient production, where within a group we have to work together.

Which means I don't have a problem with regarding someone as a UI specialist if that is what it takes to get a product out. However, I'd like us to keep in mind that the rhetoric of "skill" reverses direction, from a "skill" that enhances the flourishing of the employee considered as a total person (such as piano playing, engineering drafting, and computer programming) to a "skill" in which the employee has to narrow his focus and give up some of his drive to power, such as data base administration, UI design, or human resources management.

See my blog post re this topic