Click here to Skip to main content
13,355,018 members (59,168 online)
Click here to Skip to main content
Add your own
alternative version


41 bookmarked
Posted 6 Jun 2004

The Science of Software Development (Part 1 - Rules & Principles)

, 13 Jun 2004
Rate this:
Please Sign up or sign in to vote.
A guide to becoming a better programmer.


In the programming world, we have a large range of skills. One programmer may take a month to create a program, and another might be able to do the same application in a day. The first program may be full of bugs, and un-maintainable, while the 2nd is stable and easy to extend. In this series of articles, I will explore different facets of these facts. My objective is to provide you with tools you can use to improve your abilities as a software developer.

This first article deals with helping you evaluate how much you know of the basics - object-oriented programming and design. I'll do this by breaking down object oriented programming into 3 tiers. Hopefully, you will be able to find your own level within those tiers, and use that to find the next steps to improving your knowledge. Right then, on with the show....

The Program

I thought this would be easier to follow if we discussed it in terms of an imaginary program. My example that comes to mind is a simple form with a data grid, and a popup data entry form that is used to enter new data into the grid. Note that any code samples in this article are pseudo-code - there is no downloadable code for this article.


When you first learn the game of chess, you learn the rules. Pawns can move like that, and knights like that, and the game is over when the king is trapped - checkmate!

Programming is the same, in that the first thing you have to understand are the rules. In programming, this is the syntax, and the programming environment (e.g., Visual Studio). Once you know the rules, you can write a program. In terms of our example, someone who has just learned the rules would probably write the code something like this:

sub MyDataGrid_RowClicked()
   Dim MyDataForm as new DataForm()
end sub
sub MyFormSaveButton_Clicked
   Unload Me
end sub

The application will work. When a user clicks on the data row, then the data form will display. Once the data has been updated, then the grid will refresh.


Once you have learned the basic rules of chess, you start learning the principles. A queen is more valuable than a pawn. Knights and Bishops are roughly equal in value. Try and control the center of the board.

In programming, we have principles too. They are fairly well known, and have been for a while. Coupling, cohesion, use of functions...there are many more. Once you know the principles, your programs become "better". This means that they are easier to write, understand, and extend. They may scale better, and interface easier.

Once a programmer has learned some programming principles, they may recognize that the sample code in the previous section was flawed. MyGridForm and MyDataForm refer to each other. In object oriented terms, this is known as coupling, and it is bad because they are now dependant on each other. When one changes, it can cause problems in the other. Multiply by a thousand, and you have spaghetti code.

Armed with knowledge that coupling is bad, we may re-write the previous code as follows:

sub MyDataGrid_RowClicked()
   Dim MyDataForm as new DataForm()
end sub
sub MyFormSaveButton_Clicked
   Unload Me
end sub

This is superior to the previous version, because MyDataForm is no longer coupled to MyGridForm.


If you want to succeed in chess competitions, you have to start studying. You study the games of the grandmasters, and you study the patterns of the opening moves. You study your own games, and you study the games of your peers and rivals.

In January 1995, almost 10 years ago, a group of four authors ganged together and published a book called Design Patterns. This book contains some of the knowledge of the programming grandmasters. They describe patterns as "simple and elegant solutions to specific problems in object oriented design". There are only 23 patterns in the book, but each summarizes years of hard-earned experience. In terms of concentrated knowledge per square inch of text, the book is very dense. (That's just my way of saying that it is not light reading material).

With new-found knowledge of patterns, we can revisit our application. Some of you may have noted that although MyDataForm is no longer coupled to MyGridForm, the reverse is not true. MyGridForm is still coupled to MyDataForm. With a little knowledge of patterns, we can remove that dependency.

abstract class FormCreator
   function GetForm(rowData) as Form
end class

concrete class MyFormCreator
   function GetForm() as Form
      MyDataForm = new DataForm()
      return MyDataForm
   end sub
end class

sub MyDataGrid_RowClicked()
   dim MyDataForm as Form = MyFormCreator.GetForm()
end sub
sub MyFormSaveButton_Clicked
   Unload Me
end sub

The above is an implementation of the Factory Method pattern. I won't go into details, because that is not the point of the article. Suffice it to say, MyGridForm is no longer directly coupled to MyDataForm. If I wanted to, I could easily substitute another form MyOtherDataForm, without touching MyGridForm.

My Advice...

If you are learning the rules, then...

  • Be aware that there are principles too.
  • Understand that programming is not just about solving the problem at hand. There are consequences to the ways that you solve the problem. Try and be aware of that when you program.
  • Understand that programming is not just about solving the problem at hand. Yes, I know I already said that. It's important, because that understanding is what will help you see the reasoning behind OO principles.

If you are learning to apply OO principles, then...

  • Start by tackling one or two principles at a time; don't try to learn it all at once.
  • Don't get caught up, or intimidated by the terms - encapsulation, inheritance, interface inheritance, coupling, cohesion, Liskov substitution principle, etc.
  • Try to understand the reason for a principle. It can slow down development if you apply principles just for the sake of it, without understanding why. It can even lead to whole layers of your application that serve no real purpose. Once you understand the reasoning behind the principles, it becomes much easier to choose how and where to apply principles.
  • The most important thing is that you try - the rest comes with experience. You will make mistakes, but your programs should still be superior to the ones you developed beforehand.

If you are learning patterns...

  • Accept that you will never know them all. Some will be easier than others to pick up, and some you will never find a use for.
  • Start by thinking of a particular challenge that you have, and then try and find a pattern that seems to help.
  • Buy and read books on programming and design techniques. Try and expand your horizons.
  • There are other patterns besides the original 23 - there are even some for business-domain specific stuff, such as accounting. Sometimes, it is worthwhile looking into those.
  • Lastly, beware of overusing patterns - they can be overkill. Not every solution needs to be the most elegant and extensible one that you can devise.


Every developer has to be a designer as well. Even if you have someone who provides the broad brush-strokes of the application design, you still have to code the details. That said, if you never learn design patterns, you can still be a good programmer.

The same is not true of the principles. You absolutely need the principles to be able to design your own applications in such a way that they can survive the test of time. Experience has taught me that a medium to large program that is written without the use of principles will be re-written or scrapped. A small program that is written without applying OO principles will always stand on its own, and never integrate well with others.

For many of us, it's been a difficult (although exciting) few years picking up yet another language (C# or VB.NET or ASP.NET). We have to remember that there is more to it than just the language and the framework, and the latest technical how-to article.

There is such a huge wealth of knowledge available on the Internet, and in books (some of which are listed below). Enjoy.

References and Further Reading

Most of the references here relate to Principles and Patterns. For the rules, check your online help/SDK.

I believe the originator of the chess-programming analogy was Robert C Martin. I have not been able to find that reference though.

Article History

  • 9 Jun 2004 - Altered introduction text.
  • 14 June 2004 - Changed title, added some references, tweaked the intro and the conclusion based on feedback.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Steven Campbell
Web Developer
United States United States
Steve is a software developer working in Minneapolis, MN.

You may also be interested in...


Comments and Discussions

GeneralMy Dear Expert Pin
negm_phlestin4-Apr-07 13:14
membernegm_phlestin4-Apr-07 13:14 
GeneralRe: My Dear Expert Pin
Christian Graus4-Apr-07 13:26
staffChristian Graus4-Apr-07 13:26 
GeneralArticle Update Pin
Steven Campbell14-Jun-04 19:15
memberSteven Campbell14-Jun-04 19:15 
GeneralJust a little precision Pin
Franck Quintana7-Jun-04 14:50
memberFranck Quintana7-Jun-04 14:50 
GeneralRe: Just a little precision Pin
Steven Campbell14-Jun-04 19:31
memberSteven Campbell14-Jun-04 19:31 
GeneralInteresting... Pin
Colin Angus Mackay7-Jun-04 14:09
memberColin Angus Mackay7-Jun-04 14:09 
GeneralRe: Interesting... Pin
Steven Campbell14-Jun-04 19:18
memberSteven Campbell14-Jun-04 19:18 
GeneralCongratulations! Pin
Franck Quintana7-Jun-04 8:09
memberFranck Quintana7-Jun-04 8:09 
GeneralRe: Congratulations! Pin
Steven Campbell7-Jun-04 13:01
memberSteven Campbell7-Jun-04 13:01 
GeneralSame old stuff ... Pin
Sébastien Lorion7-Jun-04 7:26
memberSébastien Lorion7-Jun-04 7:26 
GeneralRe: Same old stuff ... Pin
Steven Campbell7-Jun-04 14:00
memberSteven Campbell7-Jun-04 14:00 
GeneralRe: Same old stuff ... Pin
Colin Angus Mackay7-Jun-04 14:12
memberColin Angus Mackay7-Jun-04 14:12 
GeneralRe: Same old stuff ... Pin
Colin Angus Mackay7-Jun-04 14:13
memberColin Angus Mackay7-Jun-04 14:13 
GeneralRe: Same old stuff ... Pin
Sébastien Lorion7-Jun-04 17:39
memberSébastien Lorion7-Jun-04 17:39 
GeneralRe: Same old stuff ... Pin
Colin Angus Mackay7-Jun-04 14:18
memberColin Angus Mackay7-Jun-04 14:18 
GeneralRe: Same old stuff ... Pin
Aaron Eldreth7-Jun-04 15:56
memberAaron Eldreth7-Jun-04 15:56 
GeneralRe: Same old stuff ... Pin
Sébastien Lorion7-Jun-04 17:40
memberSébastien Lorion7-Jun-04 17:40 
GeneralMissing stuff Pin
Philip Fitzsimons7-Jun-04 4:37
memberPhilip Fitzsimons7-Jun-04 4:37 
GeneralRe: Missing stuff Pin
Franck Quintana7-Jun-04 7:47
memberFranck Quintana7-Jun-04 7:47 
GeneralRe: Missing stuff Pin
Steven Campbell14-Jun-04 19:10
memberSteven Campbell14-Jun-04 19:10 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.180111.1 | Last Updated 14 Jun 2004
Article Copyright 2004 by Steven Campbell
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid