Red Squirrel Reflections
Dave Hoover explores the psychology of software development
Thu, 05 Mar 20096 years of Red Squirrel Reflections, I'm calling it quits. I've now officially gone nuts! Update your RSS feeds and subscribe to http://feeds2.feedburner.com/redsquirrel. See you there!
Fri, 02 Jan 2009
Looking back on my goals for 2006 and 2007, it's gratifying to see that I've accomplished some things. In 2006 I wanted to finish writing the book. Yeah! It's 2009 and the book is done! Better late than never. In 2007 I wanted to spend more time in Obtiva's home office and hire an apprentice. Yeah! It's 2009 and I've been working from our office since April 2007 and we've hired 6 apprentices since that time. For the last 3 years I've wanted to learn more about interface design. Sigh. Still very little progress on this.
So, without further delay, my goals for 2009:
Thu, 04 Dec 2008
In late 2006 and early 2007 I was doing a lot of "selling" for Obtiva. I was trying to win a project big enough to allow me to roll off my current on-site consulting gig. I wanted to start a new practice at Obtiva I called "The Studio". This practice would allow us to work from our office in Wheaton, Illinois, USA and hopefully allow us to create an environment conducive to apprenticeship. I had already found some Rails projects for us to work on. One of these projects allowed us to hire Ryan Platte, Obtiva's fifth full-timer. The rest were done in our off-hours or with sub-contractors, none of them were big enough to justify me leaving a steady, long-term gig a few miles from home. And then in March 2007, I was contacted by Gary Levitt about a project called Mad Mimi:
Hey Dave, I'm a bass player, came to NY from South Africa to contribute to the Paul Simon Group. I set up a music company and am building a hip application for musicians.
He went on to say that he had all the "groundwork" for the project completed, meaning the requirements were ready to be executed over the course of a few months. Anyone who has ever been involved with a software project for more than a few months would find that claim pretty funny, but it was great to hear that Gary had already started laying the "groundwork" (coached by Jeff Patton) and had a delivery date in mind. I was thrilled to receive that email from Gary, and ecstatic when a week later I ended up winning the project despite stiff competition against some people and companies I have a ton of respect for.
I rolled off my on-site gig a month later and showed up in "The Studio", a low-budget, 3 room office about a mile from my home in Wheaton, IL, USA, that smelled a bit like the dentist office down the hall (which meant that kids would occaisionaly run down the hallway screaming as they tried to escape their impending doom). There I was, all by myself, with a new client in New York and some fixed-price, fixed-scope 1 week milestones to churn through. And churn we did. In those first weeks Mad Mimi morphed her identity more than once and a few weeks later we had something we could play with. Mad Mimi was all about creating Promotions, making it easy for people to compose beautiful emails in as few steps as possible. Unfortunately I'm not good (yet) at making things visually beautiful, and so Gary (yes, the customer) nominated himself to become the CSS ninja, and over the course of the coming months, Gary learned how to navigate a Rails code base, run the app locally, use Subversion, and develop beautiful CSS designs. Eventually he even learned how to use Capistrano and deploy the app to the server, but I'm getting ahead of myself.
Not surprisingly, it took longer than a few months to create the product that Gary wanted, partly because Gary discovered what he wanted along the way, and partly because I was still learning how to do what Gary wanted. I had to implement Ajax image uploads along with image drag-and-drop to allow people to have a WYSIWYG-ish experience creating their Promotions. I had to pick and integrate a Rails-friendly background task processor (circa mid-2007) to allow users to pause, cancel, or observe the progress of their Promotion mailings. My drag-and-drop code eventually got rewritten by Tobie Langel when he joined the project in early 2008. The background task processor that I chose, BackgrounDRb 0.2.1, seemed like the only viable option at the time, so I chose it and we're still using it (though I wouldn't say we're raving fans). There was also the issue of dealing with large (to me) data sets triggered at any moment by a user action, such as a user uploading 50,000 contacts or sending a Promotion to 70,000 people. I had some previous (bad) experiences with handling lots of data with ActiveRecord, so at least I knew what not to do, and I got something working with data sets of less than 100,000 with a mostly empty database.
Along the way the Studio practice was growing. I quickly brought Brian Tatnall on board as our first apprentice in May 2007 to help with Mimi and some smaller Rails projects. Brian had worked for a small design shop previously and his big client followed him to Obtiva, so instead of helping me reduce my workload, he actually increased the Studio's workload by bringing a huge (for the Studio) ecommerce project with him. By the end of 2007, the Studio team had grown to 5 people, 3 of whom were apprentices, and Brian had rolled out of the Studio onto an on-site, hedge fund client.
Mimi's development gradually slowed over time due to my growing Studio responsibilities, Gary's burn rate, and waiting for Tobie's brilliant re-write of Mad Mimi's Promotion Composer. We silently launched MadMimi.com in February 2008, where it lay dormant for several months as Gary tweaked it and allowed a small number of initial customers to try it out and put it through its paces. At this point we were still on the same low-end RailsMachine server that the project had started with. As the initial customers started working with more and more data, and sending more and more emails, we found that running 6 Mongrels and BackgrounDRb and MySQL all on the same little server wasn't working. We worked with the guys at RailsMachine to split the web front-end from the BackgrounDRb back-end onto 2 low-end servers. Once we started getting significantly more load, we went to one of their higher-end "8 core" accounts. I must say I am a very happy RailsMachine customer, and we have just finished migrating our large e-commerce client onto RailsMachine. RailsMachine's people are incredibly responsive and have a knack for teaching you how to fish rather than just handing you the fish (they've taught me a lot about system administration).
Gary eventually started promoting Mad Mimi in May 2008. This was were the real fun began. Working with a customer to create something that only exists in their imagination can be an exciting process, particularly when you have the rapid feedback that Rails provides. But watching your code go out into the real-world and begin to generate revenue for your customer and feel the load of real-world data is not something I've been so close to before. Early on in May or June, I wrote a Capistrano task that would spit out Mimi's monthly revenue from the command line. By this point we had trained Gary to use Capistrano, so he was able to watch these numbers closely (as did we). I remember the week that Mimi started generating enough revenue to pay for her server costs ($300 per month). That must have been in June. Then Mimi was generating $1000 per month in July and we got excited. Gary wasn't paying for any advertising, just blogging and getting mentioned on Ajaxian and 37Signals Product Blog. And people were loving Mimi. Gary had created a certain vibe around the product, from the look-and-feel of the site to the Campfire chat support that Gary and his brother Dean expertly manage. Mimi's revenue was growing steadily and I was falling in love with the subscription-based web service model popularized by Basecamp.
Not surprisingly, Mad Mimi's traffic was growing too. We handled our first 100,000 person mailing with a couple hiccups. I needed to do some database optimizations to help with some non-performant scenarios and we needed to increase the speed of the mailings. We had a BackgrounDRb worker responsible for each mailing and it would simply run through the email list, sending one at a time. For our bigger mailings, this was taking too long, so I split up the big mailings to be handled by multiple concurrent workers, and worked on some caching strategies to improve our mailing speed. Our fastest mailings now hover around 20 emails per second. We're going to need to improve that even more, but for now it's sufficient. Gary learned all about how to get emails to render correctly in all the different web clients. Brian and I wrote TamTam so that Gary could create HTML emails with CSS and not have to use inline styles. Colin and I learned about DomainKeys and got those working to keep some of the pickier email providers happy. And by now we've sent out mailings as big as 350,000 and have sent several million emails within a 48 hour period. I've had to write my first couple MySQL stored procedures in order to optimize certain SQL queries and imports, with some guidance from a friend of mine. Needless to say, I've learned a lot in the process.
I presented my experiences with Mad Mimi at Windy City Rails in September 2008. At that point Mimi had just over 150 paying customers generating just over $5000 per month in revenue. I predicted that Mimi would hit $10,000 per month by December. And I'm excited to announce that this prediction was accurate. Mimi now has just over 300 paying customers generating over $10,000 per month. It has been an awesome experience watching Mad Mimi come from Gary's vision to a viable product to a contender against the established email marketing platforms. After seeing the way Gary learned CSS and was adamant about the product's personality, Mimi has forever changed the way I see my customers. After experiencing success with rapid feedback and leveraging Rails to iterate quickly with Gary, it has forever changed the way I approach my projects. And after seeing the simplicity of Mimi's revenue model and watching Gary turn away one buyout offer after another, it has changed the way I think about start-ups.
Nowadays, the Studio is 10 people and still growing. We've split into two teams and will be splitting into a third in the next month or two. I'm proud of the Studio and how much we've improved it since the chaotic, early days when we were chronically over-sold and our first few apprentices didn't get enough mentoring. We've had a lot of trial-and-error, but we've slowly, steadily improved our practices, discipline, and processes over the last 20 months.
Thu, 23 Oct 2008
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.
Fri, 03 Oct 2008Obie's Me Meme post...
Go ahead and follow these instructions if you're into silly memes...
Mon, 29 Sep 2008
Looking forward to a fun weekend with Leah, Fred, and Dan.
Thu, 12 Jun 2008
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:
Tue, 10 Jun 2008
Sun, 08 Jun 2008
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?
If you knew then what you know now, would you have started programming?
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?
Tue, 03 Jun 2008
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.
Fri, 25 Apr 2008
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.
Wed, 23 Apr 2008Paul 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
Sat, 05 Apr 2008Neal 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!
Sun, 23 Mar 2008
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?
Wed, 13 Feb 2008
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.
Wed, 22 Aug 2007
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.
Tue, 10 Jul 2007
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.
Sun, 24 Jun 2007
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.
Wed, 30 May 2007
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.
Thu, 24 May 2007
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.
Mon, 21 May 2007
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.
Fri, 11 May 2007
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.
Fri, 20 Apr 2007Gareth 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 # nilUp 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.
Mon, 16 Apr 2007Ryan 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.
Thu, 05 Apr 2007Tyler 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
Mon, 26 Mar 2007
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.
Wed, 21 Mar 2007
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.
Thu, 15 Mar 2007TextMate's diff view. I hadn't tried this before so I typed it in and crossed my fingers...
svn diff config/* | mateWhich (and I shouldn't be surprised by this) instantly popped up exactly what I wanted:
Fri, 09 Mar 2007Tyler'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.