With our latest product release, we have ventured into the world of Apple. Yup, our product is now officially supported on the Mac.

I think I can safely say that this was not something on our roadmap a few years ago, but we recognized the trends, and now have this offering for our customers. With this support, it was determined that we needed a few more Macs in the organization, the Product Management team included. Now, I’m not sure I stepped forward, or everyone else stepped back (except me), but I ended up being the PM Mac guinea pig.

I have been using PCs since, well for a long time, so this was definitely going to be a learning experience. Let’s say that Google and I became very good friends the first couple of weeks with my shiny new Mac.

In my travels, I stumbled across this article that lists the top 30 mistakes made by new Mac users. Even though this article is a little old, it is amazing how many still apply. Here are a few that I have already qualified for:

15. Installing a program every time they want to run it because they think the installer is the program.

16. Where’s “the internet”? (looking for the Windows Internet Explorer “e” icon)

19. Looking in vain for an uninstaller app, because they don’t realize that uninstalling an application on Mac is as easy as dragging the program icon into the trash.

23. Saving everything to the desktop or somewhere on the hard drive other than their home folder

These are just a few of my favorites, and I’m sure I’ll fall into a few others. Someone once told me that if you need to do something on a Mac, pretend you don’t know anything about computers, and think to yourself what the easiest way might be to accomplish that task. Chances are that is how it has been implemented on the Mac (see #30 in this list). Anyone run into any other goodies that aren’t listed here?

I don’t know why, but every time I go back to some simple shell scripting I can never remember the one liner for loop.  For those who know what I’m talking about, it is the one command you need over and over again when it comes to performing the same thing on a set of files.  I can never seem to remember the simple syntax and it always leaves me scratching my head.

So I thought I would ask a forum on shell scripting and  was promptly answered with:

for file in `ls`; do rm -rf $file; done

I don’t think they were very friendly.  Although they have the syntax correct, please don’t try this at home.  If you don’t know why, please turn off your computer.  In the end, a simple Google search brought me to this blog with all the details.

So in the end a simple command to create copies for all my .java files to .java.bak:

for i in `find . -name "*.java"`; do cp $i $i.bak; done

Don’t forget, those are executable quotes that you’re using for the find command.  Maybe there’s a better way to do this, but in the end I find the one liner for loop very handy…if only I can remember it.

On another note, I tried this with my Windows Cygwin installation and it doesn’t work.  Anyone with insights into that?

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.

While I may not be the most active Twitter-er in the world, the one thing I have noticed is that there is an awful lot of activity around the term “code review” lately. Since code reviews have become a widely used practice, I thought I would share one of my experiences about code reviews with you, from a product manager perspective.

In my first Agile team, many years ago, it was tabled (in our retrospective meeting after a couple of Sprints) that code reviews should be added to our definition of “Done”.  Let’s just say my initial response was less than enthusiastic… but why was that?  Well, in my opinion (perhaps uneducated on this topic), doing code reviews seems to add more to the time it takes to finish stories, so that means less stories are getting done per iteration, which potentially means longer release times, or releases with less functionality than hoped for. This is not something a Product Manager is usually receptive to. After some debate, we put it to a vote where the “yays” defeated the “nays” by a fairly healthy margin (okay, it missed being unanimous by one vote).  So we updated our “Done” criteria and moved into our next Sprint.

Our next couple of sprints went off similar to our earlier sprints, I didn’t really notice any differences. We seemed to have about the same number of stories being started and completed, and I for one was mildly surprised that we were able to maintain the same velocity, even with the extra process of doing code reviews for each story. Curious, I decided to talk to one of the more senior developers about what was going on. He walked me over to our Scrum board and asked me if anything looked different. Nothing jumped out at me initially, until he pointed out that the number of ‘bug’ cards (the dreaded red cards) were significantly less than in those early iterations. He proceeded to tell me that the code reviews were playing a major role in this. Developers were finding things early and fixing them before passing the code onto the testers, leaving the testers to focus on testing the actual features …crazy, I know.

It really appeared as though the code reviews were producing better code, without actually slowing down the development process. My opinions of code reviews did a complete 180…now they were helping to contribute to better quality code that I could show our customers, without having to sacrifice anything in the way of release delays or velocity degradation. I had become a believer!

 I think I have something to Twitter about now…

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.