Obie Fernandez

Corey Haines and RMM at Hashrocket

Corey Haines at Hashrocket / RMM from Hashrocket on Vimeo.

Join us in welcoming Corey Haines (aka The Software Journeyman) to Hashrocket for some pair programing with Stephen Caudill. Corey Haines travels around the country pair programming with whoever will feed him a scrumptious vegetarian meal and give him a spot to put his air mattress.

In the video, Corey arrives at Hashrocket (accompanied by Cory Foy) and introduces himself to the team. Then Obie, Corey and crew proceed to discuss software craftmanship and the project that Corey and Stephen will be working on for the duration of the week: RMM - the Rails Maturity Model application. A great conversation ensues that really hits home on what RMM is all about.

Explain Variable Scope with Ponies

Lately I've been using the following analogy as a valuable tool in my sales process. Used properly, it's totally killer and you're gonna love me for it. I promise. It involves ponies, kind of...

First of all, let me set the context by explaining the problem I'm helping you solve. (Mind you, I know that not everyone does Agile the way that I do at Hashrocket, so it definitely won't apply to everyone.) But if you do try to sell Agile, even if it's only to your managers, bear with me and tell me if this situation sounds familiar:

1. You talk to a new client
2. Client has a list of features desired, perhaps even a requirements document or functional spec
3. Client wants to know how much it will cost to get their project done (or just a ballpark estimate)
4. After explaining that it's up to them how much it will cost (since they will be required to prioritize for business value and manage scope) Client still wants to know how much you think it will cost to "get done"
5. After explaining for the tenth time that it's really up to them how much they want to spend and optionally giving them a wide (and meaningless) estimate like $50 to $150 thousand, they still want to know how much you think it will cost.

People that haven't done Agile software generally don't understand the concept of variable scope. They think they know exactly what they want, and they want a price. If you don't give them a price, they'll keep looking until they find a provider that gives them a price, for better or worse... usually worse.

Here's the analogy, which serves to illustrate variable scope and price very effectively. Compare the requirements to a child's Christmas list or letter to Santa. (or three kings or whatever) For reasons that will be obvious in a moment, this analogy going to be most effective with actual parents that have to go Christmas shopping for their kids every year.

Rattle off a realistic gift list like the following one:

• Barbie doll
• Barbie book that comes with makeup
• Playhouse with kitchen
• Barbie video game
• Barbie coloring book
• Pony

It's important that you communicate that all or most of these items involve ambiguity about what is actually desired.

Ask the client (or yourself): How much do you have to spend to get this list "done"?

How much does a Barbie doll cost nowadays? Twenty? Thirty? Less? Who knows? You can ballpark it, sure, but what about some of the other things on the list?

It's actually impossible to say how much it will cost to fulfill this list until you actually do the Christmas shopping! Why? Because of the ambiguity!

If you're a parent on a budget, then you might have an idea of how much you're going to spend fulfilling the desires on this list, but only because you have a budget in mind. And even in that case, you still don't really know exactly how much you're going to spend, because you're going to make buying decisions on the fly as you visit the stores where you're going to buy the gifts. Stuff will be on sale or out of stock, you might feel better or worse depending on other people you have to buy gifts for. No matter what, you must try to maximize the happiness of your child without breaking the bank and making everyone else happy.

Even rich parents that don't go shopping with a particular budget in mind will understand this analogy! They still have to maximize the child's happiness without knowing exactly what you're going to end up spending. For instance, it's the rare child that will actually get a pony for christmas, but maybe while shopping the parent sees a stuffed pony doll, or a My Little Pony playset and spends $20 to buy it and cross "Pony" off the list. Maybe they don't. I have no idea how to fulfill that Pony request, and neither does your client, until they actually start shopping.

That's where I'm going with this. Actually implementing the prospective client's project is like doing the Christmas shopping described above. You might know approximately what things on your client's requirements list will cost beforehand, but there's never a way to know exactly what you're going to end up spending until you actually start crossing items off of that list (clearing the backlog) and decide that you're done (release the software).

FOWA Miami 2009 Notes

Jason Fried

Jason opens the conference with an inspirational keynote-style, rambling, slideless talk. Main ideas:

• Look for byproducts of your business and profit from them
• Fail early, fail often is invalid in business. Learn from success.
• Free is overrated, actually it's harmful. Freemium works, but paid works better. 37signals sees much better upselling with clients that start with paid plan than with free. (Duh?)

Jason doesn't care about the competition, doesn't think about them -- just focus on building a great product. The success of competitors doesn't bother him.

As free services fail there's going to be a "flight to quality", to stable companies that make money

37signals was recently looking for a VP or Marketing and Business Development manager. Stopped rather quickly once realized they "didn't know what it fucking meant". Suggestion, before you hire someone try doing that job yourself so that you understand what you're looking for.

During the Q and A Robert Dempsey asks whether there will be consolidation in the web app field or whether OAuth and other integration technologies will help single-function apps thrive. Jason thinks integration without a cohesive user experience is a pipedream. On the other hand, big uber-apps don't work either, so maybe vendors offering multiple tools (like 37signals? heh) will continue to succeed.

37signals has 12 people now, after hiring 4 people in 2008. Key productivity advice is to stay the hell away from each other -- interruptions kill productivity. Totally opposite philosophy from the way that Hashrocket works.

Dion Almaer and Ben Galbraith

Dion left Google (news to me) to join Mozilla with Ben. Their talk is about the future of the browser. Lots of talk about how Ajax has pushed the state of the art forward. The focus of their talk is a set of four technologies that will change the world of web apps.

• Canvas. No startup delay, works on iPhone.
• Fast Javascript. Crappy status quo is a real pain-in-the-neck for web application teams. New runtimes are order-of-magnitude faster and are capable of heavy-duty processing. In other words, Photoshop would be possible in the browser now.
• Web workers. Threading for web apps?
• Desktop Integration though native service APIs exposed by Fluid, Mozilla Prism and other webby containers and operating systems.

Bespin (in-browser open-source IDE and code editor) looks really cool.

They use Delicious Library (half-million in profit) as example of making refined, sexy versions of apps that have been done a million times before.

Amazing conference animations by Chris Kelley.

Dan Theurer

Sadly, this presentation is not working at all. It's a code-oriented talk about the open APIs provided by Yahoo, but the presentation slides were corrupt and didn't work. Dan is up on stage trying to talk his way through api descriptions and code examples. Terribly painful :(

Joe Stump

The lead architect (or something) at Digg, was the seventh developer hired. Everything was chaotic in the beginning, and Joe is going to talk about the hurdles in scaling a team as you scale up and implement process.

His .vimrc file is 20 lines and has been the same for last 10 years. (In other words, developers are stubborn.) Other attributes of developers:

• Whining
• Laziness
• Eccentric

(Generalizations bad, mmmkay... I don't think he meant any harm though, but this is feeling very cliched so far)

Tells story of things that top developers have gotten from hiring companies: $50k shower installed into office "since I do my best thinking in the shower" and $30k fully-functioning desk made out of LEGOs. Funny, but I missed the point. That developers are difficult?

Good point made about team size: need to keep the size down to 5-7 people at most. (Actually, I say that 2-4 is optimal.) Break up large groups into teams with specific responsibilities.

Strong advice about code repositories. "Can't believe that I have to put this slide up here." As I've been ranting about lately, there are still teams out there not using source control. "If you have a development team that's not using source control you have to fire the team or fire yourself" - Joe Stump

Joe says to Promote Ownership (in contrast to XP's shared ownership), but I think he's talking about at a team level.

"You should have frameworks (Rails, Django, etc)... it doesn't matter, it's all about lowering barriers to entry, and frameworks definitely help there" He's been playing with Django and likes it, but Digg is not porting their 500k lines of code to Django.

Testing. Unit testing.

21 developers and 5 concurrent sprints going on.

They're writing code so quickly that they can't get it through QA and integration rapidly enough.

Kristina Halvorson

Copy sucks. Needs time and organization. (Didn't get that much out of this short talk.)

11 women out of 800 people registered.

Challenges for organizers

• Fewer women applicants
• Fewer women on circuit
• Fewer "high-profile" women speakers

The potential speaker's challenge:

• Lack of role models
• Lack of support and resources
• The girl/boy thing. In classrooms, a boy will raise his hand whether or not he knows the answer. Girl will only raise hand if she knows the answer. (Basically it takes hubris to be a presenter.)
• Perceived "white boys" club. See Chris Messina's post about that

Tag speaker ideas and offers with #fowaspeak Ryan will be listening for future Carsonified events.

Aza Raskin

Open-source is chaordic (ordered chaos). Decision-making is pushed to the nodes. Technically Aza has 1 person working on Ubiquity fulltime, but he has 10 core contributors. Mozilla Labs operates in an open-source manner internally, there isn't really a traditional division of labor.

(I'm missing the point of his call to action about the 270 million users and designing for it.)

Aza calls for "the wiimote of the browser world". He's asking for disruptive development in that space?

Neat conference trick. Tells everyone to raise their hand, then thanks everyone for volunteering and picks one person to "describe your significant other in 30s without disclosing their gender". Immediate fail by the volunteer, who began "she does..." Point it, it's difficult to leave gender out of the way we communicate, yet computers do that all the time.

Couching problems in terms of people rather than technology.

Let's move away from destination sites. From people having to go places, and make computers do stuff for them instead. Can't wait to see actual Ubiquity demo. I'm sad that technical problems are ruining some of the talks here.

Dave Morin

We've only been thinking about people for the last 2 years. (Really?) Never been a better time to be doing what we're doing than now -- the building blocks are there to build the applications that we've been wanting to do for years. Facebook is just one of the companies providing the social graph.

Facebook has 175 million people (and 660 thousand developers) as of February 2009. Facebook Connect is the first step in enabling everyone on the web.

(Sigh, almost ten minutes in, the speaker is wayyy loud, lunch is late, and this talk has said nothing so far. Frustrating. Also, although his slides are actually on the screen, he's having trouble with the clicker.)

Talks about beefier activity feeds and activitystrea.ms which looks interesting, but overall I couldn't bring myself to get excited about this talk. Very high-level.

Joel Spolsky

Don't treat software like assembly-line factory. Be like a movie studio, bring the best talent. We live in a winner-take-all society, there's only going to be one big social networking site, one microblogging service, etc. It's all about talent. Disproportionate reward example: one of his summer interns built their job listing site in 2 weeks. Over 2 years it's earned $1,043,767 dollars, paying for 6 years of intern expenses, many times over.

Based on Yale CS students statistics, there is no connection between the time taken to do an assignment and its quality. (Ratio between best and worst developers is 10 to 1.)

Bottom line: Emphasize talent in recruiting, treat them like rockstars, invest in a great office and working environment, keep them all together, long lunch tables for everyone to eat together. All great advice.

Check out Fog Creek's new office, it's gorgeous and is attracting a lot of attention.

Dave McClure

Unfortunately I missed what AARRR acronym means. He's talking very, very quickly. This appeared to be a quick talk about optimizing for "Conversion Improvement". Advice is to stop iterating when conversion increase slows down. The break

• 80% on existing feature optimization
• 20% on new feature development, possibly less

Shows a conversion dashboard with stage, conversion status, percentage columns.

Measure stuff. Keep it Simple. As founder concentrate on metrics.

(Gotta say these slides with dark colors on black background are really difficult to read, even on the good FOWA equipment. Presentation FAIL.)

Alex Hunter

The presenter works at Virgin on redesign of their main website (for which he will debut mockups today). The talk is Brand 2.0 - Why should people love you? (Should be interesting.)

• Loyalty
• Transparency
• Conversation
• Giving a fuck (LOL)

People are the new brands: think Branson, Jobs, Ryan Carson (lol)... man, but this is a powerful line of thought. You have to believe that you are creating the best possible, the best in history service or product in the history of the universe. (Ha! Captures exactly how I run Hashrocket, doesn't it?)

"Consistency is not Dogma"

"Consistency is a state of mind... like winning"

Example of blog.digg.com as one of the best corporate blogs ever. Diggnation has a 250k audience and has 10 live events per year where massive amounts of fans celebrate them.

Props to design agency Rokkan for redesign of Virgin.com. Alex is really excited about Facebook Connect. According to Ryan, Alex is "putting his ass on the line" by making virgin.com content user-driven.

Francisco Tolmasky

Ryan warms up the crowd by telling us he's been under NDA for months and that what Francisco will be announcing today will be "fucking amazing". Okay, we're ready...

Aristo is a new UI component being integrated into Cappucino and is purely open-source. Made by SOFA. The actual photoshop files (including the iterations that led to the final version) are on Github. In other words, you can use that to learn how to create a beautiful look and feel. (Awesome)

"Write once, layout everywhere" (Sorry, I was enraptured by the Atlas demo, so I wasn't taking any notes.)

Gary Vaynerchuk

Oh man, he's rocking it. Lots of quotable quotes.

"Why in the world should Kanye's next album share anything with Apple."

"You're going to have douchebags like me" running around teaming up with content-providers to monetize.

"You're going to go back to your hotel room and ask yourself, 'Why am I working at this company that sucks straight shit!?'"

He wants to buy the New York Jets. (And he probably will eventually, heh.)

You have to have passion.

It's all about the hustle. (Yah, preach it!!! And checkout my Hustle talk)

"I need to hustle more. I'm doing too many speaking engagements."

Agrees with Jason Fried, he doesn't believe in making mistakes. Everything he's done is potentially a mistake, but when you cry, you're stuck. "Stop crying."

"The fact that you know what FOWA is means that you should win... that's the game"

"There's too many primadonnas in this business... people are idiots. They're gonna lose and they're gonna lose hard because they think they're hot shit."

I asked him how many years until he buys the jets. He said 25, but if he can't he'll take out the NFL. "Fuck the NFL" (ROFL!)

"All this world is doing is making the person with the chops win... If a restaurant is awesome, but sucked at marketing, it could die (in the past)." Not now, because online fans would save it.

"You want a marketing strategy? CARE!!!"

"If you were not selling stuff before the age of 13, YOU ARE NOT A SALESMAN! ... You have to know who you are!!!"

"When's the tipping point? THE DAY YOU START, ASSHOLE!" He doesn't care about numbers and SEO. He doesn't worry about dumb shit like that, just pump out great shit and care. When he was starting out he went out to every wine blog and became part of the conversation.

"I have never drank a Red Bull in my entire life." (Comment from the crowd: "he snorts it" LOL) Offers to pitch it if anyone from Red Bull is watching and interested.

"If you're in this room trying to convince someone to use Facebook or Twitter, stop it."

---

Congrats to Ryan Carson and his crew for another fantastic event. Very inspiring. - Obie

Morning Standup at Hashrocket

Morning Standup at Hashrocket from Hashrocket on Vimeo.

One of our best practices at Hashrocket is our daily "standup" meeting, which many Agile teams would refer to as a "scrum". We follow a format that we learned from Pivotal, in which each participant either passes or answers one of the following two questions:

• What is something cool, interesting or useful that I learned yesterday?
• What do I need help with to succeed today?

It's a great way for everyone to synch up in the morning and get off to a positive start for the day. The meeting is scheduled for a strict start at 9am and attendance is mandatory. Duration is 3 to 5 minutes at most, unless there's some extraordinary circumstance which needs discussion.

RMM Behind the Scenes

Rails Maturity Model (Behind the Scenes) from Hashrocket on Vimeo.

Take sneak peak at what Hashrocket is cooking up based on the ideas for RMM (Rails Maturity Model). It's not about certification, rather it's about having an objective and neutral way of tracking the behaviors that Rails shops consider their best practices and having those vouched for and endorsed by the community at large. We don't think this implementation controversial at all, but here's your chance to decide for yourself.

For Giles, et al.

RMM IS NOT ABOUT CERTIFICATION

However, in honor of Giles' 1000+ word obliteration of a concept that I'm not pushing, it's my honor to present him with this special Strawman University certification:

I'm starting to think I should forget about pushing higher standards of web development and pick up the cause of reading comprehension.

What Matters

Picked up this little nugget from Jeff on the Spolsky podcast: "what matters is what you deliver to the customer, and how happy the customer is with what you've delivered. There's many, many ways to get there."

That sentiment strikes me as very common and I know that several people used a variant of it to protest the entire concept of a maturity model. It also strikes me as overly simplistic and damaging to its adherents. The customer's happiness is temporal! What actually matters is the customer's happiness before, during and after a project. Delivery itself is not everything nor by itself the most important aspect of a project.

Once you start identifying practices that make your customer happy during the entire lifetime of a project, I think there's significantly less ways to "get there".

Apology for a Rails Maturity Model

5/16/09 UPDATE: The Rails Maturity Models website is now soft-launched and available for evaluation at http://railsmaturitymodels.com It allows Rails development firms to document their own set of practices, their "maturity model" so-to-speak. Many people have misunderstood the concept of the site and attacked it, but I don't think it is a particularly controversial endeavor. As a matter of fact, I believe strongly that the site will be a useful tool for community introspection and understanding our success.

The outcry over my idea of establishing certification of Rails development shops based on a "Rails Maturity Model" (RMM) gave me pause, to say the least. (It also gave me a bit of heartburn.) I was wrong to suggest auditing and certification, although I want to point out that I didn't write that message for a wide audience and it was purposely composed in a tongue-and-cheek and informal style. Lesson learned.

To be clear, what I'm saying is that I agree that certification is a bad idea, full-stop. Especially for individuals. I mean, it might only be a matter of time before someone tries to establish a certification program for Rails, but I promise it's not going to be me. At the moment, nobody is proposing Rails certification, so if you're one of those people that got riled up about it, just stop and chill the fuck out. Seriously.

[ As I was writing this blog post, I took a break and walked into the kitchen where Desi is finally wrapping up some of the unpacking from our recent move. Guess what was sitting on the counter? My framed Sun Certifications from 1999! Couldn't resist posting a pic of the Architect certificate, even though I expect to be mocked mercilessly for doing so. ]

Maturity Models

On the other hand, a "maturity model" does not have to be coupled to certification and I don't think there's anything fundamentally objectionable or offensive about trying to define a maturity model for Rails. I envision it serving as a roadmap for Rails developers to adopt best practices defined by the community:

A maturity model can be described as a structured collection of elements that describe certain aspects of maturity in an organization. A maturity model may provide, for example :

• a place to start
• the benefit of a community’s prior experiences
• a common language and a shared vision
• a framework for prioritizing actions
• a way to define what improvement means for your organization

A maturity model can be used as a benchmark for comparison and as an aid to understanding - for example, for comparative assessment of different organizations where there is something in common that can be used as a basis for comparison. Wikipedia

I think an official maturity model is crucial as Rails enters the mainstream software development industry. In the words of Robert Fischer: "Once upon a time an idea like #rmm would be silly: the very fact you knew Rails implied something about the kind of dev you were."

That time has passed, but Zed is still wrong. Rails itself is not and was never a ghetto. It's more like the entire field of custom web software development in general is a ghetto. And what's happening now is that every year that passes more of the inhabitants of that ghetto switch from PHP, .NET, Java and ColdFusion to Rails as their drug of choice:

Rick Bradley: "Furthermore, In reality, where we happen to live, there seems to actually be a power law at work:  the vast majority of software and teams plying our trade are so bad that they fail nearly every metric we could reasonably apply.  Only the vanishing minority of products and practitioners pass even a single gameable metric.  Yet we ultimately have little means of discerning for ourselves, for our clients (or for differentiating for our future clients) the difference between one or the other."

In my original RMM message to the mailing list I referred to some people as "unwashed masses". Yes, that sounds elitist. No, I don't think there's anything wrong with that. Note that if you're reading this, then I'm probably not talking about you. I'm talking about people that don't keep their code in source control, nevermind git vs. svn. I'm talking about people that don't do any automated testing, ever. I'm talking about people who write an entire big application in one controller. I'm talking about people that code big database queries into both sides of a spaceship operator. The list goes on and on; I've even done major conference talks about their horrors.

A Rails maturity model would point the way out of the ghetto for individuals and organizations who wish they were doing high-quality work, but have no idea what it means to do so.

Rick Bradley: "To be able to deploy a standard of comparison (whether distributed or centrally administered and computed) that forces products or teams to either score in the vast gutter of mediocrity, or work diligently to at least game performance on a number of axes (when such gaming is, realistically, often more difficult than just working to better oneself) to separate from the pack -- would imply a vast improvement in the current and long-standing state of affairs."

Lots of people on the original RMM thread suggested that market forces should be allowed to run their course. The problem is that there seems to be a bottomless well of amateurs ready to step up and take the place of the ones that go out of business. Where there's money to be made you will have opportunistic players ready to give it a go, and don't get me wrong -- I'm not trying to say that there's anything fundamentally wrong with being an amateur. It's just that at the very least the community should give those newcomers a more-or-less official set of guidelines for how to produce quality work:

Rick Bradley: "In my limited experience the difference is usually striking and obvious:  "this is trash" vs. "wow, this is pretty good".  In the Rails community the latter is really only elicited by the products of about 10-20 shops (those shops Obie was trying to catalog in one of his solicitations this evening).  It would be great if we could get that number up to 50, 100, or even 1000.  I'd like to believe that putting a workable set of metrics out there would eventially bias progress in that direction."

I have no idea whether Rick is correct that only 10-20 shops in the Rails community consistently produce "pretty good" work. None whatsoever. That questions is actually what prompted the RMM thread on the mailing list, because I asked members to reply with their list of the top 10 shops (consultants) in their opinion. It felt like everyone had a pretty hard time coming up with answers. In fact, I asked because the question came up among myself and a colleague, and I had a hard time coming up with a solid list myself, and arguably I'm one of the most well-connected people in the community.

I don't think there's anything inherently bad in what I'm talking about here. I don't think it'll take the fun out of Rails. I don't think it kills innovation or my credibility. I don't think it's enterprise-y. I don't think it's ridiculous or that it means Rails has really "jumped the shark" (that's happening in Las Vegas in May of this year, j/k). I do think it's about leadership and taking responsibility for maturing the community that lets us make a happy living, thereby ensuring its longetivity. I do think it's about expanding the pool of qualified and competent Rails developers out there.

Actually, I hate to end on a bad note, but I really think that there's some urgency to all this and that our collective failure to set high standards for the community is strangling the continued growth of Ruby and Rails overall.

Tom Mornini: Our customers at Engine Yard are screaming for more developer capacity, and in fact, TWO previous customers abandoned Rails (one for PHP and the other for Java) simply because they could not find enough skilled and savvy Rails developers to move their projects forward.

It's not a problem only for Tom and Engine Yard. At Hashrocket we've been helping organizations transition from legacy technologies to Rails and they all have difficulties finding qualified developers. I know that folks like Courtenay at ENTP are having the same problem. Please don't shoot the messenger. Something has to be done about this, and I think it's more important than Rails 3 or anything else we are currently excited about.

Notice I didn't actually propose the contents of the RMM this time around. I have been chastised by the community reaction to my first list, particularly for including things like pair-programming. I do have an idea for a way to have the RMM be community-generated and maintained, and I'm going to put it on my list of things to do in my copious free time. If someone wants to help me with it, let me know via email.