The Face Of Bad Code

Lets face it, we've all written bad code at one point or another. If we hadn't, we probably would never release any functional software. Remember, code that isn't ideal doesn't equate to code that doesn't run and help someone else accomplish some task. Code can always be re-factored, and, it should be re-factored.

I often find myself testing my own software from and end user perspective and thinking about the code that is running when I perform certain actions. I think "well, it works, but just barely". I have to force myself to think "well, it works, and that is all the user cares about; it can be re-factored later".

Don't be tempted to re-factor before you get something functional into the hands of the end users. Make notes on what doesn't work well and fix it in conjunction with the user-provided feedback. If you don't release, you don't get the feedback. Only you as the developer know what needs to be re-factored, only the end user knows how well your software solves their problem.

Release Early, Release Often, Break The Interface

Release early, release often. The credo of open source software development in most cases. This didn't become the case simply because open source developers enjoy the task of doing project releases. In fact, this task is often burdensome, especially for projects with many components. This open source development philosophy became so common because it works. The idea behind releasing early and releasing often is to generate early feedback from the user community. This feedback is invaluable to developers and user interface designers alike. But why does it matter if the feedback is early? Does the feedback lose something if it comes much later after the software has been released? I think it certainly does. Although feedback regarding any open source project is valuable at any time during the development life cycle, the earlier this feedback is received, the lesser the likelihood of the concerns being pushed back. That is, if a given open source software project is released one week and users of this software express their concerns the following week, it is likely that these concerns will be addressed in the following release.

This entry raises an interesting usability problem with open source software projects. That is, users of sloppy, or, disorganized user interfaces get used to it. They simply accept the fact that this is the way the user interface is and is unlikely to change. The entry is slightly dated, although, unfortunately, the problem persists in many modern day open source software projects. So the glaringly obvious question is, how is something like this fixed? Aren't there countless usability experts out there that can design beautiful user interfaces? Surely some of these experts are willing to work on some of these open source projects that lack in the usability arena? The answer would be yes, there exists extraordinary usability talent in the open source community but as the entry suggests, there are different pressures face in open source projects than in the proprietary counterparts.

So what do these projects do with the user interfaces that lack in usability? They leave it up to the end user to figure out how they want the user interface to look by adding an endless stream of user preferences. These preferences allow the users to turn off undesired behavior. I say this is an endless stream because once one user interface preference is added, it is hard not to add more preferences of other user interface components. Additionally, this leads to a recursive user interface design problem because of the need to maintain these preferences. Again, as the entry suggests, this can become quite the mess to maintain because users of the software can quite easily grow accustomed to these "patch" type settings.

So what is the solution to this problem? Unfortunately, I do not have a solid answer as I'm no usability expert. However, reducing the number of moving parts on any user interface is always a good idea. I find the "less is more" principle invaluable in regards to user interface design. When it comes to user interface preferences that have been put in place for the end user to customize the "look and feel", they are most likely to hide components that clutter the user interface. Developers shouldn't take the decision to add new preference or configuration values lightly. Once added, new configuration options should be there to stay. When adding a new preference that allows end users to hide a given user interface component, think long and hard about the necessity of the component in question.