I can’t tell you how many times while working with clients I have heard; “this system needs to be totally rebuilt.” Which, in most cases, is a very bad idea at best and a disaster at worst. I would like suggest to those in the “rebuild the system” camp to relax, refactor, and move forward in an iterative fashion.

Refactoring

It really is this simple, every time you go into a piece of existing code, leave it better than when you started. That means refactor by breaking up long methods and badly named methods that are difficult to understand. Rename “things” so that they are more clear; you should be able to understand the code for the most part with out using excessive commenting. Do not worry about “patterns” until the code base is stable and predictable with automated tests. Everyone one wants to jump on the “patterns” band wagon but I am telling you that until the code is stable and broken into reuseable objects there is no reason to even consider patterns.

Keys for success (conclusion):

• Automated test suite (of course, you need this regardless if you are building new code or refactoring)
• Refactor a little at a time (Do try to redo the entire project at once. Identify small sections that can be refactor and move on)
• Don’t get fancy! You don’t have to move the existing code to design patterns or slick algorithms. Just make it work and concentrate on clean code! 

Most of the time when I look at object designs I find that folks build systems without fully understanding the application domain. To rephrase that, I am saying that software developers build systems without fully understanding all the parts of what the client needs are. Of course, the difficult thing about this is most clients don’t have that knowledge either; or, it might be they forget to tell you many of the details associated with a particular business event that ends up compromising the final design. Clients have much of their knowledge wrapped up in their heads, and not on paper on in work instructions. This tacit knowledge is a major concern to software developers and can be the most difficult aspect of building maintainable software.

Object Problems

One of the main problems I run across when looking at existing systems is that they (the systems) are very difficult to maintain due to lack of business logic understanding on the part of the initial developer. The single biggest issue I face when extending or expanding existing software systems is that the objects have been poorly designed and do not take into consideration all the business logic necessary to add functionality without totally rewriting the software object itself. The objects are either incomplete or immature in fundamentals. What this does is cause programmers to add a ton of  “if” statements and “case” statements into the code to make up for the exceptions caused by not understanding the business logic.

Object Behavior

Object behavior is the idea of designing a system of objects that interact according to how the actual real-life system behaves. This is totally different that designing according to what a real-life system is. It is like asking yourself, “how does a person behave” rather than, “what are the properties of a person” … if we are using a person as a design object as so often you see in books and code examples. In using an “object behavior” approach to design you are forced into domain discovery more than with “object property” design. This will almost always produce a hierarchy of objects using inheritance much more than property design. It will also tend to push a lot of the decision making for domain exceptions down to object creation (using polymorphism) rather than if-else or case statements, which is usually a better, more maintainable design.

A simple (real life) example is a paint line that paints small car parts. The initial developers designed the system with a single object (part) that gets a paint record when scanned into the system. Each part must have a mold record between certain dates or that particular part must have special treatment before it gets painted. There was a string of “if” statements in the code that tested for all sorts of exceptions; such as: is the part a reinforcement in which case it doesn’t need a record. Is the part scanned by a manufacturer that requires a different sort of paint? Is the part an assembly which itself doesn’t require a mold record but it does require looking up all of its sub-parts for correct mold records. So you can see how complicated the code might get looking for all sorts of exceptions to a very general domain rule, “does this part have a mold and is that record within an exceptable range? With more diligent behavior discovery initially the developers would have realized that the behavior of the parts would have classified themselves into objects and then they could have used polymorphism much more effectively.

Conclusion

While it seems easy to build decision constructs into code to take care of domain exceptions you will be much better served in the long haul to do a more thorough investigation into object behavior using polymorphism in place of if-else and case statements. Assuming most of the lifespan of the code with actually be in maintenance phase, the extra time in understanding and building a better system will more than pay for itself in software updates alone, not to mention the fact the code will work better. If you are coming behind others modifying code, like many of us do, then refactoring to better object models is absolutely essential unless the code you are working on is to be retired soon anyway.

As you know, software developers spend a fair amount of time with our noses stuffed into books, websites, and whitepapers trying to further our design knowledge, reduce construction time, and improve return on investment for ourselves and our companies. We all want to build better software, right? We buy books on software construction techniques. We read articles on topics like “using metaphor in use cases” and “practical UML” and “.NET pattern shortcuts” and the list goes on. We study software patterns, anti-patterns, and refactoring techniques. We spend money to go to seminars and training. The truth of the matter is; however, the only way to really improve the way we build software is to do it, over and over and over and over. In other words, just like in sports, fine art, music, cooking, and just about anything else, we have to practice to get better. There is no way, for example, to read books and watch videos on how to play guitar and expect to improve without practicing what we have learned first. You still need to know the information in the books and videos; but, it takes practicing those skills to really improve. And in fact, just like with music, you can progress much faster if you have someone teaching you the skills and showing you what you are doing wrong, and right!

The Problem

Most developers work in isolation in small companies supporting products and business operations of the company in which they work. That means that the development staff is probably pretty small and not funded very well, and understandably so. Business folks have trouble understanding the importance of anything that isn’t directly instrumental in product production. So, as a developer in small and mid-sized companies you probably are working on lots of different projects with little time for software engineering techniques, or at least that is the way it seems. Technical training for the IT staff is many times laughable while testing and usability is simply unheard of.

I have worked in large development companies with lots of development resources; and, in very small companies where software development is considered a necessary evil. Both situations can produce equally bad software and both can produce very good software. The “trick” to producing well designed, stable software is developer attitudes and programming habits.

Some of the issues:

• over simplified examples – in books and on websites
• no manager or team support within the organization
• no training or apprentice programs for employees
• old habits are hard to break fostering stagnation

Let’s look at these issues one by one.

First, programmers purchase books and scour the web for examples and techniques in an attempt to improve their software skill sets. This is great and definitely helps but there lurks a dangerous trap and one that programmers can can easily fall into without ever even being aware of it. Almost all examples I have ran across in books are far too remedial. I am not referring to simple technical advise dealing with language constructs. Those are usually fairly useful and instructive. I am talking about the “how to design software” examples that almost always end up with the “employee / company / widget” examples that are far and away too simple and straight forward, and almost never happen in real life.

Second, developers notoriously have difficulty eking out funds and resources from business minded management. This is by no means trying to suggest that business folks are wrong for questioning the validity of programming resources; in fact, this is the perfect check-and-balance for IT departments that helps those IT folks rethink and reevaluate their technical decisions. Developers are all too quick to jump on a technical band wagon just because it is the cool thing to do. The bottom line is does it really make good business sense?

Third, training is critical to develop programmer skills. The best training, in my opinion, is pair programming in an apprentice type atmosphere. We have somewhat lost focus on apprentice programs. Many years ago, these programs were in place to bring junior craftsman up to speed and develop them into tomorrows artisan. Blacksmiths, carpenters, bricklayers, gardeners, and just about any trade you can think of worked like this. Now, we tend to think that if someone has a degree that makes them qualified to understand proper software construction, and this couldn’t be farther from the truth. College gives us the tools to understand construction, but it doesn’t give us the blueprints to build systems. Those skills are only obtained by actually building those systems under the guidance of an experienced craftsman, and without the experienced craftsman to show us the ropes we are left to trial-n-error and can end up creating some very bad software construction habits.

Fourth, as with any bad habit, bad programming habits are difficult to break. It is much easier to go about your daily development chores building software the same way you did yesterday and the day before, right or wrong. In the case Cut-n-Paste, for example, programmers replicate bad design making maintenance an increasingly difficult task and making software more unreliable instead of better over version releases. This is a huge problem and one that is often unnoticed until it is too late.

Summary

The Solution to all these issues is to have highly skilled developers mentor unskilled ones. Make sure all the development staff has adequate training and tools to do their jobs properly; certainly, but there is simply no substitute for having a true architect to show junior developers the right and wrong way to create software systems. Senior team members create a good atmosphere for development instilling good habits into their team members. Most good habits don’t cost much, if any, additional monetary investment. Good habits are not software tools (such as CASE tools); rather, good habits are how you approach the development processes. Great software can be built using Notepad and index cards just as easily as the Rational Software Suite with Visual Studio. The best ally a development team has is the willingness of it’s own staff to work well together, communicate, and train one another. This requires no expensive development tools so there isn’t really anything to prevent good software development, so why no just do it right!

This might also be called “Refactorings” but I consider all the the following points no matter whether I am building new software or refactoring old software. This has nothing to do with software patterns even though many of the refactorings are considered pattern-like. If you have not read Martin Fowler’s “Refactoring: Improving the Design of Existing Code” then you ought to. You also need to read Dave West’s “Object Thinking” but it is a bit abstract for some folks. Most of these considerations that follow come directly from these texts. There is another text my Joshua Kerievsky called “Refactoring To Patterns” that concentrates more on software design patterns. It is a great book and if you want a better understanding of refactoring then make sure and pick up this book as well.

All the metrics and software engineering that can be discovered, studied, and revealed still can not take the place of experience. In fact, experience is just about the only commodity that results in successful software projects. I also firmly believe that developers need to be mentored in an apprentice type of “farm system” to develop their talents properly and in a timely fashion. This, I believe, is truly the only way to build a successful software team of developers.

Tests

First and foremost, building test suites that are self checking is critical to refactoring and provides us the confidence to go forward with our refactoring efforts. Having test suites to check small changes we make to the code base makes it fairly easy to find bugs we introduce during refactoring. So, take the extra time and build good tests! It will pay off in the long run, I promise.

Refactorings – I keep handy

• Always use clear and descriptive variable names. If you find yourself commenting on what a variable does then you probably need to rethink what you have named the variable.
• Strive to use short methods. This keeps complex code to a minimum.
• Eliminate duplicate code.
• If you are commenting you methods a lot then you should reconsider how to make your code more readable.
• Do not cut and paste code if at all possible. If you find yourself doing this then you should take a close look at why and determine if it is possible to create a method and call that method.
• Do not be afraid to develop small classes to take the work load out of bigger classes.
• Use short, well defined methods with a single purpose (reflected in the method name)
• Use expressions instead of temporary variables
• Replace temporary variables with methods
• Replace long methods with a method object
• Use getters and setters for all private data
• Only use Setters when a property is not read only
• Use data classes instead of records
• Use Breaks or Returns instead of control flags to simplify methods
• Use Nullable objects to test for use
• Use Objects for method parameters to pass lots of information
• Set all methods that are not used outside of object to private

Metrics – good to keep in mind

• Fewer than 100 classes for a project
• Fewer than 1000 classes for an entire business domain
• Number of development iterations should be at least three (3)
• Throw away 25% of code on each iteration
• Maximum of 15 lines of code per method
• Average of 12 methods per class
• Try to totally eliminate nested conditionals and case statements
• Try to discover objects, responsibilities, and collaborators using CRC cards
• Think of all objects in terms of “human” attributes and responsibilities
• Everything is an object
• Objects must be composable (able to break code about and but back together)
• Distributed cooperation and communication replaces centralized control
• Assemble object as in theater: An example is that one person play is very simple to produce but requires a very talented actor.

 string EnvironmentData = "";
 IDictionary environmentVariables = Environment.GetEnvironmentVariables();
 foreach (DictionaryEntry de in environmentVariables)
 {
    EnvironmentData += "KEY: " + de.Key + " - VALUE: " + de.Value + "\n";
 }
 Console.WriteLine(EnvironmentData);

The problem is that every time the string variable EnvironmentData is updated, a new copy is actually created and the old string is then copied into the new copy. This is due to the Immutable string object. Alternatively, we could have used the StringBuilder object to boost performance in this situation. In fact, any time a string is changed more than twice I always use the StringBuilder object:

 StringBuilder EnvironmentData = new StringBuilder();
 IDictionary environmentVariables = Environment.GetEnvironmentVariables();
 foreach (DictionaryEntry de in environmentVariables)
 {
    EnvironmentData.Append("KEY: " + de.Key + " - VALUE: " + de.Value + "\n");
 }
 Console.WriteLine(EnvironmentData);

The performance increase is measurable over many iterations and while it doesn’t seem like much, it adds up over the enterprise; not to mention, it makes for good programming. Try this none sense code to get an idea of performance savings using StringBuilder:

Console.WriteLine(DateTime.Now.ToString());
 string FileData = "";
 for (int i = 0; i < 100000; i++)
    FileData += "HELLO";

 Console.WriteLine(DateTime.Now.ToString());
 StringBuilder FileData2 = new StringBuilder();
 for (int i = 0; i < 100000; i++)
    FileData2.Append(i.ToString());

 Console.WriteLine(DateTime.Now.ToString());

“If you think education is expensive, try ignorance” – Derek Bok

“There is nothing more frightful than ignorance in action” – Johann Wolfgang von Goethe

“Being ignorant is not as much a shame, as being unwilling to learn” – Benjamin Franklin

“He must be very ignorant for he answers every question he is asked” – Voltaire

“The recipe for perpetual ignorance is: Be satisfied with your opinions and content with your knowledge.” – Elbert Hubbard

“Fear always springs from ignorance” – Ralph Waldo Emerson

“Nothing in the world is more dangerous than a sincere ignorance and conscientious stupidity.” – Martin Luther King, Jr.

… and to give stupidity a say in the matter:
“Stupidity is like nuclear power; it can be used for good or evil” – Dilbert

Pascal case

The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. You can use Pascal case for identifiers of three or more characters. For example:

BackColor

Camel case

The first letter of an identifier is lowercase and the first letter of each subsequent concatenated word is capitalized. For example:

backColor

Uppercase

All letters in the identifier are capitalized. Use this convention only for identifiers that consist of two or fewer letters. For example:

System.IO
System.Web.UI

Namespace Naming Guidelines

CompanyName.TechnologyName[.Feature][.Design]
For Example:

Microsoft.Media
Microsoft.Media.Design

Class Naming Guidelines

The following rules outline the guidelines for naming classes:

• Use a noun or noun phrase to name a class.
• Use Pascal case.
• Use abbreviations sparingly.
• Do not use a type prefix, such as C for class, on a class name. For example, use the class name FileStream rather than CFileStream.
• Do not use the underscore character (_).
• Occasionally, it is necessary to provide a class name that begins with the letter I, even though the class is not an interface. This is appropriate as long as I is the first letter of an entire word that is a part of the class name. For example, the class name IdentityStore is appropriate.
• Where appropriate, use a compound word to name a derived class. The second part of the derived class’s name should be the name of the base class. For example, ApplicationException is an appropriate name for a class derived from a class named Exception, because ApplicationException is a kind of Exception. Use reasonable judgment in applying this rule. For example, Button is an appropriate name for a class derived from Control. Although a button is a kind of control, making Control a part of the class name would lengthen the name unnecessarily.

For Example:

public class FileStream
public class Button
public class String

Interface Naming Guidelines

The following rules outline the naming guidelines for interfaces:
* Name interfaces with nouns or noun phrases, or adjectives that describe behavior. For example, the interface name IComponent uses a descriptive noun. The interface name ICustomAttributeProvider uses a noun phrase. The name IPersistable uses an adjective.

• Use Pascal case.
• Use abbreviations sparingly.
• Prefix interface names with the letter I, to indicate that the type is an interface.
• Use similar names when you define a class/interface pair where the class is a standard implementation of the interface. The names should differ only by the letter I prefix on the interface name.
• Do not use the underscore character (_).

The following are examples of correctly named interfaces.

public interface IServiceProvider
public interface IFormatable

Attribute Naming Guidelines

You should always add the suffix Attribute to custom attribute classes. The following is an example of a correctly named attribute class.

public class ObsoleteAttribute{}

Enumeration Type Naming Guidelines

The enumeration (Enum) value type inherits from the Enum Class. The following rules outline the naming guidelines for enumerations:

• Use Pascal case for Enum types and value names.
• Use abbreviations sparingly.
• Do not use an Enum suffix on Enum type names.
• Use a singular name for most Enum types, but use a plural name for Enum types that are bit fields.
• Always add the FlagsAttribute to a bit field Enum type.

An enumeration should have FlagsAttribute present only if each value defined in the enumeration is a power of two, or a combination of defined values.

[FlagsAttribute]
public enum DaysEnumNeedsFlags
{
   None     = 0,
   Monday    = 1,
   Tuesday   = 2,
   Wednesday = 4,
   Thursday  = 8,
   Friday    = 16,
   All       = Monday| Tuesday | Wednesday | Thursday | Friday
 }

Static Field Naming Guidelines

The following rules outline the naming guidelines for static fields:

• Use nouns, noun phrases, or abbreviations of nouns to name static fields.
• Use Pascal case.
• Do not use a Hungarian notation prefix on static field names.
• It is recommended that you use static properties instead of public static fields whenever possible.

Parameter Naming Guidelines

It is important to carefully follow these parameter naming guidelines because visual design tools that provide context sensitive help and class browsing functionality display method parameter names to users in the designer. The following rules outline the naming guidelines for parameters:

• Use camel case for parameter names.
• Use descriptive parameter names. Parameter names should be descriptive enough that the name of the parameter and its type can be used to determine its meaning in most scenarios. For example, visual design tools that provide context sensitive help display method parameters to the developer as they type. The parameter names should be descriptive enough in this scenario to allow the developer to supply the correct parameters.
• Use names that describe a parameter’s meaning rather than names that describe a parameter’s type. Development tools should provide meaningful information about a parameter’s type. Therefore, a parameter’s name can be put to better use by describing meaning. Use type-based parameter names sparingly and only where it is appropriate.
• Do not use reserved parameters. Reserved parameters are private parameters that might be exposed in a future version if they are needed. Instead, if more data is needed in a future version of your class library, add a new overload for a method.
• Do not prefix parameter names with Hungarian type notation.
• The following are examples of correctly named parameters.

For Example:

Type GetType(string typeName)
string Format(string format, object[] args)

Method Naming Guidelines

The following rules outline the naming guidelines for methods:

• Use verbs or verb phrases to name methods.
• Use Pascal case.

The following are examples of correctly named methods.

RemoveAll()
GetCharArray()
Invoke()

Property Naming Guidelines

The following rules outline the naming guidelines for properties:

• Use a noun or noun phrase to name properties.
• Use Pascal case.
• Do not use Hungarian notation.
• Consider creating a property with the same name as its underlying type. For example, if you declare a property named Color, the type of the property should likewise be Color. See the example later in this topic.

The following code example illustrates correct property naming.

public class SampleClass
{
   public Color BackColor
   {
      // Code for Get and Set accessors goes here.
   }
}
public enum Color
{
   // Insert code for Enum here.
}
public class Control
{
   public Color Color
   {
      get {// Insert code here.}
      set {// Insert code here.}
   }
}

Event Naming Guidelines

The following rules outline the naming guidelines for events:

• Use Pascal case.
• Do not use Hungarian notation.
• Use an EventHandler suffix on event handler names.
• Specify two parameters named sender and e. The sender parameter represents the object that raised the event. The sender parameter is always of type object, even if it is possible to use a more specific type. The state associated with the event is encapsulated in an instance of an event class named e. Use an appropriate and specific event class for the e parameter type.
• Name an event argument class with the EventArgs suffix.
• Consider naming events with a verb. For example, correctly named event names include Clicked, Painting, and DroppedDown.
• Use a gerund (the “ing” form of a verb) to create an event name that expresses the concept of pre-event, and a past-tense verb to represent post-event. For example, a Close event that can be canceled should have a Closing event and a Closed event. Do not use the BeforeXxx/AfterXxx naming pattern.
• Do not use a prefix or suffix on the event declaration on the type. For example, use Close instead of OnClose.
• In general, you should provide a protected method called OnXxx on types with events that can be overridden in a derived class. This method should only have the event parameter e, because the sender is always the instance of the type.

The following example illustrates an event handler with an appropriate name and parameters.

public delegate void MouseEventHandler(object sender, MouseEventArgs e);
public class MouseEventArgs : EventArgs
{
   int x;
   int y;
   public MouseEventArgs(int x, int y)
   { this.x = x; this.y = y; }
   public int X { get { return x; } }
   public int Y { get { return y; } }
}

• Database connection pooling helps to take care of finding an available connection and reduce time instead making a new connection
• It is just too much trouble to code for multiple threads access the connection at once
• If the application using the open connection remains idle for a while, the connection could be forced closed by the system causing errors unless you check for an open connection every time you use it.