Why Pair Programming Should be made MANDATORY

Pair Programming is one of the most controversial topics discussed time and again. In the beginning I was a bit hesitant about this practice, but slowly I got used to this and really enjoyed working with another developer. However, when in one of my projects, I was the sole developer for nearly months, I knew how important it is for us to really have another pair of eyes. The few months I worked alone, I was not myself at all. Even though I had the opportunity to learn all the latest and the greatest technologies, I just couldn't take it anymore. I had to resign and so did I.

Now that I am reading the book "Pragmatic Thinking and Learning", I was able to clearly understand why I felt the way I was in that Job working alone. In Chapter 4: Get In Your Right Mind Andy explains about Pair Programming and why it is important. He first explains about the R-Mode and the L-Mode of our brain. So, you may ask what is R-Mode and L-Mode:

If you're looking for global, holistic patterns, you need R-mode. If you need to analyze parts and look into detail, then you need a more L-mode approach. For most of us, this level of specialization is how it is. R-mode sees the forest; L-mode sees the tress.

For pair programming, Andy very well explains that we need to get both R-mode and L-mode working together, and the only way to do this is by having your L-mode work with another person's R-mode or their R-mode work with your L-mode.

Again,to quote from this excellent book:

The navigator is free to see these larger relationships and the larger picture, And most of the time, you cannot see these relationships if you're driving. So if you aren't pair programming, you definitely need to stop every so often and step away from the keyboard.

This doesn't mean that you should pair all the 8 hours you are working. I suggest we should pair when we are working on a critical piece of our module, when we are trying to fix bugs, learn a new language, writing build files. Always better to have another pair of eyes, and another mode of brain.

What do you think? Are you using Pair Programming at all? What are your thoughts?

Clean Code : MUST Read Book

Just yesterday, I posted a brief review of Clean Code: A Handbook of Agile Software Craftsmanship written by Robert C. Martin. at Javalobby.

What an amazing and interesting book it is. Around 4 weeks back, the book was at my front door when I came back from work. The next few weeks were quite hectic and I had no time to even open the book. Finally, two weeks back I decided to just browse the contents. I first read the foreword, which again is amazing. That was the beginning, I just couldn't stop.

This time since I hadn't signed up to review this book, I thought I should try a different format of writing the review. I mentioned 5 reasons why this book was worth reading, simple ones. And, later at the end summarized what I had learnt from this book. I guess it stuck a cord with the readers, and there were some good comments as well.

Take a look at the review, and try to get this book if you read or write code. Trust me it is worth the money and the time.

P.S: I sent an email to the publisher to find out who had shipped this book, and my contact at Pearson had sent the book. I did thank her profusely for sending this book along as well.

Maven: The Definitive Guide--New from O'Reilly

For those of you who are interested in learning and using Maven as your build tool, O'Reilly has just released a book called "Maven: The Definitive Guide".

To quote from the email I received:

For too long, developers have worked on disorganized application projects, where every part seemed to have its own build system, and no common repository existed for information about the state of the project. Now there's help. The long-awaited official documentation to Maven is here.

Maven: The Definitive Guide (O'Reilly, US $34.99) serves as both an introduction and a comprehensive reference for Apache Maven, the tool that will transform the way an organization builds and manages application development. Written by members of Sonatype's engineering team—including Jason van Zyl, the creator of the Maven central repository—the book explains why Maven is replacing Ant as the tool of choice, not just for open source Java projects, but for applications in many other languages, including Scala, Ruby, and Groovy. The book also provides the first in-depth overview of Maven 2.

The first half of this book introduces Maven by example, with a series of real-world, multi-module applications that can be used as templates. The second half serves as a reference to a wide range of topics, teaching readers how to:

* Get started with Maven
* Understand the Project Object Model (POM)
* Integrate Maven with Eclipse
* Master advanced dependency management
* Use the Nexus repository manager
* Integrate Maven with Spring and Hibernate
* Write and use Maven plugins
* Generate a project website
* Customize a build with properties
* Use build profiles and profile activation
* Create and use Maven assemblies
* Develop with Maven archetypes

I did try learning Maven several times, and each time got lost in the POM. It sounds like this book is for people like me, but I already have quite a few books in my list. And with this one for me to review, I sure will have to try all the examples, and there isn't just enough time right now.

What's FuseMetrics?

FuseMetrics is an open source tool written in Groovy, which can parse the reports of many of the most common analysis tools:

* Junit
* TestNG
* JDepend
* Checkstyle
* PMD
* JavaNCSS
* FindBugs
* Simian
* Clover
* Cobertura

It produces summary metrics and graphs - sparkline and histograms.

No matter what build tool you are using, Ant, Maven, Gant or Gradle you can use FuseMetrics.

It’s completely open source and we have used it for many of our clients. To read more about FuseMetrics, take a look at the article I wrote at Javalobby here.

Try it out and give us your feedback.