Dec 29 2011

Good Bye Code Reviews, Pair Programming is the Silver Bullet….

Category: Continuous Integration,Software DevelopmentPhil @ 12:01 am
I actually wrote this post last March, but never got a chance to publish it. That pretty much sums up my year!!! I don’t think I was ever really happy with the way it flowed or the exact point I wanted to make. However, after working with some different teams this past year, I’m even more convinced that code reviews and standards should exist and be enforced. Good topic for another post!

I might have said this in a previous post, but I believe that many developers use Agile as an excuse to avoid following institutionalized processes. They prefer to make up their own extremely lightweight methodology, doing only the activities they enjoy or believe they have time for. By adopting an Agile process, many claim they can eliminate the need for analysis, design, and even code reviews! Personally, I don’t believe this was the intention of the Agile methodology. However, given the substantial number of quality gates and sign-offs that organizations institute to ensure the elimination of mistakes, it is no wonder that Agile becomes the easiest method to subvert corporate mandates and deliver software. I completely understand the theory and goal of these mandates, but it does seem that by the time they are institutionalized, the overhead of the process is more complicated than the actual business to be solved! And before anyone corrects my association of Agile and Pair-programming, I do realize that Pair-programming is a tenant of Extreme Programming, not Agile. Unfortunately, many people seem to commingle the Extreme Programming principles with Agile; XP tends to generate negative connotations in some groups, while Agile is complete accepted.

Not so recently, a coworker sent me a question, wondering if I thought that Pair-programming eliminated the need for code reviews. I have actually heard this claim by several Agile teams in the past, using pair programming as an approach to avoid the code review process. There are several reasons that developers are quick to forgo code reviews, I believe the two most prevalent reasons are:
  1. Code reviews are done as an SDLC requirement; not because the development team actually desires to conduct them or finds value in them.
  2. The vast majority of code reviews are completely ineffective; there is no preparation, no structured process, and no follow through on findings.

There is actually a lot of Internet discussion on this subject; I have included a few links at the bottom of this post which I found interesting. None of them changed my personal views, in that code reviews cannot (should not) be eliminated from the process. One point that I would concede, is that pair-programming could make the code review process easier, assuming that fewer issues will be discovered during the review.

I believe that code reviews should be a “continuous process” during the entire development cycle; whereas most people consider the code review to be a process point. Some believe that the review is something that happens at the end of development, after the code is completed, after it has been tested; typically when it too late in the process to make corrections. I feel that code reviews are a never ending cycle of four basic activities, all contributing to the overall quality of the code base.

  1. The easiest and cheapest process is through automation. There are two basic solutions, the IDE and a Continuous Integration Server. Your IDE can be one of the most effective tools. Eclipse can be configured to share coding standards and validations across the development team, eliminating numerous bad practices at their point origin. Tools such as Checkstyle, PMD, and FindBugs can easily be incorporated into your IDE. These same validations (rules) can also be utilized by your Continuous Integration server, providing the final conformance checks. Automation eliminates almost all of the soft issues from the review process and even promotes better coding practices.
  2. Pair-programming is a very valuable technique and I enjoy the collaboration and education that happens during the process. However, I’m not sure that pair-programming works on all teams, there needs to be a real sense of openness and cooperation for the pairing to be effective. And there lies the real issue, if the pair is very cohesive in their approach, you have the problem of “group think”. If everyone is thinking the same way, it will be much harder to discover issues outside of their common perspective. I believe that code reviews can be more effective when conducted by people who are not wed to the design and/or implementation; an external perspective is always valuable to the process. Another small problem is related to traceability, without the review, there are no review artifacts or documentation to support the process. Next you have the practicality of the schedule. Assuming that you can eliminate the code review process by requiring pair-programming, how do you mandate or assure that it happens? Was all of the code written together by the pair? I find it really hard to believe that 100% of the code will be written completely by the pair. Given all of the demands placed on people, with meetings, vacations, kids, etc; it would not leave many shared hours for pair to write code. It does not seem practical to mandate that no code will be written outside of the paring. So do you only review the code that was not written by the pair? Sounds complicated! All that we accomplished was removing a “learning opportunity” from everyone on the team, including the developer that wrote the code!
  3. I’m not sure that “Continuous Review” is an officially documented concept, but it is a technique that I have used successfully over the years. Continuous Review is fairly simple, but is potentially time-consuming and highly prone to apathy. The process is extremely trivial; before accepting changes from your teammates, simply review the change set in your IDE. It can be quickly accomplished using the Team View found within Eclipse. You can walk through each commit and its associated files before updating your work area. By spending this small amount of time throughout the development process (each day), you can help ensure that everyone is on the same page; even ensuring that the code is in sync with the design. You get a very good sense of the overall heath and progress of the project, just by watching the commit stream. Unfortunately, not many developers seem to adopt this role, as it takes a serious commitment and can also cause tension, when the team is not as cohesive as it should be (some developers might feel like they are being monitored).
  4. The final and most common piece of the review process is the traditional “code review”. It has been my experience that this type of review is generally the most ineffective. Even with years of published guidelines, which could actually make the process effective, they are typically tossed out due to the lack of time and management guidance. I have blogged on this subject in the past. These reviews turn out to be more of a code presentation rather than a review. This will unfortunately be the first time that many of the participants will have actually seen the code!  No time is allocated for participant preparation. Worse yet, no time is ever allocated for the correction of discovered issues. The reviews are always performed late in the development cycle or during the testing cycle, simply to satisfy an SDLC deliverable. I believe many developers have been conditioned into disrespecting code reviews, simply because they become just another meeting, which produces very little value.

I might sound like I’m against code reviews, far from it. I am against the traditional code process that focuses on developer selected code, typically presented during a meeting. I recently reviewed the Crucible tool from Atlassian. The tool is far from perfect, but is ideal for managing asynchronous, distributed code reviews. Automated tools provide a variety of methods for selecting the code to be included in the review process, such as querying by user id or change ticket number.  The selected changes are then assigned to a collection of developers and the process begins. Each developer is notified via email that they have been assigned a collection of code to review.  When convenient for the reviewer, they log into the tool and are presented the files to review. Crucible actually tracks your progress through each file, giving progress feedback to the review coordinator, indicating that progress is underway.  The developer is presented the change sets and can add comments directly into the code. Each comment can be categorized as an issue or suggestion. I think Crucible is an great tool, but provides absolutely no reporting capabilities. I have talked with Atlassian and they seem to have absolutely no interest in generating meaningful reports. Even the simplest report, which would show all of the issues found during the review is not possible to produce. I’m a huge Atlassian fan, but this lack of functionality completely boggles my brain.  In today’s evidence driven SDLC world, the documentation from the code review is actually more important the code review itself!

Obviously, I don’t think code reviews should ever be eliminated from the process. I also believe it is possible to achieve real value from them, with very little overhead. Hopefully someday, I will actually be able to prove it!

Dec 28 2011

Bluetooth Rocks with Home Phone Integration!

Category: Misc,VOIPPhil @ 12:02 am

I’m not sure how many normal people take advantage of Bluetooth technology, but I’m absolutely hooked. I run two and a half miles every morning using my Motorola S9 headphones. They are great for running, I can’t recommend them enough. I’m on my second pair; they unfortunately have an unreplaceable battery and would not hold a charge after a year or so.  My car has hands-free Bluetooth, which I must say that is pretty cool!  And now, my cordless phones are Bluetooth enabled too!

After the purchase of my OBi110, I needed to buy a real phone for the house, I honestly did not have one! I had researched Bluetooth / land-line phone integration solutions several years ago, but they always seemed rather “iffy”. I could never determine how well they really worked. They were always a little pricey, so I never took the risk.  I happen to see that Panasonic  had a line of phones with what they called a “Link-to-Cell” feature.  The phone seemed to get good reviews and was pretty reasonably priced; I picked them up for $57 from Walmart!  I have purchased Panasonic phones in the past and was always happy with them. These phone seem to be well made and comfortable to hold. I have not used the answering machine feature, since Google Voice provides that function for me; but did notice the “Voice Mail” indicator works on the phone! Think about that Integration – Google Voice services tell the OBiTalk network that I have voice mail, and then OBiTalk sends the message to my OBi adapter, which ultimately lights up the indicator on my cordless phone… Pretty crazy!

The Bluetooth integration is pretty slick. You can pair two different cell phones with the unit and assign different rings to each cell phone. You can also download your cell phone’s phone-book to the handsets. The phones even include “talking caller-id”, announcing the phone number or name of the person that called. My cell phone seems to pair instantly with the base unit when I walk into the house, no fuss at all.  The call quality seems no better or worse than using my old Jawbone Bluetooth headset. I think the sound quality is actually very good and have had no problems carrying on a conversation. You can easily make outbound phone calls with your cell phone, just dial the phone number and press the cell button.

I have only had the phones for a couple of weeks, but have been very happy with them. The convenience of being able to pickup a real phone is kind of nice, plus I don’t have to worry about where laid my cell phone down!

OK, back to the more traditional blogs starting tomorrow!  I just really wanted to share how well this inexpensive combination of technology really worked, linking together your cellular service, VOIP (Google Voice), and a traditional home phone into an unbelievably simple and convenient package!

Dec 27 2011

Google Voice Finally Useful…

Category: Android,VOIPPhil @ 12:01 am

Not my typical post, but I have been so impressed with my new toy(s), that I just had to blog about them! Over the years, I have tried every way possible to avoid paying Verizon for my phone service, there is nothing worse than paying for a home line, plus multiple cell phone lines! Yes, I have tried VOIP services in the past with limited success. I used ViaTalk for a couple of years and really liked their service; I unfortunately did not have access to real broadband, so their service was not really that great. VOIP services can definitely be cheaper than traditional copper land-lines, but still seem expensive for what you get; even Vonage is about $30 a month. Apparently, I don’t put a reasonable value on having home phone service!

Enter Google Voice. I have been a Google Voice user for a long time, even before Google purchased and rebranded it as Voice. I never achieved any great value from their service, but the integration with my Android phones was extremely nice. I mainly use it for the transcription of my voice mails. For the last year, I have used GV as my primary home phone, making most of my calls from the computer, using the Google Voice/Talk combination and a USB headset. This works pretty well, but sometime I miss talking on a real phone!

A couple of months ago, I happened to read about a free VOIP service, using an inexpensive hardware device from a company called Obihai. Their ObiTalk service provides both SIP-based VoIP and Google Voice integration.  ObiTalk provides a great amount of flexibility, including a Softphone solution, as well as applications for both iOS and Android based mobile devices.  To be honest, I really did not care about any of their advanced features, I just wanted the Google Voice integration.  I would have purchased the OBI100, but it was out of stock; so I ordered the OBI110.  Somehow, I happen to catch a deal, and picked it up for $45 from Amazon.

As you would hope, the OBi device takes no time at all to get working after you unbox it.  The first step is to create a ObiTalk account and register your device. The process is trivial, you just need to connect the device to your router and plug-in your phone. Next, click the add device button and follow the on-screen directions.  Simply dial the magic number provided by the site and your device will be connected to your account. I only encountered one surprise, the device unexpectedly rebooted a couple of times.  This behavior was actually expected, as the device has the ability to update itself from the central server. After a couple of auto-reboots, the device as been rock solid.

I have been using the service for about a month now and it has worked amazingly well. I’m not currently a fan of Google Voice’s call quality using my cell phone; I always blamed it on my Verizon service! Most of my calls seem to have a lot of strange echoes and delays, which you would assumed to be a GV server problem, not a Verizon issue.   However, the Google Voice call quality using the ObiTalk device is exceptional; I don’t think you would have any clue that the call was using a VOIP service.  The phone works as you would expect; you just pick it up and listen to that traditional dial tone, just like it always has been! I was also able to keep my Verizon phone number; the process to port  a land-line to Google is a little painful, but easily accomplished.  Because Google cannot port a land line, I had to first convert it to a wireless number, setting up a month-to-month contract. Once it was converted, Google quickly ported it over to their service, for a small $20 fee.

So, what is the downside? Today, nothing. Tomorrow, who knows! The future is the biggest concern; we have all seen numerous technologies quickly come and go over the years.  Google has not actually been very attentive to their GV user base, as enhancements to their service have been non-existent for years. Fortunately, the service continues to roll along and fundamentally works well enough for what it costs. The bigger question is how will Obihai survive?  Where do they get their funding to keep the ObiTalk service running? I’m sure they make a little money on their devices, but it hardly seems enough to fund the company in the long-term.  They provide exceptional service and a quality integration with Google, surely they will have to start charging for their service at some point. I could justify a nominal monthly fee, but if it is too steep, it would be easier to just give the money back to Verizon and user their VOIP package. Ideally, if Google has any long-term vision for Voice, they should seriously consider buying Obihai. It would give Google another open platform that would allow other SIP provides to integrate into their GV network.  It would also create a more economical and conventional solution for the typical, non-technical consumer to take advantage of VOIP technology and further expand the adoption and usage of the Voice product. I just hope that Voice does not end up like other recent Google technology victims…

One last point, Obihai does not seem to be slowing down. They are planning to release a new version of their hardware, the OBi 202. You can actually find quite a bit of information on that site related to Google Voice and the OBi services. You will have to read my next blog to find out what my other toy is!