Tempering Client Expectations (OT)

[Tim Chase]

On 04/12/2010 06:37 AM, Victor Subervi wrote:
> On Sat, Apr 10, 2010 at 3:14 PM, Tim Chase wrote:
>> 1) Preeminently, address second-order ignorance.
[elided kvetch]

"second-order ignorance" is a technical term (not intended so 
much as a slur) for "not knowing what you don't know".  If you 
google the phrase, you'll get several articles/papers on the 
topic (I think I first learned about the hierarchy in an issue of 
Dr. Dobbs or CACM/Queue magazine).  The brief summary is:

0th order ignorance (0OI):  I provably know the material

1st order ignorance (1OI):  I know that I don't know something 
(for me, e.g. sports...I know my sports-knowledge is nigh 
non-existent).  For you, it might be the inner workings of HTTP 
or SQL transactions.  You now know that you don't know it, but 
you could go read up and learn the topics and their best-practices.

2nd order ignorance (2OI):  I don't know what I don't know...if 
you don't know what you need to learn in order to develop a web 
application (so my email's "learn HTTP, HTML, ..." comment moves 
you from 2OI to 1OI because now you have a list of things to learn).

3rd order ignorance (3OI):  I don't know how to find out what I 
don't know (in your case, you've asked the mailing list, just as 
you could ask any respectable web-developer, so you know how to 
find out what you don't know and thus aren't 3OI)

4th order ignorance (4OI):  commonly described as "not knowing 
about the various orders of ignorance" :)

> Pay attention to my question, don't make up your own based on
> your own inaccurate assumptions and answer those, please.

The topic was setting accurate estimates and tempering client 
expectations (TCE).  If you don't have a foundation regarding 
what you do/don't know, you can't set accurate estimates, so TCE 
consists of "I need to learn what technologies are involved in 
doing this, and then learn those technologies".  Once you've 
moved from 2nd to 1st order ignorance, your TCE shifts to "I know 
that technologies X, Y, and Z are involved, but I only know X and 
will have to learn Y & Z before I can produce a satisfactory 
result".  If I were a client, I'd want to know the level/depth of 
my vendor/supplier's expertise.  So perfectly relevant to the thread.

> 4) Don't be afraid to reuse existing technologies:  could installing
> osCommerce on a $3/month web-server and tweaking the PHP code have sufficed
> for what you need?  Could you have used Django+Satchmo to get yourself up
> and running with proven code, tweaking what you need?  I remember you
> dismissing the suggestion to use existing web-frameworks.
>
> <sigh>
> Bringing that up again, are you? I was all but done with the shopping cart
> when you suggested I re-invent the wheel based on another technology. Yeah,
> sure, throw out 10,000 lines of the 12,000 line program so I can rebuild on
> a new technology. Brilliant, that. Thanks for the suggestion. Now, can we
> get back to my question?
> </sigh>

If you're throwing out 10k lines of code that has only seen one 
core developer and hasn't been tested in the real world against 
real hackers satisfying real customers; and you're replacing it 
with a proven-in-the-real-world framework that has been worked on 
by multiple professional developers, then yes, that's exactly 
what I'm suggesting.  It hurts to throw away that much work, and 
I've had to do just that (in my case, printing from PocketPC 
devices, having written my own printer-drivers for mobile 
printers).  There's an personal attachment to code you've spent 
hours upon hours writing.  But unless that effort nets you big 
wins over merely tweaking a proven solution, your hurting your 
customer(s).

>> 6) As for "Tempering Client Expectations" (the subject line
>> of this OT post),
>
> Ah, so you *did* recognize what *my* question was! Good!

If you're just realizing that by the time you get to item #6, I'm 
glad to see you read my entire email before getting testy. </sarcasm>

> True. I ended up taking a bath on it, and I believe that was
> merited since it was my first client project. Now, I'm dealing
> with scope-creep and trying to work my way out of it, and
> looking ahead at how to avoid complications like this in the
> future.

Heh, my wife and I joke that in those "can this marriage be 
saved" newspaper columns, every answer boils down to 
"communication is key".  Keep the customer tightly in the loop 
with regular communication -- frequent feedback regarding 
progress, costs, and whether your shared understanding coincides 
helps prevent developers from wandering off for 6months only to 
come back with 6mo of costs for a project that doesn't meet the 
client's expectations.  The customer may cut you off if progress 
is too slow or costly, but the earlier that happens, the less 
pain for both parties.

-tkc