Information Technology Dark Side

Scrum is a poor man’s agile
I won’t lie. I’m in a fairly contrarian mood today, and that is likely to influence this post to be harsher than it would be if I’d written it on a day when all was well. But, nonetheless, even on a good day I think I would agree with the gist of what you’re about to read.

Scrum is, in my opinion, the least “Agile” of all the agile methodologies. It is also the easiest to learn, the easiest to try, the easiest to add to your bull-crap resume, and the easiest to completely fail at. More on that later.

I don’t like the branding association it has with agile
Scrum is the de-facto brand of the Agile Alliance. I don’t really have anything against AA, but it bothers me that the only agile training they offer is related to scrum. It feels to me like AA positions “Scrum” as “Agile”, when in fact it is really only one of many methodologies that was inspired by the Agile Manifesto. The net effect is that when scrum projects fail, it’s not just scrum that gets a black eye, but also agile. And I don’t like that, because scrum projects fail a lot.

I don’t like the training
I’ve never taken a scrum class, so you may conclude that I don’t have any business trashing it. You might be right.

That said, I know a lot of ‘scrummasters’, and I’ve debriefed a number of people after they’ve taken a certified scrum master course, and as a general rule the training they received has failed to

1. Give them an adequate appreciation for the values and principles that make Agile agile
2. Convince them of the importance of absolutely critical development practices such as test driven development
3. Prepare them for the intense resistance they will face attempting to introduce agile in an environment where it is new

I don’t like the certification
I’ve written training curricula before, both for professionals and for college students. I’ve never offered to “certify” anyone. I don’t really place much value in certification as a hiring tool or as a job-seeking tool except in certain very special areas where I know the certification is a bonafide test of competence at some level (assuming the possessor did not cheat or somehow fake the certification). Some examples of such certifications:

• Diplomas from real colleges & universities (schools that don’t fail anyone are not “real”)
• A license to practice law
• A license to practice medicine
• Certification as a professional engineer

These certifications are difficult and expensive to obtain and therefore demonstrate a fairly significant level of dedication on the part of the obtainer. They are also very rigorous and they police their members – if you screw up in a big way they will kick you out.

CSM is about as far from this certification as you could possibly get. Anyone with $500 and two days to kill can become a certified scrum master. That’s not impressive – being the proud possessor of a scrummaster certification is only a differentiator in the stupidest of organizations. In fact, if I am interviewing you for a position and you have a CSM my skepticism toward you just went up.

The true value of scrummaster certification is to the companies that sell it. They benefit immensely from it. So far as I can tell, they are the only ones.

I don’t like the club
Because CSM is easy to get and because Scrum pays short shrift to the values and principles from which Agile was born, there is a community of scrummasters who evangelize the Scrum process without grasping why Agile works. Take this genius for example:

Every CSM class I teach, I emphasize the complete nature of Scrum as a single tool, not a collection of tools. Learning Scrum is about learning the tool, not learning how to pick and choose pieces of a tool. Let’s explore this metaphor of Scrum as a tool.

Consider a hammer. A hammer is ideally suited for pounding nails into wood. It has two parts: a head and a handle. If you take the parts and use them separately, they can still be used for pounding nails into wood… but they are very ineffective compared to the hammer (although better than using your bare fist). It is non-sensical to decompose the hammer and try to use the pieces separately. However, a hammer is not suited to other purposes such as driving screws or cutting wood. It’s perfection is not just in its form, but also in its proper application. A hammer works through a balanced combination of leverage and momentum.

Scrum is like a hammer. It has parts (daily Scrum, Sprints, ScrumMaster, etc.), but taking the parts and trying to use them separately is… you guessed it… non-sensical. The parts of Scrum combine to be an extremely effective tool for new product development. Just like a hammer, there are things you wouldn’t want to do with Scrum such as manufacturing or painting a wall. (We might not all agree on the limits of the use of Scrum… that’s something for another article.) Scrum works through a combination of pressure on the organization and “inspect and adapt” (continuous improvement).

Please. Don’t modify Scrum. If you must change things about Scrum, please stop calling it Scrum.

Source

This is in direct opposition to a number of agile values and principles, most notably that individuals and interactions are more important than processes and tools. It is also ludicrous to say you use “inspect and adapt” to obtain continuous improvement, but only so long as you don’t inspect and adapt scrum.

That’s just plain stupid.

Scrum is full of people who think like this, and it makes me sad. There is little point to scrum if you do not understand and embrace the values and principles from which it sprang. It’s just another flowchart.

I don’t like the methodology
Scrum is too rigid. It imposes a structure and process on an agile team that doesn’t always fit, and it puts pressure on teams to use that structure or else. It’s not true to the fundamentally critical cycle of experimentation and evaluation that is at the heart of agile.

I also think it puts too much emphasis on the scrummaster, and not enough emphasis on emergent planning, good design, and disciplined software development.

I don’t like the results
Bright-eyed and bushy-tailed brand new certified scrummasters are failing to deliver working software all over the place, mostly because of the three things their training failed to give them. As a result, lots of organizations are back-pedaling from their scrum implementations, mistakenly blaming agile for the failure.

Well guess what? It’s not agile’s fault. If you just “do” scrum without understanding or appreciating the values behind it, you didn’t “do” agile. You just did a totally empty version of scrum.

Is there anything left?
Nope. I think that’s pretty much it. Scrum is the new waterfail.

The one thing about The Lean Startup by Eric Ries that makes me cringe
The Lean Startup is a great book. It’s well written and convincing, and the more I read the more eager I am to put it to the test on TroopTrack, AuthorGate, and my client work. Part of the reason it appeals to me is because it jives with my own experience struggling to create a product people want on TroopTrack.

There is only one thing that bothers me about Eric Ries’s book. Many positive case studies end with some version of the following phrase: *Startup X* was able to raise *large amount of money* from *VC name* and is now one of the hottest startups in Silicon Valley.

This phrase is often provided as evidence that the lean startup approach is working for Startup X. This really bothers me, partly because the book starts out by referencing massive .com failures pets.com and webvan.com, both of which managed to raise huge sums of money. This is ironic in a book that teaches about the dangers of vanity metrics, false indicators of success in a startup.

Investment is THE Vanity Metric of Success
Do I really have to prove this? Aren’t there enough case studies in the lore of the last decade to make this a given? The fact that some rich guys are willing to give you money to keep working on your idea doesn’t mean that you are being successful as a business. The only situation in which this is not true is when your only business goal is to raise money, which isn’t really a very healthy goal.

When does the “We Can Make A Profit Doing This” assumption get tested?
At one point in the book Eric Ries says something like this (I’m paraphrasing because I’m listening to the audio book and can’t quote exactly):

As a result of innovation accounting, our revenue increased to millions of dollars per month, which allowed us to raise even more money from *some VC*

Seriously, you’re making more than a million dollars a month in revenue and IMVU needed outside investment? Is that really an indication that you are being successful?

I’m not saying IMVU is a failure. I’m just saying that investment and success are coincidental at best. That’s all.

So, shouldn’t a startup also be testing this assumption, that they can actually make a profit? Wouldn’t that be important? To me, waiting until you are generating $1M EVERY MONTH in revenue feels a little bit late. I’m just sayin’.

Profitable businesses have infinitely long runways
The Lean Startup talks about the importance of a startup’s runway and redefines it as the number of pivots a company can make before they run out of money. This is a pretty important and useful redefinition from the old definition of cash / monthly burn rate. You can extend your runway by shortening iterations, focusing on validated learning, and using innovation accounting to figure out what is really working. It’s freaking brilliant, actually.

I’d just like to make a simple point: profitable businesses have an infinitely long runway. They can pivot as many times as they want, as long as they don’t go into the hole for extended periods of time.

One of the most common requests I get from TroopTrack users is to let them add photos more easily. For the upcoming 3.0 release I decided to give it a go, and it turned out to be pretty simple. Here’s a quick video of the end result:

How I Did It
I based my approach on this tutorial. It’s meant for PHP sites, but the HTML, javascript, and CSS will still work for a rails 3.1 app. So I copied those items into the normal places and started to change things to make it work on Rails.

The most important changes are at the top of the javascript – you need to change the name of the photo parameter and the url to submit it too. Here’s how mine turned out:

var dropbox = $('.dropbox'),
    message = $('.message', dropbox);

  dropbox.filedrop({
    // The name of the $_FILES entry:
    paramname:'troop_photo[photo]',

    maxfiles: 5,
      maxfilesize: 2, // in mb
    url: dropbox.attr('id') + '/troop_photos',
....

In my case, the full path of the POST should be /photo_albums/:id/troop_photos. So I stuck the ID of the photo album we are uploading to in the ID of my dropbox div and used it to build the url. And, to follow the Rails convention for param names, I set the param name to ‘troop_photo[photo]‘.

The last big change I had to make was to set up the controller action. This was really pretty simple, since at this point the photo upload is just a regular create action that is expecting a json response. Here’s how it turned out:

  def create
    @troop_photo = @photo_album.troop_photos.new(params[:troop_photo])

    if @troop_photo.save
      render :json => {:status => "File was uploaded successfuly!"}
    else
      render :json => {:status => "Something went wrong with your upload!"}
    end
  end

Awesome Results

Making It Better
I didn’t say anything about Paperclip here. That’s because I didn’t have to make any changes at all to my existing Paperclip setup to make it work because the real action happens in the controller.

The problem with uploads like this is that they are kind of silly pathed. The file goes from my user’s computer, to my app server, to S3. It would be better if it just went straight to S3.

In my research for this, I came across CarrierWave Direct. It does exactly that. I haven’t tried it out yet, but I plan to if I ever get enough customers to worry about it.

I have a form where a user can provide a list of brands they like. We’d like to avoid duplicates as much as possible, but we also want to let the user add brands to the list on the fly. Brands is really just a type of favorite, and the relationships are set up like so:

class Favorite < ActiveRecord::Base
  has_many :user_favorites
  has_many :users, :through => :user_favorites

  scope :for_type, lambda {|type| where(:favorite_type => type)}
end

class UserFavorite < ActiveRecord::Base
  belongs_to :user
  belongs_to :favorite
end

class User < ActiveRecord::Base
...
  has_many :user_favorites
  has_many :favorites, :through => :user_favorites
end

There are other types of favorites: colors, sports teams, stores, etc. They all live in the same favorites table, and that for_type scope lets me filter them out based on type.

You might be wondering why I didn’t use single table inheritance (STI) here. The answer is simple – because I don’t need to. All favorites act the same, at least so far. Later on, if that changes, I will change the model. But for now, I don’t.

You might also be wondering why I don’t use has_and_belongs_to_many (HABTM) here as well. The answer is simple – every time I create a HABTM relationship in my models I find myself ripping it out later so I can add some other field later. So, I don’t bother with it. Sure, you could make the case that I have a model I don’t need and you would be right. You could also make the case that this is in direct contradiction to the STI decision I just made. And you’d probably be right there too. My grand respons is…

shrug.

Okay, so I want to use the jquery.tokeninput library to manage the list of favorite brands. I won’t go into the details of token input – Ryan Bates and others have already done that very well. Just go check out their stuff.

The catch is allowing users to create new favorites on the fly, rather than just picking favorites off the list of what’s already in the system. Token input works by creating a list of ID’s that are submitted with the form, so if I want to add “Coleman” to my list of favorite brands, and the system doesn’t already have “Coleman” in it, I can’t. That’s because token input relies on an active record search of favorites to make suggestions, which normally look something like this in the controller:

def index
  @authors = Author.all
  respond_to do |format|
    format.html
    format.json { render :json => @authors.map(&:attributes) }
  end
end

Note: this particular code snippet came from Ryan Bates, who I think is totally awesome, and is specific to a different application. I’m just using it as an example because that’s not what I did (but it’s perfectly fine in the normal usage).

As I was staring at this, it occurred to me that the form doesn’t really care if there is a favorite or not. It just needs some JSON to make the list work. So I did my controller action differently. Like so.

  def favorites_list
    term = "%#{params[:q]}%"
    favorites_list = []
    Favorite.find(:all, :conditions => ['name like ? and favorite_type = ?', term, params[:type] ]).each do |fav|
      favorites_list << {"id" => fav.id, "name" => fav.name}
    end
    favorites_list << {"id" => "-new-#{params[:q]}", "name" => params[:q]}
    render :json => favorites_list.to_json
  end

Please note – this is the “Make it Work” step for this code. Not the “Make it Right” or “Make it Fast” step. So if it makes you puke in your mouth, say so, but tell me how to make it right. If you don’t include some CONSTRUCTIVE criticism I’ll publicly call you out as a nosehole (it’s what my 3yo calls a nostril and we’ve adopted as a family curse word). Also, I’ve left off the respond_to block because this action doesn’t care who you are. It’s gonna respond with JSON.

All this action does is throw the search term on the back of the list of search results, with an ID that starts with ‘-new-’. Everything else will have a numeric id of course, so it will be pretty easy to tell which ones are new with a little gsub action in my attribute setter. Here it is:

  def brand_tokens=(value)
    ids = []
    value.split(',').each do |val|
      if val[0..4] == '-new-'
        fav = Favorite.create!(:favorite_type => 'brands', :name => val.gsub(/-new-/,''))
        ids += [fav.id]
      else
        ids += [val.to_i]
      end
    end
    brand_ids = self.favorites.for_type('brands').map(&:id)
    self.favorite_ids = self.favorite_ids - brand_ids + ids
  end

If I didn’t have other types of favorites, I wouldn’t need to do the last two lines that way. I would have been able to just set favorite_ids = ids and be done. But, since I have multiples of those, I have to be careful not to stomp out the other ones.

Again, this method is not slick or shiny. But it works, and tomorrow or the next day when I’m less sick of this particular story I will make it better. If you make a comment that I incorporate into my code, I will tell the world what an ubergenius you are.

So, just like that, I have a token input that I can add new values to on the fly. Yay!

I need to add full text search to an item class. The fields I need to search are :title and :description. After a bit of digging, I decided I would give sphinx a try, using the thinking-sphinx gem. I’m going with thinking-sphinx because it came up first on Ruby Toolbox. When I’m diving on something like this, I like to try something right away for two reasons: 1) if it works out I don’t have to do any research 2) if it doesn’t work out then as I do research on what to try next I have some context for making decisions.

So just like that I jump right into the code by installing sphinx.


brew install sphinx


Next is the thinking-sphinx gem

gem 'thinking-sphinx', '2.0.10'


The I plop indexes and attributes on the Item model.

define_index do
# fields
indexes title, :sortable => true
indexes description

# attributes
has created_at, updated_at
end


And I try to index my data, but I get an error: undefined method `indexes’ for #rake thinking_sphinx:index works. Hooray!

Ready, set, start sphinx!

rake thinking_sphinx:start


With that, I am ready to start searching items. So I try it out in the console first, just to see.


ruby-1.9.2-p290 :003 > Item.search("Clean")
=> [#, custom_photo_url: "http://t3.gstatic.com/images?q=tbn:ANd9GcSTIeHk4_lq...", custom_title: "Netty Pot", custom_description: "Clean your sinuses">]
ruby-1.9.2-p290 :004 >


Just like that, I have full text search!

Test Style #1

@custom_item.image.should == @custom_item.custom_photo_url
@custom_item.images.should == [@custom_item.custom_photo_url]
@custom_item.buy_now_url.should == @custom_item.custom_url
@custom_item.description.should == @custom_item.custom_description
@custom_item.title.should == @custom_item.custom_title
@custom_item.real_price.should == @custom_item.custom_price * 100
@custom_item.price.should == "$#{@custom_item.custom_price.to_s}"

Test Style #2

@custom_item.image.should == "http://www.techdarkside.com/davesmall.jpg"
@custom_item.images.should == ["http://www.techdarkside.com/davesmall.jpg"]
@custom_item.buy_now_url.should == "http://techdarkside.com"
@custom_item.description.should == "Nutritious and delicious"
@custom_item.title.should == "Toe Jam Juicer"
@custom_item.real_price.should == 4900
@custom_item.price.should == "$49.00"

Which style is better?
I have a strong preference for the second style. The first style is what I call a set of “presumptive” tests. This is the expected results are derived from model they are testing. Sure, it might make for a somewhat less brittle test because you can change how you create the item before the test without breaking the test, but you also introduce the possibility of a false positive and you also obfuscate the intent of the test. Here’s what I mean.

Unit tests commonly check two things – that a a certain method returns a certain value and that the value is presented in the proper way (format, type, etc). They also helped programmers under the intent of the methods being tested as well. Presumptive tests fail in all of these records. For example:

@custom_item.buy_now_url.should == "http://techdarkside.com"

is, in my opinion, much clearer than

@custom_item.buy_now_url.should == @custom_item.custom_url

To me, the first test makes it perfectly clear that buy_now_url is meant to be 1) a string and 2) a well-formed url. That is helpful. The second test only tells me that the buy_now_url and custom_url should be the same. But what if the buy_now_url is supposed to be a string and in my test I use a different class? The test would still pass, but the functionality would not be doing what it is supposed to, likely breaking the UI.

Bust my chops, please
It occurs to me that perhaps I’m missing something here. Feel free to tell me what it is and why it matters. I am not super awesome at TDD – I’m mostly just very functional about it and not particularly clever about writing really expressive, solid tests. So please bust my chops and make me better.

If you’re reading this, you are either as lazy as I am or perhaps aspiring to be as lazy as me. Here are some aliases I find very useful. There’s nothing technically amazing in here, but I resent keystrokes. Especially the ones I end up typing over and over and over and over.


#heroku stuff
alias herot='git push test test:master' #push my test branch to my heroku test branch
alias hero='git push heroku master' #push to prod

#git stuff
alias gs='git status'
alias gp='git push'
alias gcm='git commit -m'
alias ga='git add'
alias gitco='git checkout'
alias gitcp='git cherry-pick'


See it in action

New Filter from David Christiansen on Vimeo.

How it works
[Read more →]

From Anecdotal to Evidential
I’ve been telling myself a story about TroopTrack for the past year or so – that the conversion rate is getting better. I wasn’t really sure that was the case, but that’s how it seemed based on my general sense of signups and conversions to paying customers. I don’t like telling myself stories without checking on myself, so I did. I wrote some queries, pulled some numbers, made a spreadsheet and started making charts.

Am I Totally Clueless?
The story I was telling myself revolved around how I perceived the quality of the code base. At launch in 2009 TroopTrack was buggy. It crashed all the time, and I didn’t even know about it because I didn’t have exceptional set up yet. Late in the year I added exceptional, discovered how crappy TroopTrack was (most days I would get 30+ emails from exceptional), and went on a bug hunt that lasted through most of 2010. I wasn’t just fixing 500′s, I was also fixing functional issues reported by users. In 2011, I started feeling more confident in the application’s stability and wanted to start getting the word out somehow. I also added some new features that were requested by users throughout the year and focused my efforts on responding to support tickets. In my mind, I thought conversion rates were getting better as a result of these efforts.

My first chart was no help at validating this story. At all.

Quarterly Conversion Rate

What about the hockey stick?
Every entrepreneur wants to see a hockey stick in their growth chart. So I plotted out the number of paying customers over time, just to see how things were going. I fully expected to see a curve.

That's a straight line!

Sigh.

A different view
Clearly there was a lot of variability in my conversion rate at the quarterly level. What about year over year? That was my next chart.

Conversion Rate by Year

Okay, that’s better. At least on an annual basis, the conversion rate seems to be getting better.

Correlation or causation?
I think that last chart supports the story I was telling myself, that overall the conversion rate was getting better, but it made me think about the impact of good support on the conversion rate. The peaks in 2011 coincided with periods of high interaction between me and the user base. During those times, I was dutifully closing support tickets or rolling out new features accompanied with an email announcement. Were those activities impacting conversion rates? I think they were, and I’ve added some things to my how-to-turn-shoppers-into-customers list.

• Customers who have a good experience with a support ticket during their trial have a higher likelihood of purchasing a subscription
• Customers who see an improvement made during their trial period have a higher likelihood of purchasing a subscription

I think this means I need to roll out a new feature every month. Or at least tell my users about the progress I’ve made fixing bugs, etc. But there is a bigger lesson here, one that is reinforced by something else I’ve been doing in the fourth quarter of this year.

Customers who feel like they know me are most likely to purchase a subscription
Many of my customers start support tickets with my first name. They speak to me in familiar ways. Some of them call me on my cell phone. When I hurt my back early this year and fell behind on TroopTrack, several of them called to make sure I was okay. They feel like they know me, and I feel like I know them. These customers are very loyal and they are good advocates for my product.

In Q4 I’ve been calling every trial troop to see how things are going and to offer help. It can be hard to reach people – I leave a lot of messages. I don’t have numbers to prove this yet, but the conversion rate of the customers I am able to personally interact with feels much, much higher. So I’m going to keep calling them, and maybe I will hire someone to help me with this.

All charts lead to fantasies
You can’t collect numbers and make charts without thinking about the future. I’m kind of obsessed with 20,000 subscribers. That’s the million dollar mark. In terms of making the most impact on my lifestyle, 5000 subscribers is probably a more significant number. That’s the freedom mark.

So, assuming that I add 60% more troops than I did the year before then freedom comes in 2018 and $1,000,000 in revenue comes in 2021.
I came up with 60% fairly non-scientifically. I added 60-something new subscriptions in 2011. I feel comfortable that I can add at least 100 in 2012. That’s about a 60% acceleration.

Even though this is very, very speculative, it reinforces some very important things about this business of mine:

• The lifetime value of a subscriber is high. My subscribers are ORGANIZATIONS. Once they pick a product, they tend to stick around. Personal efforts required to obtain a subscriber are worth it
• Persistence and consistent improvement is critical
• Building my business in a way that I can sustain my efforts for a decade is the key to making it

When you are looking at projected revenue growth and the hockey stick is 6 years away, you have to think about your commitment. For me, it’s easy. I accepted the long road two years ago. To me, six years is nothing. It’s the light at the end of a tunnel, except the tunnel isn’t dark, wet, or spooky. It’s fun, educational, and kind of inspiring. This makes six more years of working hard pretty easy to swallow. Like chocolate ice cream. With hot fudge. Whip cream. A cherry. And banana slices. I’m just sayin’.

I love being a bootstrap entrepreneur.

That said, I’m not against doing things to make it go faster. For instance, I’m considering raising money to finance TroopTrack mobile and other development efforts. I’m also working on ways of accelerating TroopTrack’s viral growth, like welcome kits for new subscribers that include pass-along cards they can give to other scouters, in-store displays, and a direct mailing. I tried a print ad, but it had unimpressive results. I might try that again someday, but for now I’m going with things that feel more personal.

Start with the values dang it
I’m often surprised to encounter someone experimenting with agile who has never read the agile manifesto or the principles behind the agile manifesto. This is the place to start, and if you share these values and grok the principles behind them, you can make up your own agile process completely from scratch and be perfectly successful. Or you can learn what others have tried and invest a little in a specific agileology like scrum, xp, etc and get a headstart. The point is, you should start with the values and principles. Starting with a process and never embracing the values or principles will render your agile adoption empty of true value.

Anyway, I would like to amend the agile manifesto with another value.

Team and individual productivity over consistent tools, and technologies
My first day at a bona fide startup went something like this:

Me: What kind of computer do I need?

Them: Whatever you have is cool.

Me: What OS should I run?

Them: Whatever you want. Most of us use Ubuntu. OS X works too. Winders is harder because some of the gems we use have native components that might not be available on Winders.

Me: What IDE should I use?

Them: Whatever you like most. We are all over the place: VIM, eMacs, TextMate, eclipse, NetBeans all play here. We’d prefer not paying for whatever you choose.

At first it seemed unreal that we could just use, you know, whatever. How could that work? Wouldn’t it be a mess, all of us just using whatever we wanted?

It wasn’t. The only time it was a problem was when I was not self-sufficient with the choices I had made. Specifically, I didn’t know enough about Ruby on Rails and OS X to get our app working (HEY> I KNOW THIS IS EASY! IT WAS YEARS AGO OKAY!) and everyone else was on Ubuntu. So I switched to Ubuntu until I was more experienced, then went back to OS X when I could do it without dragging people down.

Productivity over consistency is implied by the principles
I think the guys who signed the agile manifesto already shared this value. Whether they discussed including something like it and decided not to, I don’t really have a clue. But it’s certainly implied by several of the principles, the most relevant of which I’ve listed below.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Continuous attention to technical excellence and good design enhances agility.

The best architectures, requirements, and designs emerge from self-organizing teams.

Inverting this value is bad, bad, bad
It’s easy to invert these values. Consistency is very tempting for many reasons we can articulate and for reasons we may not be able to. I think humans subliminally want consistency, even when they cognitively grasp that it’s not important. But that’s a question for psychologists, not a learned-it-on-the-street developer.

Here are some of the reasons I’ve been given for valuing consistency over productivity in the past:

• Cost savings from buying stuff in bulk (“Microsoft will give us a better deal if we buy 1000 licenses”)
• Ease of managing employee computers (“one image to rule them all”
• Network security (“we can’t protect our data assets if we don’t know exactly what is connecting to our network”)
• Commoditization of employees (“if Dave gets hit by a bus I can’t jump on his projects cuz I’d have to learn HAML first”)

These might be legitimate problems that need to be addressed. I’m not saying they don’t matter. I just don’t think consistency is the answer to ANY of these problems. There are other answers that are better, such as:

• Use open source tools
• Provide high-tech employees some general guidelines and let them do whatever they want with their equipment
• A network that doesn’t care what you are connecting with is less vulnerable than one that does
• Learn a new skill

These won’t always work, but when they don’t, other answers will. The point is, don’t invert the values. Don’t sacrifice productivity of teams or individuals for consistencies sake. That is not a good tradeoff – I think you almost always lose money, and the longer you do it the bigger the loss.