This Year's posts

Archive for December, 2008

how to work with me

Monday, December 15th, 2008

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.)

Moving on from inursite

Monday, December 1st, 2008

Starting today, I’m going to be stopping work in The site will continue running, but I may have to scale things back a bit to make it more affordable to operate.

I started to scratch an itch. After its initial launch I realized that there was a latent demand for something like it, but not quite exactly like it. I spent quite awhile trying to figure out what that should be.

I talked to a lot of people about it, I spent a couple of months working on nothing but inursite (with no client work, that meant burning through savings) with the idea that if I can find something that could take off and become a sustainable business within a few months, I’d pursue it.

Along the way I figured out what inursite should be (at least, I have a working hypothesis). The problem is that my hypothesis doesn’t fit into the one-man-bootstrapping model I’m currently working with. I don’t want to give up the model (though I also don’t think working on projects alone is ideal for me).

I promised myself if I couldn’t get it to take off within a few months, I’d move on to another project and give that a try. So, that’s what I’m going to do, albeit 3 months later than the self-imposed deadline I’d created for myself.

Anyway, I already have a new project in the works. You’ll hopefully hear more about it soon.