Archive for 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 inursite.com. The site will continue running, but I may have to scale things back a bit to make it more affordable to operate.

I started inursite.com 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.

Election Thoughts

Wednesday, November 5th, 2008

A collection of random comments from last night.

  • By far, the best moment of the night was when someone (who would remember) said: “this feels like Kennedy”. It seems all of the “we’re making history” sentiment is not imaginary.
  • I didn’t think I’d ever see masses of people on the streets of San Francisco chanting “USA! USA! USA!”. You see, the left coast liberal elite loves America too, we just sometimes can’t get excited about it.
  • McCain’s concession speech reenforced by belief that he’s a good man, who I happen to disagree with on many points, but still a good man. Unfortunately, campaigns exist to win, and will work to win at all costs.
  • Obama’s acceptance speech reenforced my belief that his even-temperament is his best quality. Can you imagine how different the last eight years would have been if we’d had an executive leader who made decisions with full information, made them methodically, and didn’t allow his emotions to dictate policy?
  • In case you still wonder whether third party candidates can affect elections, Missouri is still too close to call today, and the gap between Obama and McCain is smaller than the number of votes received by the fifth place candidate. Currently: McCain: 1,442,613; Obama: 1,436,745; Nader: 17,769; Barr: 11,355; Baldwin: 8,181. Source (as of November 5, 2008, 2:53 PM PST)

Rack::Cache is a good idea

Monday, October 27th, 2008

Fellow Ryan, Mr. Tomayko has recently released a new project, Rack::Cache that I think is a great idea for ruby web developers.

This problem has actually been bothering me for awhile, too, but I could never articulate it well enough or think of a useful solution to it.

The problem is that if the application is small and new, its rarely worth the effort to deploy an caching http proxy, yet you can still get significant benefit from something that caches entire resource (an entire page, rather than just the data that goes into rendering that page). As a result, Rails allows you to use a page cache, which writes the files to a filesystem and lets a dedicated web server serve them, without consulting your web application.

This system works fine if your cache policy is simple enough to manage it explicitly, your application has access to the same filesystem as your web server and you’re only running a few servers. Also, it can be tricky to get your web server configuration right on this front.

Once your application gets larger and more complex, it makes sense to use an http reverse proxy cache like squid or varnish, but transitioning from rails-style page caching to HTTP caching is non-trivial. You have to change your deployment and your application in significant ways. Not fun.

With Rack::Cache you only have to change your deployment. You can even do it incrementally. You could start by using Rack::Cache to cache in the heap, later switch to the filesystem and finally to memcache. When that reaches its scalability limits you can add squid or varnhish in front of your application, then remove Rack::Cache. Deployments that involve only one major change at each step are much easier to get right than trying to make several big changes in a single operation.

inursite free accounts update

Tuesday, August 12th, 2008

After launching the pro version of inursite.com last week, it became very obvious that the free version needed some updating.

So, today we are releasing an upgraded version of the free account. Previously you would only get 5 pages checked for free. Starting today, you can get 1 site checked for free. Use it wisely.

As part of the upgrade process, all free accounts had their 5 pages replaced with one site. We tried to do our best to guess which site you’d want to have checked, but in case we didn’t, you can log in and change it.