The nature of software engineers (as one myself, I use the term loosely) is to add. Start with something, and add more features, more data, more configuration (but not generally more documentation). We have the best of intentions, trying to make our software more valuable and more powerful.
As developers it is relatively easy for us to understand the design, know how features ought or ought not to be used, and the nuances of the configuration. The builder understands their own house. But can the same be said of the end user? Generally we develop software for users, not ourselves. Are the users left drifting in a sea of compexity unable to get their bearings?
Don’t get me wrong, I love Unix and grew up on it. But I have heard new Unix users complain about it being difficult to use. My best rebuttal is, “Unix isn’t user-hostile, it is expert-friendly.” How many times can something similar be said of systems we build every day? It has been my experience that each time we add something, it causes other issues which in turn require more things to be added. It can become a death spiral.
The Macintosh goes a long way to making Unix usable. Linksys and Tivo do a good job of making Linux usable.
If your software isn’t usable, people aren’t going to use it. And if noone uses it, then you are wasting your time developing it. Above all, it has to be consumable.
Remember the 80/20 rule and put it to practice. That last 20% of function is going to be really expensive, add a lot of complexity, and probably not be needed by the majority of users. Maybe you are better off without that last 20%. Keep your scope as small as possible, and don’t let it creep larger. It will definitely want to creep larger, you will have to purposely push it back.
Have good defaults, and have your software try to do the right thing automatically. How many of us want to just run the installer and crank it up without reading a 2-inch thick manual? It should do something meaningful without hardly any requirements on the user. If you absolutely need a configuration setting like a database name, figure out how to probe the database server to get a list of the available databases, and either let the user pick the right one from the list or (better yet) probe the database schema to see if you can automatically figure out which one should be used. If you need a database password, ask for it in the UI instead of requiring the user to edit some configuration file buried deep in the filesystem that is described only on page 183 of the manual.
Remember the golden rule for documentation. If you were new to this, what documentation would you want to have and how should it be organized? This applies not only to users, but also co-developers (meaningful comments, architecture descriptions, etc.).
As developers we sometimes pride ourselves on the complexity of an item we’ve built. It is human nature for us to think that bigger is better. But in the CS world, it isn’t. Elegant is better. And elegant is usually about right-sizing instead of super-sizing.
Take a look at how Agile methodology and XP describe it. Make a conscious decision of what you are going to exclude, and let it go without feeling guilty. It is impossible to please everyone, so just get used to it.
If you do it right, it should be simple. And building a simple solution usually requires multiple tries. But it is better for the developers to expend effort than for the users to.