the ryan king

I’ve been doing contract consulting work for the last year, since I left my “last ‘real job’”. Looking back on all the projects I’ve worked on this year, I’ve noticed a lot of similar problems.

The biggest theme is that I get hired to work on feature X, but I first have to spend a month building all the prerequisites for feature X. Or setting up some architecture or infrastructure. Or fixing a broken test suite. You get the point.

The next thing I tend to see is that we spend a lot of time trying to figure out what exactly it is I am to do and how we’re going to coordinate the work.

What I’ve concluded is that there are some things that my clients can do to improve the process of working together. Also, if a team doesn’t do all of these things, I’ll still work with them, but I’ll likely suggest that I work on this list first.

• test suite

  One of my grad school professors spent endless hours trying to convince me that being strict about things like testing and MVC actually made you more agile over the long run. After a few months of working on projects in the “real world” I often couldn’t remember why I wrote a piece of code the way I wrote it, which meant that I didn’t know what I’d break by changing it. If I’d written tests I’d be in a much better situation.

  Of course, a test suite is only valuable to the extent that it covers the full usage of the software. 100% coverage is rarely worth the effort, but there is plenty of good to be had from high levels of coverage (in the 90-100% range). In general, make sure it actually tests what it needs to do.

• continuous integration

  Not as big a win as just having a test suite, but it’s a good way to nudge you towards having the suite remain unbroken. The more important step is having an agreement on your team to keep the test suite up to date. This agreement requires investment from people who don’t write the code.

  The continuous integration system should also produce code coverage reports, so that you can keep an eye on how well your test suite is doing at testing your code.

• a vision

  You don’t need a detailed long term vision, but if you want help at the architecture level, I need to know what’s at the horizon, which will be a different amount of time, depending on the stage your company is in. If it’s a brand new startup, a few weeks might be the horizon. For an established company it could be years.

• a plan

  Who’s working on what? How are they doing to do it?

• a schedule

  If you’re planning on a release/launch anytime soon you should know the prerequisites for launch and an estimated date.

  Your plan schedule and priority list are all interrelated. My working hypothesis is that you can only decide two of the three, with the other one being derived from the previous two. Note that this is related to the project triangle concept.

  Typically the way I like to work is to set the vision and schedule and figure out the plan from that. So, your vision could dictate features A through Z, each of which would take a week of work, but you’d like to launch something within a month, so we plan on doing features A-D.

• one-step dependency setup

  In rails, rake gems:install should give me everything I need. I’m sure there are equivalents in other languages and frameworks. If not, there should be.

• shared workspace for design/planning

  Whatever you do, don’t email me a Word or PDF document.

• appropriate level of access

  If you want me to help you improve your architecture, I need to know what your current architecture is. Seems simple, but I’ve had this problem before.

• if it’s important it should be written down

  This is mostly a collaboration issue. I’m fine with spending time in your office or with the occasional phone call, but if the only way to get things done is by being in your office and talking to people face to face or overhearing others’ conversations, I’m not going to get much work done. The work of building software requires (at least for me) times of deep, focussed thinking that can’t be done in a room with twenty people talking to each other. Also, I find that meetings are generally a waste of time, because most people (myself included) don’t know how to run meetings effecively. So, unless you’re very good at running meetings, they should be kept to a minimum.

(Thanks to Cameron, Eric and Randy who all read drafts of this. Of course they didn’t give me any constructive feedback, they just told me to go ahead and post it.)

This entry was posted on Monday, December 15th, 2008 at 10:43 pm.