Great free tool: CodeRushExpress

CodeRush now provides a free version of their tool called CodeRush Express. You can download it from this URL:
http://www.devexpress.com/Products/Visual_Studio_Add-in/CodeRushX

They also provide a nice list of features and short tutorials on each.

If you are not familiar with the features that CodeRush or ReSharper provide that can increase developer productivity in Visual Studio .Net, this is a great way to learn.

Gold-plating the code

Developer society has given the phrase “Gold-plating” a stigma similar to “socialized” in the political world.

Some things that appear to be gold plating may not really be gold plating. Recently, while developing a web site, we decided to incorporate support for WCAG even though it was not part of the requirements. That sure screams “Gold-plating”, doesn’t it. At first I thought so, but on second thought I realized that it does not. The only support we really added for WCAG was to use PNG images instead of JPG images. It didn’t really take us extra time to implement, other than the time taken to be aware of WCAG compliance.

Sometimes it is good to think about future possible requirements because they can alter a decision that you make today. Without considering future possible requirements, some decisions appear completely arbitrary, such as PNG or JPG, but when you consider likely future requirements, you see that one choice will work better than the other.

Explaining “Refactoring” to non-programmers

Many programmers use the word refactoring to describe the changes they make to existing code that doesn’t add any new features or fix any existing bugs. The obvious question that should arise is, “Then why are you doing anything to the code?” The answer is usually, “We need to re-write the code before we can add new features to it.”

Here is an example of a case where we needed to refactor some code:

In version 1.0 of our software, we stored metadata about all our objects (Customers, orders, etc.). For example, we stored that the FirstName or the customer object was a 50 byte string, and that the ID of the customer was an 8 byte integer). We used that metadata to dynamically build web forms with all the fields from each object.

In version 2.0 of our software, we used the same metadata to build a gridview of all objects (Customers, orders, etc.). We discovered that we wanted to allow some fields in the grid that we did not allow in the form, so we implemented a workaround to support this.

In version 3.0 of our software, we added support for a new type of field that linked to other objects, which required us to workaround the workaround we implemented of the second release.

Now, in version 4.0, we want to add more options to the grid that will require us to workaround the workaround of the workaround; OR, we can possibly refactor the software so that it does not have workarounds. This means we will change the design so that our code and database store more information to eliminate the workarounds. For example, instead of hardcoding workarounds such as, “If this is the customer object and it is the zip code field, …”, we add a flag in the database that we set to true for the customer object and the zip code field, and then our code can just check this flag and implement the desired behavior. This new code is easier to maintain and support and build upon.

This is a very simplistic example of refactoring, but hopefully it can provide some understanding to non-programmers of the importance and value of refactoring