Klocwork developer Russ Sherk sporting his mo'stache. It's hair today, gone tomorrow.

Time’s a precious resource, so the saying goes. Don’t waste it. That’s particularly true for developers, who live in the critical path lane.

And if there’s someone who knows a lot about time management, it’s Russ Sherk, an intermediate developer here at Klocwork, and the father of three young ‘uns. Russ works on our Klocwork Review and Klocwork Inspect products and handles licensing.

For Russ, these are lessons learned over his six-year tenure at Klocwork.

“These are things you need to think about or you won’t progress as a developer,” he says.

Here’s what to do if you want to waste time:

1. Code without a plan

It’s easy to get carried away with ideas about cool features, Russ says. This is how you burn through the days–by doing a lot of things that don’t need to be done.

The fix: Classic agile philosophy. “You have a story. Then break it up into a list of features that must be done. You take those features and you break them down into tasks taking less than a day, Russ explains. A task taking two to four hours is optimal. The team here uses XPlanner for project/story/task management. You can always augment with pieces of paper.”

2. Switch tasks constantly

Mental switching eats up a lot of time because you need to evaluate where you were before you switched gears, and then go through it again when you switch back.

The fix: Get to a completion point before switching (if you can).

3. Take the idealistic approach to bad or “delicate” code

Inheriting problem code makes debugging and feature work more difficult and error prone, Russ says.

“It’s tempting to want to fix it all–but that will always set you back.”

The fix: Fix what you touch to the best of your ability. Schedule larger-scale refactoring and reorganization work separately.

4. Build infrequently

This strategy goes beyond the individual developer.  There was a time here when there were only weekly builds (Egad! Say it ain’t so!). Even 15 minutes per build slows you down, Russ says. The push by development managers for frequent builds has paid dividends.

“Now, I can go through a build process in 2-4 minutes,” Russ says. That translates into 10 to 15 builds a day.

The fix: Frequent build cycles allow you to make your changes, verify them, and handle bugs quickly.

5. Optimize early and over-engineer

This is the dark side of planning. Over-planning and perfectionism can be paralyzing.

The better approach is to keep it simple, he says.

The fix: Plan the bare minimum to get your feature working. After the feature is in place, it’s time to optimize and refactor.

And there you have it. Surprisingly, World of Warcraft didn’t even make the list.

As we have posted in the past, refactoring is a very useful technology to help developers become more productive.  I wanted to take a deeper look at how certain refactorings such as “Extract Function/Method” and “Introduce Variable” can be further enhanced with clone detection.

For the focus of this post I will concentrate just on Extract Function/Method.  Say I create some code that I know I will use frequently.  It would make more sense to create a reusable function/method.  Of course I can add a function to my file then pass the proper parameters and function call, or I can click the extract function refactoring which does this automatically for me.

void dosomething (int a, int b)
{
...
   int c = a + b;
   printf("result= %i ",c);
...
}

Now if I select the two lines and run extract function, it will ask me for a name of the function, I’ll call it “add” and we end up with this:

void add (int a, int b)
{
   int c = a + b;
   printf("result= %i ",c);
}

void dosomething (int a, int b)
{
   add(a, b);
}

Same idea for Introduce variable.  Except it works with an expression and replaces it with a variable name of your choice.

So obviously extract function and introduce variable has value,  anything you can do to make the development process more automated can only make you more productive.  But let’s take a look at how we can improve on this and show where you can really take advantage of the power of refactoring.  In most cases you are working with existing code with plenty of duplication.  This is where clone detection comes into place.  Essentially clone detection is the process of finding the same pattern you just highlighted with special attention to code semantics.  This means you now get immediate notification that there are other areas of duplication, even if variable names might be different, and replace with a click of a button.

Taking the simple extract method function, let’s say we have similar code many lines later.

void dosomething(int a, int b)
{
   ...
   int c = a + b;
   printf("result= %i ",c);
   ...
   int d = a + b;
   printf("result= %i ",d);
   ...
}

Now if we run extract method, you get notified about each clone and the choice to replace.

void add(int a, int b)
{
   int c = a + b;
   printf("result= %i ",c);
}

void dosomething(int a, int b)
{
   ...
   add(a, b);
   ...
   add(a, b);
   ...
}

This is a file level refactoring so clone detection can even apply to multiple functions in the same file!   So hopefully with this you will have a new found love for what refactoring can do you.

Today I wanted to talk about new kinds of benefits you can get from Refactoring.  Everyone knows that refactoring is the process of simplifying and clarifying code without changing the program’s behavior.  The benefits include making the developer more productive by providing tools to automatically clean up the code.  Some of you may be aware of the common refactoring such as “Rename” to rename a variable, parameter or function in your code. Or Extract Function to create a function call and body based on some selected code.

These are great and provide important value but imagine now being able to get additional benefits of reduced compile times and reduced system size in addition to the increased maintainability and reduction of complexity.  All this with a “Optimize Headers” refactoring.

For those who write Java code know of a similar refactoring called “Optimize imports”.  The optimize headers refactoring is for C/C++ code to optimize your include directives.  Specifically it is looking for extra includes and missing transitive issues.  For extra includes you need to analyze the system build structure for that file and identify if any identifiers from the included file are used.  If not then simply remove.  That will reduce your build time, system size and clean up your include structure.

Missing transitive include issue is something that consists of 3 or more files.  For example file A includes B, then B includes C.  But if file A is not using anything from B then you should remove that include and replace it with C (because file A uses identifiers from C).

I’ve added a video that shows how this is done with Eclipse.  So if you thought refactoring is just about code reuse and maintainability think again.

I recently read a book by Peter Ritchie called “Refactoring with Microsoft Visual Studio 2010” and thought I would give my review.

Great book to really help you get started with Refactoring.  Ritchie first goes into an introduction of refactoring and some of the tools available in Visual Studio 2010.  He then provides techniques to help you identify code that might need to be refactored along with examples and step by step procedures to refactor the code.

The focus of this book is not necessarily with Visual Studio 2010, as many of the refactoring examples he goes through do not even have a solution with Visual Studio, but more with a focus on C# code.  When I first ordered this book it wasn’t entirely clear to me that C# was the only language of focus.  That was a little bit disappointing for me because at Klocwork our focus is on refactoring for C/C++.  I guess I’m not surprised as not too many tools are providing a refactoring solution for C/C++ developers.  But with that said even though all examples are C#, what it really helps you understand is where and when to refactor and that is language independent.

I think Ritchie really describes the question of “why refactor” brilliantly.  The point of refactoring vs. rewriting is to fix something that’s not broken.  But as Ritchie states, he is a believer in if it ain’t broken, don’t fix it, but unless your code base defies all reality, it is likely that your code is constantly evolving and getting more complex.  Hence the need to refactor.

Another important point made by Ritchie is that refactoring falls into the developer’s hands.  It is not a task that keeps building up until you identify numerous backlog’s of refactoring.  It is something you need to do daily, as needed.

Overall I enjoyed the detail and examples provided and recommend it to any.  I hope to talk a little more on how Ritchie relates metrics to refactoring in another post.

As new words and concepts diffuse in to wider use, their definitions become simpler or broaden to cover more scope.  Like the kid’s telephone game, each time the concept is passed to another developer, the information gets a little more muddled. In software development, declaration, macros, syntax and other programming constructs have to be exact or the compilers will fail.  Yet, when developers discuss concepts about programming, most of the time, that precision of language is lost.

The telephone game  seems to have happened to refactoring.  I subscribe to what would be consider the  ”classic” definition of  refactoring: the process of optimizing or extending a class  but leaving the existing exposed interface alone.  It seems that refactoring has been generalized from that definition into covering all activities related to touching old code.  Even worse, it has become an excuse to rework someone else’s code and then bitch about how bad it was.  Just look at the twitter stream for refactoring for a never-ending torrent of  abuse.

There is one simple way to tell if your efforts are truly a refactoring or not.  Did you break any of the unit tests?  If you did, then you are rewriting code instead of refactoring it and you had better update all the test cases while you’re at it.  Don’t get me wrong, there are times to rewrite software, but they are few and far between and, in my experience, it almost never pays off.

Refactoring isn’t just a nice philosophical idea; it supports one the most basic concepts in software development–backwards compatibility.  If you want to keep your customers and enjoy that paycheck, don’t break features or APIs in products without good reason or  get buy-in before release day.

To refactor the medical phrase “First, do no harm“, for developers it should be “First, break no test”.

There has been lots of discussion on this blog (and others for that matter) on the importance of early defect detection, refactoring, and code reviews, but what does it all mean to a team of developers trying to maximize their velocity in a 2 week iteration? Based on a number of studies, and some real-world customer feedback  we have put together the following ROI…but note that this ROI is not measured in dollars, but rather in hours saved, because a development team can more easily relate to a 20 hour time savings per iteration rather than a break even point of 14.5 months. A few assumptions first…the team is made up of 10 developers, working on 5 stories (each story creates about 300 LOC) every 2 week iteration. Also, we used internal estimates for the refactoring time savings since we couldn’t find any 3^rd party data on refactoring ROI. . If you have anything more concrete, I’d love to hear about it.

From this table (which has been a regular slide in our Agile in Action roadshow series) we see that tools can help, in this example just over 40 hours/iteration, which if you break that down further works out to about 1/2 day per developer every 2 weeks. Now that is an ROI that an agile development team can relate to…

Refactoring is a vital component for software developers, helping to prevent their projects from becoming unusable, and unmaintainable spaghetti code. Equally important to some developers, is the notion of refuctoring…check out this tongue in cheek look at Refactoring vs. Refuctoring. Be sure to check out the slide deck at the end.

Refuctoring describes the process of making your code unmaintainable by anybody but yourself.  I love some of the examples of Refuctoring such as “Pig Latin”, “Treasure Hunt” and my personal favorite “Stating the Bleeding Obvious”:

For example:

//initialize a to 1
int a=1;

Not that I’d ever do that (pause while I go clean up some code). Ahem, right anyways I thought I’d throw out some other refuctorings:

1.    “Catch me if you can” – Use so many goto statements that it will make anyone’s head spin.  Especially when you start adding backward goto’s.  Take a look at the CVS source code,  they have some nice (nasty) examples.

2.    “Giant tar pit of hell” – This is hard to blame one single developer as it really encompasses many developers getting together to create one big cohesive piece of crap.  You know you have a problem when you run out of printer toner trying to print these.

"Giant tar pit of hell"

3.    “WTF” – Using names that no one will know…ever.  If you create a bankaccount object, instead of calling it ‘x’, here’s a wild idea, why not call it ‘bankaccount’.  Let’s face it we are all guilty of this.

Now if you really want to be special (I don’t mean in a good way), try combining #1 and #3:

int afunction()
{

there:
   ...
   if(something)
   {
      goto here;
   }
   if(somethingelse)
   {
      goto there;
   }
here:
   ...
   if(somethingelseagain)
   {
   goto end;
   }
end:
...
return;
}

I have to admit, I’m not winning any awards either. It is certainly time to get on the refactoring bandwagon.