Project Aardvark Revealed

Project Aardvark is a relatively novel publicity stunt organized by Joel Spolsky, the current grand master of small ISV publicity techniques.  The idea is to have a team of interns churn out a whole product over the summer, all while being filmed for a documentary.

From Yaron’s latest Project Aardvark blog post:

On the name front we had a meeting today and decided on the final name.  It’s all registered and a preliminary site is even uploaded.   Good luck finding it 😛

Much ado has been made about dropping hints as to what Project Aardvark does and how secret it is, but come on.  It’s a registered domain on a public webserver.  It’s not going to stay secret very long if you taunt people like that.  Eventually, some inquisitive soul is going to go looking.

In this case, the inquisitive soul is me.

I present the “secret” product of Project Aardvark:
From the site:

SidePilot allows people to help their friends, relatives, and customers fix their computer problems by temporarily controlling their computers via the Internet. It costs $9.95 for a day pass, or you can try it for free for five minutes

In short, it appears to be a competitor to

There you have it, folks – the big secret revealed.  And being the savvy marketer he is, I’m sure Joel is pleased as punch that someone took the bait and went looking for it, because now all the buzz-y conversations will start.

You’re welcome, Joel.  :p

Unavailable = Effective?

I’ve told you once, and I will tell you 1,000 times more in my career:  if you are not 100% unavailable for at least 2 hours a day, you probably aren’t getting much done that’s of any importance.

Although I not-so-famously disagreed with Jason Fried on the issue of functional specifications, I find myself 100% in agreement with Jason’s position on spending time alone.  Jason’s recent post demonstrates a solid understanding of what it takes to be effective and productive:

Getting in the zone takes time which is why interruption is your enemy. It’s like REM sleep – you don’t just go to REM sleep, you go to sleep first and you make you way towards REM. Any interruptions force you to start over. REM is where the real sleep magic happens. The alone time zone is where the real productivity happens.

I couldn’t have said it better myself.  But Jason takes it one step further than even I did:

So, what do you do if you aren’t 8 time zones apart and forced into alone time? You require it. Set up a rule at work: make half of the day alone time. From 10am-2pm, no one can talk to one another (except during lunch). Or make the first half of the day alone. Or the last half. But make sure to make the alone time zone contiguous – interruptions kill productivity.

Wow.  Half the day!  It seems excessive, but I like it.

We live in a grossly over-connected world, and I am convinced that the communication overhead we all have to put up with makes our professional efforts feel like running a marathon while knee-high in molasses.  I don’t think anyone can challenge Jason’s’ assertion that developers are most productive when nobody else is around – in fact, this stands for most jobs in most industries.

As usual, I can hear all you would-be artiste types getting ready to use this as a justification for refusing to communicate with anyone, ever but bear in mind that before you can set up a no-interruption schedule, you have to actually talk to customers, co-workers and managers alike to figure out what it is you’re supposed to be building.  And yes, that might include writing a functional spec.  Deal with it.  😉

But in general, yes – be less available.  Be more defensive of your time.  Be as in control of how your time is spent as you possibly can.  Your clients may whine at first, but once they see the results, they’ll thank you.

Interesting Responses To “11 Clients” Article


I seem to have stuck a chord with some folks – both good and bad – with my article about 11 Clients You Need To Fire Right Now.  I’ve gotten more feedback on this piece than on anything else I’ve written to date.

From my eMail:

“Don’t expect to stay in business for very long with that attitude.”

“Without burning bridges, you just enumerated a series of client archetypes that we have all worked with.  Great job!”

“You can’t just fire a client if you are under contract to complete a job for them.  I hope you get sued for breach, you smug ass.”

“I’ve always been afraid to stand up for myself against abusive customers, for fear of losing a contract.  But if you can do it, maybe I can too.  Thanks for talking about this!”

“You are now #1 on my list of vendors I will never work with.”

From my discussion forum:

Fletch writes, “I can think of a great topic for an article called “The One Software Developer Who Should Be Fired Right Now.”

John Borkowski writes, “Every one of the clients listed in the article will cost you money– at best by wasting your time, at worst by not paying at all.  If anyone honestly wants to serve clients like that, I have about 30 referrals for you.”

Gary writes, “If a vendor broke a contract with me because he didn’t like the payment schedule or because he decided I wasn’t a big enough fish, I’d see to it that vendor never worked in my industry again. Period.”

Around the blogosphere:

Eric Wise writes, “I couldn’t agree more.  It always amazes me when clients consistently pay late knowing that my company has employees and subcontractors that I’m responsible for.  I often wonder how they would feel if mysteriously their next paycheck was a month late.  Generally though I don’t consider this a client firing event unless the lateness is extreme.”

Kevin Dangoor writes, “I think everyone who has been doing software for a while has worked with some suboptimal clients.”

Joey deVilla writes, “I’m certain that Hawkins is speaking from real-world experience; I’ve seen a number of these client types from my consulting days and from horror stories told around the bar at developer gatherings.”

Overall, traffic has spiked by 100% in the past two days.  It seems as though the other consulting pros of the world have felt the same pain I have with regard to abusive clients.  Of course, the bad ones serve to help me remember to appreciate the good ones.

A word about breach of contract, which seems to be a relatively common concern when discussions of firing a client come up:  don’t you all write termination clauses into your contracts?  The client might decide they don’t like you, either, and want a way out of the contract.  Nobody wants to get up every morning and either work on or pay for a contract he is unhappy with.

In general, my company has a policy that either party to a contract can cancel for any reason with 10 days notice.  Work to date must be paid for in full, of course, but if a client isn’t happy with our service there’s no way I’d try to strong-arm them into staying.  And it works going the other way as well.

Is my company the only one that does this?

11 Clients You Need To Fire Right Now

Since I’m constantly writing about what developers do wrong, it seems only fair to address problem clients as well.  I recently had to terminate my business relationship with a couple of clients, and a couple more may be on the way.  I know I’m not the only one, so perhaps these insights will be helpful to other independent operators.

Everything in nature has a life span – creatures, relationships, weather systems, everything.  We rarely know how long that life span will be, but once something’s life span is at an end, it is usually obvious.  The same is true of client relationships.  Sometimes, it is necessary to fire a client in order to serve the bigger picture of what you want your business to become.

Now, it’s one thing to suggest that some clients are best avoided to begin with, but considering the way most small businesses operate right on the razor’s edge, it sounds downright crazy to say that you should actually get rid of current clients!  But it is the truth. The relationship between client and provider – like every relationship between human beings – must be a value-for-value proposition in order to survive.  This is commonly referred to as a “win-win” scenario.

Technical projects are tough.  You can crack open a textbook and find the classic 7-step project management methodology, but out here in the real world, strange things happen.  People don’t always do what they say they will do.  Things take longer than expected.  Third parties toss the occasional monkey wrench into the works.  These kind of things have to be taken in stride while keeping your eyes on the prize, so please don’t get the impression that I’m suggesting you cut off all your clients for any perceived infraction.  Odds are, you do something that bothers your clients on a semi-regular basis, too.

That said, over the years I have noticed certain abusive behaviors that are highly problematic and are often symptoms of behind-the-scenes issues that you have no control over, but that will affect you negatively anyway.  So when you notice these abusive behaviors, stop to think about your past history with the client before terminating them.  Now, on to the specifics.

The 11 Abusive Client Types

You should fire your client if the client consistently proves to be one (or more!) of these abusive types:

THE DISILLUSIONED consistently expresses disappointment with your work even though it is of good quality and conforms to spec.

I used “and” instead of “or” because as we all know, just because something is to spec does not mean it is of good quality. 😉  As you gain experience and complete more and more projects, you will discover that certain clients are not satisfiable.  They ask for x, you give them x, and they complain that they wish it was y.  You can do your due diligence, be cautious when gathering requirements, lead the client through a thorough analysis of where they are and where they expect the project to help them go, and even receive positive feedback throughout the various project milestones.  Sure, they signed off on the spec.  Sure, they saw the deliverables every week and approved them.  Sure, they told you that you were doing great.  Yet, once the project is complete, the client is crestfallen.

What happened?!?!

If you held up your end – and you need to be really sure you did so –  nothing happened.  You just had the misfortune to take on a chronically unsatisfied client.  The problem is, this dis-satisfaction is likely to result in being badmouthed, stiffed on an invoice, or even dragged into court!

A client who is constitutionally incapable of appreciating your work is not a client you should be involved with.

THE SUSPICIOUS consistently expresses a lack of trust, disdain for your work, or questions your integrity.

There really is something odd about software development (and other types of computer-centric work, such as graphic design) that makes people think they can just pick it up over a weekend( I think it has to do with the ubiquity of the PC as a tool, and the fact that people confuse the tool with the skills, but I digress).  As such, you will sometimes encounter a client who regards you as something of a scam artist, someone who is charging premium rates for doing what (in his mind) essentially amounts to typing.  “After all,” he thinks to himself, “my 15-year old nephew seems to know his way around the computer, and he only charges $10/hour.  Why, I’ll bet I could get HIM to build an enterprise-class ERP system instead of this Christopher fellow, and save myself a bundle in the process!”

Once you become entangled with someone who regards computer work as some sort of overpaid custodial function, you will never be able to submit an estimate, fix a bug or even suggest a solution without being second-guessed and third-degreed to death.  If your credibility starts over at 0 at the beginning of every conversation, you will be spending valuable time explaining yourself that could be used doing something with some sort of economic yield for your client.  This is not a situation you want to be in.  I guarantee that no matter how many times your client forces you to spend two hours to explain the 15 minutes you spent refactoring his data access code, if these kind of things happen to add up and put you behind schedule, your client will not share the blame with you.  This goes double if you have that special flavor of suspicious client who will not allow you to speak to their IT department, ISP or previous developer for fear that you will all plot against the client.  Being the guy with whom the buck stops can be a lonely road to walk sometimes.

A client who is constitutionally incapable of trusting in your expertise is not a client you should be involved with.

THE CHISELER consistently complains about your bill, even though it conforms to the estimate they agreed to.

So you did your job with regard to setting expectations, you wrote out an estimate that mapped back to the functional spec so everyone knew exactly what was being built and what it was going to cost, and your client signed off on the estimate.  Not only that, but you managed to beat your own estimated by 5%!  Congratulations, you’ve done a great job!

So why is your client complaining about how expensive this project is when they had a chance to either sign off or bail out before the work ever started?

It is said that there are no price objections, only value objections.  But if you did your job correctly, the client was provided with enough documentation to know exactly what they were buying and what it would cost.  Assuming you did your job right, you’ve likely stumbled onto another form of chronically unsatisfied client – the kind who is always disappointed with the bill, even if he is happy with the delivered work.  Some folks really do want something for nothing, it seems, and they will use passive-aggressive tactics to try to get you to lower your bill.  Some will even go so far as to refuse to pay, even though the invoice is less than the estimate.  Don’t fall for it.

A client who is constitutionally incapable of honoring a deal is not a client you should be involved with.

THE BULLY consistently is verbally abusive or threatening to you.

I don’t think this even needs an explanation.  We’re white-collar professionals, not street thugs.  Any client that will curse you or attempt to physically bully you (believe it or not, I’ve seen it happen) needs to be dropped with all due haste.

THE SOMETHING-FOR-NOTHING consistently increases the scope of the project but refuses to pay for the additional work.

Estimates are a funny thing.  The very word “estimate” means approximation, not precision.  However, it is often the case that when a client receives an estimate detailing “x cost for y units of work,” it is read as “no more than x cost for as many units of work as I ask for.”  I don’t know why so many clients seem surprised to learn that if you change the specifications, the amount of work involved – and therefore the total cost of the work – changes, but this is the case more often than not.  I also don’t know why so many clients treat an estimate as though it is written in stone.  Although a service provider should take great care to produce as accurate an estimate as possible, it is still just a highly-informed guess.

But I digress.  As I said above, when you change the work to be performed, you change the cost to perform the work.  It is a simple relationship.  But it is often the case that a client will ask for an additional feature – a BIG one – and then express some combination of shock, disgust, resentment, or even outright anger when the estimate is revised upward to account for the additional work.  Certainly these folks don’t add items to their grocery purchase after the cashier has totaled them up, expressing shock or anger when the cashier adds the price of those items to the existing total.  So why do it with software projects?  Again, I suspect this has something to do with the ubiquity of the PC and the inclination of non-technical people to mistake the tool for the skills, but I’m digressing again.  The bottom line is, x amount of work costs y amount of money.  If you change x, you change y.  It really is that simple.

A client who is constitutionally incapable of offering additional value in exchange for additional value is not a client you should be involved with.

THE SLOW PAY consistently pays invoices late.

In any small business, cash flow is king.  Heck, in any large business, cash flow is king.  So let’s just say:  cash flow is king, period.

Once you and your client have come to an agreement on payment terms, so long as you are keeping up on your deliverables, your client should be keeping up on his payments.  Jack Welch once said “If it’s Friday and you got paid, you and the company are even.”  Well, this applies to business as well.  It’s tough to have a healthy relationship if one party feels as though the other has gotten “one up” on him.  Well, the best way to keep everyone even is for you to make your deliverables on time and for your client to pay the bill on time.  Anything less than that from either of you means that the other is being taken for a ride.

A client who is constitutionally incapable of paying a bill on time for work that was delivered on time is not a client you should be involved with.

THE FLAKE consistently is late meeting responsibilities, but still holds you to the original schedule.

We’re all well-versed in the classic three-dimensional attributes of a software project: time, cost and features.  We’re also probably well-versed in the problems that can come along with servicing an undisciplined client who cannot meet his responsibilities according to the project schedule.  This by itself is one thing, but when the client is in charge of action items that are blocking other action items, it is a problem.  This problem is compounded when you are expected to deliver the project on time despite these blockages.  If you’ve done your due diligence but your client consistently cannot or will not fulfill his end of the project agreement with regard to approvals, copy, design meetings, etc. then your client has no business thinking that his tardiness with these items will NOT impact the schedule.

A client who is constitutionally incapable of understanding that in order for a project to be delivered on-time, everyone must meet their obligations is not a client you should be involved with.

THE LIAR consistently lies to you.

Again, this doesn’t even need much of an explanation.

A client who is constitutionally incapable of being honest with you is not a client you should be involved with.

THE BLACKMAILER consistently refuses to pay an invoice until you perform additional work at no charge.

I see this a lot, believe it or not.  The Blackmailer is a special subset of the something for nothing.  Instead of taking umbrage, he takes hostages – your dollars.

Suppose you and your client disagree on the accuracy of an item or two on Invoice A.  Further suppose that Invoice B is also due, for a project unrelated to what’s being billed on Invoice A.  This brand of client will refuse to pay Invoice B until you see things his way on Invoice A, even though they are totally separate issues.  This is nothing more than good old-fashioned blackmail dressed up in a flannel suit.  The proper way to handle this is to pay Invoice B when it comes due, then either continue negotiating Invoice A or pay the uncontested amount and THEN negotiate the remainder of Invoice A.  That’s win-win.  Blackmail is always win-lose, and anyone who believes in win-lose in a business relationship needs to be cut off.

A client who is constitutionally incapable of engaging in good-faith dealings is not a client you should be involved with.

THE MONEY PIT consistently is unprofitable.

There can be many reasons a client is unprofitable.  In essence, a client is unprofitable if they take up far more time and effort than the fees you are able to charge them are worth.  In many cases, this can be a client who demands cut-rate prices, extra unpaid support, or who repeatedly does things that require you to work harder.  Heck, it might even be your own fault for agreeing to a bad deal – it’s happened to all of us.  Just like your client, you are in business to make money.  If you and your client are unable to work together in a way that allows you to make money while providing good value to the client, it’s time for that client to go.

A client who is constitutionally incapable of offering you a fair rate for your services is not a client you should be involved with.

THE CLINGER consistently makes unreasonable demands regarding your availability.

In this business, you’ve got to be available to support your clients.  We all know that.  However, there is a certain standard of reasonability that must be applied to how determine how available you should be.  First off, I have a well-known and often contested belief that if you are NOT 100% unavailable for at least 2 hours a day, you probably aren’t getting anything done that’s of any importance.  But at the same time, I’m saying you’ve GOT to provide reasonable support.  Well, certain clients don’t care about reasonability, they want the emotional payoff of seeing you get cracking on their latest request…NOW!  If I have scheduled development work on the calendar, and a client calls in with an “urgent” request for a new feature, if that client is otherwise stable and the request is not a bug fix, that client is getting put in the next opening on my schedule.  They are not getting put at the front of the line just because they want a new feature built by next Wednesday.

This is actually good for the client, as it helps them to impose discipline within their technology projects.  And as I’ve said before, it is good to tell your clients “no” sometimes, so long as you have a good reason for doing so.  Anyone who calls with a bonafide emergency gets taken care of right away, no questions asked.  But “hey, I thought of this cool new feature, can you have it done by tomorrow?”  No chance.  As a service provider, you are not a member of staff at your client’s company.  You are an external provider of services and although you need to available for a reasonable amount of time on a reasonable amount of notice, you will never be able to provide good service if you practice interrupt-driven development.

A client who is constitutionally incapable of applying a “reasonable man” standard to requests for your time is not a client you should be involved with.

Letting them down Easy

There’s no need to be rude with a client, although you should be firm when it is time to dissolve the relationship.  Not mean, not haughty, not “now I have a chance to get back at him for being mean to me/wasting my time,” but firm.  Once you’ve made the decision to terminate, have faith in your own judgment and don’t even entertain avenues of conversation related to NOT dissolving the relationship.  Rejection is powerful stuff, and an abusive client – much like an abusive lover – will be spooked enough to say anything to avoid allowing the rejection to be final.  People react very strangely to the word “no.”  Clients – particularly abusive ones – are not at all accustomed to being told “no.”

Before you signal your intent to terminate, get your ducks in a row in order to make things easier for both yourself and the client.  Have their invoices to date prepared as both hard copy and PDF.  Have any client-owned project materials that are in your possession boxed up and ready to FedEx to them.  Have any source code or database scripts that they have paid for burned to CD and ready to FedEx as well.  And if you can do so, have a referral to a different provider ready for them – preferably a provider to whom you have spoken to and qualified as being interested in taking on the client and the project.

As far as the “how” of terminating a client goes, I have done it both face-to-face and via eMail and phone (due to distance).  Despite the fact that I am not conflict-averse, neither way was easy.  I suspect that most of you will be somewhat conflict-averse and prefer to use the phone or eMail.  Be careful – remember that eMail does not convey any kind of tone or vocal inflection, and runs the risk of coming off as brusque or cold.  I suggest that you make a list of your reasons for firing the client and review them for your own clarity, but do not get into an argument with the client – each point you bring up is ammunition for an argument about why that item is not really grounds for dissolving the relationship, but you’ve got to avoid unproductive conflicts.  Stay polite, no matter how hot the client gets with you – remember, you are not trying to exact revenge, you are just trying to save yourself from further abuse.

As a service provider, your game needs to be tight.  You need to be delivering on your promises and staying on top of your projects.  If you are doing so, and you are being abused by one of these 11 client-types, you need to seriously consider nipping the relationship in the bud and giving yourself an opportunity to let the void fill with higher-quality business.

Do Your Clients Ever Make You Furious?

If so, I offer a free 10-day e-mail course that can help you resolve exactly the kind of conflict that’s outlined in the article above.  Paying late, not responding to emails, arguing about art direction…enough is enough.  Sign up for Conquering Client Conflict today and learn to make more money & get more respect by squashing these conflicts.

On Functional Specs and Project Pitfalls

Revised on 13 May, 2015

I found a good post about functional specs when I was reading Ian landsman’s blog this morning.  Ian notes the different opinions on whether or not writing functional spec is a good idea – one camp claiming that spec is purely a political appeasement move, and the other claiming that  spec is vital to a well-written app – and ends up coming down on the side of those of us who write functional specs.  Good show, Ian!  He also wisely notes that functional spec is best done in small bits.  I agree – the bigger a single iteration of spec is, the more likely it is you missed something.

There is a reason that I included inadequate/unclear requirements amongst The 5 Pitfalls of Estimating a Software project – this problem is HUGE in the industry and it cannot be solved by saying “specs don’t work – don’t write specs.”  It’s true that ultimately you need people to agree on the functional spec, just as it is true that they eventually need to agree on a user story or an interface mock-up.  This doesn’t not make the functional spec an appeasement document, though.  If anything, the process of developing a functional spec should get people talking about – even fighting about – what task experience the app needs to provide.  The biggest fear a developer has is to deliver an app only to be told “that’s what I asked for, but it’s not what I want,” and the process of developing a functional spec – done correctly – will avoid this. That’s why I’ve always advocated that every project needs at least – dare I say it – a small spec.

Having said that, I’m going to leave this here:

SmallSpec - painless functional specs

SmallSpec – painless functional specs

Ahem.  Moving on…

Why did I qualify my previous statement with “done correctly?”  Simple – too many developers have an “order taker” mentality when it comes to developing a functional spec.  A client or project manager will rattle off a list of wishes – “Yeah, this program needs to cure cancer, gnarfle the garthok, walk my dog, do my taxes, and make me a sandwich.  It’s pretty simple, you should be able to do it in about 2 hours.”  Now, at this point the developer can go one of two ways:

  1. Say “yes, sir” and shuffle off to make a half-hearted attempt at doing what he knows is impossible, only to be driven to drink and beat his children when hopelessness finally sets in, or
  2. Push back on the client or project manager, challenging their demands; “no, that doesn’t fit in-scope (unless we make adjustments elsewhere in the project)

I’ll give you three guesses what a good developer will do.  😉

When developing a functional spec, it is your obligation to act in a consultative fashion and challenge your clients assumptions and requests.  This is not McDevelopers – you don’t simply serve up whatever the client in the drive-thru orders through the speakerbox.  It is your job to protect the client from himself.  If you find that even after developing a functional spec, the delivered app is met with “that’s what I asked for, but it’s not what I wanted,” then odds are you have failed your client in some way.  Note that I did not say the spec has failed – you have failed.  Perhaps you didn’t probe deep enough.  Perhaps you let some assumptions slide.  Perhaps you didn’t lay out the different scenarios your client’s requests could lead to clearly enough.  I’ve been there, and it is painful to not only let your client down but fall flat on your face with your release.

Controlling scope creep is also part of doing functional specs correctly.  One can claim that functional specs inherently lead to scope creep because it is easy to add something to a Word document, but I disagree.  I think weak developers lead to scope creep.  Again I say – a good developer will not allow this to happen.  A good developer will push back.  “This change conflicts with xyz” or “This change will double the cost of abc” or “This change is not technically feasible,” etc.  When it is obvious that the scope of the project is in jeopardy of changing, a good developer will speak up and offer suggestions.  In some cases, the developer must be willing to stand firm and say NO.

Functional specs don’t fail.  Developers do.

To be fair, the “don’t write functional spec” guys were primarily designers at the time, although over the years they’ve built one hell of a software empire, and presumably still don’t believe in functional spec.  Even so, a designer is dealing with a different set of concerns than a developer is.   I get the impression that some people have a mental image of a functional spec that is just a massive, Steve McConnell-style Word doc with endless bullet points and no interface examples.

This is not how I do my specs here at Cogeian Systems.  Rough wireframe UIs are always liberally sprinkled throughout my functional specs to illustrate what the text is describing.  However, I don’t go into tremendous detail in the spec, nor do I go off building a real, functioning UI until it has been decided what that UI should do, and how it should do it.

A good functional spec should get you on the right side of the 80/20 rule.  Given that, it’s natural to allow for some discovery-as-you-go. And as you make these discoveries, your spec should become enlightened as you do.

I will stick with the approach that has made my projects successful – committing the application experience from a user POV down on paper in an appropriate level of detail in the form of a functional spec – and vetting it with the users – before writing a line of code or building a working interface.