Just Another Glance at Pair Programming

I've always had issues with pair programming. It's not that I disagree with the value claims that people associate with it. I just have personal issues with it. Here are some of the things that have bothered me:

• Watching someone else use a computer is like fingernails on a chalk board. I know I'm not perfect but seeing how other people get things done with the mouse and keyboard gets my egometer running and I just want to push them out of the way screaming "IF YOU CAN'T DO IT RIGHT DON'T DO IT AT ALL", but honestly... it's not about the right way to do things, it's about the way I do things.
• Staying focused while navigating is an uphill battle. I'm used to working alone. I'm also used to thinking with my fingers attached to the keyboard. I've always had a hard time being the navigator for too long. I just have a tendency to get bored.
• Having someone else tell me how to spell my variables names is punishable by death. I don't care if you think the variable should be fooBo when I type fooBO, next time you drive you can change it yourself.
• Some of the old reasoning behind pairing is obsolete with the use of powerful IDEs like Eclipse, Intelli-J, and others. I don't need someone telling me I missed a semi-colon at the end of a line because eclipse does that for me.

Honestly I have to admit that some of those things are petty and just personal quirks. At the end of the day I have to think about my motivations and just maybe those things shouldn't be that big of a deal (as long as I didn't strangle someone). Other things may require a little understanding of what's really going on when two people truly, productively pair.

What is the point? I'm not going to dig into any text books or even reference wikipedia on this. This is just me stating things from the perspective of a lowly developer.

Pair programming helps keep individuals on track. When I work alone it's too easy to take that personal phone call or do some web surfing (yeah, even tracking down technical, java related web info has to be considered personal surfing). Pair programming increases the quality of code. It's not about missing semicolons or mispelled variables anymore (thanks Eclipse), it's all about checking in code that is clean and efficient and easy to maintain. When you have more than one person working on code it's much harder to make stupid mistakes. Yeah, I said stupid. And we all make those mistakes from time to time. Copy/paste mistakes. Unneccesary else mistakes. So many things that are too easy to do and really easy to overlook will more than likely be caught by a pair of programmers than a Han Solo cowboy coder.

What about staying engaged and focused? I do have a problem with that some. But I recently did some pairing in a way I hadn't thought of before. Once we understood the task at hand my pair wrote the first unit test (yes, we wrote the test first), then when it ran and failed he slid me the keyboard and told me to implement the code to fix the test. I did, then I wrote the next unit test which failed and he got to implement the solution... that was the fastest day of work I think I've ever had. I was very impressed. Personal conversations were cut to a minimum and we both stayed focused on the task at hand since we were both implementing the code in tandem.

I'm not saying that everyone should pair all the time, but I don't think it's a bad idea to do it a little more than you may be doing it already. Every programmer's goal should come down to delivering clean, quality, bug free code. I think pairing will definitely help you in achieving that goal.

Until next time
Les

Welcome to the Jungle (of extreme programming)

This past week I changed teams at work. I went from a standard, cube oriented team to an xp (extreme programming), team room situated team. After 5 days I have to admit I'm very impressed. Things seem to just flow, and that includes the time in the day.

In my previous team we used a bastardized scrum process. What I mean by that is we worked from a log of broadly described requirements and we had a daily stand-up meeting (scrum meeting) where each person reported on their current workload. But between those daily scrums it was mostly cave time in each person's cube where they worked on whatever they pleased (which means a lot of personal, non-work related stuff). Except for 1 solid leader on the team and 1 or 2 others this was pretty common (guilty).

On the xp team it's more rigorous as far as daily tasks go. It's a mix of xp, scrum, and lean methods. Everything, and I mean everything, is done in a defined process. From the way the requirements (user stories) are defined and accepted (yes, accepted by developers), to the way tasks are maintained on a kanban board and everything is required to be done by a pair of programmers doing test first development. And even when a pair gets the task "done" it isn't officially done until it gets "accepted" by another pair (a process that when done properly guarantees almost zero bugs released post-development).

I know it sounds a bit legislative, and honestly I had my doubts as to how it would affect me. But the work load is easily divided and things get done. In a 5 day iteration we clear the board and if we need we can pull stories that are ready in the backlog. The only problem this team has had is lack of ready to go stories in the backlog (but that is changing with the addition of 2 in house Business Analysts).

So far I'm loving my new work environment, I really don't miss my cube (but yes Brian, I do miss you man, you should offer to take someone elses place :-) ). I want to get into details in later posts about the kanban board and some of the ways I've paired and also our use of Fitnesse which so far is mind blowing. I'm marking down week 1 as a productive week.

Until next time
Les

Lone Star Software Symposium - Day 3 Recap

Meanwhile, back at the Ranch...
So the conference has come to an end and several hours driving and a short night's sleep in my own bed and now I'm back at work. This was a great experience for me. I would definitely go back to a NFJS conference if I got the chance.
The final day was no let down. The four sessions I attended were great.
The recap:

Design Patterns in Java and Groovy

I know I've gone on and on about Groovy, but this class really got my attention. This was my first session with Venkat Subramanium. Venkat is the author of several books (one of which I already have) and a very charismatic speaker. What he did in this session was present several common design patterns in Java, discuss the complexity, and then write the same functionality in Groovy right there. This was an excellent session to see some Groovy in action and see just how simple and easy it makes very robust Java tasks.

Caring about your Code Quality

This was more of a speach presentation than a coding presentation. But with Venkat back at the helm that's not bad at all. This session covered why Code Quality is important and why caring about your own code quality is important. He shed light on a lot of common coding fallacies and practices. This is a very important subject that encompasses every facet of Software Engineering, not just the Java world. Great stuff.

Agile Test Driven Development With Groovy

This and my last session were both presented by Jeff Brown. This was an interesting class to me. It started differently than I expected with a background of unit testing and TDD. But once Jeff got into the coding section and really greased the testing wheels with some Groovy goodness it was really interesting. The simplicity of your code that Groovy provides really makes some remedial testing tasks almost too easy (compared to what it takes to do those tasks in Java).

Powerful Metaprogramming Techniques With Groovy

This session really got into the mud with the meta-programming capabilities provided in Groovy. His examples were pretty cool. He made several builders (xmlBuilder, outlineBuilder) and showed how simple it is to manipulate compiled classes on the fly to empower your code to really do what you want it to do, not just what your framework wants it to do. He explained a bit about the ExpandoMetaClass which is a very powerful tool in Groovy (and a tool that came from the Grails project). Again, good stuff.

Conclusion
This conference was very useful to me and my colleagues and I have decided that Groovy is going to be a tool we use in our framework. We'll start small using it as a helper for our unit testing, then we'll see where we can take it from there.


Until next time
Les

Lone Star Software Symposium - Day 2 Recap

Here I am at the end of Day 2 and I'm miserable. There are several reasons for that, but they don't have anything to do with the Conference itself. One reason is that I miss my wife and my son. Another, and probably the biggest, reason is that I'm stuffed beyone enjoyment on BBQ from Red Hot and Blue because I have mostly no self control when it comes to BBQ.
Here's the wrap up:

Filthy Rich Clients with the Google Web Toolkit, Part I

Overall this is a very interesting toolkit. It allows you to development heavy, ajaxian, rich, javascript based web apps by writing nothing but Java code. Google has written a compiler that takes the Java code and compiles it into multiplatform, crossbrowser Javascript. It's really slick and I could definitely see using it to throw together some personal projects. The session wasn't horrible.

Real World JSON

This was another course by Scott Davis and I really enjoyed it. JSON (Javascript Object Notation) is basically the best alternative to XML (the 'x' in AJAX). JSON let's you express objects and lists of objects as plain text (and what's more light weight than that?) and process it right in your web page without have the heavy, cumbersome syntax of XML to grind through. I could see using JSON in future web endeavers. Good presentation.

Grails - Agile Web 2.0 The Easy Way

This got me back on track with my new trend in self study. It was presented by Jeff Brown and he did a really good job at showing the quick and dirty of what Grails really is. This was really a repeat for me since I attended Davis's Grails session yesterday, but he added fresh light to areas for me so it wasn't a waste. Good presentation and a good primer for the next session.

Advanced Web Development With Grails

So this was the best session of the day. It was Jeff Brown's second session and it really dug deeper into the workings of Grails and building real world web apps with it. He showed us the power and EASE of creating custom tags in Grails (as opposed to the painstaking process it in the JSP world). He demonstrated some remote calling and object relationships (managed right in your bean object and persisted on the fly to the Database, yeah, that's right). I definitely think that the entire Groovy/Grails paradigm could change my programming landscape for good, if only I could get it accepted at my job.

As I said to begin, overall I'm enjoying and learning. I would recommend this conference to any, ANY Java based developer.

Until next time
Les

Lone Star Software Symposium - Day 1 Recap

Without going into detail regarding the trip to Dallas and the typical checking into the hotel I'll just say that for the most part today is what you might expect from the first day of a conference. I really enjoyed the sessions I attended today. All three of the sessions I chose were led by Scott Davis and all things revolved around Groovy.

The Blue Pill

The first session was Groovy, the Blue Pill, and yes that is a reference to The Matrix and the next session carried the reference further. The Blue Pill was basically a crash course in Groovy. What it is. How can it be used. What are some basic features that make it so groovy and not just Java without the semicolons (which is optional). It was a good track for me as I'm still fairly new to Groovy. Sure I didn't really get a lot of "new" out of this one since I've been reading a lot of intro to Groovy stuff lately, but it was refreshing.

The Red Pill

The Red Pill was just a continuation of the Blue pill. After the intro course he was now able to present more nitty gritty Groovy functionality. It covered closures, metaprogramming, and much more. A very good session for me as this is where I'm standing on the Groovy landscape.

Grails for the Struts Developer

This was a very interesting session to me. He began and spent a large part of the course talking about Struts. It's origins and it's benefits. Much praise was discussed for what Struts had implemented in it's day. But then came the current state of development on the Java platform and some negative topics regarding Struts were breached. Then he introduced Grails and talked about how you can simply use Groovy over your current Struts apps. Then he rolled up his sleaves and created a Grails app from scratch. With scaffolding doing all the work it was a matter of minutes before he had 3 CRUD apps up an running. Not a lot of new stuff for me, but a good refresher preparing me for my session on Grails tomorrow.

Keynote

Interestingly enough to me, the keynote speach at the end of the day was almost the best part (not taking anything away from Scott and his Groovy kool-aid). It was an awesome presentation about the state of software development and how long it's been this way and where it will likely end up going (which looks bad from here). He talked a lot about development anti-patterns that are common and I swear the man must be camped out or video taping our department because the first six patterns he discussed were common every week practices for us. I wasn't really shocked, but hearing it all explained so pointedly really made me wonder how much longer I can put up with it (as if I wouldn't run into the same issues elsewhere).

Conclusion

Overall the first day was very enjoyable and full of information. I'm looking forward to tomorrow's sessions.

Until next time
Les

Numbers the Groovy way

So far I'm still at the beginning of my journey into the wonderful world of scripting with the Java based Groovy. I'm seeing a lot of neat things, but still I'm just scratching the surface. One thing that I see so far that is really useful is the way numbers are handled.

In Groovy, everything is an object. There are NO native primitive types such as Java (which is Object Oriented with a handful of primitive exceptions to the rule). So in early iterations of Java you had to manually box your primitives into objects to work with them in Collections and other Object based processes.

Groovy has that covered. In Groovy you can reference a number just like an object (because it is an object). Then if you need to make a List of int's it's boxed on the fly because there is no int but everything that would be a Java int is and Integer (auto-boxing to the extreme).

// using the Groovy built-in function .times you can
// simply say you want to do something a number of times
// without having to setup a full fledged for loop
10.times
{
 println "my line"
}

That's just one sample, but I hope it show's you how simple it is to work with numbers in this groovy scripting language.

Until next time
Les

Lone Star Software Symposium - NFJS

This weekend is the No Fluff Just Stuff (NFJS) conference in Dallas and I actually get to go. I'm pumped about this since last year I missed out when it was in my back yard (almost literally) and this years OKC area conference got canceled. I will be posting nightly (no promises) about what is covered but I wanted to go ahead and give a heads up on what I plan on attending for those who care and those who don't.


Day 1:

• Groovy, the Blue Pill: Writing Next Generation Java Code in Groovy -Scott Davis
• Groovy, The Red Pill: Metaprogramming, the Groovy Way to Blow a Buttoned-Down Java Developer's Mind - Scott Davis
• Grails for Struts Developers: A Groovy Alternative - Scott Davis

Day 2:

• Filthy Rich Clients with the Google Web Toolkit, Part I - David Geary
• Filthy Rich Clients with the Google Web Toolkit, Part II - David Geary
• Grails - Agile Web 2.0 The Easy Way - Jeff Brown
• Advanced Web Development With Grails - Jeff Brown

Day 3:

• Design Patterns in Java and Groovy - Venkat Subramaniam
• Caring about your Code Quality - Venkat Subramaniam
• Agile Test Driven Development With Groovy - Jeff Brown
• Powerful Metaprogramming Techniques With Groovy - Jeff Brown

I'm really looking forward to it.
Until next time,
Les

Feeding with no RSS

So I recently came across an online tool while reading my feeds called Page2RSS. From their site:

It is a service that helps you monitor web sites that do not publish feeds.
It will check any web page for updates and deliver them to your favorite RSS aggregator.

I did see a warning that mentioned not using a page that get's updates by the minute since this site will crawl the page every 10 minutes and that will really get your reader down.

Having the tool tucked in the back of my mind I didn't really have a site to use it on at that moment, but I figured it would come in useful eventually. I was right. My church maintains a web page with sermons (mp3 links) posted (no Bubba, I'm not getting preachy, I really am just talking about the tool). They update it about every week, sometimes every 2 weeks. I like to keep an eye on the sermons they post since we miss a lot and don't go to evening services. Instead of having to check the page I used the handy Page2RSS tool and now I get updated when the page does.

It just crawls the page and checks it versus previous versions so I wondered how it would look. Here is a sample I got tonite (here is the sermon page)


As you can see it adds new entries from the page into the feed from top to bottom just as they added it to the page. And since the changes in question have links to mp3 files it adds those links as well without posting the URL as text and dirtying up my page.

Pretty cool by me.
Until next time,
Les