Programmer for Hire

Like everyone in my profession I get approached by folks who are interested (or at least potentially interested) in hiring me to turn their business vision into a live, working web application.

If all of the maxims of self promotion (the vital importance of networking, having strong references, keeping clients happy so they’ll continue to hire you, etc.) are true (they pretty much are), it is of course in my best interest to say yes to any project that (a) I’m qualified to do, (b) I’m available to do in the called-for time frame, and (c) my price is acceptable for.

Saying “no” based on any of these criteria isn’t terribly interesting as most everyone holds to those three prerequisites for accepting work (though based on the regularity of client horror stories with their past vendors, it would appear that a lot of folks in my profession relax a little on point (a), but that’s for another essay).

What’s more interesting is saying “no” to a project when, by all conventional measures, it amounts to good, gainful employment while providing a client with what they know they want.  I do this now and then, and I do it specifically when deep down I don’t believe in the project.  When yes, they’ve got the money and yes, they’ve got the drive and vision enough to pull the trigger, yet I can’t wrap my mind around how this is ever going to work in the envisioned capacity.  This is when my conscience pipes in, objecting to thought of taking money for a project that I don’t believe will ever bear fruit for the individual or organization willing to pay me.

Am I fallible in my estimations?  Absolutely.  I don’t pretend to know for certain how things will turn out.  But I have done enough projects that had a lot of heart and a compelling vision which turned out to be ultimately a poor idea (and in hindsight could have been recognized as such with knowledge available at the start).  For it I can recognize hints of blind optimism when I see them.  Red flags of assumptions or impending obstacles that are unaccounted for jump right out and insist upon careful consideration before I can dismiss them.

This, while perhaps annoying as rain on someone’s parade, I believe is to everyone’s benefit.  My being unwilling to take a client’s money and diligently complete the work when I can’t get behind a project might be the most generous bit of consulting I can give when confronted with a flop¹  If I send you back to the drawing board because I think the project has major weaknesses², I might well be viewed as insolent and unworthy of hiring in the first place.  But deeper than that, I might well be doing you a huge favor, helping you to either (or both) save a lot of money & time, and refine your ideas so that they do ultimately succeed once a guy like me is brought in to bring it to life.

Though it breaks my heart to turn down good gainful employment, I do not hesitate to render this favor when appropriate.

By corollary, if I’m excited by your project and think it has legs, I’ll tell you as much and (if you care to hear it, most people do) explain exactly what specific merits I see it having and why.

There’s probably a good litmus test in all of this.  Useless flattery to lobby for getting a contract is bankrupt.  If you wanna sense for how much your success matters to your developer, throw a deliberately terrible idea their way and see what they think.  Whether they they greet it enthusiastically or balk at it, ask follow up questions and you’ll really learn something about who you’re talking to as a service provider.

If I say “no” to your project, take it as a sincere gesture of commitment to its success.  My doing so might either help you dodge a bullet, or prompt you to retool your vision in a massively useful way.

Notes:

I like to create games.

Games that motivate.  Games that create focus, pressure, supreme concentration.  Done right they can be a fantastic hack for programmer productivity.

A few weeks ago I set out to build a working prototype of the DealNation members zone in a single day.  To make it interesting, I let everyone in on the game.   At 9:45am I setup my day as a collection of mini-milestones in building the system from start to finish, each with a target completion time, and put the progress chart + time line on the office whiteboard for all to see.

I had declared my fate for the day, and effectively given my word to “this is what will get done with every passing hour today”.  Folks were curious to get that kind of high-resolution look into how I work, and I promised they could view the work in progress as I pushed each mini-milestone to our dev server.

To make it more real and pressing, I openly advertised my progress throughout the day.  When a milestone was completed I would rise from my desk, write the actual completion time on the whiteboard, and settle back into my trance-like concentration at the computer once again.  No chit-chat, I was on a mission and everyone knew it.  Green marker meant I was on time, red meant I was behind.

At the end of the day, this is what everyone in my office got to see:

Yep, I gave it a zany, over-the-top name. Whatever, it's my game.

There are a lot of payoffs to this structure.  First, this day was a ton of fun for me.  It was like being in the zone of pure productive concentration for a hour, 7 times over.  I had zero problem blocking out distraction, and the mini-race to the next milestone keyed me in with renewed focus each time (it’s WAY fun to write the next actual time on the board, and striving to use the green marker keeps it interesting).

The final show off was the grand prize.  My team was delighted to see all that got accomplished in just one day, and I think their sense of appreciation was heightened by being vicariously in on the process along the way. This is about as close I know to the experience of performing for an audience as a programmer, and it creates a certain buzz which theatrical and musical performers will understand.

I recently had a good sense to add this new boilerplate section to my standard project contracts:

3.5 RIGHT TO DEMAND SATISFACTION

Acceptance of this agreement includes the right to demand satisfaction for all described features, no more, no less.  I’m on the hook to complete all the described features to the point that you love it, and you get to demand satisfaction to that extent.  So do it.  If you’re not happy, and you haven’t exercised this clause, you’re technically in breach of this agreement.  Just sayin’.

In my years of experience I have never been burned putting myself on the hook called “my work is not done until you love it” , so I realized that I may as well get the benefit of advertising as much up front.

I don’t know that this sort of clause exists anywhere else in my industry.  Flippant language aside (which in my estimation is rad: if that sort of playfulness backed up solid performance turns you off, you’re not my client anyway), I think there’s a general fear about having to appease some fictional, nightmare client who is endlessly demanding.  In my experience, when it comes to my world of web programming, they don’t exist¹.  Oh sure, there’s always room to want more features, or a cheaper price, but that’s not what what’s on the table here.

This here is a promise to do great with all of the [meticulously outlined] features within the scope of work at hand.  Software development is generally a complex endeavor so I think the average bear understandably shies away from such a tall promise.  Fair enough.  I embrace it.  It keeps me honest and fosters a healthy pride in my craft, and if I just bring my art to it using my full facility with leading edge technologies and tricks, I don’t have to worry about falling short.

So I don’t fall short.  If my first attempt isn’t loved by my client, they tell me and I tweak accordingly.  No fuss, no muss².

That’s the second beauty of stating up front the right to demand satisfaction: it creates a conversational dynamic between my client and I that deliberately CALLS FOR that kind of feedback.  We become partners in the endeavor to create software that perfectly suits, and they have a role to play called “speak up if you don’t love it.”  When the invitation to do that is clear and on the table it is easy and fun to exercise, and moreover doesn’t get compromised by a desire to be polite.

Notes:

Here’s an actual email dialog with one of my favoritest clients, identifying bits changed to honor confidentiality:

We have an idea for a SuchAndSuch iPhone app. Can you recommend a great developer?

Yep.

Mother fuckin’ me.

John

That’s what I like to hear. We’ll chat soon.

There’s something great about knowing you are completely qualified to take care of someone’s need, and communicating as much in no uncertain terms.

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.

In my experience, some of the formality of programming for hire seems to precipitate an unfortunate reliance on email for communication in lieu of picking up the phone, and this goes both ways: client to programmer, and programmer to client.  There are a number of reasons for this that I can see:

• The stereotype that programmers are anti-social and/or need to concentrate (a client might think “maybe I shouldn’t call them and interrupt their programming mojo”).
• The reality that programmers are anti-social and/or need to concentrate (a programmer might think “if I call them we’ll get wrapped up in all kinds of winding dialog about out-of-scope feature requests and what-ifs”).
• An unclear working arrangement for that kind of time spent (does phoning up the programmer hotline rack up billable hours?).
• A perceived notion that an email, being less intrusive, is a better way to respect the other party’s time.

These are all valid reasons, but the downside of being stuck with them is the [largely hidden] downside that lurks in relying on email communication for such a thing as software development.

Software development is complex.

It’s not necessarily hard, but it’s complex: there are many small parts that come together to make up the finished product.  The process of creating it is therefore is ripe for ambiguities, misunderstandings, and varied interpretations of the same stated intentions.

The antidote?  Clear and fluid communication.  Communication that does not require formalities like a scheduled meeting with 2 weeks lead time.  My ideal is being able to pick up the phone, get my client up to speed on what’s going on, and answer whatever questions are on the table.  Five minutes is par for the process, and when it really works we end the call feeling like genuine collaborators building something great, clear that our visions are aligned and we’re on track.

By email that kind of satisfaction just isn’t possible.  If I have a question, there’s a decent chance that what I’m asking won’t be fully addressed by the email answer I get back, and an even better chance that I’ll have a follow up question precipitated by that answer.  The minutes both me and the client have spent typing up our correspondence quickly passes the five minute mark, and the back and forth doesn’t do nearly as much to bolster a sense of team, or confidence that all is progressing smoothly.

That’s why I like to encourage that kind of accessibility: I want my clients to call me up when they’ve got something on their mind pertinent to the project, and I request of them license to do the same.  I have yet to have a client abuse the privilege or even come close to doing anything that could be called wasting my time.  When I come across a design decision I hadn’t considered and don’t know enough to pick what will be best for the business, I love calling my client and getting them in on the scenario.  It gets them interested and involved in new opportunities, and lets them be more at the helm of getting exactly the end product they want.

This pertains to more-or-less corporate development projects, where projects are invariably rooted in a real bottom line intention.

If your developers aren’t hip to the surrounding business lingo, or don’t have time (or inclination) to learn the bigger picture  (like which kind of customers are going to be using it, the anticipated ROI, or what the customer support team really needs, etc.), make sure you’ve got a translator to bridge the gap.

On one side, a good translator will ensure that the business brains devising the project aren’t overlooking some great opportunities that tech could offer to solve the problem, and that they aren’t asking for what turns out to be a technical nightmare for only a minor gain.

On the tech side a translator will make sure the programmers don’t get carried away with the “cool factor” (tech for the sake of tech), and that instead what they’re churning out is a real fit for what’s intended.

The net result on both sides is that a good translator will keep a project on track, true to it’s original need, and ensure that the technology being employed is a good fit for the problem at hand.