8th Light Blog

This Monday my colleagues and I went to 37 Signals’ Getting Real workshop. Overall I give the workshop a thumbs up. They seem to be a good groups of guys.

from left to right: DHH, Gilberto Medrano, Paul Pagel, Jason Fried, Me

I’ll summarize by saying that the workshop is about how 37 Signals works. How they make decisions, how they build software, how they design software, and how they sell it. They were very candid about everything and that was refreshing.

At the end of it all, my colleagues and I begged the question: what did we learn? We all agreed that we didn’t really learn anything except that our philosophy is very similar theirs. However, there were a few points of contentions.

37 Signals builds their own software and they have a system that suits their purpose perfectly. 8th Light develops software for clients and that means we have to do things differently. One difference was acceptance tests. During the workshop, Gilberto asked what 37 Signals’ opinion was on FIT and acceptance tests. David (DHH) responded by saying that they don’t use or need acceptance tests because acceptance tests can’t capture the design and usability aspects of their software. I actually had this conversation with DHH a year back or so at a Ruby gathering in Chicago and he was of the same opinion. I agreed with him then and agree with him now. If I was building my own software and was essentially my own customer, I wouldn’t use acceptance tests either. But when building software for clients, acceptance tests become a critical tools for communication. Clients have expectations and no matter how many words they use or gestures they make, their intent does not become concrete until you put it down in an executable format. I would not dare to engage in a contract development arrangement with out acceptance tests.

There were a few other strategies that work for 37 Signals but wont work for 8th Light, such as hiring strategies and distributed workforce. Mostly this is based on 8th Light’s apprenticeship model.

If you get the chance to go to their workshop, check it out. And keep your eye on these guys. Their tools are pretty sharp and I trust they’ll impress us plenty more.

Show me a software craftsmen and I’ll show you someone who can program in any language if they had to.

From time to time I meet developers who define themselves by the one and only programming language they know…. “I’m a Java developer”, “I’m a .NET developer”. It’s deplorable. I suspect such people don’t care much for their career.

Better are developers who can whip up code in multiple languages. Web developers, for example, often have to code in javascript in addition to the primary language whether it be Ruby, Java, or .NET. That’s respectable. Yet, many of these developers are intimidated by the notion of programming in some other language like C or C++. It’s a shame. There’s lot’s to learn from unfamiliar languages.

A Craftsman will not shy away from using the right language for the job. They understand that the act of programming is fundamentally the same despite the language being used. A craftsman is not intimidated by unfamiliar languages. When they’re confronted with a new language, they’ll learn it. After all, new programming languages are easy to learn.

In rails, migrations are generated like so

paul-pagels-computer:~/RailsProjects/project paulpagel$ ruby script/generate migration CreatePacketTimestamp exists db/migrate create db/migrate/013createpacket_timestamp.rb

This creates a numbered migration with an up and a down schema direction. This has been incredibly helpful when dealing with the schema changes. The problem our team has found is doing migrations with subversion.

You run migrations by

paul-pagels-computer:~/RailsProjects/project paulpagel$ rake migrate

Which looks in the schema_info table to find which version of the schema your database is representing, and updates it to the most recent version (the highest number).

The problem comes into play when you have multiple people making migration scripts on their local machine at the same time. If two different people did a migration at the same time and committed them you would end up with two migrations. Which one gets run?

I am not sure how to solve this one yet. I have been loving rails, but this has already has put a dampener on it.