Social Engineering in Software DevelopmentImitating Actions

time to read 3 min | 574 words

The absolutely hardest thing in most projects is to (and I am going to be blunt), to get the customer to shut up and let the team start working. I have been in several projects where the actual move from blah blah talking to actual doing was a painful and drawn out process.

In one particular example, I was brought on as a team lead for a team that had 4 months to produce a system. I was stunned to discover that the last two years were spent in meetings on top of meetings on top of meetings. At some point I flat out abandoned the spec, forced got management approval to talk directly with the users and started supplying them what they wanted. I still consider this to be a horrible project, but at least we shipped.

I found several approach that can facilitate the move from talking to doing. The first one, and the one that I prefer, is to actually start building the software. Now, I don't refer to building the actual production software, but to building a spike of how things are supposed to work. Show it in the next meeting, and I can almost guarantee that the discussion is going to shift radically.

When you put something in front of people, especially since in spike mode you can get things done really fact (no code quality, no error handling, pure nasty coding). In several past projects, I have used this approach to leap over the "let us just get started" hurdle.

The main issue is that the business would like to really understand what they want to do, before asking the developers to do so. But since many things are fixed already, that is, the general concepts are already known, and the devil is in the details, we can start painting the outline of the system in broad strokes and fine tune it later.

The idea is to push the business into that mode. And spikes get us there quickly.

Another method that I have started to use lately (which is even easier than spikes) is the use of UI mock up. Using a tool like Balsamiq Mockups, this is ridiculously easy. It also serve as a great spur to actually starting to do things. Instead of getting mired in details, I can get a pretty good picture of a vertical slice of the application, and go away and actually implement that.

Here is a mock up for the landing page for the NHibernate Profiler web site:


You can see the real thing here. As you can see, it isn't the same at all, but I think that we can all agree that there are marked similarities between them.

This mock up took about 3 minutes to build, and we did that while on the phone and with screen sharing. But it meant that we talked about something concrete.

When you are starting to talk in concrete terms, you have already much closer to getting starting doing something real.

Those are just a few example of initiating actions, actions that can get you to move from the talk talk talk phase into the get things done phase. It is important to make this move as soon as possible, for several reasons. Not least of them is that we value working software over comprehensive documentation and lengthy discourse.

More posts in "Social Engineering in Software Development" series:

  1. (05 Feb 2009) If it doesn't hurt, it doesn't matter
  2. (10 Jan 2009) Imitating Actions