McDonalds, Six Sigma, and Offshore Outsourcing (notes)

These are notes from a talk I’ve given in various forms at SCNA, CodeMash, and Magic Ruby. I’ve mirrored them here from the InfoEther weblog.

Me at SCNA
Photo credit: Monty Ksycki

The presentation is called “McDonalds, Six Sigma, and Offshore Outsourcing – Unexpected Sources of Insight”. Here’s the abstract:

We software developers like to think of what we do as an art form (or a craft, if you’re at this conference). I was once asked to come up with a set of guidelines for creating great software so our (huge) company could more effectively use an offshore development team that had been delivering amorphous piles of crummy, nonworking code. I was frustrated and responded with something like this: “Give me a list of guidelines for how to make a beautiful song!” The nerve! Repeatable processes? Who did she think she was talking to?! This is a creative process! This is ART!!!!

I’ve since grown up a bit and I’d like to talk about how I was wrong and how we can all hopefully learn from my mistakes.

The Art-Craft-Commodity Continuum (from my presentation)

In it, I tell the story of my experiences with the Six Sigma quality methodology and with offshore outsourcing, urging developers not to blindly write off potentially useful software development strategies based on hearsay and misunderstanding. I also propose a customer-driven, data-driven approach to software engineering, dovetailing off of InfoEther’s Chief Scientist, Glenn Vanderburg’s recent ruminations on “Real Software Engineering”.

The original, scary Ronald McDonald
The original Ronald McDonald (Willard Scott)

Videos from SCNA will be posted on InfoQ eventually, and I’ll link mine here when that happens. In the mean time, many people asked me for pointers to some of the books and resources I mentioned during my presentation. Here’s a link dump that you might find useful:

Rails 3 Recipes needs tech reviewers!

UPDATE: We got 8 times as many volunteers for Rails 3 Recipes reviews as we need. You people are awesome! Closing the call for help now.

The original Rails Recipes has been used by tens of thousands of Rails developers as they’ve worked toward mastering everyone’s favorite Web framework. Five years later, and after the release of Rails 3, we’re seeing a new wave of Rails developers. Through my work with InfoEther and The Pragmatic Studio it’s clear that an updated version of this classic would help a huge group of new Rails developers.

So here comes Rails 3 Recipes!

I’m a little over half way done with the new edition, which is full of both substantially updated and entirely new content. Now I need your help.

Before we take the book to Beta, we need technical reviewers. To tech review, you need to either already know Rails fairly well or be interested in trying to use the book to learn (some Rails knowledge is assumed).

In return for your comments, we’ll give you a free copy of the electronic and paper versions of the book as well as a mention in the book itself.

Interested? If so, please contact us at and let us know your level of Rails expertise. We can only handle a certain number of reviewers (probably 15), so we’ll be limited to accepting the first who get in touch.

To those who are interested, THANK YOU!!!!!!

If the original Rails Recipes’ success is any indicator, Rails 3 Recipes is going to be the book every Rails developer will have sitting on his or her desk over the next couple of years. I’m very excited about it and looking forward to some feedback.

width 120

How Rails Developers do Ajax (with jQuery) in 2011

Wanting to survey what the current state of the art in Rails Ajax development is, I asked this question on twitter:

Rails developers, how are you doing Ajax with JQuery these days? .js.erb templates? Rendering partials back old-style?

I got a lot of great responses! 44 last time I checked. Here’s what I found out people are doing:

  • mustache.js
  • Sending JavaScript back down to the client using .js.erb template files (Ryan Bates linked a couple of examples here and here)
  • JQuery templates
  • Hitting RESTFUL endpoints and responding with JSON data to be manipulated on the client
  • Using backbone.js
  • Rendering partials and updating elements on the page with their raw content (the original old-school Rails way of doing it)
  • Use SammyOnRails

There is definitely a divide and a lot of opinion (suprise!) between those who are OK with delivering JavaScript and/or HTML from the server to be rendered on the client and those who prefer to deliver data and have the client process it. I’d characterize the former as the less clean, more pragmatic approach and the latter as the idealistic cleaner approach. It seems that tools like mustache.js, backbone, JQuery templates, and Sammy.js are tightening the gap between quick + dirty and slow + clean.

What do you think? What did we miss?

I Don’t Know

I had the pleasure of watching Scott Chacon keynote at CodeMash this week. He spoke about how Github “manages” its development team and product development. I enjoyed the talk, and encourage you to download his slides if you weren’t at the conference.

Scott is a very energetic speaker and talks really fast, so he ended his keynote with a lot of time to spare (something I wish I would do more often). So he took questions from the audience.

A lot of the questions were about trying to fit Github’s process into companies of very different profiles. So, for example, “Would this work in blah blah blah environment that is totally different from Github?” Scott’s answer was excellent in these several cases:

“I don’t know.”

He didn’t blow the questions off. He then discussed possibilities. But it was incredibly refreshing to hear “I don’t know” from a speaker being questioned in front of an audience of almost 1000 people.

I wrote in The Passionate Programmer about the difficulty and importance of learning to say “no”. I think “I don’t know” is scarier and harder and maybe more important.

When someone regularly says “I don’t know”, you trust them more when they say they DO know.

Dead-End Jobs: Are You Suffering From Stockholm Syndrome?

Have you heard of Stockholm Syndrome? It’s a name given to the condition wherein hostages develop positive feelings toward their captors despite being held in negative, unfavorable and even life-threatening conditions. Victims of Stockholm Syndrome will even inexplicably stay with their captors even when given the chance at freedom.

Hopefully nobody reading this is literally being held hostage right now. If you are, good luck!

For the rest of you, why might I suggest that you are suffering from Stockholm Syndrome? Because employment relationships can manifest themselves in this very way.

In the article, Love and Stockholm Syndrome: The Mystery of Loving an Abuser, Dr. Joseph Carver says that the following four situations serve as a foundation for the development of Stockholm Syndrome:


  • The presence of a perceived threat to one’s physical or psychological survival and the belief that the abuser would carry out the threat.
  • The presence of a perceived small kindness from the abuser to the victim
  • Isolation from perspectives other than those of the abuser
  • The perceived inability to escape the situation


Looking back at my own career (specifically some of the extremely intelligent people I’ve met who are stagnating in oppressive companies or positions) I have recognized that many of these people (and sometimes myself) have felt “stuck” for no obvious reason. Some people seem just plain crazy when you look at their skill sets, ability, and the low quality of work or environment they’re willing to put up with.

So I contacted Joseph Carver to ask his opinion. Could this be Stockholm Syndrome? He agreed. In email, he said “SS is most likely to develop when the employee feels trapped, perhaps by a high salary, fear of losing a career, or fear of humiliation.” So let’s look at his four conditions:

Perceived threat:

Getting fired, being humiliated, not being a “top 20%” employee, not getting a raise. Employers wield a lot of perceived power over employees, especially for those in very traditional corporate jobs. The employer must be willing to carry out the threat. Every business is under the right conditions. It’s how businesses work.

Small kindness

Got a Christmas bonus once when you really needed it? Make a competitive salary? Great benefits? Get to work on a technology you don’t think you’d be able to work on elsewhere? There ya go.

Isolation from other perspectives

Again, a big corporate environment is ripe for this kind of isolation. If you work for BigCo, you learn to do things The BigCo way. The company’s organizational structure becomes a blueprint for your career progression. You start to lose sight of what industry pay and incentives look like since you have a homogeneous population to compare with. Unfortunately, from what I’ve seen even the best run companies create this kind of isolation of perspective and group-think. Charismatic leaders are particularly capable of creating a culture vacuum around a cult of personality.

Perceived inability to escape

According to the Bureau of Labor statistics, American adults spend by far more time working than any other activity. That’s a lot of your waking time being trapped in a routine. In a Stockholm Syndrome situation, the captor chips away at the self-esteem of the captive. So for most of our waking hours, those of us trapped in dead end jobs like these are exposed to environments which systematically destroy our self-confidence. Not only that, a persistent fear and feeling of failure makes it harder to actually explore the options for leaving the bad situation. The instinctive self-preservation reaction in this kind of situation is to work harder to try to avoid the perceived threat coming to fruition.

So, what if this describes your job? You owe it to yourself to find a way out. Hopefully recognizing the signs will show you that the real situation is far less grim than you might believe and that you have control over how you choose to spend the majority of your adult life.

I’m writing this for the many people I’ve met (and the countless I haven’t) that are senselessly stuck in bad job situations. Please stop wasting your precious time.

Software developers: how do you know when it’s the right time to do a big software rewrite?

Yesterday I asked this question on twitter:

Software developers: how do you know when it's the right time to do a big software rewrite?

I’ve written about this topic before (The Big Rewrite). I’m revisiting it for a presentation Rich Kilmer and I are doing this weekend at JRubyConf.

I got a bunch of replies. Some serious, some sarcastic, some obviously filtered through the jading effects of a few Big Rewrites played out. The answer ranged from “NEVER!” to “as soon as you feel like it’s necessary”. The one consistent theme is that software rewrites are scary and the decision shouldn’t be taken lightly.

Drivers include maintenance cost, programmer happiness, politics, and fear.

Here’s what the developers on Twitter said:

when the mud (from big ball of mud) falls into your eyes

seriously, though, i believe when you lose confidence implementing changes it’s probably a good time to consider a rewrite

when you find yourself monkey patching areas that you wrote at 2am on a Saturday thinking “ugh, I just want this done with” 🙂

the right time is after reading your infamous blog post.

for us the big rewrite was: Scale fail (Can’t support more than 100000 titles) and customers want linux and not windows

almost never. Incremental rewrites of specific components results in better isolation and less risky code.

My team did it once. The first dev team was gone, the code, design and database were a mess, there was no docs, no unit tests

the bugs were all over the place, the chances were slow and risky and we needed to add tons of features.

The CIO figured out that it would be more expensive to maintain the current product than to create a new one

when you’re singing “WTF! WTF! WTF! Holy Christ! WTF!”

when you look at a code made by you and curse the programmer behind it

when the pain starts to exceed the political pain required to get that kind of authority

@RobotDeathSquad BigRewriteQuestion does have a useful side effect: the earnest responses tell you “where that person is at”.

when someone ponies up the dollars for it

When your velocity is very, very low because of design and architectural problems in the code. Its a big hump though.

90% of the time it makes more sense to refactor the existing code. Unless it’s a ColdFusion app 😉

It’s time for the big rewrite when the most experienced developer has lost all faith in the code base.

However, before beginning a big rewrite, you need to “fix” the management responsible for a codebase that needs a big rewrite.

> i do not wait for this moment, i try to refactor everytime 🙂

Big rewrites only occur when both product and engineering management act “unprofessionally” per @unclebobmartin’s definition

when i realize i’m spending more time compensating for existing code than writing new code.

when everyone you ask says “oh that class? Yeah it’s garbage. Nobody wants to touch it.” Chances are, it’s not the only one.

if the cost of adding value now is higher than rewriting and then adding value? I usually feel a rewrite is the scary option.

When I start to consistently feel loathing rather than excitement when I think of better designs.

@thomasfuchs I am pro-”abandon ship” as well. The need for big rewrites are signs of more sinister problems.

We rewrote our app once when the original app was unbearable to maintain.

For us it’s whenever the boss tells us to 🙂 We converted an app from VFP 9 to #rails in just under 2 yrs

That’s the hardest question I’ve ever had to answer in this biz. You never know, you just guess and hope you’re right.

It’s time for the big rewrite when things are screwed-up or messy AND nobody is bikeshedding – in other words: never

Secondly, if given the opportunity, I like walling in the existing app and building new apps around it to extend function.

I try to avoid big software rewrites as they tend to be a death march. Instead try to chip using a strangler application

When developers don’t look happy while coding. The less enjoyable it is for programmers the more rewrite is needed 🙂

Must consider context, so right answer is “it depends”. But the raising of the question itself is probably an indicator.

When maintaining the system in production gets too expensive (include running costs of hardware and admin time).

a rewrite takes less time and has less risks involved than a functional conversion but results in lower quality as well.
by functional conversion I mean a rewrite-from-scratch scenario, and by “rewrite” I meant “refactoring”

Imagine you’re hit by a car

I was scrolling through articles on this site earlier, and I decided to re-read some of my own encouraging words for a shot of inspiration. On the post called What Would You Rather Be Doing? I came across this comment by Derek Sivers and wanted to make sure everyone saw it.

  Derek Sivers Says: 
  May 13th, 2009 at 05:39 PM

  Imagine you’re hit by a car today, wake up in the hospital, and the doctor is saying, “Sorry. We can’t stop the bleeding. You’ve only got an hour to live.”

  You’re laying on what you now realize is your death bed. Oh no! No no no! All those things you wanted to do! You never went to Italy! You never started       
  that business you knew would be a huge success! You never asked-out that gorgeous person you flirt with! You never flew ZeroG. You never lost 30 
  pounds and got proud of your looks. You never had kids.

  Make that list.

  Then make it your to-do list.

  Eliminate all those potential regrets.

Thanks, Derek!

23 travel tips to make long trips more enjoyable

I travel a lot. Not the most of anyone I know, but enough to have found myself inconvenienced plenty of times and to have learned ways to make life more comfortable on the road. Here are a few tips that I’ve collected over time (or most recently via twitter). Hopefully they’ll come in handy to others.

  • Always carry a power strip in your suitcase. Great for international trips to avoid having to buy multiple adapters. But even in your home country, hotels can be really bad about providing enough outlets. I have one of these which fits nicely in a suitcase or laptop bag without taking up too much room.
  • If you like coffee or tea, bring your own favorite brand of instant mix. I’m not a big Starbucks coffee fan, but their Via product is the best tasting instant coffee I’ve ever had and beats the coffee available in any hotel room anywhere. When you’re trying to beat jet lag, having something better than the usual hotel swill is very welcome.
  • Considering getting a portable WIFI router. Many of the hotels I stay in only provide ethernet connections, which would otherwise tether me to a desk. Given how much work I do at my computer, being able to sit where ever I like in the room is important. I also use the WIFI router to connect multiple devices without having to (potentially) pay multiple times for internet access. We have an old airport express which we use for this purpose.
  • Be careful about SMS messages. Even if your phone works overseas, you can easily amass a ridiculous cell phone bill from sending or receiving SMS messages. One friend accidentally ended up with a $600 bill from text messages alone after a trip overseas. It’s not unusual for each text message to cost $0.50 or more.
  • Rent a cell phone and/or internet access device when traveling internationally. As an example, in Japan’s Narita airport you can easily rent a portable WIFI access point which provides internet access via the cellular network right in the arrivals area. On my last trip, I passed the time on a bus video chatting with my wife. Another cell phone option is to bring an unlocked phone and buy a pre-paid SIM card for it in your destination country.
  • Carry your own meal replacement bars. You never know when you’re going to find yourself stuck on a tarmac starving or inconveniently moving from flight to flight during meal times. Keeping your eating on schedule helps significantly with jet lag, but it also just helps you not feel terrible as you travel. Joe O’Brien suggests Clif Bars. Personally I like the GNC brand protein bars.
  • Always keep a spare set of clothes in your carry-on luggage if you’re checking bags. I don’t do this one, but I should. I spent several days freezing in the winter in Poland a couple of years ago because not only did I not have extra clothes in my carry-on but I checked my coat to avoid having to lug it around on the flights. Big mistake. Polish Air lost my suitcase and didn’t get it to me until nearly the end of the trip.
  • Use something like Tripit to consolidate your itinerary info then print it out.
  • Leave your international travel supplies packed. For example, there’s no reason to take your travel power adapter, WIFI router, or international power supplies out of your suitcase if you always use the same luggage. When I went to Japan recently I ended up tearing the grounding pin out of my Macbook Pro power cable so I could plug it into the Japanese outlets. BTW, I don’t recommend doing that.
  • Especially for really long flights, drink a lot of water. Air travel can dehydrate you. The effect of drinking water is subtle but magical. You’ll feel much better if you make yourself do it.
  • Spend a significant amount of time outside in the sunlight on your first and second days in a new time zone. Go for a walk, breathe a lot of fresh air, maybe even do some outside exercise. Natural light and fresh air are two of the best tools for beating jet lag.
  • Consider traveling light and not checking any bags. Saves time and is safer than checking luggage (see my Poland story above). I confess I still don’t usually do this but I should.
  • If you fly any significant amount at all, stick with one airline and record the miles. I get free upgrades on many domestic flights and some international flights simply because I fly United all the time.
  • Use to pick your seats. I’ve been using it since Dave Thomas told me about it several years ago and I’ve more than once saved myself from an undesirable seat that I otherwise wouldn’t have known about until I boarded. When you’re going to be stuck in the same spot for 5 hours, you don’t want to be e.g. wedged into the wall in a seat that doesn’t recline.
  • Another one from Dave Thomas: Start living in the destination timezone when you get on the plane. When you arrive, no sleeping until at least 8pm local. I’m going to New York tonight and I let myself get up at 5AM MDT this morning since I knew it was 7AM EDT. I sometimes take it to the extreme, adjusting a few days early if I know I’m going to have trouble waking up for work in the new time zone. David Black says he can’t manage to stay awake until 8PM when traveling east, so he limits himself to a 1.5 hour nap. I can’t limit myself to a 1.5 hour nap so I avoid sleeping at all.
  • If you have any aptitude for language learning at all, you’d be surprised how easy it is to learn a few basic phrases. Spend a short amount of time on the plane learning some key phrases in your destination country. If the country has a different alphabet than the one you’re used to, don’t assume it will be too hard to learn. I learned Hiragana and much of Katakana for a recent Japan trip and instantly found it useful. Even though I would misread some things, it came in handy for me. When in South India, it took me two days to learn how to phonetically read Kannada.
  • If you’re going to be shopping, take a bigger suitcase than you need. Don’t fill it on the way there so you can fill it on the way back. Another option is to buy a cheap duffle bag and fill it with dirty clothes for the trip back using your main suitcase for your purchased items.
  • Don’t fold your clothes. If you roll them, they take less room in your luggage.
  • Scan your travel documents and upload them to a web site somewhere that will be easy to get to while you’re traveling.
  • Ian McFarland suggests: “Keeping all your key docs in a clear plastic folder helps a ton. Tripit itinerary, passport photocopies, any paper tickets”, etc. I haven’t done that before but it’s a great idea.
  • David Black suggests that if you wear glasses, bring an eyeglass screwdriver. I had an eyeglass malfunction in Hungary once and it took two days to find a screwdriver to fix them (busy work schedule, unfamiliar with the area, etc.). The world looked lopsided for two days. Very annoying.
  • Choose your flight schedules carefully. I personally like to plan to get to my destination fairly early. Even for domestic trips, I’d rather schedule myself to get in at 5PM and sit around with nothing to do than schedule an 11PM arrival, risking a delay and an unwanted late night. Jeremy Hinegardner also suggests minimum 2 hour layovers. Delays happen and a longer layover is like an insurance policy. You pay a little every trip to avoid paying a lot when you really really don’t want to.
  • Also from Jeremy, in his own words: “Travel problems: don’t get pissy. There are 2 people who care about it, you, and the person helping you. One of them can stop.” Wise.

I’ve collected travel advice from a lot of people. Most of it is common sense, but if I forgot to mention someone, my apologies. Here are the people whose ideas I took from Twitter today (thanks all!):

Matz Ruby World Keynote

The following is my real time transcription of the translation of Matz’s speech at Ruby World 2010. I was typing as fast as I could while he spoke, and I probably made some mistakes. I might have left out some words or sentences. If anything doesn’t make sense, assume it’s my fault and not Matsumoto-san’s. Anyway, I enjoyed Matz’s keynote and thought other English speakers might like a chance to see what he said.

I’m Matsumoto

I Started Ruby in 1993 at NaCL: When I joined the company after graduating from college, I didn’t have much to do at the time. I was not fired fortunately. But I had plenty of time so I started to work on Ruby as a side project.

So at the time, there was ONE user of Ruby. Then I started to develop Ruby with some other friends.

In 1995, Ruby was released and distributed over the internet for general use. At the time, people on usenet got interested in Ruby and gave me some feedback. Also we used a mailing list to distribute information on Ruby.

So within days, about 200 people got involved. So in 1995, the number of people who knew something about Ruby was about 200.

Even after that, Ruby was known to a relatively limited number of people.

Then in 1999, I published a book called Object Oriented Scripting with Ruby. This was the first book on Ruby. It’s only natural. Who else is going to write a book on Ruby, right??

At the time, this sold pretty well. Cumulatively, we sold almost 20,000 copies. I’m sure I’m allowed to discuss this number. Probably it’s only 17,000 in real numbers. This was in Japanese, so Ruby was known to the whole nation. So in 1999, Ruby was known to a lot more people. More engineers and programmers knew about the language.

I started to hear from many people that they knew about Ruby.

In year 2000, a book in English was published. Many people in the world came to know about Ruby.

Then in 2004, Ruby on Rails was released. Of course, most people know about this Web application framework. Ruby on Rails is very productive compared to competing frameworks in other languages. There was an active discussion on the comparison of performance. It was welcomed by many people. We estimate that the number of users grew to 100,000 people in 2004.

In 2008, US-based Gartner released a survey. In the report, Gartner estimated that the total number of Ruby users reached 1,000,000. This was a huge number as you can see.

In the same report, the reporter predicted that in five years (2013) the total number of users would be 4,000,000. Ruby is open source. You don’t have to pay anything to use it. You just download it. It is therefore very difficult to know how many people are using it. I created Ruby myself and I don’t know how many people are using it, so I’m not sure how Gartner reached their conclusion. But anyway, 4,000,000 people are predicted to be using Ruby in 2013.

So in 20 years, this project which started with one person may have increased from 1 to 4,000,000 users. This is beyond the normal growth rate of a technology.

This period of Ruby’s popularity was due to the popularity of Ruby on Rails.

There is a ccompany called Tiobe Software which is a software company in the US. Their Tiobe Index rates the popularity of programming languages using Google, Yahoo, Microsoft, and other search engines to rate the popularity of languages on the internet. Back in 2009, according to Tiobe index, Ruby was ranked #10. And in 2008, it was ranked #9.

In this year, 2010, it was demoted to #12.

You may have a concern about the future of Ruby, but if you drill down deeper, you will see: objective-c is getting more popular, driven by iPad, iPod, etc. development. Objective-C is required. So it jumped form 42 to 11. And Go by Google was released in April of last year. So where it didn’t exist previously it jumped up to #15.

As you can see, Ruby represents 2.221% of programming language references according to Tiobe. That’s good.

So don’t have a concern about this.

But this marks a very interesting symptom. The end of the ruby “bubble”. When I joined the company, the bubble economy was still there. Then it collapsed and caused a lot of trouble. A “bubble” is not sustainable. Bubbles are therefore undesirable.

There are many comedians and musicians named as “one-hit wonders”. I don’t want Ruby to become that.

The life expectancy of a programming language is pretty long. Fortran was created in the 1950s. I want Ruby to be like this. That’s why this presentation is called “Sustainable Ruby”. The question is how to maintain Ruby’s high level of quality and the high level of quality of the people.

So in order to implement “sustainable ruby”, we must first discuss the benefit of Ruby. Benefit is very important for Ruby to be sustainable.

Benefit #1: Productivity. One of the reasons that Ruby is quite popular is that its productivity is quite high. An embodiment of this is Ruby on Rails. When Rails was released, it was often cited that people would say that Rails had 10x productivity over java. Ruby developers didn’t really believe this, but a specific developer in the US wrote an article saying that he felt that HIS productivity over Java when switching to Rails was 10x. In 2005 and 2006, this one sentence caused a lot of arguments and discussion.

After several years of discussion and usage of Ruby on Rails, it may not be 10x but there are many cases where you can enjoy the productivity of Ruby on Rails over Java.

Also, another example of how Rails is productive is that it can take only 15 minutes to develop a web application. In 2004 at a Brazilian conference, David Heinemeier Hansson demonstrated web application development using Ruby on Rails. Without any preparation, no design, no database, he started to create a blog application. You could create articles, list them, etc. He created this application in 15 minutes. In 2004, creating an application in 15 minutes it was astonishing. It was great marketing to do that.

I’m a software engineer and I’m not very interested in marketing. But that video was a huge contributor to making Ruby on Rails popular. Ruby itself didn’t have any marketing, but Ruby on Rails promoted Ruby as well.

Was the Rails framework the sole reason behind the productivity boost when using it? I don’t think so. Ruby itself also makes the productivity possible.

Post-Rails frameworks.
Rails 3

Merb was emerging as a post-Rails framework, but it was quite unique in open software. Merb and Rails jointly created a new framework in the form of Rails 3. Also, Rails 3 is inheriting some of the Merb characteristics. Totally new framework by combining/merging different frameworks.

So far I’ve been talking about the benefits that Ruby can provide in order to make Ruby sustainable.

The second element is the Potential the language can demonstrate. Now we have the technology and the technology is convenient and we can create some benefits. But we need to have potential in the Language for people to make investment.

Around Ruby we have much new technology. Ruby on Rails, for example, introduced innovations in Web development. It wasn’t the first web framework. Not even the first Web framework in Ruby. There were already a lot of web application frameworks in Ruby when Rails was released. But under the circumstances, Ruby on Rails implemented new ideas that triggered productivity enhancements in Ruby AND other languages (python, etc.). So Ruby on Rails had a huge impact on the web application development arena.

Whenever a new technology is created, the surrounding areas also enjoy the benefits of this technology. Not all new technologies will be successful, but some of them will really boost the entire IT industry.

We do see some of that trend in the industry. To support the new technology we need to have smart engineers (hackers). The smart engineers usually come to the interesting technology. Whenever there’s new technology that’s created, it invites the smart engineers who then create new technology. This is a positive cycle. Ruby is one of these positive cycle enforcers.

Benefit, Potential, and….


The author of The Passionate Programmer, Chad Fowler, is here. I feel embarrassed to say something about him before his keynote. But I have to say this. He is right to emphasize passion. Many people are passionate about ruby. Engineer passion is very important. Passion is key.

In the US there is a conference called RubyConf: The first one was held in Tampa Florida. There were only 34 attendees at the first conference. Right now we have more than 500 people attending. If the venue could handle it we could probably fit 700 or 1000. They actually limit the number of attendees. They sell out every year. This year RubyConf will be held in Matsue’s sister city, New Orleans. It will be the 10th. It is the longest running Ruby conference on the globe.

Euruko. Poland, Barcelona, Berlin, Prague. On the last day, Euruko always invites speakers to bid on where Euruko should be. Speakers make their case and the location of the next Euruko is voted on.

Two weeks ago we had RubyKaigi. It was held in Tsukuba City. Not in Tokyo. I graduated from Tsukuba univeristy. It made me feel like i was going home. We had about 700 people at RubyKaigi this year. RubyConf will have 500 (ed: actually 600 to 650). The biggest conference is held in Japan.

As you can see here in this venue as well Ruby World has so many people from so many countries. I would say that the IT industry is japan is becoming truly internationalized. We have a disadvantage in Matsue because it’s so remote, but the passion of the Rubyists makes it possible.

We also have regional Ruby conferences in India, China, Brazil, all over the US, etc. They also have another conference called RailsConf:, which is operated by a professional event management company (ed: and Ruby Central). They had 1800 people. So that really boosts Ruby.

Startup passion. I’m going to talk about US companies, but there are many venture companies in Silicon valley who are very interested in Ruby. More than 60% of VCs use Ruby to provide the system. Among the famous ones known to Japan includes Twitter. As a startup, they implemented everything using Ruby from bottom to top. Currently they have 100s of millions of users. Much of the RUby has been replaced but if you access twitter you can still see twitter driving the system.

As of last year another acronym was introduced “ARC”. Agile, Ruby/Rails, Cloud. I’ve heard that VCs ask startups who aren’t using Ruby, “Why not?” Investors are pressuring startups to use Ruby. “It’s faster, so if you can shorten your release by one month why not use Ruby?”, they say.

A few years ago when startups were getting started, they wanted to attract smart engineers, so they used Ruby to attract them.

Executives’ passion: Productivity is the key. It’s not just the engineers who are passionate about Ruby. Productivity is one of the biggest factors for businesses. Executives started to realize the importance of using a productive language. Productive languages drive profit. Some executives are finding hope in Ruby.

Differentiation can be found by using Ruby. The japanese IT industry is characterized by conservatism, so many may be reluctant to use Ruby. But by making the decision to use Ruby, they may differentiate themselves. There is also the possibility to change the entire industrial structure by switching to Ruby and other open source technologies, driving more SMBs.

In Japan, major IT companies receive contracts and subcontract to others. But with Ruby and smart engineers, these can be driven to small businesses which can innovate. This drives hope.

Motivation drives Hope

for Food
for Money
These are very pragmatic

for Good Cause
But some people might make a bigger attempt to change the world.

Many people are finding hope in Ruby. Many found potential in Ruby.

Not all have succeeded. Some are extremely successful. Some are not. What made the difference?

In some cases, the benefit was not enough. Or people couldn’t see the potential. But the biggest factor was PASSION! How passionate or decisive they were made the difference.

Lots of people love Ruby. Pictured here (ed: he shows a picture in his slide) are the smiling faces of the staff of the RubyKaigi. This is not organized by professionals. 700 turnout is already beyond its technical limits. But when we ran the survey, most people were satisfied by the conference. It’s miraculous considering the tough circumstances. But these people are passionate.

Many people are surrounding ruby. Hacker,s engineers, executives. They LOVE Ruby.

Of course I love Ruby myself. It’s my child. Every day I am expanding my affection for Ruby. There are so many people out there that love Ruby. As a Japanese, I’m reluctant to say “love”. Actually one guy said “I love you”. I am poor at English. I was very embarrassed 🙂 For Japanese, it’s difficult to express love in a direct fashion. Of course that guy didn’t mean “love”. He just loved Ruby. Like a strong kinship.

Many people love Ruby. Let me give you some examples:

NaCl. When i started at NaCl, Inoue-san he actually picked me up and allowed me to work on this. Back in 1995, there was no way to know if Ruby would be used by anyone. But the president, Mr. Inoue-san had the faith and the vision to hire me and let me work on Ruby. He gave me plenty of time to work on Ruby. It’s all possible because of him.

In 2006, the Matsue mayor actually visited our lab. We would like to use Ruby to revive the city. I had to reply, “Are you out of your mind?” Can you believe this person would try to revive our city using Ruby? Many people living in many places outside of Matsue, so I said maybe it’s difficult but someone from the city told me the Mayor was very serious about this. The mayor himself actually expressed his desire to use Ruby. So as a local government, Matsue city is committed to promote Ruby, which is very very exceptional on examination. How much contribution we’re making to the city really is unknown.

This is Mr. Mizoguchi the Shimane governor. I don’t know how to show my appreciation to him. I’d like to take this opportunity to thank him again. There are many other local governments who are interested in using Ruby to revive their city. But the question is how passionate are the top management or the governor or mayor? Even if the promoters work hard, unless top management is passionate about the promotion it’s not going to work.

One exceptional case is the governor of Fukuoka. A rival of Shimane :). For some reason he really loves Ruby. I’m living her and he’s in Fukuoka. There’s no relation. But Fukuoka is committed to using Ruby and they have organized the Fukuoka award and they have the Ruby Business Commons headquarters.

Here is a noodle called Ruby on Matsue Ramen. The maker of this Ramen sent me an email. The maker of this has no connection to Ruby, but he has a local businesses and wants to promote Ruby. He offered to include the Ruby logo on this noodle to contribute to sales. It’s remarkable. This person volunteered to make Ruby Ramen for us without us asking.

And thanks to all the efforts of all these people, Ruby is exciting right now.

I have been engaged in Ruby for 17 years and i think it’s making sense for me to be passionate about Ruby. But many others are passionate about Ruby. I don’t understand why, but Ruby is loved. Love is driving Ruby.

With the support of so many people, we are able to hold this Ruby World conference for the next two days. And I hope that for these days we can fully discuss the benefits of Ruby so that it will be helpful to what you do. 17 years ago I was the only one person who used Ruby. But over 17 years, people who are using Ruby (more than 1,000,000 people) in university Research, implemented in IT industry, etc.

Some of the things Ruby users are discussing are quite inspiring. Without this conference we can’t attract all of these great people to Matsue people. We should take advantage of this opportunity.

Ruby is supported by passion. And by love.

One more thing: The Ruby Association which I chair provides Ruby programmer certification. We have this announcement today that we have created a new “Gold” certification for Ruby programmers. This requires a higher level of skill. If you go to the Ruby Association home page, there is a press announcement which explains what you need to do to be qualified as Ruby “Gold” certified.

Thank you.

Switching to Android

Instead of upgrading to the iPhone 4, I decided to get a Nexus One from Google. I’ve had it about a week so far and I’m happy with it.. Some friends and colleagues have asked for my impressions, so here is a brain-dump of the highlights so far:

  • Speech recognition is actually useful. Big surprise here. I can tweet, search the web etc. with minor edits to my dictated text
  • I can write applications and put them on my own phone easily at no cost
  • The API is (for my brain) much more straightforward than working with Cocoa. Maybe it’s the years of experience but I also strongly prefer working with Java over Objective-C
  • I don’t miss the iTunes store. I was worried about that, but Amazon’s mp3 purchasing service is just as convenient (and you get mp3s instead of DRM’d media by default)
  • The UI is clunkier and uglier than even the first iPhone
  • I’m not finding myself missing any significant apps. There are some minor ones I wish I had but I don’t but it’s no big deal
  • Wifi tethering (Android 2.2) is a good thing
  • I’ve never met an on-screen keyboard I didn’t hate. Android is no exception.
  • Kelly has an iPhone 4. We are traveling together. Everyone, everywhere asks her “Is that the new iPhone?”. Nobody anywhere asks me about my phone. (Actually one person did yesterday but I think she felt sorry for me not having a phone as fancy as Kelly’s)
  • I thought the idea of widgets on the home screens would be faddy and lame (like it is in most cases on desktop OSes). It’s actually pretty useful.
  • The Android message bus architecture makes some really neat system-level things possible from 3rd party apps. For example, I have a little app called Handcent SMS which improves on the built-in SMS functionality of the phone. As far as I know this sort of thing isn’t possible on the iPhone and i appreciate it as a user and as a developer.
  • I had a Google IO phone a year ago and the Android ecosystem was barren in contrast to what I’m seeing today. That’s a huge change in only one year
  • I can now differentiate my ring tone from that of everyone else around me in a public place 🙂
  • I don’t know of a good way to download video to the phone. I like to watch television shows and movies on my phone while traveling on airplanes. iTunes makes that trivial for the iPhone. Fortunately I have an iPad, but it’s always nice to have a backup.
  • The Kindle app is a wonderful thing. Just like it is everywhere else. Now to sell my actual Kindle. Anyone want to buy a first generation Kindle?
  • I see Java exceptions more often than I would expect (, for example). It’s kind of embarrassing when it happens, but being a Java developer myself I’ve actually found it to be much more useful than the app just crashing. Sometimes the exception class thrown gives me a clue to help diagnose the problem. That makes me feel smart. I don’t think my parents would appreciate this feature.
  • The background/multitasking stuff is nice.
  • It reminds me of switching to desktop Linux. Linux is usually uglier and less usable than its commercial rivals. Android is similarly ugly and slightly less usable. I also find Linux more exciting. You can get deep into its guts. You can customize it to your heart’s content. You can program it to the limit of your capabilities (as opposed to the limit of its EULA). And it’s weird, in both a good and a bad way. Unlike switching to desktop Linux, I’m often finding myself saying: “Oh, nice. I wish the iPhone had that.”

All that being said, I love my iPad and if I didn’t have it I might not have been able to so easily let go of the last remaining Apple mobile device I had available to me. If anyone wants to send me an Android tablet I’d gladly evaluate and review it.

RubyConf India

I’ve decided to travel less this year. Since my job involves a lot of travel, this mostly translates into going to less conferences.

So for 2010 I so far have only one conference on the agenda (other than those I’m co-organizing): RubyConf India.

I’m speaking at the event and also helping out on the proposal committee along with Pratik Naik and Ola Bini. So far the program is shaping up well, and I’m excited about the conference.

If you’re looking for a combined technical and cultural education experience, I highly recommend going to RubyConf India. Kelly and I lived in Bangalore several years ago and absolutely loved it there. We can’t wait to get back to our second home. Bangalore was a culture shock at first, but that’s another strong reason to go. For us, it went from culture shock to comfort. Bangalore certainly didn’t change to make that happen—we did.

So, while it’s hectic, noisy, and sometimes shocking, Bangalore is a beautiful place which had a profound effect on me. When I was there, I couldn’t find any other Ruby programmers. It will be really exciting to go back to an entire conference devoted to Rubyists.

Registration will be opening in the next couple of weeks. Follow RubyConfIndia on twitter for announcements. Bangalore men milenge?

My Friend John was Shot – Please Help

Click here to lend your support to: Help John recover and make a donation at !

My friend and fellow Rails developer John Lannon, lead developer at, was mugged last night while picking up dinner for his wife. He didn’t have anything on him to give to the robbers and they shot him point blank in the chest.

His friends and teammates at Resonant Vibes are raising money to help with his recovery. Please consider helping a fellow developer and a remarkable individual who (not that anyone does) really does not deserve to be in the predicament he’s in now.


Welcome to Ben Scofield – RailsConf Co-Chair

Today we opened the RailsConf Call For Proposals. So we soon begin the several-month process of putting together the program for RailsConf 2010 (in Baltimore!).

I’m particularly excited to start the process this year, because we’ve made a very positive change to the team. We’re bringing on Ben Scofield as program co-chair this year. In case you don’t know Ben, he’s the author of Practical REST on Rails 2 Projects, Technology Director at Viget Labs, organizer of the roving Developer Day conferences, and a fantastic speaker (he helped created too).

So please join us in welcoming Ben, and start working on those RailsConf proposals!

See you in Baltimore!

(unofficial) RubyConf 5k Run

David Chelimsky and I were chatting a couple of weeks ago about my recently acquired running hobby and he asked “Why don’t you organize a 5k race at RubyConf?”

Then I said something like “heh”. Then we both thought about it some more and thought it might actually be a fun thing to do.

In a previous email, Jarkko Laine had volunteered to coordinate some morning exercise sessions at RubyConf, so we’ve pulled him in as well.

So now, David, Jarkko, Kelly and I are organizing some kind of 5k race for one of the mornings of RubyConf.

Can you run 3.1 miles?

If so, be on the lookout to sign up and have some fun.

If not, even better! Chances are even if you don’t run at all right now, you can practice and get ready to run (or mostly run) 3.1 miles by RubyConf. Check out a program like Couch to 5K for an easy progressive schedule that will get you to running the distance without feeling like you’re killing yourself.

We’re still getting our collective act together, but I wanted to share this to get you thinking about trying to run 5k if you haven’t before. There might be some fast people in the crowd but I’m hoping for a greater ratio of people who have never been able to run just trying to finish it.

So start training and see you there!

Toward an Agile Career Development Methodology

Since finishing The Passionate Programmer I’ve been putting a lot of thought into how to package the advice from the book into something more structured, serial, and prescriptive.

The Amazon reviews for the book are almost all glowingly positive with the occasional piece of constructive criticism. Here’s one such excerpt from an otherwise positive review by Ira Laefksy which I agreed with and took to heart:

I was somewhat disappointed with the lack of a road map to carrying out this excellent advice over the career of a self-driven software professional and the only tool to locate the appropriate essay for choosing to carry out being the table of contents. Perhaps the author/editor will provide chronological/situation-based guidance to employing this life-changing advice in a companion web-site making the volume more accessible to the demands of a particular life/career situation in addition to being an invaluable set of essays.

Ira and I have the same idea. What I think we’re both looking for is a career development methodology.

As an example methodology pulled from the software field, Extreme Programming has always been codified as a set of distinct practices, all of which can be beneficially understood and adopted on their own. But, as the famous flowchart shows, XP doesn’t just give you a bunch of great ideas about how to develop software. It tells you what to do when you get to work each morning.

The idea of following a software development methodology is nothing new to any of us in the field. It’s common practice. Software projects are expensive, complex and (sometimes) important. Letting them chaotically emerge isn’t a reasonable approach for a professional to take.

So why should our careers be any different?

Mike Swaine recently approached me about writing an article for
the Pragmatic Bookshelf’s PragPub issue #3. I decided to use this as an opportunity to explore some of the ideas I’ve had about crystalizing the advice from The Passionate Programmer into a prescriptive career development methodology.

I think I’m onto something, but I’d like feedback. The article, titled “Clone Yourself – Destroy Your Job Through Automation and Outsourcing”, contains just the beginnings of what I have in mind. Please go read it and let me know what you think.

Upcoming Travel and Speaking Engagements

I gave myself a little break this spring and early summer, but the pace is about to pick up again. The rest of the year is looking pretty busy. Here’s what the rest of this year looks like so far. If you’re a reader of this weblog, consider stopping by to say hello.

How Learning a Second Language Changed My Life

There’s an old joke I heard in India which goes something like this:

What do you call a person who speaks many languages? Multilingual

What do you call a person who speaks two languages? Bilingual

What do you call a person who speaks one language? American

Sad, but usually true. I got fairly deep into my adult life without having learned anymore
than the bare minimum Spanish I was required to study in the Arkansas public school system.
As you might imagine, I wasn’t all that conversational in Spanish by the time I graduated.
My father’s mother was German and my mother’s mother is Japanese. I grew up hearing many
languages spoken but somehow never learned another one. As a German-Japanese-American, by my
mid-20s I started to feel like I was missing something serious.

I was sitting at work in a big company lunch room one day talking
to an Indian friend. I asked how many languages he spoke and he said six.
I told him I was envious and that I guessed I would need to just
eventually move to another country so I could be immersed enough to
learn a language. I was tired of being the typical monolingual American.
He said, “Look around. Anything significant about
the people you see?” I looked around and it turned out I was the only
person in the lunch room who wasn’t Indian. He said “Learn an Indian

So I bought every Hindi book, CD ROM, and video I could find and
started watching Bollywood movies for fun. Within a year or so I was
pretty conversational. I started teaching my wife, Kelly, Hindi as well, and we
used it as a secret language when we were out in public.

Kannada Script
Photo by Asha Susan

Based on my self-driven Indian cultural immersion, when an opportunity
came up at the big company I worked for to have someone expatriate to India to help set up a
software development center, I was the first choice. My wife and I
spent a year and a half living in Bangalore trying to
blend in like real Indians (except for the physical appearance thing of

Photo by J.P. Dalb�ra

We took two private Hindi classes per week plus I took
Kannada and studied the Veena
twice a week each as well. The Veena lessons were particularly cool
because the teacher didn’t speak very much English at all and wrote
all the music in Kannada script, which I had
taught myself over a long weekend after we moved to Bangalore (I discovered that after learning to read
Hindi, it was relatively easy to learn any Indian language’s writing system). Knowing that I couldn’t have succeeded in these Veena lessons had I been limited to English was extremely empowering.

While in India, we were fearless. We walked the back streets of Bangalore where westerners don’t go. We weren’t afraid to find our own transportation or do our own business anywhere, despite the huge cultural differences and language barriers. And when we went up North where everyone spoke Hindi, we didn’t have to worry about trying to find cab drivers who spoke English. We were able to go to small villages and talk to anyone we encountered. We got to see what India was really like and to experience the immense warmth of its people, which we’ve discovered is multiplied when you even try to say “Hello” or “Thank you” in their language.

Me and some children around Agra

The benefit of learning Hindi didn’t stop at the Indian border. All of this led to another of the best experiences of my life. When
we were about to head home from India, my wife got an email from a
non-profit group in Louisville, Kentucky (our home/destination) that
supported Tibetan monastic refugees: “Help! Does anyone speak Tibetan
or Hindi?”. The director of the non-profit
( was desperate and half-joking when she
sent the request. They had just moved a senior monk from an monastery
in India to Kentucky to lead a dharma center when the local
Tibetan translator had immigration problems and was suddenly no longer allowed to stay
in the US. The monk didn’t speak any English, so the dharma center was basically
stuck there with him without anyone who could help communicate. We didn’t know a whole lot about Tibetan Buddhists at the time but decided it wouldn’t hurt to help, so we responded saying we spoke Hindi and were due back in Kentucky in a week.

Geshe Sangay Gyatso

This started a long relationship with the institute which included a
stint with both of us serving as directors. We also became very close friends
with Geshe Sangay Gyatso from whom we learned a
lot about Tibetan culture and Mahayana Buddhism. He even lived with us
for a while. The center was in between lodging arrangments for him, so it made perfect sense for him to stay
with us since we could all communicate. We had developed a family-like relationship. He stayed with us for about a month. I remember the smell of incense and the sound of chanting coming out of his room every morning as he
practiced his faith. It was a seriously humbling and life-changing experience to let
the pressures of corporate life reflect from his perspective after
work each day.

Being Geshe Sangay’s translator led us to amazing
experiences, including a lot of dialog with the spiritual leaders of
Louisville when we attended and participated in interfaith events. One of the highlights of these experiences was when I
had the opportunity to tour the gardens of The Abbey of Gethsemani while translating
for the recently retired abbot of the Drepung Gomang Monastery in India. I believe I’m one
of very few non-monks to see the full beauty of the Abbey, and it’s an experience I’ll never forget.

As the direct result of learning Hindi (and now a little Tibetan and Kannada), I’ve had some of the greatest career, cultural, social, and spiritual experiences of my life. I’ve made dear friends I could never have met or communicated with, and I’ve learned things that would have been much harder to learn without the language skills. Is learning a language a good use of your time? Absolutely.

How Ruby Mixins Work With Inheritance

Yesterday I asked on Twitter whether anyone was successfully using is_paranoid in a Rails application, because I had confused myself into thinking it couldn’t possibly work.

The problem I was having wasn’t is_paranoid’s fault, but it turns out it actually can’t do what I wanted it to do in its native state. The explanation of why is something I thought a number of Rubyists might benefit from hearing, so here it is.

Briefly, an explanation of is_paranoid: if you declare an ActiveRecord model to be paranoid, whenever you attempt to delete that model, is_paranoid will instead set a flag which indicates that the record is deleted. is_paranoid uses default_scope to filter out soft-deleted records in your queries. So you can act as if records are deleted without actually removing the rows. If is_paranoid is new to you but sounds familiar, you might be thinking of acts_as_paranoid, which is Rick Olson’s original implementation of this idea.

What I wanted to do for the specific application I’m working on is to declare that every model should inherit the is_paranoid behavior. Easy enough, I thought, given the way these things typically work in Rails’ inheritable accessor setup:

But when I tried to destroy an instance of (for example) Person, the regular ActiveRecord destroy code was invoked and the records were being actually destroyed. Bummer.

So I cracked open the code to is_paranoid and found this perfectly reasonable idiom:

At this point, after pretending I was an idiot for a few minutes, I realized that this code was indeed incapable of doing what I wanted it to do.

Some of you already know why. For the rest of you, let’s talk about how Ruby’s mixins fit into its inheritance mechanism.

Maybe it’s just me, but when I think of something getting “mixed in” to something else, I imagine the two things becoming intertwined. So, the natural assumption when mixing a module into a Ruby class would be that the methods of the module get intertwined with the Ruby class. And for the HelloWorld of mixins, that indeed appears to be the case:

But if you start mixing modules that implement methods the class also implements in, things don’t go quite as smoothly:

Instead of “Overridden do_something” as some might expect, this code prints “Doing something in Thing”.


Because when we mix a module into a Ruby class, we’re not actually intermingling the methods of the module and the class. Instead we’re inserting the module into the class’s inheritance hierarchy. A good way to see how this works is by using the “ancestors” method:

When a method is called on an instance of SubThing, you can see that it is looked up first in SubThing’s class, then Thing’s class, then in IneffectiveOverride, and so on.

(I used yuml to generate this. Cool site!)

To further demonstrate that mixins don’t really get “mixed in”, notice what happens when you try to include a module at multiple points in the inheritance hierarchy:

If a module is already present at a higher point in the hierarchy, it won’t be mixed in again.

So is_paranoid was apparently built without the goal of being able to mix it into ActiveRecord::Base. Sounds reasonable to me.

Productivity tip: Let Derek Sivers Take Notes for You

I just finished reading the inspiring The E-Myth Revisited, which like my own first book My Job Went to India suffers from an incredibly bad name.

This is definitely one of the most practically useful and potentially career-changing business books I’ve read. As I started getting toward the end, I realized that I should have been taking notes. The book is an excellent read, but at its core, it can be distilled into a clear outline of stuff to do after you read it. I was reading on my Kindle, which I’m still not good at using as a quick reference device. So, while I was excited about going back through the book and making myself a TODO list, I wasn’t sure how to best do it.

Then I remembered Derek Sivers’ book list. Derek has obviously spent a lot of time thoughtfully preparing a list of recommended books with reasons behind each recommendation. Not only that, he includes detailed notes on each book. I read his notes on E-Myth Revisited and was pleased to see that all of the important stuff is captured. Thanks Derek!

Speaking of Derek and books, don’t miss his book, How to Call Attention to Your Music. It might be titled for musicians but I think everyone will find something valuable inside.

No More Projects

As a young self-taught software developer, one of the first books I remember reading was Steve McConnell’s Software Project Survival Guide: How to Be Sure Your First Important Project Isn’t Your Last. Who knows why I picked that one of all the possible books but I somehow knew I wanted to learn something about the broad practice of software development instead of just focusing on how to make specific widgets appear on the screen in Delphi or VB or how to automate the shell on our VAX cluster. I probably happened upon the book while aimlessly thumbing through spines in the local book store and was drawn to the snazzy cover.

And so it was that one of my first experiences in learning software became project-focused. “How to be sure your first important project isn’t your last” indeed. This thing called software development was apparently all about doing projects.

I was not alone in this understanding of how software development worked. Most of the people I encountered in my professional life approached software work this way. When something needs to get done, the first step is to name it—sometimes with a silly code name and sometimes with a generic name like “the HR system project” and the next step is to start planning the project.

I’ve started to notice a bad habit. Whenever I need to do something I don’t want to do. Or, worse, something that I want to do but I am prone to procrastinate (according to The War of Art procrastinating something is a sign that it’s important). The bad habit is this: I turn it into a project.

Projects are lovely for procrastinators. As soon as you call something a project, you give it permission to not be completed right now.

Events such as the Rails Rumble have shown that it’s possible to finish software projects in two days that might take a corporate development team weeks or months in a normal project scenario. What’s the difference? Do the Rails Rumble participants throw quality out the window? Do their apps suck? Do they avoid testing and cut corners? Yea, sometimes. But so do most corporate development groups. That’s how things are.

I’ve learned over the course of my career that the amount of time I spend on something doesn’t positively correlate to its value or quality when finished. In other words, if I do something really quickly, it’s not likely to be less valuable than something that takes me a long time to do. Within obvious limits.

So if you want something to take a long time, call it a project. If you want it to get done, just get it done.