Archive

Archive for March, 2011

The Right to Demand Satisfaction

March 23rd, 2011 2 comments

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 exist1.  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 muss2.

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:

  1. This is assuming a contractor is only taking on work that is within their ability to deliver, which is, it turns out, not to be overlooked nor taken for granted.
  2. If I think it’s easy to build software to be loved on the first pass, it’s really easy to do armed with feedback from looking at a real, tangible first attempt
Categories: Business, Communication, Essays Tags:

What Happens if I Get Hit by a Bus

March 8th, 2011 No comments

A fair question indeed.

I bill myself as an ultra effective development team of one, citing of course virtues like eliminated communication overhead, a shorter route from business vision to application design and implementation, nimble ability to adapt the application to changing business needs when they come up, and 100% accountability when it comes to turning out quality.

Oh, and it’s cheap to hire one person instead of six.

So naturally it has occurred to my clients on more than one occasion to ask me “what happens if you get hit by a bus?”  If I’m the guy who’s doing it all, naturally I represent a sizable single point of failure.

Here’s my answer.

You replace me.  Though I do have a publicly documented love affair with Classic ASP, Classic ASP developers are a dying breed, so it would be irresponsible to start any new substantial project for a client in that language. No, anything that’s built to last I would start in PHP or perhaps Ruby on Rails, languages that boast thriving communities of developer talent from which you could draw to replace poor old mangled (or dead) me.

Now then, when you replace me my successor will need to be trained on how to work on the code base I’ve laid down.  If I’m NOT dead I can guide them through to get them up to speed quickly.  I if AM dead the good news is that my code is quite beautiful and well organized, with perfectly uniform indentation and formatting, completely consistent conventions, and immaculately well factored.  Any developer who is worth their salt in the language I have laid down will be able to understand, trace, and build upon my code within one day of poring over it.  (If not, fire them.  Trust me.)

Furthermore, whatever I did manage to complete before carelessly failing to look the other way while crossing that hypothetical street will constitute a massive leg up on your project.  Remember, typical development projects tend to be heavily loaded on the front end with meetings, spec docs, planning, project management, and other such things that don’t get you closer to a usable piece of software.  Before that Greyhound sent me to a better place even a half-completed prototype done by me will have enabled you to shortcut through all of that, leaving you with a sensible solution strategy and design foundation already in existence.

So in conclusion: if I get hit by a bus, you replace me.  You’ll miss me as you move forward at not as smooth or fast a clip as before, but your project will have gotten the benefit of my precious last remaining pre-bus-hit days.

It’s kinda like getting Frank Lloyd Wright to draw up the plans for your house and then he can’t finish it.  It’s still gonna be a pretty snazzy house even if some junior architect needs to rough in details like which tiles to use in the bathroom.

Categories: About Me, Business Tags:

Why I Don’t Negotiate on Price (and Why That’s Good News)

March 6th, 2011 2 comments

I recently quoted $250 in response to a client with a particular feature request.  The reply I got was asking if I could add this feature for $125, citing perfectly good and valid reasons of it not seeming like that much and a desire to keep costs down.

Here is my exact reply:


Nah,

Whenever I let a client name the price I turn into a poor businessman indeed, and it puts me on a slippery slope of devalued self worth trying to please clients who will nickel-and-dime me and don’t really value my time.  Most damaging is that it tends to prevent me from doing the great and interesting things with my talents that I’m committed to doing in this lifetime.

Poetic waxing aside, I have a LOT of real world data that the price I charge for the value I provide is above-average fair and, relative to other vendors, sometimes ridiculously cheap.

Now then on this particular price, I’m not hosing you to make a couple extra bucks as though I were a shoe-in for the work: between transitioning mentally from other projects, sorting out your request, pre-pondering the best solution, doing the coding (which I reckon is what you figure should cost $125, and reasonably so), testing it, launching it, testing it live, being generous with any tweaks/enhancements you might request (has it been your experience that I’m fairly generous with these?  It is my aim that it has, and please let me know if I’ve fallen short!), and the sliver of added complexity that it entails for future maintenance/trouble shooting, I stand by my estimate of 2 hours.

(A common alternative to this is quick, get-er-done style work where one change breaks something else, perhaps familiar to you! :)

That said, you might have noticed that a lot of items in the list of things above represent the overhead of doing a non-trivial amount of work of ANY size, and you would be right to think that that sort of overhead is roughly constant no matter how much substantial work is to be done.  I do my best to have evolving and tweaking a system be as fast, easy and painless as possible (and I understand I do pretty darn good at it relative to my industry), but the general rule still always holds: that we’ll both always get a better value for our time and money the more you can batch feature and change requests together (a full day’s work in my experience is generally the tipping point).

Whatever you think for this one is totally cool by me.  If the day ever comes that you want to transition from me for any reason, be it price or whatever (or in the event that I need to move on myself) I am completely reliable to be 100% cool and helpful in facilitating that transition.  I’ll even train the next guy on the code and be available for quick questions (in the past for clients I really liked I’ve even done this training for free).  I’m committed that you NEVER have the experience that you’re stuck with me when you could do better.

Whew, that’s lot!  I didn’t mean to talk your ear off with the above, and know that I don’t mind your request at all.  Hopefully you’ve gotten some nuggets on how to get the best bang for your buck out of me.

Cheers!
John


Looking back there are a lot of things about this communication that I like.  It is a candid look at how I work with and honor my client relationships that I am happy to share publicly: it gives some insight as to how to get the best value of out me, reveals that a lock-in is NOT part of my business model, and gives the freedom to choose.  Negotiation-wise there are a lot of points made and I want to add a few more to round out the exposé of my thoughts on the matter.

My stance on not negotiating price serves both me and my clients because it keeps me honest and true to my standards.  Coupled with my willingness to facilitate anyone in transitioning to another developer, it holds me to a standard of being the best and giving the grade-A experience of working with me. If I don’t perform at the level I say I do and thereby someone can get a better value with someone else, I will lose that business and I should.  Short-cut jobs with me are simply not on the table, though the option to get one somewhere else is.

Psychological factors play into it as well.  When I know I’ll be earning what I feel I’m worth for a piece of work, it’s easy and a joy to put the shine on it and go the extra mile, and my clients regularly reap the benefit of this.  By contrast, in the past when I’ve allowed myself to get beat up on price I had to fight against the devil on my shoulder telling me that just meeting the spec-doc minimums was acceptable.  I always won, but those then were the clients I eventually fired.

If nothing else, not negotiating on price forces me to work with the right clients.  For a mom-and-pop business looking to get a website online, I’m expensive.  For a million-dollar company for which custom software is an integral part, I’m cheap.  In some cases ridiculously cheap.  So if I’m getting push back on my price, it’s a sign that we’re not a good fit, and acknowledging that sooner than later is useful for both of us.

And in case you were wondering, my rate of $250 was accepted via email reply 14 minutes later.

Categories: About Me, Essays Tags: