What do you think "great software" means?

I am always looking for new ideas and new ways of doing things. Today I find myself reading Head First Object-Oriented Analysis and Design, and in chapter one it ask you the question, "what do you think great software means?".

Ok, I'll take a stab at that.

Great software does what the customer wanted, and a little bit more. From the user's point of view it should be simple, reliable, and easy to use.

One of my more successful applications was a issue tracking system, similar to Jira, but with less bells and whistles and no admin interface. Internally we also used a monolithic application that was purchased for about $250,000 with another couple hundred thousand spent on training, support, and custom development. It took some time, but in the end the home-brewed application won out, but not because of it's superior feature set. The application gained popularity because it was easy to use (and easy to teach someone to use), did exactly what we needed, and could be customized to fit our exact future needs. That expensive behemoth on the other hand wasn't completely suited for what we needed to do, and could not be customized to do exactly what we needed, but it was as close as we could get. This inability to meet our specific needs meant that it was a source of frustration by the people that used it.

Great software is easy to maintain. By "maintain", I mean that it rarely breaks down and is easy to get running again. By "maintain", I mean that it is easy to customize and extend.

It has been shown in study after study that the cost of maintenance is a huge part of the total cost of a software package. Maintenance includes both keeping the application running and enhancing it. If an application is a "success", you will spend most of your time enhancing the product. If it is a "failure", you will be just trying to keep it running. Happy users want more features, unhappy users just want to use a different application.

Great software is easy to read. A developer can jump right into the code without ever seeing it before and not run away screaming.

If you write an application for your company and you are the only one capable of understanding how it works, then that application is a failure. It may give you a sense of job security, but when you leave the company they may find it cheaper to replace the application you wrote than to try to understand it. I always take the time to look for ways to simplify the code, make the code shorter, make it easy to read and understand. The best code can be easily understood without comments or documentation.

Launched Penlets.com, for Pulse Pen Users

<backstory>
Back in May I was at JavaOne and had a great time. Among other things I picked up a Pulse pen from Livescribe. If you haven't heard about the Pulse pen, here is the short version... The pulse pen is a computer in a pen, allowing you to record writing and audio as well as write penlet applications in Java. Pre-installed demos include a piano that your draw on the paper then tap to play, and a translator that can translate written words into several other languages.
</backstory>

A colleague and myself were really blown away by the possibilities, and picked up a few of the pens at JavaOne so that we could play around with the Java API. In doing so we learned some things that weren't completely documented, and required some trial and error. So we thought that if we were already doing the research that we might as well publish it on the web. In doing so we created Penlets.com. The site has tutorials, applications that you can install on your pen, and Pulse pen related resources.

So, if you picked of one of these cool pens, we hope that you will visit Penlets.com

Cheers.