XP Youth

Obie Fernandez had this to say about pair programming:

Truth is, pair programming is one of the only effective ways that a lot of us have ever witnessed keeping average developers from pissing away 95% of their productivity engaging in non-work such as reading and writing blogs, instant messaging, personal email, shopping online and otherwise wasting time on bullshit.

So, we need the XP youth to keep us inline? If I'm not doing my job, I should be fired. Period. End of story. We all can't be above average, but we all need mental breaks (I doubt most developers spend 95% of their time shopping online).

Pair programming has pluses and minuses. It takes a certain personality to be good at it. I've had very few good pairs in my career. Nothing can match the creativity of two minds locked in a common crusade. It's great. BUT, I have found it takes a person that can take constructive critism of their ideas, is vocal, loves programming, and the most important: listens. Your average developer if he's browsing the net for 95% of his time probably doens't "love" what he/she is doing. I found while pairing can give the illusion of productivity, it's easy for one part of pair to be asleep at the wheel to speak. If you don't love what you do, you will find ways to avoid doing it no matter what hurdles managers throw at you.

I love pairing with passionate yet humble programmers (the greatest minds I have met have been this way). But, I hate pairing with ego maniacs. I love short bursts where we colloborate intensely and then go program solo for a short while. Get back together and show each other what we did. Rinse, repeat. I find it keeps the creativity spark alive (because you can experiment without the sucritiny of another to verify if the idea is good) and the interaction rich. It allows the feeling of working together, as well as ownership of a piece of it.

Pairing should be something that is not mandatory. It should be up to the programmers. Anything forced is going to cause people to find ways around your dogmatic rules. It's human nature. XP should be agreed upon, not enforced.

Confession Time

"A wise man changes his mind, a fool never" - Spanish Proverb

Well, at least it makes me feel better right? Well, I have a confession to make. In the past, I have argued for the use of accessors on instance variables. I liked accessors because they looked the same in the code as a method call and the flexibility. But, several months ago, I tried writing code without accessors. I was shocked by what I found about myself. First, it was hard after programming with accessors for so long and it didn't feel natural. But, I got over that in the first month or so. Second, I noticed that I broke encapsulation of my objects less. In fact, if I felt the need to access an instance variable outside of my class, I questioned myself thoroughly and generally tried to find another way.

I thought I was writing good code, but I was making little sins that added up. Forcing myself to use accessors only when necessary caused my objects to be more self-contained. I started writing smaller objects. My code got way better. So good in fact, that I find myself on the other side of the accessors debate.

Yes, I now frown upon the use of accessors by default. It leads to data structures (not objects) and controllers (not objects). The funny thing is the road to breaking encapsulation is one paved with small sins along the way. Besides, with today's tools, it's easy to switch the accessors if needed.

Oh well, I had to get that off my chest.

Too Many Toys?

I sometimes wonder do developers have too many toys? In Java, we have a plethora of open source frameworks to choose from for our next or current project. There are so many options that it can literally make your head spin right off! I've been on several Java projects in my career and every single one of them has used a different technology stack. In fact at my new job, I didn't know a few of the frameworks that were being used at all. With all of these technology choices, it would seem our life should be a piece of cake, right? Well, guess what? It's not.

There's one thing that hasn't changed. Good design and thought. Frameworks are only amplifiers in this regard much like languages. They can make our life easier if we apply them to good sound design principles. But, I think that's what is missing in our field. Go to any Border's and Barnes and Noble bookstore. Hell, go to any coder's shop and what you will find are rows and rows of books on the latest "cool" frameworks and languages. It's all vocational. You might find a little section on design if that. And it's not like we don't have great books on design. Hell, I can list several and still have more to recommend! These are the books that will stay on my shelf long after the latest framework fad or language has gone to the legacy island of old technology. It amazes me how many developers are up on the latest technology, but have never read a book on design (or maybe just one).

It shocks me. Knowledge is our most treasured asset. I strive to understand the core concepts and to go beyond. I'm always trying to learn from anything I can find (even non-software books) if it can give me a glimmer of understanding more about our field. Sometimes, I think though, we get so caught up in the flavor of the month, that we neglect the knowledge that will survive after the fads are dead.

Do we have too many toys? We're spending all of our time playing with them and not learning the core concepts that's behind them. I think that's sad. I love solving hard problems, but I want to spend my learning the problem domain. I want to learn the business of my users so I can solve their problems in elegant ways. The world of business is one of the most fun beasts to tame. I don't get excited anymore about applying the latest technology to a problem, but by solving it period. The tools needed are in your head. The frameworks only amplify what is at the core. When push comes to shove, it's still takes thought to do a good design.

So, here's my solution: read one non-vocational technical book per year. Understand it. Become it. Or at least be able to argue why you hate it. I read more books about design that any other every year. It's time well spent and it only makes you a stronger developer. Rock on, brothers!

Design Patterns of 1972

Sam Griffith sent me a link to "Design Patterns of 1972". What a great read. It's a call to arms to take our languages further. Mark uses several pattern examples from computing past and shows how they were implemented later into programing languages so that they became eventually invisible. I loved the fact that he says that we shouldn't stop at design patterns, but figure out how to incorporate them into our language. I've long believed we are doomed to repeat past sins if we don't research the paths traveled before us. Just go read "Software Fundamentals: Collected Papers" by David L. Parnas and prepare to be shocked if you doubt what I say. Anyway, Mark's article is awesome and thanks goes to Sam for showing this to me!

Now, let's roll up our sleeves and take our industry further!

I miss Zappa

I wish Zappa was still around. I always loved his wit (read his autobiography if you have a chance, it's classic). This exchange between him and a talk show host is too funny (via "Influence: The Pyschology of Persuasion" by Robert B. Cialdini).

PINE: I guess your long hair makes you a girl.
ZAPPA: I guess your wooden leg makes you a table.

Made me laugh. Time to fire up "Grand Wazoo".

Working On The Railroad

My new job is going fantastic. I'm programming in Java and learning a ton of new frameworks. I'm becoming very impressed with Tapestry. And it's great to finally see Spring in action. The domain is challenging. This is the first time I've been in the shipping business so everything is new. Of course, business is business so there is some familiarity. I am having an absolute ball. Oh, did I mention I have a window seat? Well, I do!

Time And Money Library

I'm proud to announce that I am the project manager and a developer for the Time And Money Java Library. It's an exercise in Domain Driven Design. I'm having a lot of fun with great developers. ROCK!

Updated: Comment Unit Tests For Ruby

I finally got around to updating my Comment Unit Tests For Ruby just for the fun of it. It's more robust, has a better model, and it has tests. I can now put unit tests in the comments of my code. I started using it on a project that I have and I'm loving it!

Here's a simple example:

### >>> 3 + 4
### >>= 7

You can even use variables:

### >>> a='i'
### >>> b=' love '
### >>> c='michelle'
### >>> a + b + c
### >>= 'i love michelle'

And if they are part of the same comment, it will keep the variable bindings active, so you can do this:

### >>> a + ', robot will never die'
### >>= 'i, robot will never die'

And finally, if comparing two objects bores you, then you can create your own equality check like this (notice the >>>?):

### >>> a = 5
### >>> b = 4 + 1
### >>? a == b

Enjoy and Ruby on!

Functional Programming Considered Harmful? Nonsense!

Luke Plant recently wrote a blog entry on "Why learning Haskell/Python makes you a worse programmer". He rants about how difficult it is to write in a functional way in C# (and Java as well). And ends with this quote:

The moral of the story: don't bother improving yourself, unless you have the freedom to improve your environment accordingly. That's rather depressing. Can anyone put a better spin on this and cheer me up?

After reading this article, I was reminded of an argument to remove objects and blocks from Smalltalk. Basically, the argument of closures versus objects is futile. They both have their place and strengths in design. But, without closures, you can use simple objects as a substitute.

Luke's article argues how hard it is to instill functional programminging in languages like C# and Java. I think while it is hard to use pure functional style in these languages, it's matter of changing the way you think about it. I find since I don't have blocks/closures in Java, I use more of a stream approach (think pipe/filter pattern). It's a little trickier in the iterator objects, but the users of the code have to write less and their code is easier. I used this technique to good effect in my Reflective Testing Framework. As for side-effect free programming, I think it's a good goal to try to attain. We have a thing called encapsulation which can localize the effects of change. It's all in the way we think about it.

So, the next time, you see a road block because Java or C# doesn't have some feature from one of your favorite dynamic or functional languages. Think about the goal of the feature and ways you can attain it. Sure, code is more succint in Ruby, Python, Haskell, Scheme, and a host of other languages, but for those of us in the trenches, we might not be able to use them. We're stuck with Java/C#/C++. Be creative and remember to always keep your code easy to understand.