…Omni Group Ad.
Although they missed to show the cursing, screaming & yelling at the computer which happens far more often then the end-zone-dance 🙂
…Omni Group Ad.
I don’t mind people giving us feedback on our products. I don’t mind people making suggestions on how the software could be improved. I don’t mind people pointing out glaring omissions, substantial flaws, bugs & crashes. I know our software has bugs, can & should be improved substantially. As Dave Winer puts it: “We make shitty software and we know it”.
In fact, we rely on the feedback to provide a better product.
What I mind is the way in which feedback is provided – and 37signals post showed some of the ways. What I mind is the general attitude of somebody not involved with the development of some piece of software presuming to know that some things are trivial & absurd.
I don’t talk about diplomacy – I talk about courtesy. That’s something we should have learned from mom and dad back when we were kids. Courtesy doesn’t come in the way of pointing flaws & bugs precisely. In fact, courtesy requires us to point out flaws & bugs precisely. Courtesy also doesn’t hinder us from cursing at software developers, screaming, yelling, wonder about their stupidity or using a broad selection of four-letter words. As long as we’re doing it while in a room all by ourself.
Courtesy is about treating others with the respect they deserve. Because we want to be treated the same.
Useless, absurd, must, need, appalled, just, infuriating, essential, etc.
That’s what I’m hearing everyday.
As a developer, I face complex problems everyday (or should I say complex problems are upon me everyday? :-). I may come up with a rather lengthy serial blurb of code with a couple of conditions & loops. This blurb may neither be an object-oriented nor a clean, maintainable piece of code – yet. The code may look easy-to-understand and simple to me now because I’m still fully engaged in the problem and its solution. There are three key factors which contribute to its complexity:
* Length of methods / scoped code blocks
* Number of conditionals
* Number of loops
Reducing this undesirable complexity is straightfoward: Ruthlessly reducing duplication. During this process, I will most likely introduce new methods and new classes. This sure makes the system itself more complex, too. However this is desirable complexity – complexity which can be easily dealt with in future revisions of the code. Because I reduced duplication and decoupled the different components of my solution.
Or, to rephrase it, reducing unmaintainable complexity with managable & maintainable complexity.
So for any reasonably powerful feature or piece of functionality added to a system, the code won’t be simple. It will add complexity to the system. But doing it right will ensure that the system can still be dealt with in the future.
Here’s an excellent post by James Shore: Quality With a Name.
If you haven’t time to read it all, make sure to read the section “Principles in Practice”, where James discusses private instance variables and nails the issue right on the head.
Die Nachricht des Tages. Er hat es wirklich getan und Lehmann genommen. Wer sagt hier Deutschland wäre nicht reformfreudig.
[Update: Die Schlagzeile der Bild-Zeitung heute morgen gesehen beim Bäcker: Klinsi Killt King Kahn. Der war gut. Ein Sonderlob.]
I applaud the courage of the Office 12 UI team to take the risk and introduce a new UI (the “Ribbon” being the most prominent feature of the new UI) to deal with making Office more accessible, discoverable and in the very end, usable.
This is great stuff and worth looking into in great detail. Here are some great resources on the new Office 12 UI:
* BayCHI session video & audio
* Jensen Harris’ Blog