fixing versus working around problems

At times people will come to me, or the Plasma project in general, with a request to work around a problem. One such request we've gotten a few times recently is to be able to turn off the desktop toolbox. The immediate question I have is, "Why?" and my immediate response to a request to do such a thing without an explanation of the pain points is, "No."

Here's why: usually if the pain points are identified they can be addressed. Personally, I'd rather fix things than simply work around them. Why? Well, besides resulting in a better product in the long run (which should be enough on its own) this prevent the accumulation of configuration options and code paths that exist only to work around problems. That's a bit like putting corks on the end of all the forks in the house because poking yourself in the eye with one hurts. Instead of corking your forks, maybe you should be asking yourself, "Why do I keep poking myself in the eye with them?" If you can answer that question, maybe you'll find a fix that doesn't render the forks in the house more cumbersome to use.

There is an annoying reality to be dealt with, however: not all fixes will happen immediately.

This fact leads sometimes to the suggestion that a short term solution should be thrown in for the interim. The problem with this idea is that these "short term" solutions way too often become long term bodges. Worse is when the problem actually gets fixed, but we can't remove that "temporary" solution because someone has decided they really, really need it (often they don't, they've just gotten used to it being there... change == bad, after all).

Even worse, when it's a work-around what usually ends up happening is that we stop getting feedback and testing from those who felt that particular pain in the first place. The two-fold downside here is that (a) Plasma developers don't know when the issue is actually fixed (or not) and (b) those users end up getting shorted when their pain point is addressed because they probably will stick with the work-around out of inertia. Why bother writing software in the first place if it doesn't get used, right?

So when coming to us with a paint point, instead of proposing a solution (e.g. "Let me turn off the toolbox") explain what the pain points are.

Karol Szwed described (one of?) his paint points with the toolbox as "Whenever I close a maximized window, it animates. That's visually distracting and annoying for me." Now that is feedback I can work with, and I fixed that issue today. Turns out it was a pretty trivial thing to fix actually (we now check to see if the hover event that was triggered happened from crossing the threshold area of the toolbox; this prevents spontaneous hovers that happen in the main target area of the box from triggering activity, which is what happens in the window close case).

I'm interested now to hear from Karol if he finds the toolbox OK or even just better now. Hopefully the answer will be "yes", but maybe it'll be "not yet satisfying, though this is better". If that's the case, then we'll get on to the next set of pain points.

Only once we have arrived at a set of non-resolvable pain points is it a valid proposal to start working around them. And yes, I recognize that there are non-resolvable pain points, even if due only to people's differences in personal tastes. That is when we start bringing in the options; and if we can we try and come up with a passive configuration mechanism.

We're not there yet with the desktop toolbox, though. The next set of fixes is allowing the position of it to be changed (e.g. different corners, edge middles, ...). This requires making the painting code more generic (it assumes the top left corner; that stupidity is the fault of my own lazyness combined with time pressure pre-4.0... not overly hard to fix, though). Once that's done, then we'll see what pain points remain.

It's surprising how often by just chipping away at paint point after pain point, a feature at some point "suddenly" becomes not only palatable but has perceived value.

Under the category of "dealing with Aaron 'The Psycho' Seigo" (that's my wrestling stage name): it's also great if you don't try to cleverly convince me that your proposed solution addresses a real problem through fanciful argumentation. It may be a personal foible of mine (probably is) but if you try and BS me, I'm more apt to just ignore you. Nobody's perfect.

So, for instance, some individuals claimed that the toolbox interfered with their ability to close windows. This is obviously untrue since it lives beneath all windows. Instead of searching for additional reasons I should care (e.g. by construing a "usability problem" that isn't your pain point, and this case is just plain bogus), simply describe the symptoms of the problem much like Karol did. Your "job" isn't to convince me, it's to explain the problem. I'll believe you have a problem if you just say what it is. Then I'll try and come up with a solution (often with requests for further feedback from you on it). No exercising of your extreme cleverness is required.

This is really a lot like the doctor and patient relationship: as a patient your job is to accurately describe the symptoms. If you start trying to offer diagnoses you're going to at best be wasting the doctor's time and at worst throw the doctor onto the wrong track as he might interpret your self-diagnosis as an explanation of the symptoms. Even if you're a doctor, you're probably still best served by explaining the symptoms (though you'll probably do a much better job of that than your average patient): the diagnostician's specialties may be different from yours and their subjectivity is invaluable.

Of course, we are still left with the issue of "not all outstanding issues will be fixed immediately". The question I have to ask myself is if it is better to write software that will still be useful in 10 years time or if I'd rather smooth over (often rather minor) inconveniences today. I personally don't want to do a rewrite of the desktop shell again. Ever. So while I do bow to pragmatism whenever plausible, I'm also trying to prioritize the future so that we don't end up with another kicker, which is to say: a great app that just can't be budged further, resulting in the loss of so much of the effort that went into it.

Given how far we're getting between 4.0 and 4.1 (not to mention the backporting we've done), it seems we're going fast enough that we can afford to lean a bit more towards "future benefits" than if the project was moving at a slower pace.