The discussion

The room discussed everything from lean startups, doing a startup with venture investment, working for large businesses, working for medium- and small-businesses, and the difference between “working at a startup” vs. “being an entrepreneur”.

I went in with an agenda: I love the idea that developers should team up and funnel their “excess passion” into side projects, taking no outside investment, and growing these projects enough to allow them to quit their day jobs eventually.

My friend from the Brandery, Dave Knox, asked me to share their “Brandsmith” concept that they’re rolling out to help get more developers involved at the Brandery this summer. The response from the room of successful developers was quite unanimous: none of the experienced developers in the room would be interested in an arrangement to work full-time for four months for $5,000 for the upcoming Brandery class.

The group showed a conservative side in several areas:

• Many aren’t really interested in taking a career risk by joining a startup for sweat equity. Angel & early-stage VC funded environments don’t promote good work/life balance, which experienced developers with families value greatly. Even though corporate jobs can be frustrating at times - working with people who don’t care very much, or aren’t highly skilled, the steady paycheck is compelling.
• Some, including me, were against the entire concept of accepting outside investment, instead favoring ideas that can be executed with spare time, inline with DHH’s distaste for “swing for the fences” business models.
• Some, including Gaslight Software co-founder Doug Alcorn are comfortable consulting and the risk of finding clients versus the make or break of a single product.
• Bill Barnett, another Gaslight Software co-founder, advocated the less than developer friendly idea of heavy marketing first to vette the business idea and follow with minimal development. Once you have a market tested idea, you then invest in the functionality demanded by your customers.

However, some of the meeting attendees are working for startups now, where they work with people who are excited and energetic.

After listening to the room, Kevin Rohrbaugh took a stance that, based on what he heard, if he was going to do a startup, he’d probably do it in the Bay Area, because the likihood of finding a smart co-founder is greater there. I took the stance that I’d do it in Cincinnati, because there are not dominant companies like Google, Apple, and hundreds of others with which to battle for top talent.

A big consensus at the end was that the members of the Cincinnati Ruby Brigade really value community. Working and learning from a small team where their opinions get heard, where they can work with people who are better than them that they can learn from. And the typical incubator startup in Cincinnati doesn’t seem to provide this sort of opportunity.

My answer

Ruby developers are spoiled, in a good way. Our language and development practices are centered on developer happiness. When our code is bad, we call it a “code smell”. When our work environment is bad, we view that as a “work smell” and will not tolerate it for long. Life is too short.

Cincinnati needs more of our experienced developers to start successful web product companies where we can create a work enviroment that works for us. These companies would grow into a core group of companies that will attract talent, serve as a role model for startups, and prove that it can be done in Cincinnati. These developer-founders will create developer-friendly work environments, focusing on product quality and customer service (let’s call it the Apple model) over marketing and salesmanship. A recent article on Forbes.com supports my answer – Great CEOs Must be Either Technical or Financial.

I also think it’s important for everyone in the startup to dabble in all aspects of the business, to create a better understanding of the work others are doing. In other words, “idea guys” should spend time to learn HTML. The developers should man the customer support queue and talk to prospective customers.

We need companies where young Rails developers can get a couple of years of real-world experience in a good work environemnt, then split off and do their own thing, creating a greater demand for technical talent.

What’s next?

I’m grateful for the efforts that CincyTech, Brandery, and other startup-oriented groups have made. They are moving the needle in the right direction.

The members of the Cincinnati Ruby Brigade looks forward to ongoing engagement with the creative & marketing communities on these issues, for the benefit of everyone involved in the Cincinnati web tech industry.

• The upcoming QCMerge web conference can provide a forum where an expert panel can discuss these issues. I would thoroughly enjoy sitting on the panel. “If you think can’t start a web-based business here in Cincy, I challenge to you come to QCMerge.”
• We invite Laura Baverman to continue digging into these issues. Let’s setup some time to get opinionated people on these subjects together to further the discussions.
• The developers of Cincinnati.rb should lead by example, and practice what we preach. We will pull together a “mastermind” subgroup to discuss product ideas, and spend time actually building stuff rather than talking and doing code katas :)
• Brandery is a great start, but it isn’t enough. It’s focused on investment-seeking B2C and B2B2C models. There are huge opportunities in B2B and SaaS business models, as well as unfunded “bootstrap” efforts.
• We need more success stories in the Cincinnati tech startup scene to inspire and attract developers.
• Everyone with core skills (marketing, creative, technical) needs to recognize when they are taking non-productive attitudes towards their non-primary communities. It takes expertise in all areas of business to be successful.

Can Cincinnati be a tech hub?

Are we pigeon-holed as a “marketing” and “branding” city? Can we make the leap to becoming a legitimate, respected “tech” startup town? In some ways we’re trailing smaller markets in Ohio, such as the Youngstown Business Incubator which has a strong portfolio of growing tech companies, and 300 people working on a downtown campus that forms a nucleus for growth.

The future: software shortage

I listened recently to an episode of “The Web Ahead” with Jen Simmons where she talked with Luke Wroblewski about the future of the web. Citing the rapid growth of mobile, and the fact that more than 50% of adults in the U.S. now have a computer in their pocket, that over the next five years the demand for software will explode, and that every company is becoming more and more a software company.

Software developers, especially those in emerging languages, are in a very good position.

Ultimately, I agree with the conclusion of the article, that the market for smart developers willing to work for sweat equity in Cincinnati has far more demand than supply. Even with focused effort, there are numerous forces that may cause the situation to get worse, rather than better.

• Ruby 1.9.2p0
• Rails 3.0.1
• Backbone.js 0.2.0
• jQuery 1.4.3

Start a new project

rvm use 1.9.2
cd Documents/work
rails new backbone-crm
cd backbone-crm/
rm public/javascripts/*
curl -L http://code.jquery.com/jquery-1.4.3.min.js > public/javascripts/jquery.js
curl -L http://www.json.org/json2.js > public/javascripts/json2.js
curl -L http://documentcloud.github.com/underscore/underscore-min.js > public/javascripts/underscore.js
curl -L http://documentcloud.github.com/backbone/backbone.js > public/javascripts/backbone.js

Ensure you’re setup

Delete the index.html and replace with this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<!DOCTYPE html>
<html>
  <head>
    <title>Backbone test</title>
    <meta http-equiv="content-type" content="text/html;charset=UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="chrome=1">

    <script src="/javascripts/jquery.js"></script>
    <script src="/javascripts/json2.js"></script>
    <script src="/javascripts/underscore.js"></script>
    <script src="/javascripts/backbone.js"></script>
    <script type="text/javascript">
      var object = {};

      _.extend(object, Backbone.Events);

      object.bind("alert", function(msg) {
        alert("Triggered " + msg);
      });

      object.trigger("alert", "an event");
    </script>
  </head>
  <body>
    <h1>Backbone CMS</h1>
  </body>
</html>

We are simply creating an empty object, extending it with Backbone.Events, bind an event called “alert” to it, then trigger that event. Not too exciting, but we are up and running with Backbone.js.

But that doesn’t help us build an app. So let’s nuke that code, but first, let’s get the contacts resource built.

rails generate resource Contact first_name:string last_name:string email:string
rake db:migrate

Fill out the controller:

1
2
3
4
5
6
7
8
9
10
11

class ContactsController < ApplicationController

  respond_to :json

  def create
    attributes = ActiveSupport::JSON.decode(params[:model])
    @contact = Contact.create(attributes)
    respond_with(@contact, :location => contacts_url)
  end

end

And then let’s switch out the javascript on the index.html with this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<script type="text/javascript">

$(function(){

  var Contacts = Backbone.Collection.extend({
    url: '/contacts'
  });

  var contacts = new Contacts();

  contacts.create({
    first_name: "John",
    last_name: "Doe"
  });

});

</script>

Reload the page, and open up Firebug and you’ll see the message got through to the Rails controller, and check the database, the data should be there.

Five Principles

• Entrepreneurs are everywhere—not just in startups, big companies need them too.
• Entrepreneurship is management—you’re building an organization in an environment of extreme uncertainty.
• Validated learning—the primary reason for existence for a startup is to learn. The best way to do that is through scientific experiments that test each element of the vision.
• Build-measure-learn—ideas are built into products which are measured generating data that we learn from and form new ideas, including whether to pivot or persevere. Through this loop learning informs the vision, and vision drives the learning.
• Innovation accounting—establish the baseline, tune the engine, pivot or perservere. Cohort analysis is important concept here, because you don’t get fooled by the snowball effect of traditional metrics. Good metrics need to be actionable, accessible, and auditable. Use A/B split testing once the baseline is established to improve the ratios.

Key insights

• Any work that generating value (providing benefit to the customer) is waste. In the context of a startup, any work that isn’t directly linked to a learning experiment is waste.
• The two most important assumptions entrepreneurs make are the value hypothesis and the growth hypothesis.
  • Value: will the product or service really deliver value?
  • Growth: how will customers find the product or service?
• Concierge MVP—operate the product with people doing the work that computers will eventually do, to test the viability of the whole concept before building a lot of software.
• An experiment is a product. And first products should not be built to be perfect. Their role is to generate data that we can learn from.
• Learn the difference between dangerous vanity metrics vs. nuts-and-bolts actionable metrics.
• Keep batches small—strive to keep delivery as close to continuous as possible.

Four questions before starting something

• Do customers recognize they have the problem we’re trying to solve?
• If there was a solution, would they buy it?
• Would they buy it from us?
• Can we build a solution to that problem? (The common tendency is to jump right to this one.)

Types of pivots

• Zoom-in Pivot—a single feature becomes the product.
• Zoom-out Pivot—what was considered the whole product becomes a single feature of a larger product.
• Customer Segment Pivot—the product solves problems for a different customer than originally conceived.
• Customer Need Pivot—we learn about the customer, and that they have bigger problems that we can solve, which may require tweaks to the product or perhaps a different product altogether.
• Platform Pivot—change from an application to a platform or vice versa.
• Business Architecture Pivot—switch from high volume, low margin to low volume, high margin, or the reverse.
• Value Capture Pivot—changes to revenue or monitization model.
• Engine of Growth Pivot—change in growth strategy: viral, sticky, paid.
• Channel Pivot—change in sales or distribution, where or how it’s sold or bought.
• Technology Pivot—change to capture superior cost and/or performance.

Four primary ways past customers drive our growth

• Word of mouth
• As a side effect of product usage—others see the customer using the product.
• Funded advertising
• Repeat purchase or use

Three engines of growth

• Sticky—product is addicting to use.
• Viral—people tell people about it.
• Paid—buy ads that generate customer acquisition.

How to nurture disruptive innovation

• Provide scarce but secure resources
• Give independent development authority
• Embed a personal stake in the outcome
• Protect the parent organization if it’s not used to an experimental culture

Signup

1. Visited the Google APIs console and turned on the Google Prediction API.
2. Needed to sign up for Google Storage account - this seemed discouraging, since it was a Google Docs waiting list, and I figured I’d be dead in the water tonight, maybe waiting forever. I wrote as persuasive an application as I could :)
3. I noticed that they metioned they were going to turn on billing in early 2011, pricing was only $10/month. From the console, there was a “billing” link that I could enable. So I decided to enable billing, hoping that would help with Google Storage account issue.
4. Checking my email, I had already been emailed a Google Storage invite. Not sure if it was automatic or my application caught their eye (I suspect the former) but the hurdle was jumped. Woot!

Hello Prediction

I followed the hello world tutorial that Google provides. I won’t cut-and-paste all the steps, since the tutorial is well-written, but here are some notes from the process.

I needed to install gsutil - pretty easy; instructions here.

I needed to create a Google Storage access key.

Can’t use bucket ‘examplebucket’. I used ‘play-prediction’ and it allowed me to create bucket and then I copied the file up using gsutil cp ./language_id.txt gs://play-prediction/prediction_models/languages.

Save your Google API Access Key (found on the API Console through the “API Access” link on the left, at the bottom of the page “Simple API Access”, to file googlekey.

I copied oauth-train.sh, oauth-check-training.sh, and oauth-predict.sh to my local project folder, and chmod 755 on the to make them executable.

I was able to train using ./oauth-train.sh play-prediction/prediction_models/languages command.

./oauth-check-training.sh play-prediction/prediction_models/languages yielded the expected result, training accuracy was 0.95.

./oauth-predict.sh play-prediction/prediction_models/languages "\"Sitting around on a Sunday night, decided to finally take a little dive on something that’s had my eye for a while, the Google Prediction API.\"" was interpreted as English correctly.

./oauth-predict.sh play-prediction/prediction_models/languages "\"El sol se levantará mañana y quién sabe lo que traerá la marea?\"" was interpreted as Spanish correctly.

./oauth-predict.sh play-prediction/prediction_models/languages "\"La gloire est éphémère, mais l'obscurité est éternelle.\"" was interpreted as French correctly.

I noticed the engine didn’t perform as well on short phrases, to be expected.

Closing

Very cool system, took me about an hour to get through the tutorial.

Mission accomplished, Google Prediction API is much less abstract in my mind now.

• The current moment, including our current emotional and physical state.
• Our long term view of the world, which shapes what things mean to us.

If we bring this tug-of-war into our active conciousness, we can focus ourselves to towards the achievement of our goals.

We are making three decisions every moment of our life:

• What am I going to focus on? On the past? The present? The future? Myself? Others?
• What does it mean? Is it the end? Is it the beginning? Is it punishment? Is it a reward?
• What am I going to do? Give up? Move forward?

Add Heroku

First I cd to the project, which is already using git & github.

heroku create --stack bamboo-mri-1.9.2
heroku addons:add mongohq:free

Cleanup gems from beta to release

Cleaned up my Gemfile:

1
2
3
4
5
6
7
8
9

source "http://rubygems.org"
source "http://gems.github.com"

gem "rails"
gem "bson_ext"
gem "mongo_mapper"

gem "haml", "~> 3.0.2"
gem "compass", " ~> 0.10.0", :require => false

App errored because of Heroku read only file system

Googled around, found this post which had a straightforward workaround. I had a static stylesheet related to jquery-ui in my /stylesheets directory, so after some trial and error, I ended up modifying /config/compass.rb:

css_dir = "tmp/stylesheets/compiled"

and added this file: config/initializers/stylesheets.rb

1
2
3
4
5
6
7
8
9
10
11

require 'fileutils'
FileUtils.mkdir_p(Rails.root.join("tmp", "stylesheets"))

Sass::Plugin.on_updating_stylesheet do |template, css|
  puts "Compiling #{template} to #{css}"
end

Rails.configuration.middleware.insert_before(
  'Rack::Sendfile', 'Rack::Static',
  :urls => ['/stylesheets/compiled'],
  :root => "#{Rails.root}/tmp")

I also had some cleanup due to a change in format of box-shadow in Compass.

Add custom domain

Finally I just needed to switchover the DNS, and add custom domain to heroku:

heroku addons:add custom_domains
heroku domains:add incentimove.com

All done, and I get to shut down what was supposed to be a short-lived $30/mo. Linode VPS :)

Thanks Lincoln for your helpful blog post and to Heroku and MongoHQ for your kick ass products.

Why do it?

We know we’re for real, but how do we communicate that quickly and effectively?

I’ve been pushing us to just show the numbers… while we’re always pushing for improvement, on the whole I’m proud of our activity and just showing visitors our numbers in real time, I believe, should be convincing. Here’s a screenshot of the finished product:

You can visit the site (during business hours is best) to see the stats bar in action.

The technical nitty-gritty

We knew that we’d end up with people sitting and watching the stats increment, so we wanted to make sure the request was fast. We use Resque as our background processing system, and along with it came Redis. We basically took the ideas in Resque’s stat module and implemented a very fast way to get the counters from our system.

However, the data is actually coming from a different Rails app than our marketing site, so we rolled a simple little jsonp service. Here’s the controller:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

module Api::V1
  class StatsController < BaseController
    caches_action :index, :expires_in => 10.seconds

    def index
      @stats = Board::Stat::DAILY_STATS.inject({}) do |h, stat|
        h[stat] = Board::Stat[stat]
        h["#{stat}_today"] = Board::Stat["#{stat}_today"]
        h
      end

      render_json(@stats)
    end
  end
end

In the destination page, we drop in a simple div that is filled in with javascript:

1
2

<div id="stats" class="hidden wide bordered">
</div>

The controller response was quick, but we were getting so many hits to it, we had to optimize further.

We did two 2 things:

• Define an explicit jsonpCallback property. It turned out that the way we had jsonp setup, it was generating a unique callback string with each request in the URL, effectively nullifying our cache of 10 seconds.
• We found that requests were happing around the clock, people were leaving our page up in a browser window. A quick check on ($("html").is(".blurred")) did the trick—we stopped updating the stats if the browser window wasn’t active.

The refined javascript:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105

$.fn.boardStatisticize = function() {
  var stat_box = this;

  $.ajax({
    cache: true,
    dataType: "jsonp",
    jsonpCallback: "statsicizer",
    success: handleResponse,
    url: "https://board.recruitmilitary.com/api/v1/stats"
  });

  function handleResponse(data) {
    var stats = data;
    var displayed_stats = ["active_jobs", "job_views",
      "candidate_accounts", "candidate_profile_views"];

    for (i = 0; i < displayed_stats.length; i++) {
      insertStat(displayed_stats[i], stats[displayed_stats[i]]);
    }

    function insertStat(key, value) {
      $("<div></div>")
        .addClass("block")
        .append(blockLabel())
        .append(totalCount())
        .append(todayCount())
        .attr("id", key)
        .css("width", (stat_box.innerWidth() / 4) - 22)
        .appendTo(stat_box);

      function blockLabel() {
        return $("<h3></h3>")
          .addClass("label")
          .text(BR.board_stat_labels[key]);
      }

      function totalCount() {
        return $("<span></span>")
          .addClass("total-count")
          .data("count", value)
          .text(commafyNumber(value));
      }

      function todayCount() {
        return $("<span></span>")
          .addClass("today-count")
          .data("count", stats[key + "_today"])
          .text("+" + commafyNumber(stats[key + "_today"]) + " today");
      }
    }

    $("#candidate-form .job-count")
      .text(commafyNumber(stats["active_jobs"]));

    stat_box.removeClass("hidden");
  }

  window.setInterval("updateBoardStats()", 10000);

  return this;
};

function updateBoardStats() {
  if ($("html").is(".blurred"))
    return;

  $.ajax({
    cache: true,
    dataType: "jsonp",
    jsonpCallback: "statsicizer",
    success: handleResponse,
    url: "https://board.recruitmilitary.com/api/v1/stats"
  });

  function handleResponse(data) {
    var stats = data;
    var displayed_stats = ["active_jobs", "job_views",
      "candidate_accounts", "candidate_profile_views"];

    for (i = 0; i < displayed_stats.length; i++) {
      updateStat(displayed_stats[i], stats[displayed_stats[i]]);
    }

    function updateStat(key, value) {
      var total = $("#" + key + " .total-count");
      var today = $("#" + key + " .today-count");

      if (total.data("count") !== value) {
        total
          .addClass("updated")
          .data("count", value)
          .text(commafyNumber(value))
          .switchClass("updated", "", 5000);
        today
          .addClass("updated")
          .data("count", stats[key + "_today"])
          .text("+" + commafyNumber(stats[key + "_today"]) + " today")
          .switchClass("updated", "", 5000);
      }
    }

    $("#candidate-form .job-count")
      .text(commafyNumber(stats["active_jobs"]));
  }
}

Great work from Michael and Jason on this, we continue to get daily complements on our new home page, and I know this feature is central to the great experience.

One of the managers @ RecruitMilitary forwarded me a great sample from Get Satisfaction…

Insidesales.com CRM is a very ambitious product. It has a LOT of functionality. Unfortunately it’s got too many flaws for me to recommend it. I’m posting this review, as a current customer, as incentive for them to improve the product, in particular, my issues with it.

Sales Process

Their sales process was impeccable, and the rep we got was very sharp and helpful (thank you, Ben!). Not too pushy, let us evaluate on our own time.

I was a little bit concerned by the apparent lack of polish on the app, but assumed the internals were strong, that they just didn’t have a “great” UI design lead, which I can forgive. The price was significantly lower than Salesforce, so I let it go.

We knew we’d be heavy user of SOAP API, we reviewed docs and had some concerns there, but not enough to kill the deal.

Implementation

Weaknesses in the software begin to manifest.

• Lead import would occasionally lock the entire server (reps on phone affected.) They did respond quickly to resolve this, but it really shouldn’t be allowed to happen.
• We were given API docs for 2.0, SOAP endpoints for 1.6, documentation was very sparse. Once we finally figured that out (I had to get sales rep back involved to give me a contact that could understand our problem.) Once we got 2.0 endpoints, the code was untested, we had at least a half-dozen back and forths trying to just get the API to work as advertised. This cost us weeks.
• Training was weak, and after toying around with the product for a few weeks I actually corrected the trainer about how converting leads to Account/Contact works.

Production - Current State

Note: I’ll adjust this section as new issues are uncovered and old issues resolved

Pros:

• Dialer works - our sales reps are more productive.
• Dialer initiatives are very flexible and work great.
• Total talk time reports are very good management tools.
• Support team is responsive.

Cons:

Support:

• Support tickets disappear from our UI when they resolve them, and we can’t see progress on tickets. I’d love to see them move to an off-the-shelf support system like Tender or ZenDesk, losing their homegrown system.
• Support team’s technical knowledge doesn’t go very deep, and I had to go outside the process to get my urgent API issues worked on. Support has acknowledged that their exposure to API issues is limited, but I’d like to see a smooth escalation process on their end for these issues.

Accounts:

• Duplicate accounts cannot be merged! Contacts have to be moved manually. (Even though there is a “Merge Accounts” button.)
• A user asking “sales administrator” can’t convert leads without it changing them to the owner. We have significant cleanup to do after import, we’ll have to login as each user to avoid extra steps.
• Can’t convert a lead that has an existing account without duplicating the account.

Mass email:

• Mass email process is a bit backwards - must create a template then can email all contacts in an account, but it doesn’t provide any verification that the content merged in well before saying “OK, scheduled to send.”
• I couldn’t find anywhere to see a list of send jobs pending or completed.

General:

• URLs are not canonical - when looking at a lead URL is something like https://recruitmilitary.insidesales.com/leads/lead?itemOffset=0 where it should be https://recruitmilitary.insidesales.com/leads/{id} - something that can be cut and pasted + shared
• App is somewhat ugly - lots of different font sizes, kludgy UI in spots
• Application is optimized for Internet Explorer; some things don’t work in Firefox
  • Pages don’t fit the browser - bottom scrollbar often when doesn’t need to be there (maybe Firefox only)
  • Form designer barely works in Firefox

API & Import:

• SOAP API is very basic, not all objects fully implemented (for example, can’t import product details for a deal)
• Report (summarized) data not available in API
• API returns deleted LEAD records, no way to filter them out. We had to ask for a purge of test data.
• Account/contact import is broken, we had to import hundreds of thousands of records through individual SOAP API interactions.

Reports:

• Reports present data that contradicts other reports.
• There is a beta reporting system pasted in there, but not cohesive with other report lists.

JabberDog:

• Can’t archive past JabberDog jobs, so the dropdown continues to grow and grow.

Updates:

• In April 2011, I had a nice call with Ken Krogue regarding this blog post, and his committment to doing what it takes to win us over and convert this blog post to a positive review. I look forward to that journey, it will help both of our businesses in the long run. More to come :)

What causes Manager Developer Syndrome?

It starts with prolonged experience to the concerns of management, such as generating cash for payroll, pursuing hot deals, and taking care of important customers.

The individual is then exposed to the awesomeness of outside-in BDD/TDD testing methodology and tools, and a world where seemingly thousands of developers on Github who are “doing it the right way”, flaunting their excellent work in plain sight.

This combination of factors triggers the realization that the individual sucks and should do something about it.

What are the symptoms?

• Not refactoring. Without tests, it’s deemed just too dangerous and not enough short-term ROI. Plus there are a million other things to do, including checking your email, since it probably has accumulated 40+ emails since you decided to spend a few hours focusing on code.
• Not releasing code publicly. It’s not tested. No one will use it if it’s not tested.
• Making commits on group projects late at night, when hopefully no one is looking.

How is it treated?

• Stop the bullshit excuses, and just invest the time to finally REALLY learn and use RSpec.
• Start contributing to open source projects, even if it’s just helping to improve documentation.
• Stop adding new implementation code without tests, even in projects where there are no specs presently.
• Bonus points: Stop using TextMate and learn to use a real editor (VIM or Emacs).

This domain was previously pointed to http://rywalker.mp; Google now has old www.rywalker.com references from that era. It’s bugging me, so I want to try to clear it up in the future by having a no-www canonical URLs for this site.

Before:

<VirtualHost *:80>
  ServerName rywalker.com
  ServerAlias www.rywalker.com
  DocumentRoot /home/deploy/apps/rywalker/nesta/public
</VirtualHost>

During my research, I discovered that there is a duplicate content myth circulating, and I did wonder if Google would love me more if I wasn’t tossing duplicate content out there with my server alias.

After:

<VirtualHost *:80>
  ServerName rywalker.com
  DocumentRoot /home/deploy/apps/rywalker/nesta/public
</VirtualHost>

<VirtualHost *:80>
  ServerName www.rywalker.com
  RedirectMatch 301 ^(.*)$ http://rywalker.com$1
</VirtualHost>

Simple enough, hopefully my clarity goes rewarded by our search engine overlords. And if nothing else, I’ll be happy to see the www.rywalker.com references disappear from search results over time.

I’m working on this view:

Since we’re trying to encourage registration, I want to show certain fields, even if the user hasn’t filled out the information yet, to encourage them to complete the profile.

Here’s how a view may look without presentation pattern or helpers:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<ul class="contact-information">
  <li class="name">
    <label>Name</label>
    <b><%= @candidate.name %></b>
  </li>
  <li class="phone">
    <label>Phone</label>
    <b><%= @candidate.phone ? @candidate.phone : "Not provided" %></b>
  </li>
  <li class="work-interests">
    <label>Work Interests</label>
    <b><%=
      if @candidate.work_interests
        @candidate.work_interests.map { |wi| wi.name }.join ", ")
      else
        "None selected"
      end %></b>
  </li>
</ul>

Here’s what it can look like with them:

1
2
3
4
5

<ul class="contact-information">
  <%= profile_detail "Name", @candidate.name %>
  <%= profile_detail "Phone", @candidate.phone_text %>
  <%= profile_detail "Work Interests", @candidate.work_interest_names %>
</ul>

Presenter code:

1
2
3
4
5
6
7
8
9
10
11
12
13

class CandidatePresenter < CachingPresenter
  presents :candidate

  def phone_text
    return "Not provided" if @candidate.phone.blank?
    @candidate.phone
  end

  def future_work_interests_names
    return "None selected" if @candidate.future_work_interests.empty?
    @candidate.future_work_interests.map { |fwi| fwi.name }.join ", "
  end
end

Yes, you could build these presentation methods into the model, but that really clutters up the model. Yes, one more layer in the stack, but tossing this sort of stuff into the model really clutters it up, and ActiveRecord is already doing perhaps too much.

Helper code:

1
2
3
4
5
6
7

module CandidateDashboardHelper

  def profile_detail(label,value)
    return if value.blank? || label.blank?
    "<li class=\"#{label.downcase.dasherize}\"><label>#{label}</label><b>#{value}</b></li>"
  end
end

The libary we’re leveraging is Mutually Human’s fork of Zach Dennis’s Caching Presenter. (Hi Mark, Zach, Craig, and John!)

Yesterday I gave an hour talk at our company’s annual meeting, where I described how we’re going to tear down our monolithic legacy ASP app and replace over the next few months. In the afternoon, after thinking it through, I decided to name the collection of projects “Chaos 2010”.

In order to install a call center solution we need to replace our current phone system, so that’s project #1. InsideSales.com also has a CRM system that’s better than our homegrown system, so we’ll toss out that old system for all our sales team.

Problem is that breaks other parts of the monolithic legacy app, so we have to quickly follow that up with email marketing system work, accounting switchover from quickbooks offline to quickbooks online, launching our new job board product, building a new event management system, and then finally rebuilding all of our custom dashboard/reports that we have.

The current system has this structure:

The final system should look something like this:

We are building a list of projects in Google docs (image intentionally downsized to obfuscate details).

Each column outlines at a high level what we need to do within that project, what that project fixes, what that project breaks, and finally a list of things that remain broken after the project is complete.

The first two projects basically break a ton of stuff, then it’s six projects to try to put it back together. The end result will be that the company is in much better shape for the expected growth when the economy kicks back in.

Future Updates

I’ll report back in after we complete each project of Chaos 2010 with observations what went well and what went poorly. Wish us luck!

1. Write new feature/scenario. Autotest runs your features and finds pending steps. It remembers those scenarios.

2. Define pending steps. Each time you save, autotest reruns the pending scenarios. Watch them turn red and blue.

3. Pick a red step. Write the spec which exercises the (unwritten) implementation behind that step. Autotest sees your new red spec and remembers it.

4. Work on implementing the spec. Each time you save, autotest reruns the red spec. No need to run any features until you’re done with this. Autotest keeps you drilled down.

5. Finish implementing the spec. When the spec turns green, you’re done! Autotest pops the stack and reruns the scenarios you’re working on.

6. Repeat from Step 3 until your scenarios are all green. Now that you’ve done a chunk of work, Autotest pops the stack again and runs all your specs to make sure nothing is broken.

7. Fix any unit-level regressions. Once your specs are green and the scenarios you were working on are running, Autotest runs your entire feature set.

8. Fix any integration-level regressions. Now your features should all be green. Return to step 1.

1. The Brain Dump

The Team

You will find it best to gather at least one other person to get through the brain dump quickly and effectively.

The Media

Start the process using paper index cards. There’s something about paper that will help you move quickly and creatively through this important first step.

Roles

Record all the roles for the users of the system.

Actions & tasks

Note every action or task they may want to do, or that you may want them to do.

Wrap up

When complete, organize your cards into a prioritize list by role. So if you have five roles identified, you should have five prioritized lists of desired features/tasks/stories. Then toss the paper.

2. Modeling & User Stories

Develop “Ubiquitous language” — Words that work for both the code implementation and conversations with the customer. This language is also important for the screens, which need sentences + verbs (not typical programmer screens, which have lots of function, but no explanation.)

Add a few sentences to describe each story—just enough information to serve as a token for a conversation that will take place closer to implementation.

3. Implementation

Using the prioritized list by role, do the top row. The most important task for each identified role. This will encourage you to build a system that acts as a “walking skeleton” for the rest of the system.

Screens

• Which screens - REST conventions can do a lot of work - what is the logical name of the noun-verb combination?
• What’s on them - design from the inside out. Just the content without the outer frame of navigation. What matters to the user of the screen. What are they trying to do? Put in words what things they are trying to do on the screen, including the various paths they may take. (Don’t just assume the page should be a standard REST-template form.)
• Be completely rational, “don’t make me think” - when I see the screen, I instantly know what to do with it, it’s easy to complete the task.
• Least effective difference - give things visual priority, doing just enough to create the hierarchy.

Flows

Think with actions, every action has 3 screens…

• How you get to it
• How do you do it
• What happens afterwards - how do i know it worked. What do i want to do next?

HTML & Coding

Hopefully you know how to do this :)

1. Begin with modeling
2. Screens need language.
3. Typical programmer screen: Lot’s of function, no explanation. No verbs. No sentences.
4. Start with a model that works for both the implementation and the customer. “Ubiquitous language”

SCREENS

1. Which screens - REST conventions do a lot of work for us - what is the logical name of the noun-verb combination?
2. What’s on them - design from the inside out. Just the content without the outer frame of navigation. What matters to the user of the screen. What are they trying to do? Put in words what things they are trying to do on the screen, including the various paths they may take. (Don’t just assume the page should be a standard REST-template form.)
3. Visual style & tricks - be completely rational, “don’t make me think” - when i see the screen, I instantly know what to do with it, it’s easy to complete the task.
4. Least effective difference - give things visual priority, doing just enough to create the hierarchy

FLOWS

1. Think with actions instead of screens
2. Every action has 3 screens:
   • How you get to it
   • How do you do it
   • What happens afterwards - how do i know it worked. What do i want to do next?

TEMPLATES

1. No HTML in helpers
2. No clever builders
3. CSS/JS follow same REST-inspired naming conventions (action-specific blocks in each file)
4. Treat ERB like an image tag (i.e. small, maybe calling a helper, etc.)
5. Use helpers to reveal intention.

GitHub

GitHub makes it very easy for developers who don’t know each other, but have common problems to solve, to collaborate without communication (very low friction).

Ruby on Rails

Rails makes it possible to develop web apps w/ web services rapidly.

Cloud Computing

Companies like Heroku, Slicehost, Amazon EC2 are make it easier & easier to deploy & scale your infrastructure without needing hardware experts.

SaaS

Software as a Service has become mainstream & acceptable, and it’s easy with tools like Spreedly or RailsKits to allow customers to buy without any sales involvement. Because Rails apps commonly have both web UI + web service APIs, these can be used as standalone apps or components of bigger apps.

If you build each component of your system in a decoupled way, you have built something that could potentially be developed out as a standalone project that could be either released as open source (and get developers around the world to debug/improve/expand it) or release it as a SaaS subscription product.

The Catch

The catch is that very few web developers are so close to the edge of this. If you’re starting from scratch, or aren’t afraid of the big rewrite, be sure to choose a partner that is using a lightweight dynamic language like Ruby or Python, and that uses open-source software behind the project. Any other choice, and you’re wasting your money.

Product management is about managing the experience cycle and building something that people will want to use.

Experience Cycle

DDO has a paper on what it calls the Experience Cycle.

In a nutshell, I love the model, and I think it forms the core for what product managers should be focusing on.

• connect & attract possible customers
• orient them to the possibilities (i.e. product presentation, documentation, demos, trial account)
• interact with the product/service, with a good experience as the outcome
• extend & retain, develop customer loyalty
• help them become an advocate, communicating their satisfaction with other people

They break down Apple at the end of the PDF, which has some of the best managed brands on the planet.

Google Product Development Product

Evelyn Rodriguez posted her notes from a talk about how Google focuses on user-centered design, using small, agile teams (like startups) to develop ideas.

“If you build something users will use, there will be a way to make money.”

“Good quality, by itself, improves usage.”

• Build something that is valuable to people.
• Monetize it (with separate monetization team)

I think this Google stuff is very complimentary to the Experience Cycle content from DDO.

So my “short answer”, with evidence from two very successful brands I admire, is this:

“The essence of product management is designing, creating, improving, and monetizing customer journeys.”

Great consultant-speak, but what about execution?

For existing product, I think execution =

• Maintain or improve product quality (& customer experience)
• Monetization (attract customers, clearly communicate potential benefits of product usage, getting them to buy, keeping them happy & getting them to renew, and hopefully getting them to talk about us in a positive way)

We can change the language, to be less consultant-speak or put it in specific terms for our projects.

• Assign a small team (2-3 people) to manage the product/project. Don’t make the error of assigning one person solo. A small team helps ensure continuity of knowledge & healthy peer pressure to perform.
• Their mission: 1) ongoing monetization 2) improving customer experience.
• How to accomplish the mission is up to them. They should feel free to find customers directly, or to try to sell product through the existing sales force – let them decide how to grow revenues and improve user experience, with assistance from specialists & executives, as requested.

Of course, you have to have good people for it to work, of course, since each project acts as a mini-startup.

Business Initiatives are a Form of Art

Leonardo da Vinci once said “Art is never finished, only abandoned.”

Whenever we’re attempting to develop a new project, refine an existing product, reorganize a department, re-envision the brand (really any business initiative or project), execution requires significant creativity. These sorts of projects, like art, are never finished, only abandoned.

You might be saying “no.” If we reorganize the department, the project can be called “done”, we can move on. I argue that if you analyze WHY you reorganized, you’ll uncover an underlying unachievable ideal. You reorganized the sales department because you wanted to MAXIMIZE THE EFFECTIVENESS OF YOUR SALESFORCE, an initiative that is perpetual.

You redesigned your website in order to IMPROVE CUSTOMER EXPERIENCE. An ideal that cannot ever be fully realized.

Very little project management software supports this worldview, that projects are never finished, only abandoned. So I’ve been thinking about how software like that might work.

Products are like Fireworks Shows

Products are like fireworks shows. If you put on a good fireworks show, people expect you to do it bigger & better next year. To meet their expectations, you need to plan an escalating annual budget.

Products should be work the same way. If you spent $50k on a product in 2008, plan to spend $75k in 2009, and $100k in 2010. Don’t fool yourself into thinking that there was some upfront investment in year 1, and that year 2 can require 1/2 the investment.

Yes you can skimp in year 2. However, your “fireworks” are not going to impress anyone–your audience will see that you cut your budget in 1/2. And YOU FAILED TO MAXIMIZING YOUR INITIAL INVESTMENT.

The metaphor is getting strange, and I know nothing about the real business of fireworks shows, so I move on to a better metaphor…

Project Portfolios Require Gardening

Smart business people are charismatic and results-driven, and sit in leadership & management roles. They tend to generating lots of great ideas. Let’s call these “seeds”.

They influence the organization to act on many ideas. Let’s call these germinating change initiatives “seedlings”. Taken individually, the idea was sound, the cost to get it started was low. It was a no-brainer to allocate resources to get started, to test out the idea a bit.

The problem is in aggregate. The resources required to tend the rapidly growing garden greatly surpass the organization capacity.

It’s FUN and seems very productive to grow a seed into a seedling. Unfortunately, that’s where the problems start…

The Overcrowded, Decaying Garden of Too Many Plants

The problem with many small businesses is that we often plant many seeds, grow many fragile seedlings, and then don’t dedicate adequate resources to continue to nurture these seedlings into maturity. Creative executives move on to the “next great idea”.

The landscape becomes crowded. And important initiatives of yesterday are temporarily dropped in order to focus on germinating some new idea. Decay sets in. What can we do?

See the Landscape

The software would need to help expose the landscape. What investments has the organization made? What is the state of those investments? Which important initiatives are being underfed? What initiatives should be terminated? Which need to be be pruned or changed?

IS THIS A PROBLEM YOUR BUSINESS FACES?

I’m curious if this is a generally universal problem, or perhaps I’ve just been exposed to a subset of industry where this problem seems to be most pervasive (web software companies).

Perhaps ERP software covers this off? I’ve not been exposed to ERP software, nor have I seen anything tailored to Small- and Medium-Sized Businesses (the market segment that I’ve spent my career focused on.)

1. Spaghetti flows freely

The codebase is large enough to require some refactoring, but very little of it has ever been done.

2. Outdated platform

The site is using outdated technology that no good developer really wants to touch anymore (i.e. Microsoft ASP, data-processing-centric Java, VB.NET, etc.)

3. The experience sucks

The site is ugly, hard-to-use, etc.

Who is to blame?

Who is to blame for an application to get to the point that it needs tossed out the door? If resources were unreasonably constrained by non-IT management against the recommendations made by IT, then the non-IT management is to blame. However, if IT never asked for additional resources to avoid the 3 strikes, then it must take full responsibility for the impending death of a codebase.