Programmer for Hire

It may be either a sign of laziness or of wisdom, but I’ve had a few conversations of late where I’m deliberately selling my clients on fewer and/or less complicated features.

On the surface this is bad salesmanship: I bill by the project, and of course the price tag for a given project grows with my estimate of the complexity of what I’m building (and hopefully the value gained by the client, as well).  The more features a client is certain they want, the more features I get to build and charge accordingly for that work.

So what’s up with my recent kick of advising fewer features?  Turns out it’s mostly situational with a dose of outside wisdom.  The projects I’m thinking of are both of an “expand in a new direction” variety: one is a pilot program to prove a new concept in their e-commerce, the other is to make a hub for a community to interact online in a way they haven’t before.

The dose of outside wisdom is the 37 Signals bit on the Race to Running Software which states simply “get something real up and get it up quickly”.  Both of my clients found it refreshing to hear things like “Tell you what, it’s just the pilot: we can leave the customer address book feature out for now, and add it in later if it turns out to be important.” and “Let’s see what your users do with just the ghetto-fab system of posting comments.  Then we’ll know what they’re bumping up against, if anything.  If it suffices, we’ll have saved ourselves a lot of extra work.”

Planning to build non-critical stuff up front involves a lot of guesswork and creates a bigger gap between speculation and real world feedback.

Would I like to be hired to build the customer address book feature?  Sure, it’s a tidy little feature that would be really slick and is clean to implement.  But let’s wait to see the first 5 repeat customers who place orders shipped to more than one address before we build it.  That will save time and money while we focus first on getting the system ready to launch at all.

It’s simply having an eye on the prize.  And I’m talking business win, not a juicier contract.

A few weeks ago I was on a conference call with a client talking about a new, expanded direction they were mapping out for their e-commerce.  The scope of the project was well within my reach to execute quickly and thoroughly, but there were good & valid concerns expressed over me being the keeper of the system as a one-man show.  After all, it would not work if a problem arose that only I was trained to address at a time when I was, say, gallivanting about in Panama: it would be irresponsible to structure a major part of their business to be vulnerable to failures that arise with poor timing.

As I’ve mentioned before on this blog, I’m a big fan of the benefits made possible by being a team of one.  I also really like the agility and flexibility afforded by being a solo act in the business aspect of my trade.  So when it was asked if I would hire and train up others to make possible a 24/7 manning and support of the project, I saw it fit to propose a re-framing of the situation.

This particular client is big.  The company has their own dedicated IT department complete with plenty of smart folks who are able to build, run and maintain complex systems.  They are also savvy about outsourcing: they know how to keep their own internal team smoothly handling internal operations by calling in outside talent to help with big initiatives when they come down the pike (which is why were having the conversation at all).

Rather than operate as a separate team on this project, I reasoned, why not have my contribution to the project be an augmentation of their existing resources?  Given they already have an in-house team that works on other things which integrate tightly with their e-commerce, I could do the heavy lifting for the project (that is to say: design and build it to everyone’s delight, and see it through to a successful launch), and then take necessary steps to leave their internal team empowered to own and maintain it with minimal effort.

It’s like building a building.  The work of the architect and the construction crew are distinct from that of the maintenance team and cleaners.  The better job that the former does enables an easier ongoing job for the latter.  In our case of software development I’ll refer to these two parties succinctly as builder and maintainer.

Characterizing a Successful Arrangement

So what are the characteristics that should probably be in place for such a collaborative hand off work to everyone’s delight?  There are a few things I can think of (this list is no doubt exhaustive, if you can name one I missed please leave it in a comment):

• The system handed over by the builder should as clean and intuitive as possible. Clean software architecture rules the day here, and any lingering patch-job hacks represent a great disservice of future burdens to the maintainer.
• The builder should train the maintainer. Without a doubt, the curse of knowledge can easily give the builder a comforting illusion that it should be easy for the maintainer to spot and fix problems the arise.  Rather, a maintainer should be left confident that they know how to navigate the structure of the code.  When they have reached that level it should be their call to make, not for the builder to assume.
• The builder should be accessible to the maintainer over time. Not 24/7 for hot fixes (that would defeat the purpose of handing off to a maintainer), but as an adviser for deeper, more long term issues including building further on the system.
• The maintainer should be technically qualified for the role. They needn’t be as skilled with the code as the builder (after all, it’s easier to maintain a well built system than to build it well in the first place), but they should be able to track down and fix minor bugs in addition to more regular maintenance.
• There should be general camaraderie and a shared commitment as a team between builder and maintainer. While hardest to quantify this is perhaps the most important: it’s a problem waiting to happen if a builder hands off the project with any air of “it’s your problem now”.  When the builder is oriented as a long term partner, his or her priorities are well-aligned with the project as  a whole: “I will do it right because I am ultimately accountable for its performance”.  The desire to avoid saddling the maintainer with a problem is a powerful motivation to set them up well.

These characteristics represent a chunk of overhead of the Augmenting a Team route, relative to using a separate one.  When handing off a project to a separate team, that team is free to manage long-term maintainability internally, however they deem appropriate.

What’s interesting about is that is how, in the scramble to get it launched, notions of longer term maintainability can (and do) fall by the wayside.  When a builder steps in to augment a team on a project, the above characteristics form a nice recipe for clean execution of a project; one that is mindful of both the initial work and long term maintainability.  It’s like having people over for dinner: you’re more likely to clean up your place out of courtesy to your guests.  A builder who knows that a maintenance team will be looking at and learning their code soon will do more to be proud of such a close inspection.

Last week the members of an organization I’m friendly with looked to me to what you might call “spot check” a project proposal that they had received.  It was a sizable project, so there was to look things over to ensure that it, as scoped out, would predictably leave them happy with the result when the work was all done and the fee was all paid.  I looked for answers to the following concerns:

• Are there any disconnects between the expectations of the organization and the contractor’s understanding of those expectations?
• Is there anything missing?
• Is the scope of the project sufficient to complete what the organization wants?
• Are there any gotchas, or foreseeable add-ons that will be needed later?
• Is the time line accurate and realistic?
• Is the price commensurate with the work, and reasonable against industry norms?

Doing this was a great opportunity: I got to exercise one of my more unique abilities to help out some friends, and I got a rare chance to compare how I roll with others in my trade.

What ideas, lessons, or insights did I take away from that comparison?  Plenty, but for now I’m going to focus on the one that strikes me the most:

I’m super inexpensive and work uncommonly fast.

(A corollary to that, I suppose, is that my sales process is rubbish: if I could pitch on a lot more projects a year I could perhaps get away with selling fewer but far less sweet-of-a-deal jobs for my clients.)

After fully grokking the project as laid out and enjoying a follow up conversation with members of the organization, I was clear I would be delighted to do it for literally half the price and could deliver it several weeks sooner, which made me feel pretty darn effective.  My deepest compliment however was what came back to me from the contractor: the presumption that in order to realize such cheap speed I would be using off-shore resources.

Nope, it’s just little ol’ me and my friends at Playground Creative. :)