-
Get a monthly update on best practices for delivering successful software.
I got a few angry and scolding comments on my last post on pair programming. Let me address each of the issues in turn:
It's easy for folks to misunderstand pair programming and to dismiss it as useless, weird or wasteful. It's one of the first things that gets ditched when the going gets tough, yet it's one of the most important, along with TDD. That's why I wanted to make as strong of a statement as possible in favor of pair programming and against singleton programming.
Topics: Agile Development, Pair Programming
On my rails projects, I've used restful_authentication before and I am using authlogic now. Even though I have passed the initial hesitation phase with authlogic, I can't say that I am totally sold.
What I like about authlogic is it refrains from providing any controller/view level support and handles model layer better. Instead, it provides a solid model functionality that is similar in principle to ActiveRecord and provides lots of how-to examples on how you might code your controllers/views/workflows. It does it well. Although authlogic is complemented for refraining from too much code generation, Authlogic still does a lot of magical stuff. You encounter this readily with tests. Instantiating and persisting a user will log you in! It is hard to test your User model from console since authlogic will fail if you try to instantiate User object in console. You have to jump thru hoops (include Authlogic, set proper controller reference) to get it to work. Continue reading »
Cold Caller: I just Googled "Software+Developers+Chicago" and your company didn't show up on the first three pages. You can use our help!
Me: I just Googled "Search Engine Optimization Consultants." Your company didn't show up on the first three pages either.
Cold Caller: Thanks for your time, sir.
When scientists and engineers explain their esoteric disciplines to the general public, they reach for analogies. Sometimes those analogies are apt and serve to clarify what is hard to understand, sometimes they are less apt and serve to obfuscate and confuse. We certainly use our fair share of analogies in software development -- construction, manufacturing, brain surgery -- and some of them, especially the one to construction, have been very harmful.
So when I saw the article in the NYT this past week on pair programming, I started counting the analogies.
Topics: new york times, Pair Programming

A lot of pair programming chatter this week. Starting with a New York times article describing pair programming at Hashrocket. It's an interesting article, with a tone that could be described as "anthropologist describing the strange, yet quaint customs of the native tribe"
Obie Fernandez followed up with a list of 10 reasons why pairing doesn't work in most cases. It's actually a list of the things that Hashrocket does to support pairing, although entries like "2. Most software developers just don't want to work that hard" and "1. Most software shops don't really care about excellence" do have a certain, "aren't we great" vibe to them, causing Mike Gunderloy to dryly observe: "Funny, Extreme Programming Explained never said anything about fancy hw or being awesome as a prerequisite for pair programming."
C'mon Mike -- everybody knows that being awesome is a prerequisite for everything in XP.
Josh Susser adds that pair programming isn't right for all projects, particularly projects that have long compile times that force the pair to stare blankly at the screen.
I'd also add this interview with Kent Beck because a) every programmer could use some more Kent Beck in their life and b) because he talks about XP as being concerned with the the social context of programmers, with pairing being a part of that.
Now you are caught up. Here's the part where I talk.
Topics: agile, Ruby on Rails

A couple of days ago I happened upon an interesting article about the difference between art and design. The author makes a lot of interesting points, and whether you agree or not with the statements he makes, the article does make for a great conversation starter.
Art and design are two different words, and some say two different worlds as well. The use of each often comes with a distinct connotation. I could go on about how design's goal is to solve a problem, whereas art doesn't necessarily always have a problem to solve. I could talk about how art doesn't necessarily require a common user experience, whereas design more often than not does. I could expand upon that by discussing how art doesn't require that a thing be usable, whereas design is often judged in part or whole by its level of usability. I could even discuss how art can be effective whether done collaboratively or not, and contrast that with numerous examples of how here in our agile software development environment at Pathfinder we find collaboration inseparable from our design process.
But I could also talk about how much art and design overlap and blend, so much so that it becomes difficult to make concrete distinctions. And how, sure, software design is about solving a problem, but it's also about solving a problem beautifully. Continue reading »

If you're an ambitious new Rails developer in Chicago who wants to work along side Dr. Noel and our other sage Rails developers, check out our Rails Internship.
Topics: Ruby on Rails Internship
The problem: I needed to display a warning to a user if the data they were looking at was more than 90 days old.
The solution: Create a method that takes 2 dates (either DateTime or Time), and returns the number of days, or hours between them.
def self.difference_in_dates(date1, date2, unit = 1.day) return nil if date1.nil? || date2.nil? || unit == 0 (( date1.to_time - date2.to_time ) / unit).round.abs end
The problem was simple enough, and my tests were all passing, so I moved on to my next task.
That code has been out in production for several months, but earlier this week, a new developer told me he got an error when running the test:
NoMethodError: undefined method `to_f'
for Mon, 21 Sep 2009 14:29:38 -0500:DateTime
(we're running this in Rails 2.0.2)
I looked at the code, knowing it was working before, ran the unit tests myself, and didn't see the issue. Now I'm on Windows and everyone else is on a mac, so as soon as I run into an issue that no one else has seen I want to prove if its a Windows problem. But wait, this test has been running in our Continuous Integration server (Hudson) for months, and no one else on the team ever had any issues with it, and the code has been working in production without any errors in the logs.
I jumped into rails script/console to see what's up, and here's what I found:
>> x = DateTime.now => Wed, 23 Sep 2009 00:00:00 +0000 >>; x.to_time => Wed Sep 23 00:00:00 UTC 2009 >> x.to_time.to_f => 1253664000.0
Which is what I expected, but when I asked the other developer to run that same instruction, he got an error.
>> DateTime.now.to_time.to_f NoMethodError: undefined method `to_f' for Mon, 21 Sep 2009 14:29:38 -0500:DateTime
What's up with that? We're running the same code, and all of our libraries are the same version. Looking at the date value in his error, I saw the timezone, and decided to try this variation locally:
>> x = DateTime.parse("2009-09-21T14:29:38-0500") => Mon, 21 Sep 2009 14:29:38 -0500 >> x.to_time.class =>; DateTime
So I'm gathering that when there is a timezone and you ask DateTime.to_time, its just going to give you back a DateTime.
Continue reading »

I've worked on more than a few software projects over the decades and one of my favorite little misunderstandings is the Importance versus Effort disconnect. That's where non-experts assume that because a particular part of a software system is more important than another, it must also take more effort to develop. That is rarely the case and, in fact, importance -- however that is defined -- is rarely a driving factor in determining effort or cost. This sort of misconception can result in some planning and budgeting mistakes, sometimes to comic or even tragic effect.
To illustrate, I can point to a trading system that I worked on (the names have been changed to protect the innocent). The average size of a transaction in this system was over $1 billion in 1990's money. The part of the system that resolved the transactions was really really "important," but the part of the system that allowed an application helpdesk to support users by seeing what their user's saw cost 60% more to develop. That's right, an "unimportant" helpdesk module was more expensive and took more effort and cost more than the "important" backend that handled billions of dollars a day.

Please continue reading after the next sentence.
I installed Snow Leopard a couple of weeks ago.
Wait -- don't stop reading. This isn't a post about how to install MySQL or a post about whether or not Snow Leopard is the Greatest Thing Ever. There are plenty of other places on the Internet where you can get that information.
I wanted to talk about two cool corners of the Ruby universe that I started using as a result of my Snow Leopard installation: MacRuby and RVM Continue reading »
Topics: Ruby on Rails
At Pathfinder, we do our best to help our clients experience the software through the eyes of the user. Defining a feature includes explaining who will be using it, what they need to accomplish, why they need to accomplish it and how they’ll actually do it.
We start with personas (who) — they define the user base and let us identify the primary users whose needs we should focus on, which in turn drives the feature list. Personas also bring the human element into software development. Rather than using a vague term such as actor or user, terms that can easily be dismissed, we now have Myrna from Accounting, a numbers guru who is the primary user of the new software. Myrna is not so easily dismissed, especially once her needs and goals are identified.
We move onto user stories, all of which are written from the point of view of the personas: Continue reading »
Topics: user centric design
The other day, I was trying to get the icon for a button in flex programmatically for a FlexUnit test. The code I was testing set the icon of a button using setStyle('icon', ICON). I attempted the obvious button.getStyle('icon') in the test, but was surprised that this always returned null.
A little bit of digging revealed that the I needed to go through the style declaration for the button. When changing my test to assert on button.styleDeclaration.getStyle('icon'), I was able to successfully access the icon.
I found this a bit non-intuitive, but fortunately it only involved some investigation and minimal code changes.
Topics: flex 3
If my previous post about the value of agile meetings over traditional status meetings got you interested, I want to share a common pattern of behavior I often see from teams trying scrums for the first time. Hopefully you can avoid these and save yourself some time.
For new teams to Agile the statuses given in scrums are generally … well … lies. “Yep, on time. No obstacles.” I was once told by a colleague that, “You can’t hide on an Agile team.” This is true. However, this kind of exposure can be extremely uncomfortable for individuals to get used to. In traditional software teams people aren’t used to their peers asking them direct questions and paying close attention to their progress.
Continue reading »
Vu360, the latest Pathfinder product, was launched by our client the Blue Book of Construction earlier last month.
It’s an Internet-tethered desktop application that enables easy viewing, markup and takeoff of PDF and TIFF documents for the architecture, engineering and construction industry. Some of the features include:
Continue reading »
Sometimes I write these just for me.
As I've mentioned a couple of times, tomorrow I'll be speaking at WindyCityRails, and I need a checklist of all things I don't want to forget, and all thing things I want to do to make the talk great.
Continue reading »
Topics: Ruby on Rails