Robby on Rails: Tag book

Embracing Failure, part 1

Robby Russell — Tue, 10 Apr 2007 16:38:00 -0500

I’m currently reading To Engineer is Human, by Henry Petroski and found the following applicable to software development and managing client and customer expectations.

“As much as it is human to make mistakes, it is also human to want to avoid them. Murphy’s Law, holding that anything that can go wrong will, is not a law of nature but a joke. All the light bulbs that last until we tire of the lamp, all the shoelaces that outlast their shoes, all the automobiles that give trouble-free service until they are traded in have the last laugh on Murphy. Just as he will not outlive his law, so nothing manufactured can be or is expected to last forever. Once we recognize this elementary fact, the possibility of a machine or a building being as near to perfect for its designed lifetime as its creators may strive to be for theirs is not only a realistic goal but also a reasonable expectation for consumers. It is only when we set ourselves such an unrealistic goal as buying a shoelace that will never break, inventing a perpetual motion machine, or building a vehicle that will never break down that we appear to be fools and not rational beings.”

I’m sure that most of us are guilty of having high expectations for products that we purchased. (why does my ipod screen scratch so easily when in my pocket?) We also set high expectations for the code that we develop, which is why we (hopefully) continue to refine our process. We’re bound to time and budget constraints, which often prevent us from testing every imaginable edge case. Given our constraints, problems are almost always going to arise. It’s no wonder that we see Test-Driven Development as an important part of a healthy development process. We want to catch our failures as early as possible.

Our clients often have high expectations and it’s almost always very reasonable. That’s not to say that some clients will not have highly irrational expectations. It’s our job to manage these expectations as best as possible.

Do we mislead our clients by convincing them that our TDD/BDD process is going to prevent any bugs from creeping from the woodwork after the development cycle is finished?

“I thought that we paid you to fully test the code?”

Really… is that even possible? Can we predict (and test) every possible interaction within an application? Highly unlikely.

What we can do is plan for and embrace failure. We can help our clients understand that almost every application needs to be maintained after it’s initial development cycle. Bugs are inevitable and there needs to be a clear process for handling them.

Perhaps I’m abusing the bug fixing process by calling it a failure… but I’ve also found that yes… many bugs are due to failure. Whether that be a failure to specify application behavior, a failure to understand the project goals, a failure in communication, ...or maybe a failure in our software architecture. We’re constantly failing.. and it’s okay!

IT’S OKAY TO FAIL! (some of the time…)

“No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art. Contrary to their popular characterization as intellectual conservatives, engineers are really among the avant-garde. They are constantly seeking to employ new concepts to reduce the weigh and thus the cost of their structures, and they are constantly striving to do more with less so the resulting structure represents an efficient use of materials. The engineer always believes he is trying something without error, but the truth of the matter is that each new structure can be a new trial. In the meantime the layman, whose spokesman is often a poet or writer, can be threatened by both the failures and the successes. Such is the nature not only of science and engineering, but of all human endeavors.”

As we’re creating these virtual structures… are we really taking the time to reflect on our failures? This is why some teams adopt practices like iteration retrospectives and post-mortems.

I’ll end this with a few questions, which I hope that you’ll share your experiences about…

In what ways is your team embracing the failures of your development projects?
How do you help manage your clients expectations… so that they too can plan for and embrace failure? Isn’t their new business venture on the web… likely to experience some failure?

We have so much to learn…

Jeremy signs a book deal

Robby Russell — Thu, 27 Apr 2006 17:37:00 -0500

Someone finally snatched him! Since Jeremy Voorhis started working with PLANET ARGON, he’s talked about how a few publishing companies had contacted him about writing a book on this new fancy web framework… Ruby on Rails. Due to being too busy with PLANET ARGON development projects... he would send them away. Yesterday, he announced that he recently signed a contract with O’Reilly to write Rails in a Nutshell.

Congratulations Jeremy!

...does this mean he isn’t as busy with development work? No… it just means he’ll sleep less in the next several months. ;-)

I'm leaving...on a jet plane...

Robby Russell — Wed, 12 Apr 2006 16:36:00 -0500

I’m sitting at the Portland Airport with Jeremy… we have almost 2 hours to kill before our flight leaves. We love the free wifi at the PDX Airport. I took a few moments to upload some pictures to our flickr account and thought I’d take a moment to mention some cool news.

Jeremy Voorhis, Lead Architect at PLANET ARGON will be writing a book for O’Reilly. He mentioned it on his blog this morning it appears. :-)

Congrats Jeremy!

Keep your eyes on the Canada on Rails Flickr group!

The Book Business 2.0

Robby Russell — Tue, 28 Mar 2006 16:12:00 -0600

I saw David pointing this blog entry out to Jeremy.

Some interesting discussion/debate between DHH and Tim O’Reilly. :-)

Alpha reviewers selected

Robby Russell — Fri, 10 Feb 2006 14:10:00 -0600

First of all… wow, I got a lot of responses.

I just sent the invites to the people that I selected… think I selected 7 out of the 46 people that responded.

:-)

Programming Rails - Alpha Book

Robby Russell — Fri, 03 Feb 2006 12:34:00 -0600

Up until today, I have had a small group of individuals (people like harrisj) helping me with the peer review process for my upcoming book, Programming Rails. We’re getting it ready to launch as a Rough Cuts book in the near future and I wanted to allow a few of you to be part of the pre-Rough Cuts review process.

I’m opening this up to 6 lucky winners!

Send me an email to robby@planetargon.com with a short description of your experience with Rails so far. I want 2 newbies, 2 intermediates, and 2 advanced Railers.

Only do this if you can spend time reading material and posting notes on each chapter. :-)

Visit www.programmingrails.com for more information about my book and apparently… you can add it to your Amazon Wishlist.

UPDATE No longer accepting applications! I got 50+ in 2 hours… eek! :-)

Ruby eye for the anti-newbie guy

Robby Russell — Wed, 18 Jan 2006 09:44:00 -0600

I was skimming over a few RSS feeds ( blogs.thoughtworks.com ) this morning and came across an entry by Griffin Caprio. He shared his thought on the new book by Chris Pine, Learn to Program and says the following:

”...You wouldn’t see these types of books in other professions like medical, engineering, or accounting because there are boards that prevent just any old person from practicing in those fields.

Not so in computing. But is this what we want to encourage? Anyone and everyone picking up software and just giving it a go?

And I understand everyone’s love of Ruby, but come on people. It’s just a language.”

Actually, yes. Learning to program, build, create, test, problem solve, etc… are all things that we should encourage.

Let’s do a quick search on amazon for the following, Learn to Program. I’m pretty sure these books have been common place for the past 20+ years… so, what’s the big deal?

It’s like telling a kid not to build a bird house until he gets a contractors license and a permit.

...or telling someone to not pick up a guitar until they had proper lessons.

...or maybe you shouldn’t be running a business without graduating from college.

I could go on and on.

Oh… and by the way…

puts "Hello World"

is much sexier than

public static void main(String[] args) {
  System.out.println ("Hello World"); 
}

On that note… check out Learn to Program by Chris Pine.

UPDATE Griffin has followed up to my blog entry with another. He goes on to say, “The kid who builds the bird house above would never be hired to build an actual house. Not true in Software Development.” (read more)

I think this problem raises a completely different problem. Why are unqualified people being hired to do things that they aren’t qualified for? Do we blame the people learning to program or do we look at who hires these people in the first place? I’m still confused by his argument.

That kid may not get hired to build a house, but he may get interested in that as a career and continue to pursue it… if someone hires him to build the whole house, then the person hiring should be held accountable do some degree as well. Check references! ;-)

On the flip-side… is this an argument to only take people who have been approved by some board (...MCSE?) seriously when hiring developers?

Update #2

Griffin has outlined his points in more detail in this third entry.

Why’s (Poignant) Guide to Ruby in PDF form!

Robby Russell — Tue, 13 Sep 2005 06:57:00 -0500

The famous, Why’s (Poignant) Guide to Ruby has been released as a nicely formatted PDF.

Thanks to Leon Spencer for providing the world with this PDF.

leon++

DHH interviewed by O'Reilly

Robby Russell — Wed, 31 Aug 2005 06:46:00 -0500

I just finished reading a very nice interview of David by O’Reilly

You can read it here.

While reading it, I recalled a brief conversation that I had the other day, when someone said that they didn’t like Rails because, “it assumes things” which translated to the fact that they didn’t like that it had a uniform directory structure, pre-defined naming conventions, etc.

After spending this whole year, teaching myself Rails, reading the documentation pages… (probably at the API site a few hours a day), this concerned me. A lot of people are quickly turned off by the fact that Rails has opinions. But, let’s think about this for a moment. Rails has opinions built-in that help speed up the development process when you accept those opinions. If you don’t, you don’t have to pspend any more time than you did prior to using Rails. So, their argument is, “why bother with Rails?”

At first, the answer isn’t so obvious…. but if you consider all the opinions that Rails expresses, do you honestly feel that every one of them is wrong? If so, Rails is probably not for you. If you find a good portion of them to be quality opinions, then… Rails just might be your cup of tea afterall.

Pluralization make you feel weird? Turn it off. (one line of code will do this for your whole application.

Wait, you want to use category_id as your primary key?

class Category < ActiveRecord::Base
  set_primary_key "category_id"
end

Yes, I know… it’s tough. ;-)

Another thing that I am wondering now… what is the conductor?

My guess? Some added bonus for Rails that allows you to run a Rails application off of one or many servers… now that would be nice. That’s my guess though… what is yours?