Paired Programming

I posted this internally at Guidewire today in response to a "meta-analysis of empirical studies done on analyzing the effectiveness of Pair Programming." shared by colleague. Then I thought this is actually a pretty good short summary of my point on Paired Programming nowadays:

As useful as they are, my problem with these analysis is that they are trying to isolate the behaviors that work best when applied together. This applies to TDD, team development, short iteration, continuous integration, etc.

Unlike engineering, software development is actually a discovery process, during which most of the value comes when discoveries are put together. For example, when two heads get together, the value is not only about performing complex programming tasks correctly, sometimes it is actually more about realizing that there are other parts in the system that can help with the current task, or even not to attempt because someone has already tried.

On the other hand, programming is a highly concentrated task. Once interrupted, it always takes a while to get back to the mode, and we all know how frequent interruption is during a normal work day. With paired programming, you can actually keep the flow even when one person is interrupted for a short period of time. There are practices that you need to do to make sure that this is really the case. For example, it it turns that the the person is going to help another pair for a long period of time, the right thing to do is to switch the pair, etc.

Also the practices of XP work the best when they are working together. For example, rotating your pair routinely help the effectiveness of the paired programming. If you do TDD during the paired programming, it will help the two people to focus and lower the overhead of communication.

One last thing that I have found out about paired programming is that it helps the team communication. Paired programming forces the two people to talk constantly, which creates the "omni-communication". I know some people find it annoying. But I have sit in such environment on many occasions and once you get used to it, the kind of information you can pick up without any effort is very surprising. Many project managers I talked to also reported that because of the "omni-communication" they pretty much eliminated the "status meeting" and replaced it with "issue resolving meeting".

Thoughts of the Day

This person posted a blog with the following content, then posted another blog saying he just deleted it and made the apology. Several weeks later, he posted another blog saying he is quitting.

I don't know the details, but I swear to agile god that I would rather quit than have this happen on my team.

It doesn’t bring any benefit , Pardon I asked stunned to hear the response I reeled in surprise as I took in what I was being told I mentally backed up a bit so in effect the team lead on a high value project was telling me not to worry and more to the point it was unlikely that anyone at least anyone on his team would ever worry about refactoring a piece of code I had come across because it worked and it was unlikely we would ever need to change it!

I wanted to say but its wrong , its bad code but I didn’t I stood there and said oh ok I understand and I walked away and sat back down and carried on letting my fingers fly across the keyboard trying hard to block out the bad code screaming at me form the other file.

Green Day Blog

Something hilarious: http://www.youtube.com/watch?v=T4SDQu7Izrk

And something useful:

• http://www.bankrate.com/brm/news/energy-environment-2007/environmental_myths_a1.asp?caret=3a
• http://blog.guidewire.com/blog/marcusryu/archives/2007/10/more_important.html
  

Cotta 1.2 Release

I have got quite a few good feedback from Brian who is using it ('in anger'!) at Guidewire. So I am putting together a 1.2 release, even though the change list is really small.

This also include some JavaDoc updates. Even though I am not a believer myself on JavaDoc, I have come to realize that it is still a recognized way of communication and sometimes preferred over email or forum.

(I have been writing drafts about the work that I have been doing at Guidewire, just never been able to publish any of them... Not good if I want to keep this blog alive)

WebGen, Cool!

I finally run into WebGen today when checking out rSpec. So far by the look of it, it is exactly what I have been looking for for the last two years! Of course, that means that one third of my work with BuildMaster will be out of commission, but this is such a good thing!

I supposed this was bound to happen sooner or later.

I thought it was a bit odd that I didn't find anything interesting when I had the idea of generating a static HTML website based on specified template and using wiki style format like Textile. I had several simple websites to generate at that moment (my homepage, jBehave at the time, Cotta, and BuildMaster), so I settled for creating one of my own with some simple Ruby script as the base. It worked out well because I have been able to update the content very easily. Earlier this year, I also set up the selenium Ruby project very easily.

It didn't come without a price, when I released BuildMaster 0.7.0 . I just settled for the fact that there is simply not one that is easily found. I also try my best to enhance it to be more powerful and flexible but I just never got enough time.

Now with WebGen, I can finally take something off my plate and still get what I want. Since I wrote those websites with Textile syntax already, I don't see a big content format conversion either.

My first reaction was that "Man I wasted a lot of time because the lack of information". Then I realized that I learned pretty much everything I know about Ruby and rSpec while working on this module, and that the Cotta layer that I extracted out of it is still very valuable. So even though I do need to do a better research next time, this time it worked out for the best.

Agile 2007 Experience Report

It is finally over. Julian and I have been working hard on this experience paper for agile 2007, and I have just come back from the trip to Washington DC for the presentation.

The title of the paper is "Large Build Teams: Help or Hindrance?". If you google it, you should see an older version.

When I got the copy of the experience reports at the agile 2007 registration booth, it sure feels good to flip through the pages and locate the fruit of my hard work in print. Now I really admire the authors who can keep coming up with good books.

The presentation itself went very well too, although I wish I had more time to make a good point of what I have learned in this project. Oh well, those who are interested can certainly read the report and contact me directly.

How Old is the Concept of "Inversion of Control"?

Think this article by Martin Fowler, probably most quoted, is the first one talking about this concept? Well, then we were both wrong, because I have just found out this article, "The Dependency Inversion Principle", published as early as 1996!

Isn't that something?

With Wing Bark, No Quack

I have heard tons of insane software development project stories, and this one beats all of them added up...

I only hope the story is not true...

Atlassian and Cenqua

Two of my favorite companies from down under is now one. I love it.

Atlassian taught me that wiki can be cool and professional, and that Bugzilla is not as good as a bug tracking system can get.

Cenqua simply saved me from the CVS madness.

Thank you both!

Sad Day for Polite Software like IDEA

IDE Showdown - Evangelists duke it out at Cologne JUG

My hats off for organizing this meeting. However, based on the conclusion that the article has drawn, I mark this as a sad day for the polite software like IDEA. Apparently we still live in a society where the quantity of the work, i.e. feature list and 'advanced features', rather than the quality of the work, i.e. how you implement the same feature in polite way, matters.

And I am also annoyed every time someone says "Eclipse is more than just a Java IDE", or "Eclipse is more than just an IDE", as if it is a good reason for it to be poorly designed and most annoying to use. You know, that is not even a good excuse.

I can rant on for days. But I have been ranting for so long since Borland decided to stop the development of JBuilder purely out of fear for Eclipse (hence my reason to quit) several years ago, that I am just tired. All that I feel up to do right now, is to quote Alan Cooper in his great book “The Inmates Are Running the Asylum”:

It is abundantly clear to most of us that common folk don't know the difference between a token ring and a mood ring. We need these creator of "faster, stronger, better" innovations to be sure that the creations actually improve our work and lives -- not simply drive us crazy. We need the technology to work in the same way average people think. We need a revolution to restore our sanity.

Update: I also think that IDEA is wrong by trying to fight on the open source battle ground. Of course you are going to lose! What is so wrong by saying

Our business model is to produce a killer softerware full time and get paid well enough for it to be sustainable. Because of our business model, we have the purest agenda and vision for our IDE, i.e., make Java developers do their own job in the most efficient way. If any other FREE IDE can beat us in this market, we will cease to exist. But so far, it looks like we are the best. And we ARE supporting open source in our own way, by giving out open source licenses.

Squeak - My New Language of the Year

When someone took the time and write a tutorial like this, the least that I should do is to read it through and learn it to show my respect.

I am not totally sold on the ""Learn at least one new language every year" (p. 14 on Pragmatic Programmer book). Not that I don't think it is a great idea. I just think for one it would be very hard to do since it normally takes one (me at least) several years to learn to fully appreciate the language. Another reason is that I think it is more important to contribute back to the society of what you have learned than keep learning for learning's sake. I know I have not contribute enough as it is, given the pressure to put food on the table, making my way to afford a house in bay area, take time to enjoy life, and such.

But when all you need to do is to download the Virtual Machine and Image, and read the tutorial, and you are up every night feeding the baby anyway, why not.

Update: As it just turned out, this post showed up in case you wonder what are the choices are out there if you want to learn smalltalk.

Second Update: Free (and Legal) online Smalltalk books

Yak shaving

I have found this Yak Shaving to be true in many occasions, especially when starting the BuildMaster project.

I think that is why Agile development works. You use one iteration to focus on one level of the work to build a "Walking Skeleton" as described in "Crystal Clear". At the same time, you keep updating the story backlog about all the work that you discovered on the way so that you don't lose anything and can prepare for future iterations at the same time.

Reference: Really Bad Powerpoint

Julian sent me this link, "Really Bad Powerpoint", as a guideline as we are developing our presentation for the Agile 2007.

I do find the content convincing, especially about preparing full notes but not handing them out, and use less words on the slides.

I don't think I agree with the idea of no transition, though. I have had good experience using them, and I have seen others using them with good effect.

Bad Interaction Design - Installing Acrobat Reader

It just so happened that two day after I was impressed with Firefox' good interaction design, I was utterly annoyed by the installing process of Acrobat Reader.

What is so wrong about downloading an exe file that is an installer (using any download manager that I want), run it, and choose the location that I want to install the program???

Oh no... You need to install the nice "Acrobat Get", which is either an ActiveX control for IE or Firefox plugin, which of course means that you have to set the security setting on your browser. Then you have to wait for that thing to come up, start downloading, and silently install the program at the place where it sees fit (which happens to be my C drive that has only 1.5 GB left).

So I ended up with even smaller space on C drive (40 GB free space on D drive). And guess what, my computer hung during the process and I had to do a hardware shutdown (holding on to power button for 5 seconds).

Update: Tom just commented and provided this link to download the installer.

ftp://ftp.adobe.com/pub/adobe/reader/win/8.x/8.1/enu/AdbeRdr810_en_US.exe

Thanks! I love internet!

Test Doubles

This is a nice article that covers the topic very well. Stub, Mock, etc., are all part of the test double.

Pay attention to the very first paragraph. Going out of this context is how mocks are getting abused.

Good Interaction Design: Closed Tab List

I was very delighted to discover the "Recently closed tab" feature in firefox!

If you accidentally close a tab, you can now recover it through the menu "History-->Recently Closed Tabs". And guess what, your history is available as well!

Now that is a good interaction design.

Remote vs Collocated Team

There is a heated but surprisingly friendly discussion about Remote vs Collocated Team going on right now at Yahoo! agile-usability group. I have just started paying attention (and try to follow it) this weekend because the daily digest I get each day is full of it now.

It is pretty interesting to read. Well, if you have done XP coach or consulting at a firm that is not so hot on everything about agile, you might appreciate it more.

It is also interesting to point out that the very first post started with this:

Maybe this is not a hotly debated topic any more since ...

rSpec 1.0.4

Busy with BuildMaster, selenium-ruby, and Entrance, I have not looked at rspec for a while.

Until the Code Kata with rSpec we did at BayXP last week.

Boy have they changed...

And all for the better I'll say, after converted one file last night. Personally I liked the 'specify' more like 'it'. Actually, I thought they would go with 'should' since I type that at the beginning of the every specification name.

But that is small thing. With the new version, it would be a lot easier to come up with new matchers, re-use behaviors.

Update: Check out the rspec report I have after converting to this version! It is actually cool to see the broken tests report, more so than the passing report that rspec has itself

http://buildmaster.rubyforge.org/rspec/

Different Perspective: Singleton as Dependency Management

I used to loath the singleton pattern, mostly because of the pain it has caused me whenever I take over some old code and try to write test on it. Interesting enough, Guidewire has used it in a way that is actually kind of cool.

If you have tried to manage component dependencies before the IoC container came out, you are probably fully aware of the pain you have to go through when a new dependency is introduced. Either you end up with a HUGE interface, or you have to change the signature of a handful classes and make some of them have longer parameter list in the process.

Here those dependencies are manager as "Dependencies" singleton interface. It is a set of static methods to be precise. So if a class decides it needs to use metadata layer to build the query and database layer to execute the query (like the archiving project that I am working on), it can just grab the instance by calling "PLDependencies.getExtractController()" and "DatabaseDependencies.getDatabase()". The dependencies are set up during the server initialization (through dependency registrations) and never changes.

There are some behavior changes associated with this design. Two on top of my head:

* No mocking/stubbing. Nothing is stubbed out within the application. We use H2 for testing and the database is reset using restore. So the tests run fairly fast. After seeing some horrible mocking code, I like this style more and more.
* Be aware of the dependencies. With dependency injection, you get used to understanding the dependency relationships by looking at the construction and method parameter list. With this design, surprises can really happen. You could very well call into something that does not take any parameter only to find out that it actually does a lot of things.

It is not the perfect design, but once you understand the pattern and learn not to abuse it, you can actually manage the dependencies quiet easily.

Test Coverage

http://www.artima.com/weblogs/viewpost.jsp?thread=204677

The above link got passed around at Guidewire the other day. It reminded me of the consulting days where we had to figure out the right answer for the right stage of the agile enablement.

This also reminded me about another interesting thing is this "90%, 50% rule" from Adam. He told me that he started paying more attention to the line coverage of the projects that he has been on. What he noticed is that the line coverages seem always end up at 90% or 50%. Normally 90% are the projects that developers are doing test-driven development, and 50% are the ones that people recognize that writing tests is an essential part of software development but not necessarily in the TDD fashion.

I do remember that all my projects in ThoughtWorks had the around 90% coverage. I wonder how much we have at Guidewire or my open source projects. The reason that I don't know is because at Guidewire the QA tests affects the coverage as well so it is not the same thing. My open source projects are all done in the TDD fashion so I never bothered to spend time create something that I don't really use.