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.