Thursday, July 31, 2008

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.

2 comments:

Edward G. Talbot said...

Robert -

I mostly agree with you, with one exception. I do not think that great software requires no comments or documentation to understand. Now, I would agree if we said that it requires no comments or documentation for a great programmer in the language(s) in question to understand. But in some languages, even very good programmers will have trouble following code that is written as well as it can possibly be to balance business needs (including flexibility) with security and of course ease of maintenance.

I would also add that in many real world situations, great software is not as good for the business as good software. I have rarely ever had time to write great software - as such, I am probably almost incapable of it at this point. But what I do is start out by figuring out what great software would be and then figure out how close I can get within my limitations. The important thing is to neither get hung up on trying to accomplish something that isn't gonna happen, nor use time/resource limitations as an excuse not to come as close as you can. It's a delicate balance.

Anonymous said...

Great Software is pretty easy really, "It just works" would describe it for me externally ( for users ), minimal if any downtime, minimal if any training, minimal if any support, in other words users focus on their job not the tool they are using.
Internally it's simple to expand , debug & understand with intelligent reusability & rationalisation.
But there is a major difference between what the requirements for great software for a user & developer, way to often it's designed for developers & not users.