Obie Fernandez

Now Available on Video: Hashrocket

Hashrock't Series: Jon and Sandro on Pair Programming from Hashrocket on Vimeo.

Shot on location at our offices in Atlantic Beach, Florida one day before our big move to new office space in Jacksonville Beach.

In one of the ways that we must be different than all other shops in our niche, we actually employ a documentary videographer who tries to capture what Hashrocket is all about on a daily basis. Maybe someday we'll pull together a "Hashrocket: The Movie", but for now my ambition is simply to provide our friends and fans a way of getting to know the Rocketeers and maybe learning something from watching us at work and play.

Getting our National Service groove on with Apps for America

I'm proud to announce that Hashrocket is answering President Obama's call to national service on Jan. 19th by getting together and building at least one App for America contest entry. Week-long brainstorming over what we'll build has not led to a conclusive decision, so we'll get together around 9 am and time-box the decision on what to build to at most an hour. We're leaning towards an app that gets you familiarized with your local politicians and how they are connected to issues that affect your community.

We're not focused on winning the Sunshine Foundation prize, but the judging criteria does provide us with a good set of guidelines for the day:

Awards will be judged based on the following criteria:

1. Usefulness to constituents for watching over and communicating with their members of Congress

2. Potential impact of ethical standards on Congress

3. Originality of the application

4. Potential usability of the application

5. Code quality of application

By the way, we're throwing down the gauntlet to other Rails firms to do the same thing! (Nearby and want to join our team for a hack day? RSVP here)

Pricing RailsBizConf

With over 40 respondents I'm starting to get a good idea of how to price registration. Given the difficult economic times, I was expecting a lot of respondents to my RailsBizConf survey to indicate a problem with the proposed registration cost. I was wrong, which makes me more confident that I'll actually be able to make this event happen.

 

Some interesting comments submitted as the other option on this field:

• Wow, really? In this financial climate I have a hard time believing there are enough large Rails companies to afford this. I do hope I'm wrong though.
• PWYC (dream on?)
• I'm a poor student => $500

I'm talking to a design firm about some brand identity and marketing collateral today, as well as some preliminary talks with event planners.

Please keep the responses coming in and help me spread the word.

RailsBizConf Survey

The RailsBizConf idea has been brewing in my head for close to a year and I'm finally ready to start making it a reality. I'd like to bring together principals of Rails consultancies for a 2-day conference, focusing on the business aspects of our niche.

As a first step, I am collecting your feedback about the idea, and plan to use the information to help me retain a conference organizer and narrow down the date and location. If you're at all interested, please fill out the following survey.

Cheers,
Obie

Powered by Wufoo

External link (in case of problems with the embedded form)
http://obiefernandez.wufoo.com/forms/railsbizconf/

Satyam Schadenfreude

You may have heard that Satyam, one of the most prominent Indian IT outsourcing firms, is in deep doo-doo this week, due to revelations that they inflated their balance sheet by almost a $1 billion (among other sins).

As executives at other Indian outsourcing companies nervously assess what impact the scandal will have on them, many industry observers now argue that the Satyam case will damage India's reputation as a reliable provider of IT services. Because of the Satyam scandal, they say, Indian rivals will come under greater scrutiny by regulators, investors, and customers. "The bubble is going to burst in terms of trust," says a fund manager in Hong Kong who has followed Satyam closely. Doubts about the reliability of Indian outsourcers are especially important, since customers often allow the Indian companies access to sensitive systems. "This industry doesn't just make widgets," the manager explains. "It's an intimate relationship." Certainly, says Gartner (IT) analyst Diptarup Chakraborti, "there will be caution in the short term, skepticism, and questioning." After all, "no one wants to do business with a known fraudster." (Empasis mine)

I can't believe how many years has it taken for our industry to come to this realization! No disrespect to my great friends and former colleagues at smaller firms in India, but I am not surprised one bit that the corruption flows from the top at the big Indian contractors.

Over the years, some of my bigger enterprise clients have flushed ridiculous amounts of money down the toilet with Satyam, Wipro and Infosys. All of us collaborating and integrating with their software teams were privy to their dirty, little secret. They usually had one guy that actually knew (anything about) programming, floating at least five or six others that didn't have a clue and hid behind the excuse of language barriers. However, since their individual bill rates were around $20 or less, the managers on this side of the world thought they were getting a great deal!

Good riddance!

Top Ten Attributes of Good Clients

The following attributes are arranged in countdown-style, to denote relative importance to me. I'm the first to admit that it's a subjective and incomplete list. Also, to go beyond "good" and be considered a "great" client, they would have to possess almost all of these attributes and more. No single attribute can redeem an otherwise "bad" client by itself, and many of the attributes on this list are of similar importance.

10.  Friendliness (and camaraderie)

Nobody really wants to work with dry and/or unhappy people or people that don't care that they are part of a team. Friendliness and camaraderie goes a long way towards smoothing over the bumps in the relationship that will unavoidably crop up. The question "Would I want to have a beer with this person?" that we sometimes use as a basis to judge job candidates applies equally well to potential clients. Always acting as a team engenders a more successful and satisfying project for both parties.

9.  Gives you positive publicity in public

Our great client, David Cohn (of spot.us) comes to mind. We did great work for him and in return he has promoted Hashrocket with an infectious enthusiasm that is more than I could have ever dreamed of asking from him. The positive feedback loop of goodwill and results is priceless -- my developers at Hashrocket are actually competing to get the chance to work with David on upcoming phases.

8.  Pushes you to learn and evolve in private

The positive flip-side of enthusiastic promotion in public comes from clients that push you privately to  evolve your internal processes and raise your output. I'm talking about clients that treat you more as a partner than as a vendor, and take corresponding measures to help you improve. Those clients play a non-trivial part in the growth and success of your business via their questions, advice and support.

7.  Realistic expectations

One of the most important skills that a good consultant possesses is the ability to properly set expectations. However, the client needs to be receptive to expectation-setting and be open-minded about evolving their own plans as the relationship evolves and the project takes on a life of its own. I never take this attribute for granted; too many times I've been burned by clients that refuse to acknowledge the realities of software development and the impact of scope creep on schedules.

6.  Involvement

A great client doesn't want to simply hand off responsibility for the project to you. They want you to be their partner and they are communicative and optimistic about your involvement. Involved stakeholders aren't afraid to make decisions. They stay engaged and communicative during the entire project. They don't make you wait hours or days for responses to questions, and they are enthusiastic participants in your acceptance process, allowing you to finish the project without being overly demanding.

5. Open-mindedness

You might have some success with a close-minded client that has money and lets you drive a project mostly by yourself, but in my experience the client has to be highly intelligent and open-minded to understand and apply Agile concepts to their business and allow you to do the same when you're working with them.

4.  Respect

Do you want to deal with a client that second-guesses your advice and decisions? Of course not. This is one reason why it's so critically important to truly be an expert of the domain in which you consult clients. You can't ding a client on this attribute if you are making legitimate errors in your advice and decisions. However, if you know what you're doing and have the track record to prove it then make sure you get the respect you deserve.

3. Has a viable business model

Great clients that are established companies are not in the process of going out of business or struggling through corporate crises that distract them from the success of your project. Great startup clients have a business plan that you believe in, or at worst, you can see some viability in. You might be tempted to work with clients that do not have viable businesses, but it's a risky proposition. Eventually the same problems that are dooming their business will make them aggravating to work with or cause them to default on their financial commitments to you.

2.  Diligence

Great clients takes the time to read and understand the contract they signed with you. They take the time to learn and appreciate your development process. They don't act in ways that subvert your development process. They respond to your communications in a timely fashion. They provide thorough and detailed answers to your product-related questions.

1.  Pays on time

Simply put, great clients always pay what they owe you and they pay on time.

---

Consultants, what are some of the top attributes that you associate with great clients? Share your thoughts in the comments...

Think you have what it takes to be a great Hashrocket client? Contact us at [email protected]

Limitations of a Story-driven process

Over the course of the last six months, time permitting, Hashrocket has been working on a product initiative codenamed "Launch Pad". Hashrocket does a lot of Web 2.0 apps, and most of them have a similar assortment of basic functionality and social networking features: user accounts, event notification, photo uploading, commenting, etc. Naturally, there is a desire to take our sum knowledge of building these types of features and codify it in the form of a base application and suite of plugins.

I'm describing the reuse proposition, one of our profession's holy grails, which ideally would bear fruit in terms of cost savings and shortened time-to-market for our clients. Not to mention that a productized Hashrocket Launch Pad is a product that I could sell at a profit, proven by folks such as Pivotal, with their social media platform, licensing for which starts at around 30k.

Initially, Launch Pad was an informal effort and we didn't have a good way to measure progress. Months ago, we went through a storycarding effort to identify the features desired and establish accountability for progress. The stories were entered into our story-tracking tool, Pivotal Tracker, and estimated.

Here's a illustrative snapshot as an example of the type of  stories we ended up with:

If you're familiar with Tracker, you know that the green background on those stories means they were finished and delivered. Acting as stakeholder for the project, I went into our testbed deployment and verified that the features requested were present and met my expectations. So far, so good. After getting through most of the stories, we now have a version of our Launch Pad that exists in the form of a "baseapp". Not quite salable, but useful in the following way: we can clone it as a starting point for greenfield projects, to get that big initial boost in velocity.

Therein lies a problem. It's one thing to have a rich set of functionality in a baseapp when you haven't started a project yet. WIN! It's a whole 'nother thing to have a baseapp with desired functionality when you need to add that functionality to an existing project. FAIL!

The answer of course, is to factor the functionality into more-reusable forms, namely Rails plugins (or gems) that can be added piecemeal to either a barebones baseapp or an existing project. How do you track that work?

We recently had a storycarding session to try and figure out how to do that. The issue is that now we are not focusing on end-user functionality. The user role (in terms of acceptance) is the application developer that needs to use the plugins and gems that we ultimately end up with. Unfortunately, it took quite a bit of time to reach that somewhat obvious conclusion!

Round and round we went, trying to determine how to name the story, describe it and structure acceptance criteria. After much argument and fretting about implementation, we eventually we ended up with something like this:

Story: Adding Photos

In order to provide photo collections for my client,
As a developer,
I want to be able to add photos to a domain model

Acceptance:

• Installation instructions
• Declarative macro makes model act like a photo collection
• Generator-created: Photos controller that includes photo resource module
• Generator-created: Views (new, form partial, javascript, FancyUploads)
• Generator-created: migration
• API documentation

This is a very high-level story! One of my guys called it a "12-pointer" to denote how much it needed to be broken down in order to fit in with our typical process (limited to 1, 2 and 4 point stories).

The problem is that as the stakeholder, I don't want this story broken down! This is the level at which I want to do acceptance, for at least a couple of reasons: 1) I already went through a long acceptance process for many of these stories the first time they were implemented, in the language of the end-user. 2) In order to properly define acceptance criteria for this story, I would have to know exactly how it's going to be implemented, and that information is not available until they actually sit down to figure out how to do the extraction into gems and plugins. In fact, one of the reasons that the storycarding session was feeling so painful was exactly that we were spending so much time arguing about implementation -- out of place in a typical storycarding process where you leave implementation details for later.

That said, to do acceptance for an application developer story, I would need to go in and do things such as follow the API instructions to add the photo functionality to a testbed application. It was starting to feel like I was using our typical story-driven process in anger. It shouldn't be this hard to do something as conceptually simple as an extraction to plugins.

Somewhat frustrated, I ended the storycarding meeting and changed direction. Come in tomorrow and take one of the features from our existing testbed application. It has really good spec coverage, so spend the day extracting it to a plugin and make sure you don't break the testbed app's specs. The following morning we'll have a meeting to see how you did.

Where have you experienced limitations of a story-driven process and how did you deal with it?