Programmer for Hire

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.

My recent involvement in spot checking someone else’s proposal really brought home for me an interesting dichotomy in approaches and schools of thought when it comes to spec’ing out a project.  (By “spec’ing”, I refer to the process of assessing and describing the specific needs of a project, and then assigning a price tag and time line to that assessment.)

My training (or, perhaps more accurately, my invented approach from when I started doing this back in the MonsterCommerce days) has taught me to do a rigorous analysis of all facets of the project up front.  I don’t submit a proposal until I can firmly describe what features will be included (to at least the level of detail of which entities the system will model and manage), and am able to assign a price tag to each one of those features.   There are a few pros to this approach that I can think of:

• A pretty accurate price tag for the whole project falls out just by adding up the module costs, plus perhaps some overhead of communication, project management, and/or padding for middle- and end of-project tweaks and revisions.
• I’m clear what I’m committing to so I know I can deliver on time (and not bust).
• My client sees exactly what they’re getting: it’s an opportunity to verify that our understandings align, and they can spot if there is anything missing.
• A sort of a la carte pricing becomes possible when clients can see how various features contribute to the cost: it enables them to tailor things to fit their budget or decide to hold off on certain features if necessary.

The major con of this approach is the time and effort it takes on my part to cook up such a rigorous sketch of the project before I see the first dollar.  The ability to do it quickly thanks to copious practice does well to mitigate this con, however.

The other approach then is of the quick, more glossed over variety.  This is where a price is given based on satisfying the high-level needs of a project, and that price will be set to cover a fair chunk of reasonable expectations to that end.  (In other words it’s like the contractor saying “We don’t need to go into details, I’ll price it so that no matter what specifically you’re thinking I’ll be happy to deliver.”)  I’ve seen it done often enough to know that it’s not uncommon, and there’s good reason for its popularity.  From the perspective of the one preparing the proposal, it’s quick, it’s easy, and though it may be accepted less often, it’s more profitable when it is.

Now with this dichotomy laid out it bears mention that the two approaches I describe are actually two points on a spectrum, one that extends out to greater extremes in both directions than what I describe above.

There is no objective best place on this spectrum to be for both clients or contractors, every point has certain drawbacks and merits.  (I may seem biased towards the detailed end, but rest assured I know the dangers of being too detailed: clients eyes glaze over, and/or they’ll feel locked in by too much contractual rigidity).  Still, if you’re hiring someone to do a project, it’s probably useful to recognize where your contractor is with their proposal: if you get a proposal where the feature scope is fuzzy AND it names a price, you’re probably paying for a big cushion of guesswork.