8th Light Blog

I am a better pair than solo developer. For me, software is a collaborative art from the start to the end. Starting from the beginning of a project, where the developers need to collaborate with the customer s and stakeholders of the project to learn about the business domain. Then working with the project manager for sorting priorities and deadlines to make the business goals realizable in the fastest amount of time. Also development is collaboration, via pair programming, to produce a dialog between the developers on their vision of the implementation of this code. The last part, pair programming, is what I would like to focus on.

Having a pair has the traditional advantages of keeping disciplined and sharing the knowledge base. That is a starting point, but pairing is quintessentially important to my process due to the diversity it provides. A diversity of approach and implementation provide me with enough to perform at a highly creative and expressive manner.

Since you are not driving the keyboard and control of the computer, there is more time for contemplating code you wrote and direction you are moving. Most of my good ideas come from the time when someone else is typing. Since I was just working on the practical, I have my head wrapped around the code, and since I am not responsible for typing, I can reflect in the abstract.

I have heard many places that a benefit of test driven development is that the tests force you to design the API of the objects you are using as someone would use them. Well, pair programming, in compliment with programming ping-pong, forces your code to be clean. When you write a test, it isn’t you that makes it pass, so you have to think with expression and intent in mind. So, you end up writing the test FOR your pair. It becomes a form of writing, not just coding.

Sometimes, the test needs to be explained. While explaining something to a pair, your test must hold up your own arguments. Often times when I come to explain something I just wrote, I think of a better way to do it. Explanation is the best form of validating you understand where you are going well.

Also, pairing is how I learned most of my developer personality. Taking bits and pieces of the traits of my pairs through years of pairing. My style is a composite of pairing with various mentors and peers of mine. It has shown me how people approach this craft.

1. You find your self delivering software to your customer who says “That’s not what I asked for.”

Using FitNesse allows you to communicate with the customer up front. Before a line of code is written, you can have all the behavior expressed in an executable format. Make sure the customer helps to write these tests. Once your FitNesse test is in place, all you need to do it make it pass. Due to the cut-and-dry aspect of executable specifications (FitNesse test), one the spec is passing, you have delivered precisely what your customer asked for.

2. Bugs sneak into your system as development progresses and these bugs takes weeks to find and remove.

FitNesse is a tools to help you drive development with tests. When practices with discipline, test driven development will insure that you have a FitNesse test for each and every feature in your system. The moment a bug is introduced, you will know about it because a FitNesse test will fail.

3. It is difficult to create documentation for your system and it is constantly out of date because the system is changing.

FitNesse offers a unique documentation solution. When ever you write a FitNesse test, you are in fact describing how the system works. In other words you’re documenting it. The web/wiki based nature of FitNesse makes documentation simple and convenient. The best part is that the documentation in FitNesse can never go out of date. Since you’re keeping your test passing, and your tests are documentation, it’s impossible for them to lie.

---

There is an article I wrote about FitNesse for Windows Developer Power Tools. This book, just released today, includes articles on dozens of free tools that .NET developers might benefit from. If you write .NET code, check it out. If not, keep in mind that FitNesse will work for almost any language.

I heard about the Getting Real workshop from a good friend who is a web designer/developer. We used to talk some time ago about using the UI as a tool to drive the development and he told me I should go to the workshop if I could. I have to be honest, I didn’t know that much about 37signals and (you’re welcome to laugh) I didn’t know that one of the speakers was actually the creator of RubyOnRails.

A bit skeptic, I read a blog from somebody that participated in one of the workshops last year and my interest kept growing and growing. I told one of the company’s partners to give it a try and to my surprise he registered everybody for it. “The workshop better be good!” I said to myself.

So there we were, sitting down and waiting to see what these 37signals guys had to say. Right at the beginning of the presentation I learned that a businessman (Jason), a programmer (David) and a UI designer (Ryan) would be the speakers. It sounded like a success formula to me: it would not be about some nerds talking about adding the digit 2 in the 0-1 binary language; it would be about REAL-world professionals talking about REAL web/product development approached from diverse angles beyond the plain and traditional “bit-and-bytes” speech I am used to hear in that kind of activities.

What a way to start!

The speakers did a good job on keeping people interested while sharing without any hesitation the fruits of several years of pragmatic experience. Their advice was rich and wide: from how to integrate organically the layout and usability design with the programming endeavor using the application itself as a real “wireframe”; to business-oriented tips like how to hire the right people effectively. As an architect (on the traditional sense - building design!) it was refreshing to see Christopher Alexander “in-action” on some of their slides while talking about design patterns; and to hear about 37signals’ approach to Mies Van Der Rohe’s aphorism “less is more” applied to all aspects of the product development.

The workshop was great, definitely worth the time and investment and I have no hesitation recommending it to everyone that wants a more “holistic” and practical exposition to what software development should really be (if you want to Get Real!). A sincere “thank you” to the 37signals guys and to everyone there that helped to enrich the workshop with questions and comments.