Technology notes Vol 1, Issue 3 Jan 07

Welcome to the third issue of Technology Notes. This time we'll talk about silver bullets in software development and GUI design. I'll also write about a related topic: that of managing technologists.

* Graphical User Interface design

Most people incorrectly think that GUI design is simply a matter of dragging and dropping cute (or not-so-cute) buttons from a toolbar onto a flat surface. Furthermore, many UI designers go by the adage "Cute is user-friendly" - i.e. the fancier the interface (metallic buttons, colourful pictures and the like), the better. Form over function. Just like the times.

Ofcourse, it is ridiculous. And the best example comes from nature. Look at any predator on Discovery, Animal Planet or NGC. A cheetah in full flight is one of the most amazing sights in nature. Why is it so sucessful? Simple. every bone, every muscle, every organ in the cheetah is designed for one thing - catching prey. Nature gives no room for excess baggage. Unfortunately, with software you have a lot of leeway. While every bit of software we write must be designed towards meeting the user's need, often we see more focus on frivilous form...often at the cost of functionality.

Such features are common place. Heavy e-mail interfaces that take ages to load, instead of plain HTML. Tiny, non-standard, fancy buttons that are hard to access and understand, instead of neatly placed standard buttons and icons. Gimmicky features that force users to upgrade their machines. Don't get me wrong. I'm not saying that all fancy UIs are bad, or that they don't have their place. For instance, a program that teaches kindergarten arithmetic cannot and should not use a standard Windows interface. However, user interfaces should never sacrifice the principles of orthogonality, affordances, learnability, closure and consistency over ephemeral feelings that won't last beyond the first use. See (an old) UI hall of shame here. See Microsoft guidelines here and in the interests of balance, the Mac guidelines here.

* Silver bullets in software engineering
(This is based on a discussion I had with a friend in the corridors at work.)

Fredrick Brooks wrote a seminal paper on software engineering where he mentioned that there were no silver bullets in software engineering or that there was no one technique which provided a solution for the various problems of complexity and cognition that software engineers face. However, with every new technology that is introduced today, we hear choruses of cheer - that the complexity of software development is conquered. Recall the hype over Java, Graphical User Interfaces, Rapid Application Development, and the dozens of technologies that we don't even remember today, and you'll appreciate what I'm talking about. However, we still haven't gotten over our search for silver bullets. Consider the problem of performance. The answer? multi-threading. Consider user-land complexity: how do you solve it? Simple, make it a Graphical User Interface! Never mind that multi-threading works only when the threads perform more-or-less independent tasks. Never mind that command-line UIs work really well for most applications, provided they offer a little bit of user-guidance to flatten the learning curve. BTW, try using Intervideo's DVD creator to make a data DVD and let me know if you wouldn't rather have an app that does this:

cd /home/fordvd
dvdwrite -f data /home/fordvd/* /dev/dvd

Anyway, lets move on to the final topic of this edition:

* Managing Technologists.

Before I write anything on the topic, let me acknowledge that I haven't managed people formally. I've led small teams, mentored people, worked with super-cool teams and am having an amazing run of luck as far as managers are concerned. Anything I write here is based on those experiences. Here are some things I think are a must if you're managing technical people:

- Good quality of work. Ok, you may not be able to ask your people to work on a static analysis project that defies the decidability of the halting problem. But the work you ask people to do must challenge their intellect. Suppose all you do is maintenance, see if you can get an additional project that furthers your product. If you do product development, try and find cool problems that your engineers can solve.

- Respect your engineers. Never ask them to do something you wouldn't do yourself. Don't shift the grunt work onto the shoulders of your reportees. Don't ask them to build a system twice. Don't ask them to solve a solved problem. Trust them - but question their assumptions. Praise honestly and publicly when they do well - rebuke gently when they don't.

- Be the "Facade" pattern. Shield your reportees from the politics of your organization. Make their achievements public. Remember that their failures are yours but their successes their own.

I'll add more when I get them.