Obie Fernandez

Consulting Masterclass

My friend Brennan Dunn and I have taken everything we know about bootstrapping successful consulting companies out of freelance work and packaged it into an actionable two-day online workshop.

In addition to the course material, you will be privy to hours of conversations we've had with other successful consultancy owners and gain entrance to a tight-knit alumni group.

You'll also walk away with customized action steps to let you take your consulting business to the next level.

Seats are very limited. Click here to learn more about the curriculum and how to register

This is an actual email from of one of our students:

Hello Again,

Here's what I've experienced over the past 4 weeks since taking the course:

1. In the last week I've been able to take two of my "do work once a year" clients into a monthly retainer relationships which will bring in an additional $20,000+ revenue annually.

2. Changed my estimating process from time & materials to value-based, fixed bids (with a couple clauses mitigating the risk of scope creeps). For example, projects I was estimating at $5,000ish are now closer to $8,000ish, and prospect clients are biting just as hard... harder actually. Communicating my companies value has completely changed our current & new clients eyes are willing to pay for any given product. If you're after hard data, two new clients are in the door grossing an additional $6,200 above what I originally would have grossed... and are both interested ongoing retainers :)

3. I'm planning a workshop based on Brennan's advice geared towards How to get new clients from your website scheduled for the end of January. This is an exclusive event catered to our Oil & Gas clients and their extended networks only. Our dev team is hyper busy while the web team is only booked until the end of February, so it's time to fill our web design/dev pipeline. Once this event passes, I'll keep everyone posted on what comes from it.

This isn't everything, just a few of the bigger notable successes I've experienced. I'd love to hear how your businesses are doing, growing, alongside giving back to Brennan re: measurable outcomes from this wicked awesome course!

Tata for now,
Kevin

Redis on Rails - RedDotRubyConf 2012

This past weekend I had the pleasure of delivering a wide-ranging talk in Singapore about using Redis as a complement to your main relational database. It was essentially a much enhanced redo of my RailsConf 2012 talk of the same name. The challenge of covering this topic effectively is that Redis is quite popular so at a single-track conference such as RedDotRubyConf, I was sure the audience would include many people that are already using Redis in production. For that reason, I cut down on the introductory material and dove into aspects of Redis, related libraries and programming techniques that I hoped would be of use to as much of the audience as possible. Apparently that strategy worked, because I was happy to get a lot of positive feedback from almost everyone at the conference.

The slides below are not particularly useful without the associated talk material, especially since I spent most of the time inside of the sample app doing live coding and code walkthroughs with explanations. However, the slides do provide you with pointers to a number of different libraries that are of definite use to you if you're using Redis to complement your relational database. I have every intention of expounding on this topic here on this blog since the technique has been very useful to me in development of DueProps. With that said, here are my slides. Enjoy.

Redis on Rails (RedDotRubyConf 2012)

View more presentations from Obie Fernandez.

The Rails Dilemma

This is a guest post by Rusty Zarse CTO of Search Discovery, spurred by a series of email conversations that we had regarding the difficulty of finding experienced Rails talent. Rusty leads the Atlanta iOS Developers meetup and is one of the better known technologists in our city.

Where'd Every RoR Go?

“Rails is hot,” ain’t no headline today. Five years ago, Ruby on Rails was an underdog, the somebody to watch, the next big thing. It's not news that the Rails community continues evolving and growing while its members do a good job protecting the integrity and quality of the platform. Rails 4 is visible on the horizon and looks better than ever. The growth of the Rails community worldwide appears to be relentless, but there's a dark underside to that growth that does not get enough attention: In terms of sheer numbers, there just doesn't appear to be enough Rails developers to properly serve the needs of the market.

Technical organizations (particularly at the CTO and Director level that I inhabit) are now faced with a stark decision of choosing the Rails platform on its virtues or reluctantly giving the nod to another technology that carries less staffing risk.

On the face of it, people might think that this situation is good for Rails developers because it means that they continue commanding astronomical billable rates, higher quality coding practices and standards for their professional ecosystem and the aura of elite superstars. But Rails remains a community-driven platform and so it's up to the community itself to identify the needs of the market and identify what can be done for our overall growth to continue to flourish.

Attracting Rails Talent

Our core product at SearchDiscovery does things that truly push the envelope. There's a lot of work remaining to be done, but we feel that it already does what nothing else in the world can do. We owe a lot to the exceptional genius of our Hashrocket team and the wizardry of the lead developer they provided to us. During my career I've led many projects and never seen a product reach this level of complexity without falling apart due to compromises and shortcuts made along the way. I attribute our success in no small part to the principles and practices that Rails embodies. It is the motivation that I had for choosing Ruby on Rails as our web development platform to begin with and continues to provide a level of quality and productivity that I believe is unmatchable.

Our dilemma is that in over 3 months of arduous searching, we have not been able to find even a single Rubyist in Atlanta interested in joining our team. I'm not talking about having to turn down interested applicants; I'm talking about not having any interested applicants to begin with.

Now we have new products in the pipeline and our CEO is pushing to choose an alternative platform. Some of us know PHP and I personally know .NET. My experience with PHP is that its a great hacky tool to tweak wordpress and everything else just becomes spaghetti soup. Microsoft .NET is the platform of choice for developers who like to write the same oil tanker full of plumbing code over and over again just to show how great they are at doing things "better" than everyone else. Here in Atlanta, a common alternative to Rails is .NET, given the large Microsoft contingent we have in town. In my opinion, .NET doesn't deliver quickly enough and PHP inevitably becomes a maintenance nightmare.

Why on earth would we consider switching off Rails? The painful truth is that we need a team of professionals more than we need the best technology. We don't even need to hire an entire army of engineers immediately. We're specifically looking to fill at least one senior position so that this individual can cultivate Ruby on Rails talent within our walls. Our long-term goal is to become that company everyone in Atlanta wants to work at. We admire companies who posses an organic energy and self-managed excellence within their development team and we're willing to invest the capital needed to get there. I feel  that we have the professional atmosphere and culture that would be attractive to Rails professionals, but where are they?

Rails in Atlanta

Obviously, timing is everything. I've tapped the local user group community and will continue to do so, but so far have not seen much interest in the position. When I do connect with a local Atlanta Rails expert, often the professional courteousness is not reciprocated. I don't want to complain about specific people, but c'mon it just isn't necessary to be rude when someone asks if you are available. Clearly I'm trying to recruit someone, but I'm a CTO not a recruiter. Is politeness too much to ask for? Most technical people in Atlanta are nice and as helpful but there are a handful of dudes with serious reputations that apparently forget that we're all in this together. Their dismissive attitudes are toxic to non programmers who just want to run a business.

Worse, these bad attitudes get back to my bosses. I can argue all day about the gazillion benefits that using Rails brings to the table, but I can’t argue against the facts of our recruiting problem!  

A Plea to the Community

I wrote this post at Obie's request when I asked him for advice. I'd failed to consider that this is more than just my problem, more than just a hiring problem: It's a Rails community concern. The Rails platform is not bleeding edge anymore. It's proven, mature, reliable, amazing and a proper choice for just about any web development problem domain you might encounter. I don't know what the solution is, but I do know that we need to ensure that it continues to be the platform of choice for innovation.  We’re committed enough in the concept to put our money where our mouth is.

What do you think? Is this actually a community problem? Let's get a greater dialogue going.

Seeking iOS Expert

I'm so dumb sometimes. I was just in the kitchen making myself a sandwich and it hit me why I have such a mental block about hiring anyone to do remote iOS development for me: I don't know anything about it! But how to get past that? I don't have time to teach myself, it would take too long and my first few projects would be crap. Too risky.

Perhaps I should follow my own advice on the subject? D'oh! What I really need is an expert to come pair with me on building the iOS version of DueProps at my location.

The way I see it that buys me getting:

• past the initial learning curve of iOS
• an early version of the actual software that I'm happy with
• more than a prayer of being able to maintain the thing myself afterwards

Now I just need to find my expert. Please email me if you are an expert iOS developer and willing to take a short-term contract (approx 1 week) onsite with me in Atlanta at DueProps HQ. Travel expenses covered and hourly rate commensurate with your experience level.

Alternatively, I'm also willing to barter time (and still pay for your travel expenses to my location). Meaning, if you are an iOS developer that needs help getting a Rails webapp up and running, I can trade my time for yours in exchange for a full or partial reduction in your rate.

Forced to disable Firefox Inspect Element due to muscle memory

It's amazing how much we take for granted certain little tasks that we do so often they become muscle memory. The latest powerful example of that fact for me has been the annoyance provoked by the addition of a native Inspect Element option to the Firefox 10 context menu, exactly where Firebug's Inspect Element used to reside.

If you had asked me last week how many times I hit inspect element in a given day, I might have guessed a dozen or so... Ha! Turns out I do it more like hundreds of times a day! And you build serious muscle memory when you do something so often. Yesterday, despite repeatedly making mental notes of the fact that I needed to move my pointer 1 more menu item down the list to the "Inspect Element with Firebug" item, I would just forget. Over, and over, and over again. Sometimes 30 seconds apart. To the point of crying out in frustration.

Twitter / @obie: Just accidentally clicked ... via kwout

Of course, you can turn off that menu item using Firefox's about:config screen, which I suspected was possible but had resisted researching based on, well, based on I don't know what, some perveted sense of principle that I should be able to learn something so simple! Still, major props to Jared Habeck:

Twitter / @smotchkkiss: @obie about:config, devtoo ... via kwout

So the remarkable part of this experience was realizing just how ingrained that particular operation was that no matter how hard I tried, occasionally even sometimes when I was purposely thinking about "ok self, remember to click Inspect Element with Firefox" MY FINGER STILL DID THE WRONG THING!

Crazy. As a sidenote, I've tried the Safari and Chrome's inspector modules and they don't even come close to competing with Firebug. I don't use Firefox for anything else other than development, which has the convenient side effect of letting me CMD-Tab over to Chrome for everything else that you browse for during development, and then back to Firefox when I'm ready to keep working. It's a nice little workflow hack IMO. Anyone else do something similar?

Can I Find an Agile, Design-Savvy iPhone Developer?

UPDATE: I realized that my approach to this problem was all wrong so I deleted this post. See my new post Seeking iOS Expert for more information.

Hiring Me As a Consultant / Part-time CTO

(Updated July 27, 2012)

My primary offering is honest and experienced advice. If you've followed me for awhile, then you know what my areas of expertise are:

• Growing a consulting operation from scratch
• Leadership of web development teams
• Adoption of Agile and Lean Startup techniques
• Ruby on Rails-related technology (I can pair-program with you or your team)

Hiring me as a consultant is really easy. You may purchase my time at a reasonable hourly rate, which fluctuates based on my workload and is negotiable based on the length of the commitment. A couple of hours will have a premium rate, but if you need more than that then I'm willing to be very reasonable and charge around what you would expect to pay a shop like Hashrocket for a developer.

You should also know that I will not try to sell you anything or anyone else if you hire me. I have no plans of building another Hashrocket. If you're interested in booking my time over the course of several months we can work out a retainer agreement similar to how you would retain a lawyer or accountant.

To book my time, we just need to have a preliminary conversation about what you want to achieve by hiring me. I don't have problems with signing an NDA, if you require it. Once we officially book our billable time together and execute a simple consulting agreement, I’ll get whatever I need from you to prepare and get started.

My email is [email protected] I can help you win.

--

Hat tip to one of my heroes, Mr. Tincup, for inspring me to describe this offer in this way. You should hire him for marketing advice.

where are un-ordered tools?

While digging up some stuff on my old blog I found this post: The new dynamics of strategy: Sense-making in a complex and complicated world that I published back in December of 2004. Almost 7 years later and I'm not so sure that we've made progress with real-world tools leveraging this research.

The authors coin the term un-order in much the same sense as undead, to refer to "emergent order". Not an absence of order, but instead the patterns that emerge from situations which undergo continual change, subject to chaotic influences. This is of particular interest to the agile community and particularly XPers, whose motto isembrace change, which explains why it seems to be getting a lot of attention from agile bloggers. I see a window of opportunity opening up for a slew of open-source projects that build on this information. While reading Wisdom of Crowds, I got the strong impression that a far-flung organization (such as the the consulting company that I work for), will benefit by moving agressively on these knowledge management advances. For instance, devise a polling tool with differing modes that match the various identities that we live on a day-to-day basis, namely: consultant, coach, manager, member of our client team, member of the parent company. Within each of these modes, features that allow referendums and continual feedback for all levels: personal, team and organization.

Maybe Asana is a step in the right direction? I've been using it with my new startup as our project management tool for everything that doesn't fit into Pivotal Tracker. Liking it so far.

The Next Big Leap

In my view, FITness, Cucumber and other acceptance test frameworks represented a big leap in software development effectiveness because they allow coders to get intimately involved with (and in some cases replace) Product Management/QA roles. Extreme Programming has developers working directly with product owners and capturing their requirements as "acceptance criteria" on story cards. Eventually, the desire to automate acceptance testing and best practices for how to express acceptance criteria led to GIVEN-WHEN-THEN support baked into actual testing frameworks such as Cucumber.

That's okay, but it's not nearly enough. Let's talk about how the next big leap in effectiveness is going to happen. Assume the following story is true:

• Given a specification for a feature that has not been demonstrably linked to business value,
• When a developer works to deliver an implementation of that feature,
• Then the worth of the implementation work is indeterminate until some future time when its business value is validated

Most feature requests that I've ever worked with in the early stages of a project, are ideations of the product visionary/designers/entrepreneur, based on intuition rather than customer feedback. And that's perfectly normal and acceptable to me. The more innovative a creation, the more work you usually have to do before you put it out in front of customers and get meaningful feedback. But the impact of those features on key business metrics are assumed, if it gets any explicit thought at all.

Aside: As for the implementation of those feature requests, I'm going to assume that being faithful to the specification is implicit, as it should be when we're talking about professional programmers. (Not working with professional programmers? GIGO)

Given those assumptions, I think what myself and others have realized as a problem with so-called "high-ceremony" adherence to methodologies such as BDD (Behavior-Driven Development) is that by obsessing over correctness of the implementation as faithful to the spec, it becomes easy to lose sight of the true value of our work: to deliver business value, as measured by key business metrics. We may obsess over crafting pristine, bulletproof, maintainable code, and yet its worth is indeterminate at best. And why, as developers, would we be satisfied with that!

"Measure as much as you can - no feedback == no direction"  Hugo Rodger-Brown

How can we establish that our work is not a waste of time? One technique that I hope to work on in near future is the specification validation of business value right in my acceptance criteria as part of its test cases. Said differently, I am looking for an easy way to specify non-functional requirements as part of acceptance criteria in such a way that it is automatically tested. It would be an extension or evolution of the current BDD toolset, not a replacement. You can even use de rigeur GWT syntax:

Given the implementation of email notifications,
When 100 customer events have been processed,
Then the mean time between events metrics should improve by 30%

or better

Then the net revenue per event should improve by 30%

or best

Then the net revenue per event should increase by $100

I care more about business value than faithful adherence to a particular functional requirement. My specifications should reflect that mindset. What makes this whole approach non-trivial is the challenge of establishing credible causal relationships in my acceptance criteria, given the multi-variate nature of dozens of interleaved features in a particular application and the way that key business metrics overlay many features at once.

Despite the challenges, I think the concept I'm describing is the next big leap. The first challenge is to get people talking about it and definition of goals. The second is to design a methodology and technical framework for accomplishing those goals.

What do we call the whole thing? Business-Driven Development? (no) What do we call the specs? Can you write specs against metrics in a tool such as KissMetrics? It's hard (or at least has been for me) to figure out what metrics I need until after I've written the features that yield measurement data used to calculate those metrics. How do I fix or at least improve that workflow? How do I describe the discipline needed to think of the metrics prior to specifying a feature?

Right now all I'm trying to do via this blog post and my public comments is to start a dialogue. I'm not trying to make any blanket statements about the correctness of BDD/TDD or testing in general, just pointing out that there's lots of room outside of that particular box for innovation.

As for my comments at RailsConf and Goruco, it seems to me that at a startup that has not achieved market fit, it's wrong to spend much time ensuring that a given piece of software matches its functional specification. (Specs that often won't exist, because the same person specifying the functionality is the person writing the code, in which case I'm saying don't bother writing the specs. Just "cowboy" it and do a complete rewrite later if it proves necessary.) Once you have your MVP, write specs for how particular code changes will impact key business metrics. Regressions will probably fail to improve key business metrics.

The question is not "should I test (or spec)", but rather it is "what should I test?" As an industry, to the extent that TDD/BDD has caught on at all, I don't think we're testing the right things, with our emphasis on correctness of implementation. When we figure out how to rigorously test for business value it's going to be the next big leap. That's a big green field waiting for all of us to play in and I want to be one of the first.

The Dark Side Beckons?

Lord Ries by Cody San

For years I've advocated a high-ceremony, test-first development methodology where use of BDD (or TDD) is sacrosanct and uncovered production code is a sin. Then I got to know Eric Ries and studied his Lean Startup stuff and got started with my own lean startup venture and over time...

Something's happening. I'm not the Agilist I should be. I want more. But I know I shouldn't.

I no longer believe in high-ceremony development practices for early-stage startups. Actually, I'm pretty sure that they're poisonous for most web startups, hence my lightning talk at Railsconf 2011. Until you are able to prove that you have a viable market, that customers will give you money for your product, you shouldn't be sinking a lot of time and money into implementation. Assuming you are a competent Rails developer, you should be able to hack out features and take on quite a bit of technical debt to build throwaway proof-of-concept versions of your product. I'm pretty much advocating construction of large "spike solutions" except that unlike the traditional XP definition, the problem you're trying to solve is the problem of finding your market fit. It has nothing to do with the technology.

Also, we are commonly told that spikes (aka prototype systems) are not meant for production and should be thrown away. I think that advice is very dependent on the skills of the people writing the prototype system. If they are experienced developers, they're going to inherently know a lot of the application patterns that should be used and the amount of technical debt introduced will be low enough to feel comfortable with the app in production.

Some caveats:

• I'm specifically talking about typical web-based applications built with Rails where nobody is going to die if you occasionally get a 500 error on an edge case. Use continuous deployment so that you're comfortable that you can turn around code improvements and bug fixes almost immediately.
• Use TDD to "discover" the design of parts of the system that are unfamiliar to you. This primarily applies to unit testing
• By all means have some integration-level specs that test the "happy path" through your system so that you don't inadvertently break your entire app. AKA "smoke tests"

Early on in the startup process, it's much more important to be testing against business metrics than anything having to do with code. One of the most thought-provoking pieces of advice I've heard lately came from Hiten Shah of KISSmetrics who told the latest LSM NYC crowd to consider the effects of a feature of key business metrics to be the acceptance criteria for that feature.

In other words, before you implement a feature, you should have an assumption that tells you what the effect is going to be: higher click-through, engagement, satisfaction ratings, etc. This results in an acceptance test that is time-shifted; you won't know the results until you deploy. I believe this is fertile ground for technical innovation. While there are plenty of frameworks that simplify AB testing and real-time monitoring, I don't believe there exists anything along the lines of Cucumber that involves developers in cultivating a mindset of provable business value. David Chelimsky and I joked around that perhaps such a tool should be called Squash.

One of the natural questions that arises from this line of thinking is: When am I no longer an early-stage startup? The implication being that at some point, you know enough about your market fit and product requirements that you can transition into what I've been calling high-ceremony development practices.

I don't have the answer to that question. I suspect that the size of the development team has a lot to do with how you'll want to answer that question for your own effort, because multiple workstreams on a single codebase has a tendency to skyrocket technical debt. All of the above is premised on your ability to keep technical debt in control -- I have no doubt that irresponsible dependence on technical debt will kill your company just as effectively as relying too much on financial debt -- I've seen it happen.

The bottom line is that once again I find myself rejecting dogmatic adherence to a particular mindset. And contrary to my initial metaphor, that doesn't seem evil at all. Maybe I got it backwards and the high-ceremony Agilistas are the dark side, and the lean startup hackers are the Rebel Alliance... what do you think?