Coding Libertarian

What are your favorite tech talks of 2011?

2012-01-10T08:43:00.000-08:00

I'm looking for some tech talks to watch with coworkers over lunch. I'm hoping the community will help out by pointing some interesting talks they've seen in the past year. Since Thoughtworks' blog aggregator is hopelessly broken please use this link to make suggestions.

Asynchronous Pair Programming(Duet Programming?)

2012-01-02T22:05:00.000-08:00

Over the last few weeks of 2011 I've been playing around with Vim and Rails. I know many people are pairing using Vim. I also know people are using Vim and screen along with some sort of voice chat to pair remotely. One of the limitations(and strengths) of pairing is that both users are working in the same session. Only one person can be typing/browsing/whatever at a time. This can be good when you're writing code but tends to suck when you're doing research (on the web or in the code base).

Introducing screen to the mix has the ability to break this dependency on a single session. Each member of the pair can have their own instance of vim in half of a split terminal. Everything that is happening in the screen terminal is still visible to each member of the pair but they have the ability to be active at the same time in separate "windows" of the screen session. Can you write the next failing test while I extract this method? Can you look up what parameters the method I'm about to call expects?

It's quite possible this practice is widespread and I just haven't seen it in my little corner of the .Net world. Are people already using screen this way? If so, how is it working out?

Basic A/B testing in .net (with nToggle)

2011-11-06T20:20:00.000-08:00

In order to add the most basic support for A/B testing to nToggle I have added the ability to specify your own custom repository for the status of a toggle. By implementing a custom repository we can write code to determine which version of a feature a given user of the applicaiton should see.

Example:(If you aren't seeing the embedded code, click through to the full post.)
In my application I have a drop down list for selecting models of cars. The number of items in this list is large and I am going to replace it with an auto-complete textbox which I think will create a better user experience. I think this change could have a large impact on users of the application so I'm only going to release it to power users to get feedback. Everyone else will continue to see the old version of the application.

First I wrap the new and old code in a web feature toggle:

Second I add the new toggle to my web.config: Notice that my new toggle has a property on it called "repository". This tells nToggle where to look for the status of this toggle.

The last step is implementing a repository which will determine if the current user is a power user:

That's all there is to it. In just a few lines of configuration and code we have created a very simple A/B test of a new feature. Disclaimer: This method is intended for short term use during development and transition. Feature toggles should be short lived and I recommend removing them(and the branches you have created in your code) as soon as reasonable.

Distributed Check-in Tokens: Pass-The-Puppy

2011-09-18T21:02:00.000-07:00

On many software development teams there is a section of code or some development artifacts which will collide if two people/pairs check in at the same time. In order to stop this from happening many teams adopt a check in token. Only the people who have the token can check in the given resource.

On my current team we have two such resources: our numbered database migration scripts (which will fail if any two have the same number) and our functional test data csv files.

Co-located teams can use a stuffed animal(like ours above) or some other physical token. For distributed teams a physical token is not an option.

To enable all of our team members to use the tokens I created a rails app I call pass-the-puppy. This app is simple and low volume, so a free Heroku account is sufficient to host it for the team. Any team which needs a set token can clone the app from github and create their own Heroku app. Sample application

As a rails novice I was quite happy to discover how easy it was to deploy an app to Heroku. Warning, it's not aesthetically pleasing.

Numbing the pain isn't necessarily good

2011-04-27T20:36:00.000-07:00

A few months ago I bought a pair of Vibram Five Fingers shoes. When I first started wearing them I realized my normal tennis/running shoes had been hiding a few things from me. The standard way I run/walk is on my heel. This means that I'm limiting the ability of my foot to absorb some of the impact of taking a step. This causes more of the impact to go directly onto my heel and up my leg. Also my Plantar Fascia were very very tight. This is important feedback that I wasn't getting.

When I had pain from running, I'd take Aleve to temper the pain and swelling, and continue to run the same way. Eventually the stress lead to more significant problems that weren't so easy to ignore. By changing the way I step I'm able to eliminate a major contributor to the pain. At first the change is hard. I was sore for a while from using a new set of muscles. It took focus to not fall back into the old step pattern.

Now that I'm adjusted, my calf muscles and plantar fascia are much more flexible. My calves haven't cramped in months. I'm able to comfortably walk barefoot on previously painful surfaces(stepping down on a rock in the street with your heel is not fun).

As usual, I'm only mentioning my Five Fingers experience as a metaphor for software development.

If you are developing an application and bugs keep popping up all over the place, you can just just fix the bug and keep on going adding and changing code. Eventually you'll spend the vast majority or your time poking and proding and trying to get the system almost stable. You'll be afraid to make any changes. Another alternative is that you can start writing tests. Start with a test for that bug. Writing tests will be painful at first. You'll be exposing all of your bad habits. Your code will be difficult to test. As you write more and more tests you'll be able to start to clean up that code. You'll begin to gain the confidence that you can make changes and add features without introducing a bunch of new bugs.

If your release cycle is six months and the releases never seem to go as planned, you can add more time for manual regression or release only every year. "It's a painful 3 months but it only happens once a year", you'll say. Alternatively you can decide you want to release every month or every week or every commit. You can automate all of the steps to release. You can write system tests that give you confidence that you haven't missed deploying a stored procedure or changing permissions on that directory. You'll have some of the same pain but if you're writing tests it'll be pain in smaller and smaller amounts. When you test a release after every commit and run tests against it, you'll know immediately if you forgot to add that new step to the deployment

Usually, when there is pain, there are causes of the pain. While you might need to numb the pain you'd better make sure you remove the cause of the pain as well. Start fixing the cause first and numb only if you still need to. Stop numbing the pain as soon as possible.

Usage is not a substitute for tests

2011-04-27T20:35:00.000-07:00

Some months ago I encountered a large Sql Server database which was not particularly well understood and didn't have a test data set. In order to develop a test data set I decided to use a tool(the precursor to nDump) which I had slapped together in about an hour in late 2009. The tool, though primitive, was already working reasonably well at importing CSV. It had no tests, unit or otherwise. All it had in the way of testing was my manual inspection of the application which consumed the database to verify that it was working correctly.

As I used the tool to understand and generate data for the Sql Server database I realized that the tool was buggy and lacking features. I decided to refactor and extend it. Because I was focused not on the tool but on the data set for the application, I continued to make changes and add features without adding tests. I did make an attempt to reasonably factor the new code in a similar manner to how I would if I had been writing tests. Not writing tests at that time was a mistake.

Later in the development I realized this and went back to add tests. How well had I done at writing testable code? Not all that well. Much of the code was easily testable but there were more than a few places where files were being created directly or concrete instances were being new-ed up in the middle of a method doing other work. It certainly takes much more effort to tease the dependencies out and add the tests after the fact. Hopefully this post will serve as a reminder to keep me from making the same mistake again.

Breaking Down Unruly Databases: The Problem

2011-03-08T00:05:00.000-08:00

In my last post on nDump I talked about a tool I've created to import and export data from MS SQL Server databases. In this post I want to lay out some of my motivation for doing so.

Often when starting at a new client we arrive to find a legacy database/databases which seem nearly incomprehensible. Development and CI often run against a shared databases which are backups of production. The state of the data is in a constant flux. If someone desires to run a local database, restoring at least a few gigs of database backups is required. One reason this is necessary is that the database(s) can't easily be recreated from scripts. This is relatively easy to get around by breaking creation scripts into parts and employing tools such as DBDeploy to run them in order.

Once the problem of creating an empty database is tackled, nobody seems to have the requisite knowledge to populate it with the basic data necessary to run the application. There are many problems that spring from a lack of the ability to create minimal data sets:

Returning to a known data set is time consuming, requiring restoring a large backup.
The development and functional test data sets can't be easily version-ed. While you can check in a backup, there is no reasonable way to diff it against a previous version.
Functional tests are often brittle as they rely upon the state of the data which tends to be rather inconsistent.
Finding data requires searching through a large data set.
Deciphering incremental changes to the state of the data is no small challenge.

On past projects, the teams have stored development and test data sets as groups of csv or XML files. Both of these files can be easily version-ed, diff-ed, and modified using excel or open office. I prefer csv files as they are more concise and contain a lot less noise. Once you have these file sets and the requisite knowledge of the database structure it's relatively pleasant to work with them to maintain known state(s) of the data. By running the database build and load in a CI build we can continually verify that we know how to build a database. Using the populated database we can confirm that our functional tests of the application(s) are still working against a consistent data set.

nDump: Managing development and test data sets for MS SQL Server

2011-03-06T16:29:00.001-08:00

I've created a small tool called nDump which I've been using to help me gain understanding of and manage data sets for complicated(legacy?) MS Sql Server databases.

What does it do?

Apply filtering select statements to MSSQL data tables in a source database

By writing select statements to return a small(as small as reasonable) related set of data you force yourself to understand the database while you create a minimal data set.

Save the filtered data to CSV files

By saving the selected data to CSV files it can be easily version-ed and diff-ed.

Convert and save the CSV files to SQL script files

Prepare them to be inserted into another database.

Delete the data from the tables in a target database

Verifies that you have correctly ordered the tables for deletion. Returns the database to a relatively known starting state.

Apply the SQL script files to the target database

Ensures that the selected data can be reinserted into the database. Allows you to run your application against only the data in your set.

Minimal data set generated

Once we have a minimal set of data, a somewhat better understanding of the database, and the application running on this data set there are many things we can do:

Add more data to set by editing the csv files in excel or open office.
Add more data through the application and use nDump to export it without filters.
Restore the database to this set of data at any time.
Run functional tests off this consistent data set.
Develop in database isolation without having to restore huge databases.

Feature Toggles for .net: nToggle

2011-03-05T15:05:00.000-08:00

Late last year my team and I helped a client to decide against Feature Branching in favor of Feature Toggles. After making this decision we realized that there didn't seem to be an implementation available for the .net platform so nToggle was born. Usage is simple and there isn't a whole lot to it.

Let's suppose we have a new feature, BlogComments, that we want to toggle. Configure your new toggle as on or off in the project's Web.config file.

Add a WebFeatureToggle around the new feature in Asp.net WebForms.
If you have Web Form elements which should not show up when the feature is enabled you can toggle them too using the RemovedBy attribute
Code in a code behind that should be toggled can use the WebFeatureToggle as well.

The Curious Task of Agile

2010-12-30T23:31:00.001-08:00

This poster contest over at CAFE HAYEK reminded me of one of my favorite economics quotes:

"The curious task of economics is to illustrate to men how little they really know about what they imagine they can design." - F.A Hayek

Simply replacing "economics" with "agile" I think the quote is equally valid:

The curious task of agile is to illustrate to men how little they really know about what they imagine they can design.

Software development suffers from many of the same problems as economic planning: complexity, lack of information, changing preferences, and unintended consequences. As with economies, when we attempt top down planning of software or attempt to plan it in detail in advance we almost always end up with a poor result. When developing software we strive for emergent design which parallels the economic concept of spontaneous order.

Freeway Driving

2010-08-09T22:20:00.001-07:00

As a software developer it amazes me how many software developers simply go on doing what they've been doing without making any attempt to grow or improve. At some point I hop in the car and begin the drive home. It doesn't take too long before I realize that it's not just developers. Many people can't be bothered to pay any attention to what they are doing in any setting. How many times during each trip do I come up behind someone in the fast lane (or carpool lane) going 10-20 miles per hour slower than majority of the traffic on the freeway. It's at this point that I begin to wonder why they are doing what they are doing. This list usually amounts to something like the following:

They think it's ok because they are going the posted speed limit (or within some miles per hour of it)
They can't stand the thought of anyone going faster than them.
They're taking a moral stand against those going over the posted speed limit.
They like the far left lanes because there is never anyone close in front of them.
...

As I get down the list, I realize that while there are some people who may identify with the reasons above, the majority of these people are likely just not paying any attention. They get on the freeway, merge over to the fast lane(s), and completely check out. They don't notice the large line of cars piling up behind then. They don't notice the frustrated people who resort to passing them in the slower lanes (at worst having to pass 2 or 3 lanes over). They've probably been driving many years and at no point have they noticed any of these things happening.

While I'm often happy to ridicule and mock them as we drive along, what I'd really like to do is lay it out for them:

You are creating traffic

As the cars pile up behind you the amount of congestion is increasing. Two cars driving slowly in the wrong lanes can just about block the entire freeway. Everyone else will be delayed because of you.

You aren't gaining anything

If you just move a few lanes over you can still go the same speed without blocking anyone.

You are creating a traffic hazard

As cars rapidly approach from behind you they find themselves with the choice to either pass on the slow side or sit in congestion behind you. In either case you are causing the freeway to be less safe than it should be.

Here are a few simple easy to follow rules

If you can't talk and drive at the same time you either a) don't talk or b) don't drive. Take your pick.
You should drive in the slowest lane that can contain your speed.
Should the need to pass arise you need to pass in a reasonable fashion. Speed up at least 5 miles per hour faster than the person you are passing. After completing the pass move back to the prior lane if it's safe to do so. If you can't pass at a difference of at least 5 miles per hour than you should slow down and stay behind the car until there is a point when you can.
If you aren't going faster than the regular traffic in the fast lanes you have absolutely no business in the carpool lane
If all of the lanes on the freeway are going a pace that is uncomfortable for you, perhaps you would be more comfortable on surface streets.
It is your job as a driver to know how many cars are in front of you and how far away they are, how many cars are behind you and how far away they are, what the pace of traffic is in the lanes to either side of you. If you don't know these things you are an unsafe driver.

So, what's the point?

I'm sure that's more than enough of me ranting about oblivious freeway drivers. The same thing applies to software developers (and other team members). You may not be the best or fastest at what you do but it is your job to keep up with what other people are doing to be better and or faster. I'd hope that you're also trying to figure out how you could be better and or faster. Even if you aren't, the one thing you should make sure you aren't doing is holding back others or possibly even the entire team. One or two people clogging up the works is often enough to stall or seriously slow down even the most productive team.

Learning Emacs and Clojure

2010-08-06T00:36:00.003-07:00

I've recently embarked on a journey to learn both Emacs and Clojure (on Ubuntu). I've made some progress learning the basics of clojure and the basics of emacs but I've struggled with getting a development flow going.

I'm going to try and document what I've learned and am learning. I'd appreciate any helpful hints, tips, or comments that people have. While writing this post I stumbled on Curran's blog which has most of what I wanted to capture and a lot more.

Emacs Installation

I'm not sure it's the best way to do it but I installed emacs 23 from the from the ubuntu package manager and followed Bradford Cross's emacs setup steps.

I recently watched this screencast by Stuart Halloway (thanks to Tim Wee) and enabled ido.el by following the instructions on emacswiki. I strongly prefer the file selection with ido.el to the default behavior.

Clojure installation

I also started off installing clojure from the package manager as well but I soon started using the leiningen build tool for clojure. Leinigen makes things pretty easy and manages your dependencies and classpath.

Using Leiningen

(With the lein file in the current directory or on the path

Starting a new project:

lein new <project name>

cp lein <projectname>/

cd <projectname>/

Download Dependencies:

lein deps

start a repl for the project:

lein repl

starting a swank server:

lein swank

TDD Flow

I've only recently started to get any flow when coding. I'm hoping people can give me some tips to make this more effective.

To get set up I run through a set of steps

Open a terminal window and start emacs in the terminal.
Open another terminal tab(ctrl-shift-t) and navigate to the project directory.
If the project is not new skip to step 6.
Add the following to the generated project.clj file to enable lein swank:
:dev-dependencies [
[swank-clojure "1.1.0"]
[leiningen/lein-swank "1.1.0"]
]
Run lein deps to download dependencies
Run lein swank to start the swank server
Switch back to the emacs tab (ctrl-page up)
I have a widescreen monitor rotated to profile so I normally split screen horizontally (C-x, 2)
Start the swank server in one window (M-x slime-connect)
Switch to the other window (C-x, o)
Open clojure test file (C-x, C-f, select file)
Add/edit test
Save test file (C-x, C-s)
"Load the file" to update the state of the repl (C-c, C-l)
Switch to the slime repl (C-x, o to switch to the other window)
Make test fail by executing the unit tests in the repl: (clojure.test/run-tests 'sample.namespace-of-tests) or to run all tests: (clojure.test/run-all-tests)
Implement code to make test pass.
Run tests and watch them pass

MicroSoft's Total Failure System (MS TFS)

2010-07-21T16:36:00.001-07:00

Let me apologize in advance for my exasperation, I've been working with TFS.
My coworker Jonathan McCracken was too nice to MS Team Foundation System in his MVP != MicrosoftFanBoy post. Microsoft will tout that all of the tools are integrated. I would argue that each of the "integrated" tools are pretty close to worst in their class. I enjoy c# as a language but in general I want to use Visual Studio with ReSharper and then get as far away from the other MS tools as possible. Disclaimer: I haven't used TFS 2010 but in my experience when something is this bad it may get a bit better but rarely will be completely transformed.

Version Control

I agree with Jonathan's assessment that Subversion is a better choice for source control than Team Foundation Version Control(TFVC). I think SVN the gap is quite wide. Let's say we want to use TFS for builds and project management but use SVN (or anything else) for version control. To the best of my knowledge there is no way to integrate any other version control system with Team Build.

Better Choices: SVN, Git, and Hg. All of which are free and open source.

Builds

Build Configuration
Let's look at Team Build (appropriately abbreviated TB). Of course to use TB we need to be using TFVC so we'll assume we've made the mistake of accepting that.

TB requires you to name your build file TFSBuild.proj. Upon kicking off a build it downloads the TFSBuild.proj file and rest of that folder's contents to a folder(BuildType) that is nested one level less deep than it's location in source control (TeamBuildTypes/MyBuildType). Not a particularly big deal since the rest of my project won't be downloaded until after it attempts to load the .proj file. Say you wanted to have some shared targets between multiple builds: So far as I can tell, you can't do it. Your .proj file will only be able to use files in it's folder and we've already established that there can only be one project per build folder because it forces it to be named TFSBuild.proj. All I want is for the build files to be co-located with the project and be flexible.

Build Status
I want every team member to be aware of the status of all builds that are relevant to them. TB is integrated with Visual Studio but the interface is awful. There doesn't seem to be an easy way to see the current status of each build type without having to dig through a list of all builds by date.

Build radiators such as a flat screen showing build status or red/green build light are great to have but unless everyone is consistently in view of them we probably need a tray icon as well. The only tray icon I could find would show green any time a build was running. If you have 9 broken builds and one that was in the process of building the icon would show green!

When a build fails on TB I almost always have to dig into a raw log to find the details as TB seems to have no intention of giving me the relevant information. Part of this is probably due to that fact that many of the unit tests were NUnit tests.

Local Builds
In the past while using NAnt running a build before check-in on a developer machine has been a piece of cake. With TB 2010 I've heard that the option is to shelve some changes and then queue up a private build. This is still more complicated than just kicking of a build at the command line and will not work at all if disconnected. Rather than embracing NAnt and NUnit and making sure they we're integrated they instead created MSBuild and MSTest to kill off NAnt and NUnit.

Better free/open source choices: Hudson, CC.net(when I last used it in 2005 probably more so now.)
Better Paid options: Team City(free for small projects), Go(formerly Cruise)

Project Management

I have minimal experience using the project management part of the suite. This is due to the fact that almost all of the clients I've worked with have chosen not to use it, even those who seem to blindly take whatever MS gives them.

Better Free Choices: Anyone have suggestions here???
Better Paid Choices: Mingle, Version One(last touched in 2005)

Question
What would your preferred tool set be if you were starting a .net project today?
Considerations: scalable to a large enterprise, easy to use, easy to integrate, easy to maintain,cost

My default toolset would look something like:
Source Control: SVN or Git if the team is distributed
Development Environment: Visual Studio w/ ReSharper
Continuous Integration Server: Team City(free for small teams), Hudson for larger teams or organizations
Build Scripting: NAnt
Unit Testing: NUnit
Project Management: Mingle(free for small projects), ?? for larger projects

Other than Visual Studio and ReSharper I've avoided anything with a price tag. There are paid tools that I might prefer but for my default I don't want anyone to be able to kill the setup based on budget.

I can have most of this set up on my local box in about 30 minutes or set up on a server for the team in a couple hours.

Sustainable Growth

2010-04-11T23:05:00.001-07:00

After reading Ross Petit's interesting article on Supplying IT Mercenaries it occurred to me that there is another reason that companies who try to focus on supplying wealth generators(as opposed to income generators) end up having resort to supplying mercenaries so frequently. Sell side firms often see growing the size of their forces as the key piece in increasing their wealth.

There is a limit to how fast you can effectively increase your forces before the structure becomes unweildy and begins to collapse upon itself. New forces take resources and time to be appropriately integrated. In good times highly growth oriented sell side firms attempt to grow as fast as possible. Supplying inadequately aligned/integrated forces to wealth generating engagements tends to sour those engagements.

Because forces seem to be flying out the door, the structure to support these forces lags behind. When a down cycle comes this overgrowth and lagging infrastructure is exposed. Given the high cost of adding forces, the company attempts to avoid removing forces at all costs. The misaligned forces make it difficult to avoid contraction with wealth generation, thus the company turns to supplying mercenaries.

Given the other effects of supplying mercenary forces that Ross mentions, I think that sell side firms would be better off to focus on maximizing wealth generation from existing forces and growing at significantly slower than maximal rate. While this will likely lower income at peak levels it should also make the troughs less deep. If hiring and integrating new forces at a more manageable rate helps the firm to avoid mercenary work, this would also lower attrition. It's possible with the lowered attrition that the firm might even grow at the same rate over the longer term with fewer bumps along the way.

Pointing Stick

2010-04-09T12:31:00.001-07:00

I'm against the use of the mouse in most cases. That's not to say that I'm particularly good at avoiding it. It requires you to take your hands off the keyboard and breaks up the flow of what you are doing. There is a solution to this problem, the pointing sticks in the middle of the keyboards. These don't require you to stray nearly as far from typing position. They works pretty well but require that you're typing on a laptop(an IBM or Dell to be specific). When you are working on a desktop and not a laptop you're pretty much screwed. Looking around on the web I've seen very few options and most of them have limited availability at best.

In my ideal world I could get something like the Microsoft Natural Ergo Keyboard 4000 but with the addition of a pointing stick. You might say that there are usb keyboards which have a touch pad on them but touchpads aren't nearly as integrated and I detest the clunkiness of using them. This is my opinion and is certainly not unanimous. It took me a week or two of using a pointing stick to start liking it.

Why is this such a big deal for me? Even on a desktop, I like to type with the keyboard sitting on top of my thighs. The side effect of this is that the mouse is nowhere near me. My alternate computer usage has been sitting on the couch with my computer hooked up to my HDTV. If you've ever tried to use a traditional mouse on the couch you probably know how quickly the pain comes.

While my desire for a desktop keyboard with a pointing stick may not be all that common it's certainly not unique. Why don't there seem to be keyboards which meet my requirements? I'm guessing patents and the company or companies holding them (IBM?). Does anyone have any good solutions?

My QA Value Proposition

2010-04-06T00:13:00.000-07:00

I've heard and observed that Quality Analysts/ Quality Engineer's(QA for the purposes of this post) are often valued a lot less than other members of software development teams. Here are some of the reasons I've heard in support of this view:

Following a script and clicking through a website is easy, anyone can do it.
We test so we don't need someone else to do it.
They never find any real bugs.
We'd rather just have another developer.

I don't agree with the perspective so I thought I'd lay out what I think the QA value proposition is.

While the entire team must take ownership of the quality of application, the QA's are the shepherds of that quality. If you are simply tossing an untested application over the wall at QA, they will be scrambling(usually ineffectively) to clean up your mess. To be effective, QA's should be full fledged members of your team, co-located with your team, testing in-phase with your team.

While QA's perform a good amount of manual testing they also help create smoke tests, help determine acceptance criteria, help write acceptance tests, and monitor performance testing.

While QA's may follow some test scripts, they also monitor browser compatibility, find creative ways to break the application, and have keen attention to detail. They are also able to step back and notice things that escape your eye after viewing the functionality in your story for the thousandth time that day.

Good QA's help expose defects, find work-arounds, and help the business to prioritize them. They monitor, minimize, and mitigate the differences between other environments and production.

While it's certainly possibly to successfully develop quality applications without formal "QA", having good QA's around makes it much easier. I think they are every bit as valuable as other members of the team.

When people don't see much value in QA's, I generally think they haven't worked with a good QA or have only worked in environments which make all but the most basic QA work impossible (i.e. "After 6 months, here is our first testable release. We have to be in production in a week. Good luck.").

I'm sure I've left out many other things. How else do QA's provide value to projects?

Offshoring Software Development isn't cheap

2010-03-31T22:19:00.001-07:00

I have some thoughts on offshoring that I'd be interested in getting some feedback on. Agree/disagree at will.

If a software developer (BA,QA,PM, etc.) is little more than a typist then it makes perfect sense.
If I send work offshore it costs me 1/X times my onshore rates.

Let's assume the average skill level is more or less the same onshore and offshore. This has been my experience with my fellow thoughtworkers.

To make things easy let's also assume a programmer in your favorite offshoring location (I chose India because it has the best food :) ) commands a salary that is 1/9th that of an onshore developer. I made up this number based on the first salary numbers I could find on the net. ( Indian developer ~10k USD (~450k INR), US developer ~90k USD) If I'm way off let me know in the comments.

Even the most optimistic person will agree that there is some additional overhead that goes along with this setup. For Example, network connections between the offices, additional development servers, and a certain amount of overlap of roles in each place. Given our 1/9th multiplier these costs seem pretty minor.

There are other more substantial issues:

Employee morale decreases on both ends when people constantly have to work late or get up early to have meetings across a wide spread of time zones.
Network sluggishness makes sharing a common code repository difficult and leads to long check-in cycles and/or painful merges.
Communicating requirements through typed documents is not effective and is even less so when crossing cultural boundaries.
People are blocked and can't continue their work because they need answers from people who are not available.
Transparency is often low within a single office. It's almost non-existent when you add many time zones and thousands of miles to the mix.

The drags on productivity listed above can be mitigated to a fair extent:

Have team members alternate spending chunks of time working in both locations. Getting to know all members of the team and working side by side with them in the trenches will increase morale, communication, and transparency. Video conferencing equipment can help as well but isn't a substitute for working together face to face. This is a pretty significant cost.
Collaboration tools like Mingle and Cruise can help keep people on the same page and ensure that you aren't stepping on each other's toes. (yep, I'm plugging my employer's products)
Distributed version control such as Git or Mercurial are supposed to help with some of the repository issues.

When all of this is added up does offshore development actually cost less? What have you observed?

My hypothesis is that on average the chances of poor outcomes are higher and the costs may not be significantly different.

Why do I suspect that this is the case? Here's an anecdote for what I imagine is the average case of offshoring:
Company A spends a lot of money on their in-house product development. CTO Smith observes that development is slow(and getting slower) and that Company A is getting a poor return on their investment. Because programming is like typing, they need more typists... at a lower cost. They hire a larger number of programmers via the lowest rate offshoring firm available. The project starts slowly. When the project is well behind schedule the answer is to increase resources significantly, incurring additional cost. Not much if anything is delivered and the quality of deliverables is very low.

This is not a condemnation of offshoring. It's a condemnation of that idea that a company which doesn't run consistently successful projects onshore will be successful in running projects offshore. It's a challenge to find high performing people. It's a challenge to run successful projects. Even under good conditions some projects will fail. Offshoring adds additional challenges.

Is it worth it to take on these additional challenges?

I think in many cases it is. If we reviewed successfully offshored projects what would we find? My guess is we'd find consistently successful deliveries with costs in the realm of 1/2 to 1/3 what it would cost to develop onshore(I just made up these numbers. Lawyered!). These companies took the opportunity to scale up(or replace?) their already successful onshore development operation. They would do so by creating a high end offshore team.

Assuming my hypothesis is correct, I further suggest:

Quality BA's, Developers, QA's, PM's are hard to find. Offshoring should be utilized to scale up because you will have a larger pool to draw from. You will assume additional risk however you may also save a significant amount of money.
If costs are really the main driver for outsourcing, I think a company considering outsourcing should do two things: 1. Take a long hard look at why development is so expensive (and/or results are so poor) in your organization. What makes you think doing things offshore will produce different results. 2. Consider co-locating the entire team, including stakeholders and business owners, offshore for the duration of the project.
Project success is impacted much more by the abilities of the people on the team than where the project is developed. if you're hiring average typists, you're probably ok. If you're hiring average software developers, you're in for a lot of pain regardless of where they are physically located.

What do you think?

Consulting Engagement Success Indicators

2010-03-29T23:05:00.000-07:00

Whenever I roll on to a new client there are a few things that I find to be leading indicators for the success of the engagement.

How long it takes to get a badge/computer/access to the building. Hopefully this stuff is ready and waiting when you arrive. I have seen cases where a badge takes a few weeks and a computer takes up to two months. It's particularly awesome if they won't provide you with a computer and won't allow your computer on their network. If I don't have all of this stuff by the end of the first week on the client it's a bad sign.
The amount of time it takes before I hear the first mention of filing a ticket. Something like "Here is your laptop, if you want a mouse or keyboard file a separate ticket for each and we'll get them for you." I've really come to hate the words "file a ticket", particularly when preceded by "I forgot to" and followed by "so that won't be ready for a few weeks."
Availability of client personnel. If the people I'm supposed to be working with are MIA or are splitting time with a bunch of other projects I lose a bit of confidence.

I used to have a few more which seem to have slipped my mind. Do you have any other early indicators for project/engagement success or failure?

agile : large companies :: recovery : heroin addicts

2010-03-29T21:35:00.000-07:00

How are large companies like heroin addicts you ask?

They make excuses and/or deny the problem. My favorite is: How bad could we be? We're a billion dollar company! When I hear this, I wonder how many companies have gone billion dollar balance sheets to bankruptcy in a short amount of time. Think about Amtrak, the major airlines...size won't save your business.
They can't maintain focus and their priorities shift constantly. The new highest priority is either the shiniest thing in view or whomever is shouting the loudest.
When they do decide to change, they're often only partly committed.
During the transition, managers are paranoid that you're out to get them. They think the changes will take away their kingdoms. Developers are paranoid that people will find out that they don't know how to write a test. QA's are paranoid because nobody tells them what to expect until they don't have enough time to deal with it. The business is paranoid that they're not getting a return from their expensive IT department.
They often flounder through short lived attempts to reform before reverting to their old ways. Management goes back to constant fire fighting. They could quit fire fighting if they wanted to, but this stuff is extremely important!

Recovery for many large companies is about as likely as it is for a heroin addict. It is possible but it usually requires a few things:

They need to hit rock bottom. A five year project that cost millions and delivered nothing. A few days with the production servers down and money flowing out the door.
They need to be committed to making serious change from the top of the organization to the bottom.
They need to treat the problems that led down this path in the first place.

Given the challenges that companies face in transitioning to agile, what do they need to increase their odds of success?

Guidance from people who have successfully transitioned. I don't mean a coach or two for a couple days. When transitioning, the team generally needs to have at least 50% experienced practitioners for at least a few months. To successfully go below the 50% threshold requires a very high level of motivation from those adopting the agile mindset and XP practices. Even with high motivation, it will take one on one support or the drive to spend a lot of extra time on their own.
Cross-functional teams with a strong preference for co-location. The more inter-team hand-offs it takes to get a project developed and deployed, the less likely the project is to succeed. Getting the stakeholders, BA's, developers, QA's, support staff, and IT dedicated to this cross-functional team and to share the same physical space will increase the odds of success significantly.
Transparency. Bring out all the warts and underlying issues. Make sure everyone understands the problems and issues at hand. If people don't agree that there is a problem, they're unlikely to participate in solving it. In the worst case, a project can be cancelled early. in the best case, problems can be mitigated or resolved and the project delivered.
A shared vision of where the business wants to go. It's very difficult to put full effort into going somewhere if you don't share the same map.
Some quick wins. If team members see signs of improvement, it can help them sustain their efforts through the instability and insecurity that comes with any change.

Why Scrum is Easy and XP is Hard

2010-03-29T16:25:00.000-07:00

I recently read Cyndi Mitchell's article on The Half Agile Path and I agree with her that "We are failing to advance good agile engineering practices at anywhere near the pace that we are advancing agile planning practices."

While I also agree with Cyndi that it is difficult for management to see the value of pairing and other engineering practices, I disagree that this is the main reason that these practices aren't usually put in place. The much bigger reason is that Scrum at it's most basic(not most effective) is mechanical. Anyone in an organization can understand and apply scrum practices. Short iterations, standups, product backlog, burn down. Hey we're agile right!!!

On the other hand XP practices like pairing, TDD, refactoring are much more difficult to learn and take a lot of time and effort to become effective at. I think you can learn these things most effectively by working one on one with people who are already experienced at theses things. This makes the cost of getting people to be moderately effective at Scrum fairly cheap and the cost of getting people to be moderately effective at XP practices very very expensive. A fair number of people will never get there. Additionally TDD and refactoring are made much harder by the large amounts of tech debt that have likely accumulated in the code base.

With a development staff of 5-20 the costs of technical up-skilling may be possible to finance. With a development staff of significantly larger these costs quickly become exorbitant.

How can we overcome this problem? I've spent a lot of time thinking about how to increase the technical ability of non-small organizations over the last few years. I've seen and been involved in a few different approaches and have some ideas. I'll save that for another post. Has anyone had consistent success in overcoming this?

Office Recycling

2010-03-23T20:30:00.000-07:00

I'm noticing an annoying trend at the client locations where I've been working. The number of recycling bins in the offices are sky-rocketing. Why is this annoying you ask? Don't you want to recycle? Don't you care about the environment?

While I certainly have some thoughts about those last two questions, they aren't the reason for my post. The reason for my annoyance is that the total number of bins hasn't changed. Corresponding to the sky-rocketing number of recycle bins is a plummeting number of waste baskets. In many of the offices I've been in lately desks and cubes each have their own recycling but there are only a few waste baskets. The planners of this no doubt imagine that trouble finding a nearby waste basket will cause people to generate less waste. Unfortunately, what actually happens is that people just start throwing their trash away in the recycle bins. If the goal was to simply change the color of waste baskets to blue then congrats and mission accomplished. If the goals was to get the recycling and trash separated by the people generating them then these efforts have failed miserably. We're now at the same place we were 10 years ago, we can either pay people to separate the mixed trash and recycling or we can get cans side by side.

White Space

2010-01-23T16:41:00.000-08:00

Ok I'll say it. I hate checkstyle. More specifically, I hate quite a few of the standard checkstyle rules. What do the following code snippets have in common? That's right, there's a good chance that they'll cause the checkstyle limit to be exceeded on my current project, for the following reasons:

There is no space between the ) and {
The { is on a new line
There is a space before the )

Too many checkstyle violations will cause the build to fail. To remedy this enough violations will have to be manually fixed. That's the annoying part of it. In my mind these type of white space differences are completely insignificant. I know there are many of you out there who obsess about this stuff and I won't get you started about tabs vs. spaces. I will say that unless you have automated code formatting run on all modified files before check-in you should not have checkstyle failing your builds. How much time has been wasted splitting string constants because they are over a certain number of characters? How to avoid this type of BS:

Any white space formatting you can't live without should be automatic and not require user action.
Only fail your build on errors, not warnings. Also, the violations listed above should be set as warnings.
Before spending any significant amount of time feeding the checkstyle, fill out your TPS cover sheet first and have it ready to go.

Beyond Business Casual

2010-01-23T03:38:00.000-08:00

As in "There is no good reason to go beyond business casual". For some reason many individuals and companies have decided that the more dressed up a person is correlates positively with how much they have to offer as well as how productive an employee they are. I would argue that where you dress on the scale (from anywhere above a greasy stained t-shirt up to a basic suit) indicates almost nothing. I wouldn't mark someone down for dressing at the level required by their company's dress code but I would say that dressing above what is required is correlated negatively with skills and positively with the playing politics. If we lived in the land of Pride and Prejudice this would all make sense but shouldn't we have moved beyond using this kind of thing as a proxy with which to measure people. There's a reason all politicians and many sales people wear suits all the time. They literally have nothing of value to offer. When this is the case, it makes sense for them as individuals to spend all of their time trying to give the false impression that they are powerful and important. Isn't it time we stopped buying into it? They always have their excuses. I have to keep up with the competition. First impressions are important. Shaking hands and kissing babies isn't as great for my image if I'm not dressed to the nines. How about developing a real value proposition? When I run into companies who are unusually casual for their industry(WAMU, Southwest Airlines for example) I often find that they are known for lower prices and friendlier service. I fairly consistently push the lower boundaries of the dress codes wherever I go. I applaud people like my co-worker who showed up to work in a plain white t-shirt and jean shorts this past Friday. Assuming you aren't wearing a bikini or mankini the odds are good that nobody will question you. If someone does, you either need to make yourself more valuable to the company or find a place to work with fewer folks who think that dress codes add value.

Moving Windows Mobile contacts to Nokia

2009-12-22T19:17:00.000-08:00

I've bought a new Nokia E71 and I was looking to transfer my contact list to gmail as an intermediate step to adding all my contacts to my new phone. I stumbled onto this help article which helped me to sync them up. The steps are for a windows mobile phone but I also found a set for the new nokia I purchased. Once they are sync-ed you can use gmail to merge any duplicate contacts. One sweet side effect of syncing was that all of my gmail contacts buddy icons will display on my phone when they call. Quick and painless, just the way it should be.

Transitioning to open source

2009-11-16T04:19:00.000-08:00

I'm now contributing to an recently open sourced project . I'm finding that the process of trying to help the project get going to be full of interesting challenges. Before I dive into that, I'll provide a little background. The Ludwig von Mises Institute is a non-profit organization dedicated to promoting the Austrian School of economics and spreading the ideas behind the economics of freedom. Educating people about economics and freedom are particular interests of mine which is what has drawn me to the project. They have open sourced the code for their websites as well as the books, papers, articles and media owned by the Institute. The project has been open source for about 9 months an has not gotten much in the way of code contributions aside from the original programmer who has been working on the project in his spare time for about 5 years. Like many projects and most single developer projects in particular, the projects has grown organically without automated tests. Little attention has been paid to the amount of effort necessary to get a development environment up and running. There is a large amount of data access directly in the UI tier as well as a large amount of business logic in the database. Changes are manually pushed to production and some changes seem to be made directly to the production environment. The feature request list consists of a few tasks as well as the output of a brainstorming session. How can we take this project from a one programmer show to a thriving open source project?

Lower the barriers to entry - As I mentioned little attention has been paid to the amount of effort necessary to get a developer workstation up and running, and why should there have been. On a single programmer project there is no cost associated with this, the original developer has it compiling and running on his own machine and should he need to set up another he more or less knows what it takes. Getting it running on my local machine for the first time took a couple of days. For an open source project this kind of up front cost is unacceptable. Even most of those who are highly motivated to contribute will give up fairly quickly if they can't see a direct path to making valuable contributions. Most of the first week and a half or so that I've spent on the project has been dedicated to easing the process of getting up and running.
- So far: Checked dependencies into source control. Set up a command line build which is able to build and run the app(including a local copy of the databases with some data) with minimal configuration after being checked out of source control.
- Yet to be done: Ensure that the data makes sense in the context of the app and comprises a representative subset. Add more detail around installing prerequisites for running the app.
Decrease the risk associated of change - Pretty quickly after starting to look at the code I realized that I had no confidence in being able to change it without breaking something, or perhaps even everything. For example I pulled the business logic classes that were in the web site out into a separate assembly. Getting the app compiling again was pretty easy but there were a couple places that the classes were loaded via xml that had been broken. This went unnoticed for a couple of days. I'd like to have a wide array of unit, integration, and functional tests. The majority of the code is not unit testable. I'm not comfortable structurally changing it to be unit testable without some form of regression available.
- So Far: Installed CI to ensure that the code and databases compile after each check-in. Explored the code and application to better understand the domain.
- Yet to be done: Add integration tests and/or functional tests in the areas where a feature is to be developed, refactor to a unit testable condition when those tests are in place. Add unit testing for areas of the code that I changed.
Deliver business value - I'm shocked and saddened that this is the third thing on my list! I've been working quite hard for a week and a half and I haven't delivered anything of value to the Institute. I can't decide if I should have delayed some of the build and ci related tasks and left them to be done in the near future. On one hand I could have have knocked out a few tasks. On the other hand a couple of fellow Thoughtworkers are willing to contribute and were able to get going much more quickly than I was. Another challenge is clearly going to be communication bandwidth. The team members working on the project are distributed across the world. In addition it's being developed in people's free time which makes it even less likely that their availability will line up to allow communication.
- So far: Some tasks and brainstormed ideas have been added to a wiki
- Yet to be done: Determine who the Business Owners and other stakeholders are. Gather some user stories in a standard format (As a ... I would like to .... so that ...?). Help the stakeholders to create a prioritized list. Address availability of requirements or lack there of. Wrap up non-value generating tasks so Business Value can go to the top of the list where it belongs.
Generate interest and buzz - I think David and the folks at the institute have done a good job of generating interest in the project by getting the news out there. I agree with his assertion that getting more people to contribute more than just talk requires getting some exciting stuff done.
- Yet to be done: Deliver, Deliver, Deliver.

I'd appreciate any ideas, thoughts, comments, criticism, etc so feel free to fire away.