A business meeting
morna.nl
morna.nl
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.
The last thing I find is people thinking SQL can solve all the world's problems to "create" new things : )
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.
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.
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.
Good. It is an opportunity to charge extra for fixing the mess. And if they don't make a mess - tough, you had charged too much in the first place.
Very few businesses are interested in getting paid once if they can get paid twice, so this pattern is perpetuated to the mutual benefit of everyone except the developers forced to spend 50% of their time building something they know won't work, and the other 50% rewriting it...
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.
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.
Funny thing is, this goes both ways-- Mr. MBA also doesn't know how to explain a subject with which he is intimately familiar in a manner friendly to people without his knowledge. Yet, anyone who doesn't grasp his latest master plan must be an idiot.
Stereotypically speaking, I find that most techs tend to have a bit more empathy when it comes to explaining things than the business people have.
Would that solve the problem?
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.
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-...
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.
Actually, come to think of it, TFA provides some good ones. If a customer has contradictory requirements, just tell them they're asking for a line that is red and green at the same time.
The article is written in such a way as to highlight Smith's dismay and frustration due to his colleagues' questions and suggestions. As a reader you are left with no idea why the Redroot does not see that a line cannot be red and green at the same time.
In practice this is exactly the bridge that Smith must cross otherwise the meeting ends in disaster. To do this it's not just a case of speaking in simple terms (though this is often effective), it's a case of figuring out what the other people will consider to be 'simple', in practice this /could/ be something quite complicated - especially to Smith since he is not used to thinking in this way.
When the client still isn't happy he adds an "Advanced" dialog to let the user specify an augmented transformation matrix ...