The other Neil gets confused with Segway inventor.
I'm pretty sure they are two different people though.
One of the problems with building a software product is that you will generally have a particular kind of user that you are targeting your product to in mind, however, you won't generally have any control over what kind of users end up using your products. If you built your product for one kind of user, the others will complain that your product isn't adequate for their purposes. However, if you built your product to suit the second group, the first group will complain.
Some groups are more vocal than others, such that it often skews real overall opinion. For instance, technical end users are very vocal on newsgroups and weblogs such that their opinions may seem more important than others, despite that they may -- for a particular product -- be in the minority of users.
Thus, when building a product, you need to choose the right parts to focus on so that you'll satisfy your target users and the users you think you might end up with. There are a number of things that your application can choose to focus on. Here are twelve possibilities:
Pick two. That's all you'll be able to implement well enough for your first version. For each subsequent version, you might be able to add one more.
Unfortunately, different target groups of users will desire different items from the list above. Technical users often wish to have efficiency and perhaps customizability. Developers would like extensibility. Macintosh users tend to like usability. Your company would like marketability.
One possibilty is to do a bit of each. That's possible, but rarely happens. If you try, you'll fall on your face, since your application will be really good at nothing.
I'm going to duscuss each of the above in more detail over the next twelve days (or probably a little bit longer than that).
When Opera decided to create a browser, they focused very heavily on efficiency. Mozilla decided instead to focus on portability and customizability. For Mozilla Firebird, those features were already implemented, so the developers began to focus on efficiency and usability instead. (Note that they sacrificed some customizabilty and portability to some degree.)
Web browsers have this unfortunate reputation of being slow. This likely stems from people having dialup connections and having to spend significant amounts of time waiting for content to download. This leads to many people believing that browsers need to be faster and so they spend time discussing the speed of one browser over another. When a new browser is released, one of the main topics mentioned on the various news sites is how fast or slow it is compared to competitors, often having a chart showing various simple tests they did. This only perpetuates the problem and makes more people believe that efficiency is of critical importance to the usage of a browser. Many people will choose one over another, simply becuase of a 10% speed benefit, despite that the faster product is worse in all of the other eleven categories listed above.
In reality, performance doesn't really matter in many cases. The difference between a task taking three seconds or four seconds is of trivial importance for many tasks. For instance, let's say application takes seven seconds to start up over a competitor which takes only two. A user that launches the application once a day, five days a week, will end up saving just over 20 minutes of waiting time per year with the second application. Hardly worth fretting over.
For a developer though, you'll likely end up with users who do fret over such things, so you may wish to focus on improving performance. However, each improvement you do costs more time to implement incrementally. The first few changes are simple, but as more performance tuning is done, you'll find that it requires much more effort to implement. At some point, it will just not be worth the effort.
One problem with making performance improvements, is that some systems simply can't be improved. Architectural decisions made in the first version or in later versions simply pervent significant improvements from being made. Much of this is programmer style. Some styles simply aren't designed for performance but for other benefits, for example modularization.
So deciding on whether to focus on efficiency is dependant on what your application does and whether you think your users will demand it.
There are two kinds of performance, actual performance and perceived performance. The former is the speed at which something actually runs, which is easily measured by various tools, while perceived performance is how fast the user thinks something is working, which is much harder to measure. The kind to focus on depends on what's happening. If you're creating a database, actual performance is more important, since often nobody is actually looking at it. If you're creating a end user application, perceived performance is key.
Improving perceived performance can be difficult. You have to trick the user into thinking that they are getting a benefit without necessarily giving them one. A common method is to make sure that it always looks like something is happening. Many applications that take a while to start use a splash screen to disguise the real time it takes. The part of the user's brain that controls their patience resets when something happens such a an image appearing, or a window changing. For greater effect, PhotoShop and other products stream off a list of components they are loading in the splash screen, such that the user has something to look at.
Another trick is to preload some components when the operating system starts up, thus improving the speed at which the application starts later. Unfortunately, one group of users sees right though this and complains about the time and extra memory it requires. This group of people are what I'll discuss tomorrow, the 'Too Much Bloat' people.