Red Squirrel Reflections

Rails Rumble 2008: Developing Run.Track.Run.

Leah Welty-Rieger joined Obtiva a couple months ago. She is an apprentice in our Software Studio. (She also recently earned her PhD in Particle Physics from Indiana University.) About a month or so ago, Leah and I were walking back from lunch and started talking about our shared interest in running. Then she told me about an idea she had for making simpler, easier, more informative running software for planning and tracking your training. A couple weeks later I found a link to Rails Rumble 2008. I'd wanted to rumble in the past, because I'm a fairly speedy programmer, and I love competition. But having very little CSS-fu and lacking any inspired 48-hour-sized ideas, I'd never rumbled. Until this year. I immediately thought of Leah's idea and realized that with the addition of CSS-ninja Dan Nawara to our Studio team, we had sufficient skills to rumble. And just because I had the luxury of doing so, I asked Fred Polgardy to join us as well, because, well, Fred's a genius, particularly with JavaScript.

We got together 3 times before the competition to formulate our plan of attack. This helped us start on the same page. We understood the domain model (Users have Runs have Splits), and we knew we were going to integrate with the Garmin Forerunner, and we knew we were going to use Flotr to build the HTML-canvas-based graphs that Leah had specified. We decided to use HAML and SASS, which I had never used, but found perfectly intuitive and productive (and now prefer it). I decided to stick with good old test/unit for TDD. I'm still much more productive in test/unit than any other Ruby testing framework and I needed something dead simple since I was going to be running low on energy. I also planned to use TDD strategically. Basically, I used it to test my models, but developed my controllers without tests. Ironically, this helped keep my controllers really skinny, since I ended up extracting logic into models (such as the Garmin XML file processing and matching scheduled runs to actual runs) and wrapping them in tests. We also decided on the name for the app: Run.Track.Run. We were both excited and disappointed to find out a day later that Relevance had created Run Code Run and would be offering free continuous integration for rumblers, and thereby leading everyone to assume that we copied their name.

The competition started on Friday at 7pm Chicago time. My wife, kids, and I with friends in their house. I rudely, and suddenly grabbed my laptop and bluetooth-enabled modem/mobile-phone and started the process of setting up our github repository with Bort, installed Debian on Linode (with Apache+Passenger, MySQL, Postfix), hooked our build into Run Code Run, and pushed our first Capistrano deployment up to the server. The next morning the 4 of us met at the office and started rumbling as a team. The rest of the story is actually pretty mundane. I got really pissed off, swearing loudly at the Garmin JavaScript libraries for a while until Fred came over and solved the problem. We did a lot of pair programming. And mostly just kicked ass consistently for 48 hours. I got to pair with Leah, Dan and Fred (sorted in order of amount of pairing time). I think everyone paired with everyone. And everyone got enough sleep. And with an hour to go, we were kicking back with beer and making final tweaks. In the end, we launched Run.Track.Run., which I'm particularly excited about, since I'm one of the (currently) 75 runners who are already using the application.

Twitter Etiquette

I have a couple Twitter pet peeves. I follow around 80 people on Twitter, and this list has been carefully optimized over time to maximize signal vs. noise. I'm a huge fan of Twitter, I actually have seven Twitter accounts for the splintered fragments of my personality. I enjoy Twitter so much that I want to highlight 2 small peeves that I'm hoping we can minimize in order to help all of us maximize our signal.

Multi-tweet tweets: Brian Marick, one of the most intelligent, humorous geeks I've had the pleasure of meeting has a long-running habit of allowing his tweets to break out of the 140 character limit. Brian, this is cheating! Embrace constraints!
Context-less replies: I could point to a lot of offenders (myself included) but I'll point at one of my favorite people, Bil Kleb. I often observe people having a glorified instant messaging conversation on Twitter. This can get really noisy if you're not careful. You want to make sure that each tweet has enough context that your followers know enough to know that they're not interested or compelled to click through a username or tinyurl.

OK, stepping down from the soapbox...

The Me Meme

I was catching up on my blog reading on the train (sitting in the stairwell) and read Obie's Me Meme post...

Go ahead and follow these instructions if you're into silly memes...

Take a picture of yourself right now.
Don�t change your clothes, don�t fix your hair�just take a picture. (should be super-easy with Photobooth)
Post that picture with NO editing.
Post these instructions with your picture

Obtiva enters Rails Rumble

Looking forward to a fun weekend with Leah, Fred, and Dan.

Look Ma, No Server-Side!

When I launched the sexy http://polyglotprogrammers.com page, I decided that it would only serve static HTML and JavaScript. I thought it would be an interesting constraint that would help me break out of my server-side tendencies. So I mashed in a Google Calendar and a badge that shows the latest posts from our Google Group. I was happy with how easy this was.

And then we launched Polyglot Programmers of Chicago and had our first meeting. Being the lazy organizer that I am, I didn't ask anyone to RSVP and we ended up ordering too much pizza and stocked too much beer. I pondered aloud at a recent Obtiva geekfest about my need for an RSVP system without any server-side dependency and Renzo suggested we use Twitter. Coming off of a couple weeks of obsessive Twitter hacking, I was keen to try it. (The Twitter API is a programmer's playground, add a <canvas> tag, and it's a programmer's amusement park.) So I hacked together our RSVP system in 10 lines of client-side code. First, I provided the link to submit the RSVP:

<a target="_blank" href="https://twitter.com/home?status=@polyglots+@ppoc+June+2008">RSVP to this meeting via Twitter</a>

Then, I read the RSVP's:

<script type="text/javascript">
function rsvp(json) {
	var confirmed = document.getElementById("rsvp")
	for (var i = 0; i < json.results.length; i++) {
		confirmed.innerHTML += '<img src="' + json.results[i].profile_image_url + '" /> <a href="http://twitter.com/' + json.results[i].from_user +  '">' + json.results[i].from_user + "</a><br />"
	}
}
</script>
<script type="text/javascript" src="http://summize.com/search.json?&rpp=100&callback=rsvp&q=@polyglots+@ppoc+June+2008"></script>

You'll notice I used Summize, which sits on top of Twitter and provides an excellent service for searching through Tweets in real-time. It's funny, when I code stuff like this I feel like I'm cheating. It's freeing to only need to think about the client-side and let the service providers worry about the rest.

Upcoming Conferences

Portland in July: I will be speaking about Apprenticeships on Open Source at OSCON with Brian Tatnall.

Toronto in August: I will be facilitating a game of Ping Pong Programming at Agile 2008 with Andy Maleh.

Chicago in September: I will be attending WindyCityRails and will hopefully have an opportunity to talk about the development of Mad Mimi alongside the product's visionary Gary Levitt.

How did you get started in programming?

objo called me out, so I'm answering the questions.

How old were you when you started programming? How did you get started in programming? What was your first language? What was your first professional programming gig?

9, 13 and 25. When I was in grade school we were introduced to Logo, which was interesting, but since I could only play with it at certain times at school, I didn't get far with it. But it definitely sparked an interest. When I was in junior high we had an Apple IIe. I loved playing games on it, and when I saw the movie Tron, I was convinced that I would one day be a programmer like Flynn. I bought a book on Basic and tried to create some games on the Apple IIe, but mostly just keyed stories into code and had them print to the screen. I gave up when I couldn't create anything compelling. It was 1999 when I was wrapping up my master's degree in child and family therapy and I was fascinated by the internet and the way it was changing the world. My wife and I had just had our first child (who slept in the closet of our one bedroom apartment) and I was looking for ways to supplement my upcoming income. I taught myself enough HTML to secure a side job as a the Teen Advice guide at About.com. Over the next year I was a child and family therapist by day, and a HTML wrangler by night, and I began to realize that I really enjoyed the technical work. I was surprised that I could sit in front of a computer and feel energized. Dreams of Flynn flooded into the back of my mind and I decided to try programming full-time. I was hired by Edventions, a startup in Skokie, IL as a content editor. Over the course of the year I worked there, I taught myself Perl and I worked my way into the programming side of the business. And by late 2000, I had officially taken the red pill. I was completely hooked on programming, specifically Perl.

What was the first real program you wrote?

Most of my early Perl hacking was fixing bugs in or enhancing other people's CGI scripts. The first real program I wrote from scratch was lovingly called PGAS, the Perl Golf Administration System. Yes, for several months in 2002, I was the main instigator of monthly Perl Golf competitions. This is the first time I've stated that publicly, and I'm not sure how I feel about that.

What languages have you used since you started programming?

Java
JavaScript
Perl
C
Ruby
C#
C++
Erlang
Scheme

If you knew then what you know now, would you have started programming?

Absolutely

If there is one thing you learned along the way that you would tell new developers, what would it be?

Find opportunities to Be the Worst.

What�s the most fun you�ve ever had ... programming?

The first was in 2004 when I worked for ThoughtWorks. I was on a team that included Dave Astels, Obie Fernandez and Aslak Helles�y. Though the weekly travel to Detroit was excruciating, working with those guys changed my career, and was a ton of fun.

The second was in 2007 at Obtiva. Our first full-time Software Studio project was madmimi.com. This project had many ups and downs, but working with the world-class Mad Mimi team and watching Mad Mimi come to life has been another career-altering experience.

Who am I calling out?

Polyglot Programming as opposed to Polyglot Programmers

I've needed to clarify something about this polyglot meme to people a few times and I thought it would be a good idea to state it publicly. There's really not much to it, but I think it's important.

There is a difference between polyglot programming and a polyglot programmer.

Ola just wrote another great layers of languages post, and I want to make it clear that he's talking about polyglot programming. I also want to make it clear that I am excited about what he's proposing, and after watching Dean's talk last month, it's also clear to me that this sort of thing is not some hot new trend, it has been going on for decades. But we should understand that polyglot programming could potentially be done by a team of single-language specialists working together to create a multi-language system.

A polyglot programmer is someone who could single-handedly create a multi-language system. A polyglot programmer is someone who might choose a single language for an entire system, and they will be more likely than a specialist to pick a language that suits the problem domain. They might program in a single language for a whole year, and then easily set aside that language and pick up a previous one. I believe that polyglot programming is best accomplished with polyglot programmers. I also believe that it's important for more of us programmers to become polyglot programmers, which is why I helped start the polyglot programmers user groups.

Like I said, there's not much to this, but I think it's an important distinction to make as the meme continues to spread.

Tweet Nodes

I ripped the WordNet server-side integration out of The Lightweight Visual Thesaurus and shoved in the Twitter API to create Tweet Nodes. It's still at total hack and only works on Firefox, but it's a fun little Twitter conversation browser.

Here's how olabini's Tweet Nodes look today...

Paul's Statelessness and Jerry's Truthfulness

I enjoyed reading Paul Graham's Be Good. I found this little tidbit of wisdom echoed the words of Jerry Weinberg'a Secrets of Consulting...

Being good is a particularly useful strategy for making decisions in complex situations because it's stateless. It's like telling the truth. The trouble with lying is that you have to remember everything you've said in the past to make sure you don't contradict yourself. If you tell the truth you don't have to remember anything, and that's a really useful property in domains where things happen fast. --Paul Graham

One of the great advantages of not lying to your clients is that you generally don't have to remember what you said. --Jerry Weinberg

Polyglot Programmers User Groups

I'm excited to announce the birth of a user group focused on exposing programmers to many different languages and providing a place for programmers to learn how to fit different languages together. Inspired by Neal Ford, Ola Bini, and our own experiences as language-agnostic programmers, Fredrick Polgardy, Tyler Jennings, and I are launching the Polyglot Programmers User Groups. Have a look!

A Retrospective on the first year of Obtiva's Apprenticeship Program

One year ago I stopped doing full-time on-site consulting. I started on-site consulting in 2004 when I joined ThoughtWorks, and continued through my first client at Obtiva. I have done a few multi-day, local stints since Spring 2007, but the vast majority of my days have been spent in a smallish office about a mile from my house in Wheaton, Illinois, USA. It was a risk to start Obtiva's Craftsmanship Studio and subsequent Apprenticeship Program, but after a ton of hard work, frequent mistakes and mismanagement, I can confidently say these last 12 months have paid off and the future is brilliant. Let me try to explain what I'm talking about, and why I'm confident about our first year's success. (And thank you to Michael Hunger for asking for more information on this topic.)

What is a Craftsmanship Studio? I should rephrase that to "What is Obtiva's Craftsmanship Studio?" because I can only speak with authority on that. First, what does "Craftsmanship" mean in this context? My best answer to that question is to advise you to go read Part 3 of "Software Craftsmanship: The New Imperative". Being a self-taught programmer, and coming from a right-brained background, the concept of craftsmanship immediately resonated with me. It should come as no surprise that when I had the opportunity to create my own practice within Obtiva, I tried to model it after the ideals that inspired me in Pete McBreen's book.

Second, what is a "Studio" in this context? The dictionary tells us that a studio is "an artist's workroom" or "an establishment where an art is taught or studied". That sounded right to me and it is supported by the fact that programming as art has been a strong theme among the leaders in our field for a long time.

The above ideas basically summed up the vision for our Craftsmanship Studio: a place where programming newcomers can come to learn the craft of software development on real-world projects working closely with experienced developers. Reality was much messier than our vision, and there were too many times when apprentices were isolated or working together without much oversight. This messiness can be attributed to the fact that I am a journeyman, not a master craftsman, and therefore this year was filled with mistakes as I learned (by trial-and-error) about project management, customer relations, capacity planning, and recruiting. Thankfully we have had about 50 retrospectives during that time and have adapted our agile principles into a process that continues to improve each week.

So if our Craftsmanship Studio is where newcomers and old-timers work, learn, and mentor, what is an Apprentice? The above reference to Part 3 of Pete's book will quickly introduce you to the concept of apprenticeship...

A central tenet of the craft model is that it is hard to pick up a skill just by being told about it. You actually have to practice the skill under realistic conditions and under the watchful eye of an experienced practitioner who is providing feedback.

This describes the need and the relationship, but in reality, who are these people, these supposed newcomers? My working definition for someone in an apprenticeship is: a person who is looking to maximize their learning opportunities, even at the cost of other opportunities. Often this means purposely putting yourself into a Be the Worst situation, which is exactly what I did when I joined ThoughtWorks. For Obtiva, this means we're looking at potential and attitude rather than credentials. These people could probably make more money somewhere else in the short-term but they are making an investment in learning that will pay off in the long-term.

I would like to see our Apprenticeship Program mature into a more formal apprenticeship with better feedback mechanisms and milestones. That said, I can say that the four apprentices who have participated in our Craftsmanship Studio have been very successful despite my shortcomings as a manager. This year reinforced for me what I learned when I was an apprentice: your apprenticeship is what you make of it. We had a Perl web developer come to us, learn Ruby and Rails and Java, and leave us writing a multi-threaded Ruby/JRuby/Java/JNI application that leveraged a 16 core machine for a local hedge fund. We had someone come to us to reboot his career, learn Unix, MySQL, Perl, Ruby and Rails and is now both managing and developing e-commerce deliveries for the Studio's largest client. We had someone come to us from a local Rails sweatshop, learn technologies like Sphinx, rSpec, god, ActiveMerchant, CruiseControl.rb, along with Perl, who is now introducing Git into the team and will soon be technical lead on his third Rails e-commerce project. We had a network administrator come to us, who after rapidly delivering several different Rails projects, is now wrangling a large, chaotic Rails codebase under control via rSpec better than many experienced developers I know.

What do I attribute our success to?

Co-location: Nothing beats face-to-face teamwork
Pair programming: Nothing beats side-by-side development
Test-driven development: Nothing beats ping pong programming with tiny feedback loops
Agile principles: Constantly re-evaluating our reality with the principles we hold and readjusting our process accordingly
Respecting our customers: We work directly with the Goal Donor and use their language to build user stories
Great tools: We use Macs with extra flatscreens and regularly bring in new technologies to boost productivity
Hard work: Staying focused on our deliveries despite tough conditions
Culture: Nothing beats an impromptu team snowball fight in the parking lot to get those creative juices flowing

All of these have added up to an ever-increasing demand for our servies, which we are getting gradually better at managing, which combined, keeps everything chugging along at a sustainable pace. This pace is the critical piece because it means we also have lives outside the office that can energize us for our next day of teamwork.

Moving to O'Reilly

After my Lorax-like Apprenticeship rant last year, I've had my nose to a few different grindstones, leading Obtiva's Craftsmanship Studio, working on the Apprenticeship Patterns, and attempting to be a good enough husband and father to Staci and the kids. Things are leveling off now as I'm beginning to understand a bit more about what it takes to manage a Craftsmanship Studio and I'm starting to pick up some momentum on the book writing. I'm excited to announce that Ade and I have decided that the Apprenticeship Patterns will be published by O'Reilly as Software Craftsmanship: From Apprentice to Journeyman in their Theory In Practice series. One of the main reasons that we chose O'Reilly is their commitment to the web and their alignment with my vision for the web site and community that I wanted to develop around the book. I'm pleased to say that they have provided an excellent platform (press release) to facilitate exactly the sort of situation I wanted: full content of the patterns available the public, community forums, and a blog.

Most of my blogging attention will be focused on the book, but I will also be posting tidbits of my lower-level day-to-day development work on my Stumblog. If you'd like to continue to follow me via feeds, please subscribe to the book feed and the Stumblog feed.

A Call for Apprenticeship

At Agile2007 last week, I snuck into the last 30 minutes of Uncle Bob's talk about Craftsmanship and Professionalism. When Uncle Bob talks about Craftsmanship he is generally talking about nitty-gritty details of the craft, such as specific practices and tools, but he did have one slide on apprenticeship. He ranted a bit about how most universities do not equip graduates with sufficient skills to allow them to deliver quality software from day one. (Not to mention the significant number of people who come into software development from other fields and have never even received the inadequate computer science education that Bob was referring to.) Bob asserted that we need to apprentice these young people, these graduates and newcomers. Bob asserted that the most effective learning situation is one where a small number of apprentices work alongside an even smaller number of journeyman, who are receiving guidance from a master craftsman. It was music to my ears until Bob polled the audience for anyone who was working in that environment.

I proudly raised my hand, but my heart sank as I looked around and realized I was the only one raising my hand.

For the rest of the conference I felt a sense of pride at the revelation that Obtiva's Craftsmanship Studio is such a unique phenomenon. But I also struggled with a sense of sadness and frustration at the lack of apprenticeship opportunities our industry is providing to graduates and newcomers. My biggest point of frustration is with small companies (1-20 people) made up entirely of super-experienced, world-class developers, coaches, and trainers. I understand your compulsion to only hire people with over 5 years of professional experience who have established reputations, but I believe you're hurting the industry by implicitly refusing to take on the responsibility to apprentice a few people along the way.

Where do graduates and newcomers go when they're looking for their first gig? They go where people are hiring entry level people. This is where we lose some of our greatest potential because people who had the potential for greatness lose heart sitting at the bottom of mediocre, bloated, beaurocratic development organizations. Imagine if young Nathaniel Talbott, inexperienced and unqualified to do much of anything interesting, had found an "entry level" position, rather than becoming the first apprentice of RoleModel Software. Sure, someone else would have probably written test/unit. And Nathaniel would probably still have become a good software developer. But I am convinced that Nathaniel's apprenticeship made an impact on our industry, and we're better because of it.

Apprenticeship is more than simply hiring entry level people. Apprenticeship is coupling an apprentice to a journeyman. That doesn't mean they're pair programming all the time, but it does mean that the journeyman is overseeing the apprentice's progress and that the apprentice has an experienced developer in close physical proximity to turn to for guidance.

Furthermore, apprentices are not necessarily entry level people. Our first apprentices generally had a year or two of experience under their belt. Some are in the middle of college degrees. Some had recently graduated. One is re-booting his IT career later in life. Apprentices are people who are willing to take on a junior role that maximizes their learning opportunities as opposed to people who try to climb as quickly as they can into roles that maximize their financial opportunities. In my experience, if the apprentice has talent and the right attitude, their financial success will inevitably follow their learning success.

Please consider creating an apprenticeship at your organization. I believe apprenticeship is our industry's best hope for addressing our talent shortage.

I was lucky enough to attend a great university, where I learned much theory (there was less theory back then). What really made the experience shine, however, was an apprenticeship that I served. One of the graduate students took me under his wing. He didn't explicitly teach me, but he showed me by example how a great programmer thinks. Working next to him month after month, I absorbed more practical knowledge about design, coding, and debugging than any course could impart.
Later, I joined a start-up in London where I served a different sort of apprenticeship. My new boss showed me that software development was as about people as it was about technology. He helped me understand the business side of the equation and taught me how great development builds personal relationships from a base of technical strength.
I "graduated" from these two very different apprenticeships a far, far better developer than I started out. Based on my personal experience, I'm a believer. Working with masters is the best way to learn a craft.
Dave Thomas in Software Craftsmanship, p. xiv

Rails TDD Boot Camp: a year later, Astels, Google

I returned from Manhatten last month after my third running of Obtiva's Ruby on Rails TDD Boot Camp. And for the first time, I wasn't completely exhausted! Although I'm not a natural-born public speaker, practice does help a lot, and hopefully it showed this time.

It's hard to believe that it was only a year ago that Obtiva was scrambling to meet the Rails training demand as we constructed our curriculum in preparation for our first course. Since that time the course has run 7 times with Tyler Jennings, Obie Fernandez, and myself as trainers in Illinois (Wheaton, Lombard, Chicago and Evanston), California (San Jose), and New York (Manhatten) for a wide variety of businesses (Cisco Systems, Northwestern University, Stony Brook University, Nielsen Media Research to name a few). It's been an awesome experience to provide these trainings and adapt the course with the changes in the Rails landscape.

I am pleased to announce that our 8th running of this course will be for our newest client Google. And I am even more excited to announce that the instructor for this course will be Obtiva's newest team member Dave Astels.

The Vehicle

This post was going to be an email to a friend who is interested in joining Obtiva, but most of what I was going to tell him were things I've been wanting to blog about, so I figured I'd make it a public-facing message...

After I had been with Obtiva for six months, I experienced a change in perspective that has changed my career, and hopefully, the careers of many other future Obtivians. At that point I had already delivered my first training course, and with the help of my fellow Obtivians, I had introduced Ruby and Rails at the J2EE shop of one of our main clients. I was excited to make an impact, but it began to occur to me that a company as small and as financially stable as Obtiva is more than just a place to work hard and make an impact, it is a vehicle that can be driven. The way that the company is structured provides us with incentive to not only do great work, but to go and create the work we want to do. And that is exactly what I did. I subscribed to a bunch of feeds like the 37signals Gig Board and started winning business. These wins allowed us to hire 4 of our 11 employees and provided us with the first wave of apprentices for our Craftsmanship Studio in Wheaton.

Nine months later, I am living a dream. I am riding my bike to work and spending my days with Brian Tatnall, Victoria Wang, and Joseph Leddy in the Studio, helping them along their paths toward mastery as we deliver Rails projects to a variety of customers using whatever tools we want. While I certainly cannot take all of the credit for my good fortune, I can say that I have maximized the situation, and we have room for others to do the same: Gareth sees the same potential and Obtiva has become a vehicle for him to grow our consulting business into the world of business and finance.

Friend, you will likely have many opportunities to join Obtiva in the coming years, but I am uncertain whether the company will be as malleable as it is today. You are a multi-talented person, a world-class software developer, to be sure, but you have many other talents that could be leveraged to allow you to use this opportunity as a vehicle to drive you toward exactly the sort of work that you want to be doing, and where you want to be doing it.

Rails moves my Bottleneck in Web Development

Geoffrey Grosenbach's latest post reminded me of something I've grown to appreciate over the last couple years: web development with Rails pushes me out of the confines of my codebase and into the other aspects of web development much more quickly than any other web development environment I've used before. Rather than slogging through the painful verbosity of a J2EE codebase, on a Rails project I am (like Geoffrey) hopping around on various servers' command lines, configuring Apache, defining CSS, and crafting Prototype-inspired JavaScript features. For whatever reason, these are all aspects of web development that I had grown to belittle in a previous life when I was more interested in intellectual pursuits.

What I'm realizing lately is that while I cherish what I've learned about objects, agile, and patterns, I'm feeling a bit lop-sided (which isn't surprising if you look at my reading lists over the years). Rails has internalized some the ideals that came out of some of the most important software development revolutions of the last few decades. Martin notes:

...the [R]uby community has formed around the best ideas of the OO and Extreme Programming communities. Listening to the keynote of Jamis Buck and Michael Koziarski I was delighted to reflect on the thought that they were right there in the values of Ward, Kent, and all the other people who've been advocating clean code, well-factored object-oriented design, and testability. These ideas have made a great impact on many other technological communities, but in Ruby-land they are the orthodoxy.

Ruby and Rails' intrinsic values mean that my bottleneck has moved away from application code and (as always) I've got some learning to do in the ecosystem that surrounds and supports a successful Rails project. Thankfully I work on a team of people that have a great diversity of backgrounds and talents. On teams like this, we often have both partners in our pairing sessions switching frequently between student and teacher. It is a priceless dynamic and one of the great advantages of working with apprentices.

The Dependencies of a Craftsmanship Studio

As we continue to expand our Craftsmanship Studio, I am becoming increasingly aware of our dependencies. In order to grow better as we grow bigger and maintain a healthy mix of apprentices and journeymen (no masters yet), we are absolutely dependent on the essential attributes of a software developer. As Andy said in one of his long-lost podcasts, the two most important attributes of a software developer are the ability to communicate well and to learn quickly. I would add passion to that list.

Mentoring apprentices comes in many forms. Some of it is indirect ... they overhear your conversations ... they read your code ... they read your blog (!). But some of it needs to be direct, and in those moments, I am sacrificing my productivity on some other activity in order to answer a question, provide guidance, or sketch a domain model. That sacrifice is an investment. I believe that 10 minutes now is going to be paid back tenfold in future productivity gains. And I believe that because it's obvious that our apprentices Victoria and Brian have the attributes that Andy was talking about.

A couple of examples ... Victoria's ability to communicate well lightens my workload because as she is implementing features, she can interact directly with our customer, allowing me to stay focused on my development tasks rather than diving into Basecamp or GMail. Brian's ability to learn quickly was apparent after I reviewed our Rails portfolio with him in his first few days and a week later he had single-handedly retrofitted ActiveRecords (with advanced associations) onto a legacy database on his first Rails project.

Thinking about Portland; Refactoring in Wheaton

I just caught up on a bunch of the blogging from RailsConf. It sounds like it was an excellent time. But I'm surprised that I didn't hear about anything controversial or earth-shattering. Perhaps Rails is stabilizing? Anyway, while part of me yearned to be there, the end of my week in Wheaton turned out to be an excellent experience in its own right (on a smaller scale).

Victoria and Brian are working their way through Refactoring and we are meeting weekly to discuss what they're learning. One of the first questions from the first few chapters was "What is an Abstract Class?" This important and fundamental question launched us into a contrast of Java's Interfaces, Abstract Classes, and Packages with Ruby's Module. I have always said in our Rails course that Ruby's Modules play double-duty (namespaces + mixin), but this was the first time I had illustrated that point to people who know Ruby better than Java. It was a good discussion and I feel privileged to be able to guide Victoria and Brian along their path toward mastery and seed a culture of learning at Obtiva.

I then shared some of my reflections on reading through the Code Smells with my Ruby hat on. The ones that stuck out most to me where Feature Envy and Incomplete Library Class. What struck me about these is how much more freedom Ruby gives you (than Java) to eradicate these smells from your code-base. Specifically, the Move Method refactoring can, in Ruby, move code all the way into the class where it belongs, regardless of whether you wrote that class or not. For example.

Establishing our Software Craftsmanship Studio

These 20 days of blogging silence were brought to you by...

Rolling off of a project at a local client
Kicking off a project in Obtiva's Wheaton office
Moving out of a flood-prone house and into a house up the road
Brian Tatnall joining Obtiva as hour first full-time software apprentice

Working in the Wheaton office has been a most excellent transition. While there are some mundane details to take care of, it's all in the name of establishing a Software Craftsmanship Studio we can call our own. Like any software company that does consulting and training, there will always be some of us at client sites or running trainings in exotic locations. But there will also always be a sub-set of us in the office delivering full-fledged projects from our Studio.

And that is what Brian and I (and soon Victoria will be nearly full-time with us!) are establishing. A place where apprenticeships flourish, where footwear is optional, where collaboration is dialed up to 11, and where we deliver top-notch software to our customers on a daily basis. It's been intense thus far, and I anticipate some great times ahead.

Ruby has variable scoping

Gareth joined me in the d'oh! club today when I revealed to him the revelation that Ryan provided me back in January. Ruby has variable scoping, meaning that this code works just fine:

if false
  a = 1
end

puts a # nil

Up until Ryan revealed this to me, I had been merrily (and needlessly) declaring my variables outside the control structures that defined them. Maybe Gareth and I are the only ones who weren't aware of this aspect of Ruby (and many other dynamic languages), but just in case, I thought I'd share it with you.

Tomayko on Scaling with ActiveRecord

Ryan says:

Frameworks don't solve scalability problems, design solves scalability problems.

I agree. Using a tool that gets out of your way (like ActiveRecord) gives you the power to design your own solutions with minimal accidental complexity.

via Obie

Heading to D.C. to demonstrate One-Size-Fits-One

Tyler and I will be presenting the fruits of some of Obtiva's Rails work at Agile 2007. We have delivered several planning and tracking tools for software development teams using Rails over the last six months. Through these engagements, we discovered that Rails proficiency and Agile coaching are a killer combination for creating planning tools that you can adapt alongside your process. While there are plenty of one-size-fits-all agile planning tools out there, they often do too much, too little, or can't adapt to your needs. If you're an agile team using planning and tracking software (rather than Excel or index cards), you need software that's actually soft, like an agile process.

If you follow a methodology out of the box, you will have one that fits some project in the world, but probably not yours. --Alistair Cockburn, Agile Software Development

Gareth Reeves joins Obtiva

Kevin introduced me to Gareth Reeves almost a year ago, and Gareth and I quickly hit it off as we carpooled to the first annual RailsConf. I was excited to meet Gareth because I remember reading some of his papers on XP back when I couldn't get enough of the XP kool-aid. Ever since then we've been working on getting Gareth into Obtiva and I'm thrilled to announce that we finally have him!

Gareth has been involved with XP from the early days, and was mentored by none other than Kent Beck. He brings a mountain of agile and Java and (more recently) Ruby experience with him and we're excited to see where his expertise takes us. Gareth's first gig will be joining Ryan for a Rails coaching gig at a nearby hedge fund.

Homesteading and Inshoring in Wheaton

I'm excited to announce that my primary goal for 2007 will come to fruition next month. Since we opened our Wheaton office in December, I've been splitting time between working on-site at one of our main local clients and leading our Rails projects out of the office. Obtiva just landed a project (yet another coastal gig) that will allow me to work full-time out of our Wheaton office building our Rails practice and further establishing our Craftsmanship Studio. Life is very good.

While the project itself is interesting in its own right, one aspect that greatly excites me is that Jeff Patton, agile product design pundit, is heavily involved. I am excited to collaborate with Jeff and experience his approach to agile software development on an ambitious Rails project like this one.

TextMate is my friend

I got a little thrill just now when I wanted to have a look at some changes I've made in one of our Rails projects and it occurred to me that I love TextMate's diff view. I hadn't tried this before so I typed it in and crossed my fingers...

svn diff config/* | mate

Which (and I shouldn't be surprised by this) instantly popped up exactly what I wanted:

Tyler's first course

I was in and out of Obtiva's office in Wheaton all week, so I was able to eavesdrop on Tyler's first attempt at instructing our Rails TDD Boot Camp. It has been humbling to watch Tyler pick up the course that I helped develop last year, make it RESTful and 1.2-friendly, and then deliver it with confidence. Unlike me, who was always on the edge of collapse after day 4 of the course, Tyler was itching for more. I believe this officially confirms that Tyler is an extrovert. You can read his latest blog post for his reflections on the experience.

Ideas for Teaching Kids to Program

Victoria is looking for feedback on her ideas for how to introduce programming to children. If you have experience or opinions on this, post it here.

BTW, the child Victoria is going to be mentoring is Rose, my oldest daughter. They'll be meeting for the first time next Thursday afternoon. Pretty cool, huh?

3.weekdays.from_now

sudo gem install facets

require 'rubygems'
require 'facets/more/times'

puts 0.weekdays.from_now # Wednesday (today)
puts 2.weekdays.from_now # This Friday
puts 3.weekdays.from_now # Next Monday
puts 4.weekdays.ago      # Last Thursday

See http://facets.rubyforge.org/src/lib/facets/more/times.rb for details.

Ruby's Protected Access

Jamis posted yet another nugget of wisdom. This one was about Ruby's method visibility, which can be tricky for people coming to Ruby from Java or C#. Jamis left one aspect of the protected access level as an exercise for the rest of us, so I figured I'd write up an example that helps illustrate when you would use protected vs. private.

class Sibling
  def ask(sib)
    sib.tell
  end
  
  def spy_on(sib)
    sib.secret # will always complain
  end

  protected

  def tell
    secret
  end
  
  private
  
  def secret
    "Charlie tooted"
  end
end

rose  = Sibling.new
ricky = Sibling.new

begin
  puts ricky.tell
rescue
  puts "Ricky will only tell another sibling"
end

begin
  puts rose.spy_on(ricky)
rescue
  puts "Ricky complains when Rose tries to find the secret"
end

puts rose.ask(ricky) # Ricky will tell if Rose asks nicely

One of the main differences for Java developers is that objects of the same class can't see each other's private methods.