Tagged:

Business problems and technology people

When you have a hammer, everything looks like a nail. I’m sure this pattern emerges in other industries, but here are some strawman personalities of web/tech types of people, and how they respond to business problems…

The Value Personality — This person can stop themself and ask about what sort of problem they have. They’re not rushing to a solution. They want to understand the problem and determine if it’s worth solving, and how to most efficiently solve it if it does. They’d rather buy something than build something, if buying is cheap and building requires continuing to own and operate a service after the fact.
The Mixed Bag — These people have the ability to answer the question “is this a technology problem?”… but they don’t always use it. They’re giddy to solve the problem and use the skills they have, so they jump head-first into creating a solution. They can be steered into agreement in discussion by being forced to confront “value” as a worthwhile component of the decision making process.
The Builder — This person has trouble contemplating a world where the answer to any question doesn’t involve them building software. They’re not clear why they would even be involved in a conversation which comes to another conclusion. The logic is something like “I am programmer; hence any discussion about a problem should lead to me writing code”.

Practical examples of problems, think about how each role might react to each:

We want to launch a company blog
We want to host events and need a registration system
We want to serve ads on our website
We want to monitor google for mentions of certain keywords

There are “build” and “buy” solutions for all of these, and I think the psychology and personality types of our strawmen will strongly dictate which direction they want to go.

So who’s “better”?…it depends. This may not be true in large organizations or very top-heavy organizations, but in the context of a small self-directed team, I think you want to make sure you’ve got the first personality type as your owners/operators and managers, and try to get as many of the first and second type as you can for your employees. Unless you have a large team with a lot of management and oversight, be careful about the third type.

That being said, there certainly is a time and place to write software! The key here is to realize that just because you happen to be capable of using technology and software to solve problems, or because you happen to be in the technology service business, does not mean that you must build new technology to solve every problem you encounter.

December 29, 2010

Tagged:

Comments (View)

Twiddle Wakka

Do you know the twiddle wakka? It looks like this:

~>

You’ve seen it in your Gemfile. Here’s an example

gem "rails", "~> 3.0.3"
gem "thin",  "~> 1.1"

~> 3.0.3 means that when you bundle install, you’ll get the highest-released gem version of rails between the range >= 3.0.3 and < 3.1.

~> 1.1 means that when you bundle install, you’ll get the highest-released gem version of thin between the range >= 1.1 and < 2.0.

I learned the name “twiddle wakka” at Jeremy Hinegardner’s Rubyconf 2010 talk, Anthropology of Ruby. During a data-driven analysis of the ecosystem of Rubygems, he found the twiddle wakka is used infrequently and asked the Ruby community to use it more.

Using the twiddle wakka in combination with consistent MAJOR.MINOR.PATCH versioning by gem authors, we can achieve better stability in our dependencies. Jeremy suggested reading two documents on consistent versioning:

In the comments of this post, David Chelimsky suggested a related document that is particularly relevant to us as Rubyists:

Rubygems Rational Versioning

I think most people are in favor of this in principle but are not consistent in practice. This leads to confusion: “Which libraries are consistent and which aren’t? Is this gem safe to declare as a dependency at the major, minor, or patch level?”

It seems like a simple way of clearing up the confusion is for authors to declare their intention of consistent versioning by using the twiddle wakka in their README’s installation instructions. If I see this…

gem "clearance", "~> 0.9"

… then, I feel the author is assuring me of the “safety” of this gem at the minor level.

Therefore, I’m editing the READMEs of our gems to declare our intention. Some may be “twiddle wakka’ed” at the major level, others at the minor level, and others at the patch level. That seems like a reasonable compromise to me since every project is at a different stage.

I’ve been guilty of being inconsistent about this in the past. Call it a New Year’s resolution, but I’d like be better about it in 2011.

What do you think? Is this README idea any good? Are you going to do the same?

July 8, 2009

Tagged:

Comments (View)

sign up, sign in, sign out

What is your Ubiquitous Language for authentication?

Common language includes “logging in”, “registering”, “joining up”, “creating an account”, “signing up”, & “signing out”.

Do you interchange these words in your UI? How about in your application code? Tests? Does your whole team use the same language across all layers of the software?

When writing a library like Clearance, I feel the authors should take a stand on language to alleviate the mental burden on designers, developers, & business analysts involved in the project.

The decision is basically arbitrary. No one set of terms is truly better than the other. What’s important is to take the opportunity to standardize all the places this shows up in code.

So we picked “sign up”, “sign in”, & “sign out”, a lingual trinity of authentication.

We liked the symmetry. We liked that there was less of a chance of writing “log in” (sounds like a verb) or “log_in” in certain places and “login” (sounds like a noun) other places.

About a half a year later and we still feel good about the effect:

Tests

context "when signed out" do
  setup { sign_out }

  context "on get to new" do
    setup { get :new }
    should_deny_access
  end
end

context "when signed in" do
  setup { sign_in }

  context "on get to new" do
    setup { get :new }
    ...
  end
end

context "when signed in as an admin" do
  setup { sign_in_as Factory(:admin_user) }

  context "on delete to destroy" do
    setup { delete :destroy }
    ...
  end
end

Application code

class UsersController < Clearance::UsersController
  def create
    ...
    sign_in(@user)
  end
end

class ParticipationsController < ApplicationController
  protected
  def ensure_signed_in
    unless signed_in?
      store_location
      flash[:failure] = "Please sign in to participate in this deal."
      redirect_to sign_in_path
    end
  end
end

module NavigationHelper
  def authentication_links
    if signed_in?
      signed_in_links
    else
      signed_out_links
    end
  end

  def signed_out_links
    [link_to("Sign up", sign_up_path),
     link_to("Sign in", sign_in_path)]
  end

  def signed_in_links
    [link_to("My Account", edit_user_path(current_user)),
     link_to("Sign out",   sign_out_path)]
  end
end