Writing good software Part II

In part 1 of this article I brought up the point that writing good software is not easy. The real problem that comes in to play here is that there are two main  tasks in writing software. First you have to come up a good plan (architecture) and then you have to actually make it a reality (implementation). In the new book I am reading there is a great exercise that I would really love to share with all of you and get your thoughts on the subject.

What does writing great software mean. This is such a great question because it means something different to different people. From the book we can take a look at a couple common answers. I am just paraphrasing here but the basic thoughts are the same.

The customer-friendly programmer says
Great software is always making sure that it does exactly what the customer wants it to do. Even if customers think of new ways to use the software it doesn't give them unexpected results.

The object-oriented programmer says
Great code is written in a object oriented manner. This ensures that there is not a bunch of duplicate code everywhere and each object controls its own behavior.

The design-guru programmer says
Great software is when you use tried-and-true design patterns and principles. You have also followed the guidelines of keeping your objects loosely coupled and your code open for extension but closed for modification.

I think most people would agree that a combination of the 3 is where they would like to be but that's not always the case. So the book poses a question to use developers. What do you think "great software" means? Here is my answer but I would really like to hear from others because I think the understanding of a goal is really our first step on an application.

I think writing great software is product of the 3 really crucial goals. The first goal of software is to meet the customer needs. This is a must because it is the single reason we are in business. This of course can be looked at in different ways though. Following a strict set of requirements should not be the goal. A customer will usually come to me with requirements but I really believe that is my job to point them in the right direction where I see fit. A good example of this is a customer wants to display 1000 records on a page. While it's true they would never have to leave this page, the performance issues out weigh the benefits and its my job to relay that to the customer.

Next we need to write software that follows some type of guidelines. This may not always be an object oriented approach but could be if you feel comfortable with it. Coding guidelines for yourself or team could prove to be a very valuable asset. If you working on code that will become public you should try and focus on community guidelines so that others can follow your coding conventions. Use of frameworks and or design patterns is not a requirement here but these options are proven to solutions to real world problems so it's not a bad idea to give them a look.

Finally I think you really need to be comfortable with your code. Write code that your happy with that produces the expected result. This will make your coding days much more pleasant. Try new things and challenge yourself to become a better developer by following these and other tips.

I hope this kick starts a really good discussion because I truly believe that good software design starts way before a line of code is typed out!