I’ve been talking with a few of my programmers the past few days about the concept of throw away code, asking them if they’ve heard of the concept, or if they’ve thought about implementing it on their teams.   All but one of them replied back to me with variations of “what a waste of time”, or “why would I want to code knowing I”m going to throw it away?”.

Spike Solutions:

Extreme Programming defines spike solutions as:

Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build a system which only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story’s estimate.

When a technical difficulty threatens to hold up the system’s development put a pair of developers on the problem for a week or two and reduce the potential risk.

The concept of throw away code is to practice coding to solve a technical problem, or practice implementing various design patterns / practices.  When your done practicing throw the code away and either start over, or implement what you’ve learned from the practice session.   When you’ve reached the end of your session then throw the code away and start over your next session.

Have a goal for each session.  Setting a goal such as learning how to implement the strategy design pattern, finding a solution for a technical / design issue, or testing out a new testing framework will help you stay focused and meet your goal.

Keep your practice sessions short, I like to keep them between 30min and 2hours, but never more than 2 hours.  Going past your set time for your session often times works against you and causes you to loose focus on your goal.  I’ve also experienced greater difficulty in convincing the business in approving longer session times.

Combining these sessions with pair programming also provides a great means for knowledge sharing with your team members. Whether you need to show a new team member your software library / framework, introduce them to TDD, or learn a new design pattern this is another good tool for you to use to help reach your goals.

So don’t be afraid to throw away your code.  In fact I encourage you to implement throw away coding sessions (aka spike solutions) in your team.

Clean Naming:

Clean names reveal intent.
Clean names reveal intent.
Clean names reveal intent.

The point I’m trying to get across here is that good clean names reveal intent.  So what do I mean by this?  Names should tell what it does, why its there, and how it’s used.  You should not have to add a comment to explain what the intent is.  This applies to variables, functions, and class’s.

Let’s take a look at an example:  Before scrolling down to the “clean” version of this example try to determine what the intent of this code is.  After a bit of study, you will determine what the intent is.

public List<int> GetThem(int num1)
        {
            List<int> myList = new List<int>();
            int num2 = 2;
            int num3 = 0;
            myList.Add(num2);
            for (num2 = 3; num2 <= num1; num2 += 2)
            {
                for (num2 = 3; num2%num3 != 0; num3 += 2)
                    if (num3 == num2)
                    {
                        myList.Add(num2);
                    }
            }
            return myList;
        }

Now take a look at this example we can see what the intent of function and each variable.  By taking the time to use better intent revealing names we can reduce the amount of comments needed and have cleaner code.

public List<int> GetPrimeNumbers(int upperLimit)
        {
            List<int> PrimeNumbers = new List<int>();
            int testNumber = 2;
            int checkNumber = 0;
            PrimeNumbers.Add(testNumber);
            for (testNumber = 3; testNumber <= upperLimit; testNumber += 2)
            {
                for (testNumber = 3; testNumber%checkNumber != 0; checkNumber += 2)
                    if (checkNumber == testNumber)
                    {
                        PrimeNumbers.Add(testNumber);
                    }
            }
            return PrimeNumbers;
        }

Exception Handling

Tip #1:  Avoid generic exception handling.

Okay now before you start spamming me with comments, emails, general hatred let me explain why.

Generally when we catch a generic exception its to take care of “unhandled exceptions”.  While we don’t want unhandled exceptions presented to the customer we don’t want to default to using Try/Catch blocks just to handle a generic exception.  When we handle an exception we need to know what we are handling and why.

Tip #2:  Instead of returning error codes throw custom exceptions.

Checking return codes for errors can cause unnecessary code noise .  Instead throw a custom exception and catch that exception instead.

Tip #3:  Wrap 3rd party COT’s exception handling in a local custom exception class.

Most 3rd party COT’s exceptions are meaningless to our applications.  It would be better to catch those exceptions together in a local class and throw more meaningful exceptions.

These are just a few areas to look at when coding to help ensure clean code.

Have fun.

David Yancey

Martin Fowler defines ‘refactoring’ as:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a ‘refactoring’) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

When I first started to look at our library of Legacy Code my first thought was to just scrap the library and start over.  Now try to sell that idea to the stake holders.  Not going to happen is it.  So that’s where refactoring come’s in.  But there are a few obstacles we have to over come in this process.

1. Sell the process to the product owner/business:
   J.B Rainsburger used an analogy that helps us with this obstacle.  The use of credit cards.  Each time we purchase an item with a credit card, we are purchasing that item with something we don’t have which is money.  Now let’s take this and apply it to programming against that library of legacy code.  Each time we do we are developing on credit and spending something we don’t have which is time.
2. Single Methods with large amounts of code:
   First let me refer you to an excellent book by Michael Feathers titled Working Effectively with Legacy Code.  In this book Michael suggests that we take that method and create a class with only that code.  With this class we can now start writing unit tests for the code and begin refactoring.  Now in our legacy code where we just pulled the large method from create a call to the method in our new class. 
3. Duplicate Code:
   “When N things need to change and N>1, Shalloway will find at most N-1 of these things.”  Basically what Alan Shalloway is saying here is that if you have more than 1 duplication of code chances are high you won’t find all instances of that duplication.  This is where design patterns come in and the phrase “refactor to patterns”.
4. Where do I start?:
   The hardest obstacle to overcome is where to start.  Practice
   • Start off by finding a section of code that you feel may could use some refactoring. 
   • Work on refactoring it for 30min.
   • Throw that code away. 
   • Take a break
   • Repeat.

   “Throw away my code!!!” you might be saying to yourself right now. Yes, Throw it away. What this does for you is reminds you that you are just practicing and 2nd it separates you from your code.

5. TDD and Refactoring?:  Yes its possible.  As you go through your refactoring you’ll see that you are refactoring to patterns, while you are doing this, ask yourself “how would I want to test this code?”  Retrain your way of thinking in how you approach code and you’ll soon find yourself refactoring through TDD and Design Patterns.

So there you have a few tips on how to overcome a few obstacles when you start to look at refactoring your legacy code for the first time.

David Yancey

I just got back from the Agile Development Practices by SQE and I felt like I was in the minority there.  As I went from sessions on TDD to Design Patterns to Refactoring each time it was asked what platform each of the developers were on I was one of 2 or 3 that mentioned .NET.  The majority was Java with a small representation of Ruby developers, which on one hand I’m glad because I got a great exposure to Java and Ruby, however on the other hand it raises the questions as to why.

So what is Agile?

Agile Manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Looking at the principles behind the manifesto we see more of what really is the driving force of the Agile movement and begin to understand why it is important to all developers to grasp this concept.

1. Our highest priority is to satisfy the customer
   through early and continuous delivery
   of valuable software.
2. Welcome changing requirements, even late in
   development. Agile processes harness change for
   the customer’s competitive advantage.
3. Deliver working software frequently, from a
   couple of weeks to a couple of months, with a
   preference to the shorter timescale.
4. Business people and developers must work
   together daily throughout the project.
5. Build projects around motivated individuals.
   Give them the environment and support they need,
   and trust them to get the job done.
6. The most efficient and effective method of
   conveying information to and within a development
   team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.
   The sponsors, developers, and users should be able
   to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence
   and good design enhances agility.
10. Simplicity–the art of maximizing the amount
    of work not done–is essential.
11. The best architectures, requirements, and designs
    emerge from self-organizing teams.
12. At regular intervals, the team reflects on how
    to become more effective, then tunes and adjusts
    its behavior accordingly.

The early continuous delivery of quality working software through continuous attention to simplicity, technical excellence, good design where the business and developers form a team to work together frequently reflecting how to become more effective through self organization.

This is just the beginning however, Agile goes beyond just what is stated in the manifesto.  There are methodologies for all aspects of the business, from the executives with LEAN, to the team with SCRUM down to the individual developers with XP (Extreme Programming).  Some of the concepts with in XP will be quite familiar to the .NET community, such as Test Driven Development (TDD) and Pair Programming. 

I want to encourage all developers to really look into what Agile has to offer and then take it to your business and challenge them to implement Agile as your new methodology.  If you are already doing Agile then start speaking up about it.  Make your presence known and help evangelize Agile in the .NET community.

David Yancey