Subscribe
Posted on February 27th, 2009
A couple of cool going-ons over the next several weeks:
- On Monday, March 2nd, David J. Anderson will be in Tampa for one day. We’re going to do a get-together in the evening, so if you are interested, let me know via email (foyc at this blog) or on Twitter at cory_foy. David is putting together the Lean Kanban Conference coming up in Miami May 6th-8th
- BarCampOrlando is April 18th in sunny Orlando, FL. Be there!
- And, while I can’t reveal too much yet, I’m planning on putting together a Day of Ruby here in Tampa. The tentative date is May 16th, but watch this space, the blog or the official Tampa site next week for more information
Posted on February 18th, 2009
In my overview post on this series, I used the term discipline, and still believe in that term. Some people commented that it may be confusing, since there are so many ways we think of and talk about discipline. The easiest way to explain it is with this awesome quote from The Fifth Discipline:
The way to begin developing a sense of personal mastery is to approach it as a discipline, as a series of practices and principles that must be applied to be useful1
Peter then goes on to talk about discipline being an activity we integrate into our lives. I think this captures the exact spirit of this series and of the research into this. The goal of this is not some checklist of practices that one can do a couple of times and feel good about themselves. Rather, this aims to be a list of embodied activities that we continually practice, learn and improve upon.
The katas we’ll be developing play a large role in this. In the book Scaling Lean and Agile, Craig and Bas say:
Many good American companies have respect for individuals, and practice kaizen and other tools. But what is important is having all the elements together as a system. It must be practiced every day in a very consistent manner2
Practice. Consistency. Thinking of the whole instead of individual practices. These are what define the disciplines we’ll be exploring. Two more quotes from The Fifth Discipline sum it up:
To practice a discipline is to be a lifelong learner. You “never arrive”; you spend your life mastering disciplines3
Practicing a discipline is different from emulating “a model”. All too often, new management innovations are described in terms of the “best practices” of so-called leading firms…I do not believe great organizations have ever been built by trying to emulate one another, any more than individual greatness is achieved by trying to copy another “great person”3
Posted on February 13th, 2009
In my last post on discipline, I discuss disciplines as being the thing that kicks in when motivation fails you. More importantly, I state that there are specific disciplines which I believe apply across software developers wishing to be better at what they do.
In doing research for this topic, I came across many references to this same concept in the martial arts world. Some interesting ideas have come from an initial scan through the book Budo Mind and Body by Nicklaus Suino. These are:
- Focus: Don’t allow the mind to wander
- Complaining: Before assuming something is wrong, contemplate on it to understand the other view point
- Don’t criticize: Focus on becoming a better person. Your attacker isn’t going to adjust to do the “right technique” – you must be the one prepared
- Dojo: Dojos are a place to practice ideas disseminated by the teacher. There is a time and a place for individual reflection
But while these are nice concepts, they are, to me, guidelines, not disciplines. I’ve found a nice summary of some disciplines in another book called Kungfu Basics by Paul Eng. In it, he describes basic, universal principles that apply across the martial arts. They can be split into two categories:
- Attitude Towards Others
- Personal Qualities
Over the next several weeks, I’m going to be examining these disciplines and showing how we can benefit from understanding them in the software world. There are 13 disciplines Eng discusses in his book, and I’m sure that as my research continues I’ll find more, or make tweaks. The culmination of this work will be going into a talk Corey Haines and I will be giving at Agile 2009 entitled Disciplines of a Software Developer. But, at a high level, here are the 13 disciplines so far:
- Respect
- Compassion
- Courtesy
- Loyalty
- Trustworthiness
- Devotion, honor and respect to one’s parents
- Sense of responsibility for those under you
- Humility / Modesty
- Honesty
- Diligence
- Patience
- Enthusiasm
- Self-Control
I’ll update this list with the links to the individual posts as I finish them. And, as always, I’d love your feedback!
Posted on February 8th, 2009
On Friday, I got the opportunity to attend the excellent acts_as_conference right here in Florida (over in Orlando). The conference is a one-track Ruby conference that had about 130 attendees show up. I was excited by both the schedule and the attendees, and though I was only able to attend on Friday, I wasn’t disappointed.
The conference opened up with the Rails Envy guys doing a talk on Rails Innovations. Some of the ones they listed included:
- GitHub
- Workling
- cache_money
- Sample Applications
- webrat (Seconded!)
- JRuby
- shoulda
- mod_passenger
- Open Source Social Networks
- HTTParty
- merb
- metric_fu
- Rack::Cache
- Internationalization
They then went into a talk about Scaling Rails. I found this extremely interesting because anyone whose ever had to deal with deploying Rails Apps may ask themselves Can Rails Scale? The answer now is a resounding yes with a combination of caching and deployment strategies, and the excellent Passenger deployment.
They finished up their talk by announcing a series of free screencasts that are being sponsored by the great guys at New Relic on Scaling Rails. It’s available right now at http://railslab.newrelic.com/scaling-rails. Go get ya some!
Next up was a live Q&A; Session with the man himself, DHH. I think that out of all the things from the conference, this stood out as being the cornerstone of how awesome the Ruby community is. No question was off-limit, and unlike other conferences where people can get into details for whatever silly secret thing it is (or worse, get into details that never get shipped), everyone seemed to feel comfortable talking about, well, whatever. Some example questions:
- What led to the Rails/Merb merge? (Short Answer: About 90% of the things the two frameworks wanted to do were similar, so why not?)
- What cool new ideas are coming for 3.0? (Short Answer: Revamping approach to AJAX and APIs for how routes work)
- Dave Thomas wants to see different flavors of Ruby, like parallel_ruby. What about something similar in Rails? (Short Answer: Working on modularizing everything to make scenarios like that much easier
- Do you TAFT? (Short Answer: No. But absolutely vital for anything larger than a trivial app)
- When are you going to change your hairstyle? (Short Answer: Never)
- If you could have, for the rest of your life, either cake, or pie, which would you choose? (Short Answer: Banana Cream Pie)
Ok, so things got a little goofy. And DHH did look like a giant blue smurf on the screen because his white balance was all out-of-whack. But it was still a great talk, and I highly enjoyed it.
In the afternoon, we got to hear from the guys at Hashrocket (choice quote: “If you don’t have a company that lets you test, try to get fired for testing” from Jon Larkowski). It was refreshing to hear them talking about all of the agile stuff they do – pairing, test-first, acceptance tests, stories – and not talking about it being “agile” but just “how they do it”. Professionalism FTW!
We then got to hear Jim Weirich start to talk about Fixtures, but instead lead us down the Grand Unified Theory of Software Development. His talk ended up focused around coupling and a term called Connascence. He focused on three areas: Connascense of Name, Connascense of Position and Connascense of Meaning. I quite enjoyed his talk, and talking with him throughout the conference.
The last sessions were on building Multi-Tenant Systems in Rails, Merb and the integration to Rails 3.0 (Key takeaway: The Merb team did have to give up their test framework and use the one from Rails) and a keynote on overcoming fear.
Of course, during and between the conference were all the great side conversations. My big takeaway is thinking about putting together a Ruby and Rails Firestarter event akin to the TDD Firestarter we recently did. But in general, I was quite happy to be at a product-specific conference having to remind myself that this wasn’t an agile conference – agility and openness are just a way of life with Ruby.