Recently I spent 2 Weeks helping a project clear its Technical Debt. Here are some results:

Topic	Before	After
Project Size	Production Code Package = 7 Classes = 23 Methods = 104 (average 4.52/class) LOC = 912 (average 8.77/method and 39.65/class) Average Cyclomatic Complexity/Method = 2.04 Test Code Package = 1 Classes = 10 Methods = 92 LOC = 410	Production Code Package = 4 Classes = 20 Methods = 89 (average 4.45/class) LOC = 627 (average 7.04/method and 31.35/class) Average Cyclomatic Complexity/Method = 1.79 Test Code Package = 4 Classes = 18 Methods = 120 LOC = 771
Code Coverage	Line Coverage: 46% Block Coverage: 43%	Line Coverage: 94% Block Coverage: 96%
Cyclomatic Complexity
Obvious Dead Code	Following public methods: class CryptoUtils: String getSHA1HashOfString(String), String encryptString(String), String decryptString(String) class DbLogger: writeToTable(String, String) class DebugUtils: String convertListToString(java.util.List), String convertStrArrayToString(String) class FileSystem: int getNumLinesInFile(String) Total: 7 methods in 4 classes	Following public methods: class BackgroundDBWriter: stop() Total: 1 method in 1 class Note: This method is required by the tests.
Automation	Maven for Automated Build Cobertura for Code Coverage	Ant for Automated build Hudson for Continuous Integration Migrator for automating Database migration process JUnit to write End to End functional Tests JUnit and Mockito for unit testing Panopticode for visualizing software metrics Emma for Code Coverage Checkstyle and JavaNCSS for Static Code analysis JDepends for calculating design related metric StatSVN for generating SVN Usage Reports Dead Code Detector for analyzing Dead Code
Version Control Usage	Average Commits Per Day = 1 Average # of Files Changed Per Commit = 2	Average Commits Per Day = 4 Average # of Files Changed Per Commit = 9 Note: Since we are heavily refactoring, lots of files are touched for each commit. But the frequency of commit is fairly high to ensure we are not taking big leaps.
Coding Convention Violation	976	0

Something interesting to watch out is how the production code becomes more crisp (fewer packages, classes and LOC) and how the amount of test code becomes greater than the production code.

Another similar report.

Steve has an interesting blog on how he discovered Refactoring. He also highlights how developers have become so dependent on automated refactoring tool that they refuse to accept dynamic languages like Ruby; because it does not have automated refectoring tools yet.

Personally if I’m using a Static language like Java or C#, I really appreciate the automated refactoring tool support. But I think its lame not to embrace dynamic or funcational languages because they don’t have automated refactoring tools. In my experience the amout of refactoring tool support you need in these languages is drastically reduced because its a different programming style/pradigm.

I just spend the last 3 hours pairing with Michael Feathers, who is on this way to the airport. Michael spent the last 2 weeks in India. During this stay in India he presented a tutorial on Working Effectively with Legacy Code in Delhi, Bangalore and Mumbai. He presented some simple yet powerful techniques of dealing with various issues in Legacy OO code. 

Recently I came across a very successful company which builds infrastructure related servers. The company has 13 people. I spent some time watching how the company works. What really caught my attention was, they were not using TDD. Forget TDD, they did not even have any concept of Tests or Testers in the company. On an average, they had a release cycle of 3 weeks and they would throw away their products every 3 months. Zero time was spent on refactoring and maintaining existing products.

Their business is in such a market that new technology and new ways of doing stuff keeps coming up every 2-3 months. So either they can take their existing products and enhance them to add the new features or they can take the latest product in the market and tailor it to their needs. Usually a lot of their products are built on open source products.  In some cases they just hire the open source author and asked him/her to customize the open source product so that this company can really adapt it to their needs.

Not always they find open source products out there. In those cases, the company would form 3 teams of 3 developers each and basically ask each team to build the same product with whatever their choice of technology was. Which ever team finishes first, would release the product. When the second team was done, they would compare the first one with the second one. If the second one was better on various parameters that mattered to the company, they would throw away the first one and release the second one.

According to the founder of the company throwing away stuff was cheaper than enhancing the existing one.

In general TDD and Refactoring are great practices to have on a team, but don’t be dogmatic about it.

Intent

Provide the participants with a hands-on-experience of real world refactoring by taking an open source project and refactoring it.

Summary

Refactoring is a very well established practice not just in the Agile Community, but outside as well. Following are some of the books that have been published on this subject:

• Refactoring: Improving the Design of Existing Code: Martin Fowler
• Refactoring to Patterns: Joshua Kerievsky
• Working Effectively with Legacy Code : Michael Feathers

Unfortunately, in-spite of such great knowledge available, there are lots of misconceptions around refactoring. The word “refactoring” is often used in a broad context where “enhancement” or “rewrite” would be a better term, and can cause nightmares to project stakeholders.

This session is an attempt to help the development community understand refactoring a little better. It will provide a hands-on opportunity for developers to explore these concepts in action. This session will try to amplify the participant’s learning process by pairing them with other practitioners and peers.

Slides

http://www.slideshare.net/nashjain/refactoring-fest

Intended Audience

This session is suited for developers and architects who are interested to learn how to refactor real projects.

Benefits

After attending this session, the participants should be able to:

• Build a common vocabulary in the refactoring space
• Identify code smells
• Eliminate code smells by applying the simple refactoring techniques explained in Martin Fowler’s “Refactoring”
• Write better unit/functional tests for legacy code
• Understand some of the techniques and pitfalls in refactoring legacy code in the absence of unit and functional tests [“Working effectively with legacy code “]
• Take existing code and refactor it to standard design patterns [Refactoring to patterns]
• Learn about the internals of the open source project chosen to refactor
• Know where to look to continue learning the techniques of refactoring

Content Outline

Section 1 – 90 Minutes

Iteration 0 / Overview : 45 mins

1. 20 mins: Quick overview about refactoring with some examples.
2. 10 mins: High level overview of the open source project’s design
3. 05 mins: The participants form pairs and each pair picks up a module/package of the open source project.
4. 10 mins: The participants spend time understanding the functionality of the module/package picked up by the individual pairs.

Iteration 1 : 45 mins

1. 10 mins: I’ll show 2-3 simple code smells, explain associated refactoring techniques.
2. 15 mins: Each pair identifies one or more classes from the module/package, which has these code smells. They try and understand what it does, in the process they might do some basic refactorings like extract method and rename variables/methods. Eventually the goal is to writes one or more unit tests around it. Once they have sufficient passing unit tests [safety net], they start cleaning up code by applying some advanced refactoring techniques. In some cases, sufficient unit tests might not be required to do simple refactoring like extract method, rename variable, etc. Sometimes internally restructuring the code, can help us understand it better. Hence the participants will have to constantly switch between ‘understanding’, ‘unit testing’ and ‘refactoring’ hat.
3. 20 mins: The pairs stops refactoring. Couple of pairs connect to a central project and demonstrates their accomplishment to the rest of the group. We can break into a discussion about each team’s refactorings.

Break – 30 Minutes

Section 2 – 90 Minutes

Iteration 2: 40 mins

1. The pairs swap partners so that each team gets a new member and one old member continues on the selected module/package.
2. 10 mins: I’ll show 2-3 little more complicated code smells and explain associated refactoring techniques.
3. Pairs try to apply these refactoring techniques for the next 15 mins.
4. At the end of 15 mins we have another 15 mins demo and refactoring discussion.

Iteration 3: 40 mins

1. The pairs swap partners again.
2. 10 mins: I’ll show 2-3 more complicated code smells and explain associated refactoring techniques.
3. Pairs try to apply these refactoring techniques for the next 15 mins.
4. At the end of 15 mins we have another 15 mins demo and refactoring discussion.

10 Minutes – Retrospective

• What worked? The participants indicate what they learned.
• What did not work?
• What to do differently next time? Suggestions from participants on how to improve the session.

Infrastructure Required

• U shaped table setup with a projector at the center of the table which can connect to all the computers.
• Either the participant get their own laptops with required software setup or we provide the participants with computers. We’ll need 10-15 computers for the participants. Each computer is set up for a pair [2 chairs]. The presenters will set up the computers with the required software a day in advance of their session.
• 10-15 flip charts, one per team.

Pre-requisites for attending the session

1. Object Oriented Programming
2. Java and Servlets knowledge [don’t worry too much about this, pairing can save you]
3. You need the following software setup on your machine before you come:

1. Latest Eclipse IDE for Java Developers
2. Latest Sun JDK
3. Latest Apache Tomcat Web Server
4. Latest Very Quick Wiki

Set up instructions:

1. After downloading, JDK, install it
2. Set the JAVA_HOME env variable is not already set
3. Unzip eclipse and try running eclipse executable [eclipse.exe]
4. Unzip tomcat and try running startup.bat or startup.sh from the bin folder
5. Take the vqwiki war and drop it into tomcat/webapps folder. Depending on the version of vqwiki you have downloaded, there will be a folder created under tomcat/webapps called vqwiki-x.x.x Where x.x.x represents the version number. For the purpose of these set up instructions, please replace x.x.x with your correct version number. Example if you have downloaded vqwiki version 2.7.8, then replace x.x.x with 2.7.8
6. Start your favorite browser and go to [http://localhost:8080/vqwiki-x.x.x] Make sure the vqwiki page shows up
7. Go to tomcat/webapps/vqwiki-x.x.x/WEB-INF/classes folder. Copy all the files expect the vqwiki folder to WEB-INF/src folder
8. In Eclipse, create a new project called vqwiki. While creating the new project select the option “create project from existing source” and point it to the tomcat\webapps\vqwili-x.x.x folder
9. Project would have compile time issues, since it needs the servlet.jar which is under the tomcat/common/lib folder. Add it to the libraries under the Java Build Path tab. Make sure that the code compiles without any problems.
10. If you don’t want to start and stop tomcat from command prompt, there is Sysdeo/SQLI Eclipse Tomcat Launcher plugin for eclipse which can simplify some of those issues. Please note that this is optional.
11. If you want changes to your classes being automatically detected by Tomcat, add the following line to tomcat/conf/server.xml

<Context path=”/vqwiki-x.x.x” reloadable=”true” docBase=”vqwiki-x.x.x” />

Note: Some of you might already have lots of these set up. Use your judgment if you want to skip some steps.