
A business meeting - mietek
http://www.morna.nl/post/4185018780/a-business-meeting
======
SatvikBeri
John Foobar is a 26 year old semi-technical analyst living in Austin who's
sick and tired of Yelp. His favorite Mexican restaurant "Mi pato esta en
fuego" has only received 2.4 stars! John wants to find food that he
specifically will like, not just restaurants that are rated well. As luck may
have it, John happens to have access to a massive amount of perfect data. So
far, so good.

John does some Google searches and finds that a "k-nearest-neighbors
algorithm" might be what he's looking for. He happens to have scored a free
SQL Server license from an old barfly in exchange for listening to his tales
about how wonderful life was when the mafia controlled New York, so naturally
John searches for ways to implement kNN algorithms in SQL.

John finds out that kNN can be implemented efficiently using a spatial index,
but that only works for two dimensions. That doesn't work because John really
wants to judge places by location, price, and the ridiculousness of their
dessert menu. So he spends a few hours trying to hack things together and
finally posts an extremely specific question on StackOverflow about extending
spatial indexes to 3 dimensions. He gets several answers that are technically
correct but don't quite solve his problem and finally gives up, resigned to
eat at popular restaurants for the rest of his days.

But if John had asked about the general problem of implementing kNN algorithms
in SQL, he would have found that spatial indexes aren't the best method.

If he had asked about implementing kNN algorithms in general, he would have
found that SQL isn't the best language for it.

If he had asked about creating recommendations based on like/dislike data, he
would have found that there are better algorithms than kNN, and that there are
several existing GUIs/APIs for these algorithms.

And if he had asked about the general problem of finding good food, well, his
friends might have told him that Yelp already has a "personal concierge" mode
and he just has to click a different setting.

Poor John.

~~~
martinced
Poor John but lucky us!

The last thing I find is people thinking SQL can solve all the world's
problems to "create" new things : )

------
bstpierre
Ha ha. I've been in that meeting -- the one where you have to explain that the
requested feature would violate the laws of physics. I've found that it's best
to keep asking some variant of "What do you _really_ want?" in order to find
out the underlying goal. This usually requires a couple of follow-up meetings
though, because the guys doing the requesting don't always know what the real
goal is.

~~~
gav
I've always considered the first rule of development is to first figure out
what the client actually needs:

Average people will try to build what the client wants and fail.

Good people will build what the client wants.

Great people will build what the client needs.

~~~
DanBC
> Great people will build what the client needs.

Be careful with pricing though. They want something cheap, that won't work.
They need something more expensive that will work. Persuading them may be
frustrating, may take time, may risk you losing the job to someone less
scrupulous than you who puts in a lower quote.

Are you going to be paid for the consultation involved in persuading them to
use the better solution?

Compare two other industries: sign making and electronic sub contract
engineering.

If you ask a sign maker to make a sign with a spelling error you'll get a sign
with a spelling error. It's up to the customer to know what they want, and it
keeps a bright line of expected behaviour from the sign maker.

Similar with sub contract electronic engineering. They build stuff to your
supplied documents. If your documents are wrong they'll build the device
wrong. If they really cannot build the device they'll get in touch. They are
charging you for a service and that's what they deliver. They're not charging
you for design work, and so they don't do that.

~~~
gav
I solve this problem two ways: firstly by being very expensive, charging
several hundreds of dollars an hour; secondly by only working on a time and
materials basis. This won't work for everyone.

Fixed priced projects only work in a few cases where you know exactly what you
are building. They are a lose-lose situation otherwise, with the client
usually being the loser.

------
micheljansen
This sounds like the in-house equivalent of The Oatmeal's "How a Web Design
Goes Straight To Hell" (<http://theoatmeal.com/comics/design_hell>).

Both stories share a similar problem: a designer (or engineer, it doesn't
really matter for this story) is brought in because their expertise is needed.
Then, rather than trusting that experience, the thing is micro-managed to the
point where it is ridiculous (or, as The Oatmeal says, you are just a cursor
in a graphics program, controlled via email). I feel that with design this
happens more, because it's more tempting to believe that their own user
experience is representative of anything more than themselves (the first thing
a proper designer knows NOT to do) and it's easier to get into bike shed
discussions (<http://bikeshed.com>).

I'm bookmarking this, because I might need it in the future.

------
jeroen94704
Definitely got a chuckle out of this one.

However, I think the message should be not be (as many engineers may think)
that non-engineers are unable to grasp basic technical facts, but rather that
engineers are lousy communicators.

Success in business depends on effective communication, especially between
people working in disparate specialist fields. Being able to adjust how you
explain a subject to the knowledge level of your audience is, unfortunately, a
skill that is not commonplace amongst (software) engineers.

~~~
enraged_camel
I'm a Presales Engineer, and a big part of my responsibility is to translate
what engineers are saying into something customers can understand, and vice
versa. Over the past 4+ years I've been at this job, I have come to realize
that this is a very, very rare skill. I don't think it has much to do with
being able to communicate (English isn't even my native language!), but rather
being able to think in abstract terms and recognize patterns among different
ideas.

One neat trick I learned over the course of my career when talking to non-
engineers is to use analogies, especially car-related ones. For example,
trying to explain a named user licensing model to someone who has never dealt
with software licensing before will be a nightmare. But if you say "it's like
having assigned parking spaces, where every parking space is assigned to an
individual," people just _get it_. Whereas an engineer will describe how the
model works from a software perspective, and the non-tech person will just
bang their head against a wall thinking themselves as stupid.

~~~
sopooneo
Very interesting advice re the car analogies. Thank you.

It seems that you are the character in Office Space* that had to madly defend
his job to the two Bobs. In my real world development experience, I find that
you are right about the rarity of your skill, and am always thankful when
someone around me has it.

* [http://www.llakomy.com/Projects/flashvideo/office-space/tom-...](http://www.llakomy.com/Projects/flashvideo/office-space/tom-smykowski-s-interview-with-bobs/view)

~~~
ajankovic
I don't think you understood that scene from Office Space correctly.

In my opinion it was supposed to be ironic. He is supposed to be communicator
but he can't communicate his importance and he is showing very bad
communication skills. After all it was taken out of context.

------
bjhoops1
You forgot the part where Smith attempts to explain in great detail and with
an inevitable reference to Euclid's fifth postulate how 7 perpendicular lines
(which are also referred to as "orthogonal" he might add) are only possible in
7-dimensional space, and that in fact, this can be extrapolated to say that
there is a one-to-one relationship between the number of spatial dimensions
and the maximum number of orthogonal lines which could conceivably be drawn,
but that since we are constrained by the 2 dimensions of the screen and there
is no simple method for displaying spatial objects of dimension > 3 in 2
dimensions, for all intents and purposes the display of 7 perpendicular lines
is not feasible.

------
Cyranix
Of course you can have seven perpendicular lines. It's as easy as embedding a
seven-dimensional graphic.

~~~
nickzoic
... Smith then produces a GUI with 14 sliders for viewing the lines.

When the client still isn't happy he adds an "Advanced" dialog to let the user
specify an augmented transformation matrix ...

------
retube
I don't get it

~~~
kawsper
Do you have an MBA?

