|
rule of engagement, #1
"Never work for someone that doesn't know the difference between a branch and a loop."
http://bigfractaltangle.com/archive/2004/01/09.jsp
Timothy Falconer
Saturday, January 10, 2004
Sounds to me like the guy didn't want to deal with people anymore so he made up some rules as a scapegoat. Hey, if you want to run a service oriented company then you have to deal with people. Even if you decide to switch to a product based company, you still have to be able to deal with people.
Saturday, January 10, 2004
Same ol' Same ol'. Here we have a consultancy that wants to "help" people by writing software for them. Read "help" as make money off of them.
Rule #1: You don't and never will fully and completely understand your customers business.
Rule #2: Your customer really doesn't NEED the software you are making for them. Did they contact you or did you sell them something they don't need. If they contacted you were you truthful in representing the fact that they actually needed the software? 95% of the time I've found that people do not need custom software. Especially small businesses. I recommend they buy a ready made accounting package or whatever off the shelf software satisfies their needs and then I teach them how to use it and set it up for them.
Your article reads like you only want to deal with people who know what they're talking about when it comes to software. Too bad. Welcome to the real world.
Saturday, January 10, 2004
LOL! Amazing - the guy wrote an article detailing why he's a horrible consultant and why nobody should ever hire him.
To be worth the rate, a contractor ideally translates client needs into code. Part one of that is understanding the client's needs. The client should not have to understand the difference between a branch and a loop - that's not their job.
And if there's a major business requirement that didn't get into the design, that's the fault of the consultant for not learning the business well enough to understand the requirements.
The author is thinking in terms of working for project management when he doesn't understand that he IS project management.
Philo
Philo
Saturday, January 10, 2004
At least he admits "Later that week, when I re-read my rules, it became clear: I don't want to do contract work for clients anymore."
I don't either. We stopped doing that at Fog Creek as soon as we could support ourselves from software.
Joel Spolsky
Saturday, January 10, 2004
---"1. Never work for someone unless they know the difference between a branch and a loop.
Just this one criteria would have eliminated every unpleasant client experience from the last two years."----
I rather suspect it would have eliminated every client experience from the last two years.
Stephen Jones
Saturday, January 10, 2004
Actually I'm not too sure I know the difference between a branch and a loop.
Isn't a branch a bit like when Granny has Alzheimers and wanders off down the street some day to get lost and never come back, whilst a loop is when she has short term memory loss and keeps asking you every five minutes where she's left her zimmer frame until you finally have enough and crack her one over the head with it to shut her up once and for all?
Stephen Jones
Saturday, January 10, 2004
No, a branch is a government organization. A loop is what they send you on when you try to get information from them.
www.MarkTAW.com
Saturday, January 10, 2004
"2. Clients must understand and appreciate our iterative timeboxed approach. They need to understand the tradeoffs. "
Gee...If they don't understand, then it's because you failed to make them understand.
His whole attitude seemed to be combative towards his clients..As if he was irritated that they wanted to give him money. Amazing.
Mark Hoffman
Saturday, January 10, 2004
<semiDefensiveResponse>
A few clarifications... we've been making custom-built software & websites for almost six years, with a wide variety of clients. We're actually pretty good at translating customer needs to working code. What I'm referring to are high-maintainence customers that don't really know computers, most of which are asking for customizations to the web applications we've built for them.
I suspect if/when you've fielded the fiftieth change request from the managing director of a non-profit arts organization, someone who doesn't read or remember your emails, or remember the clearly outlined points from any of your design talks, you'll understand the frustration. Some clients just can't get it, no matter how clear you are.
The best clients we've worked with are other technology firms, hence the "branch/loop" criteria. There's a big market here, particularly as an outsourced resource. To say that we'd have no market following this rule is short-sighted.
As for pushing our services on others when they don't really need it, that's a pretty surprising point. Most of our clients have wanted custom websites and web applications, products to sell (they were entrepreneurs), or widgets to drop into their existing software projects. I can't think of one client that we "sold" in the sense you're talking about. Almost without exception, they came to us with their need.
</semiDefensiveResponse>
Timothy Falconer
Saturday, January 10, 2004
They're perfectly valid comments from a programmer who has never mastered the art of the schmooze. He's more comfortable working for technical clients who understand development.
Developing software is hard, but so is making sure other people are happy with what you're doing, even though they don't have a hope of understanding it.
He needs to hire an account manager.
Saturday, January 10, 2004
Hire an account manager? Perhaps. But I think the flames of Timothy are not exactly deserved. I don't perceive the egocentrism of the techno-fascist weenie at work here.
The fact is, the vast majority of end users don't have the slightest clue of how a technical project is conducted. Most end users, even managers, have no comprehension that their judgement might be taxed by the tradeoffs or decision making that an outsourced project absolutely demands of them. This is the most common problem with outsourcing both for the provider as well as the client.
Many times I've dealt with end users who fight the discovery process tooth and nail as too time consuming and too difficult, and yet hold you accountable body and soul for reading their minds. The precision you need to do your job makes most end users bleed from their noses.
Most clients - even many so called "technical" contacts within companies - expect complex deliverables to be delivered with absolutely no internal or specification complexity, like ordering a baked potato in a restaurant. It's QUITE rare to find a client who doesn't require a Vulcan mind probe.
I say, "BFD" to all the naysaying. Timothy's been in business for awhile and is learning what the parameters of his business need to be. His only "mistake" was in exposing his logic to the world.
Performance speaks louder than a bunch of armchair quarterbacking. Good for him.
Bored Bystander
Saturday, January 10, 2004
I have ran a custom software development business for about 5 years.
After the first 2 years, I have decided work only with clients who knew something about technology, and to simply refuse projects for clients that didn't have a clue.
This was one of the best measure I have taken - after doing this, profitability increased a lot.
Working for a client who doesn't have a clue about technology means you have to make a choice between:
- You spend a lot of time and effort educating/teaching your client. You won't be able to bill this time and effort adequately, because this type of client usually doesn't value your work.
- You do their project, they change requirements 1000 times, and you work like hell to hit a moving target. Even after you completed the project the way they wanted it, they are still not pleased.
Both variants waste a lot of time, effort and money.
DevX
Saturday, January 10, 2004
By only taking technical clients you are simply moving yourself one stage back in the process. Those clients are going to have to deal with the non-savvy customer. Now that may be a reasonable division of labour, but to criticize the clients because they don't understand your obscure processes is like criticizing a house buyer because he doesn't the chemical properties of building materials.
Stephen Jones
Sunday, January 11, 2004
Who's criticizing? It's simply a matter of finding the best match.
Have a look at a few of the other articles in the same category, particularly "Semantic Gap". I hope it's clear that I have nothing against non-technical users. I just don't want to explain what a "record" and a "field" is any more.
http://bigfractaltangle.com/archive/cat_grannies_and_gurus.jsp
Timothy Falconer
Sunday, January 11, 2004
Why are you explaining what records, fields, loops, or branches are?
Non-technical clients should be shielded from that stuff completely. When I had a non-tech client tell me that each partner's data should be in a separate database, I politely told them that unless they had a legal requirement for that, it really wasn't something they should worry about. I stepped them back and identified the *business* concern:
- Partners can't see each other's data
Good enough, I can do that with SP's and authentication.
Non-technical clients *think* they need to be involved with technical decisions. I tried as much as possible to back them out, since there was no more point in them asking/dictating architecture than there would be in me telling GM what kinds of alloys their pistons should be made of.
If it makes you feel any better, I'm sure your clients hated you as much as you hate them. :-)
Philo
Philo
Sunday, January 11, 2004
I'm sure many organisations that have had to engage such external consultants have their own rules, amongst which might very well be...
#127 never engage someone that cannot use a knife and fork at the same time, or at least who cannot discern the difference between them.
Simon Lucy
Sunday, January 11, 2004
So, what's wrong with that?
A consulting company may only have technical skills, and work for clients who know about technology.
Another consulting company may have fantastic skills in dealing with clients who don't have a lot of clues about technology.
In the market, both kinds of consulting companies can prosper.
Why?
Because there are clients who don't care if your company has the necessary staff for working with non-technical users - they just want to tell you what they want done, in technical terms, and they want you to do it.
It's like when I buy computers: I go to a local company where I can tell them exactly what components I want, what hardware settings (bus frequency, etc) I want, etc.
I don't care if they also have the capability to sell to non-technical people. In fact, they don't have this capability.
But they serve the customers who know about computers much better than other companies, because they have lots of components, you can have a very technical discussion with them, and get advice, etc.
DevX
Sunday, January 11, 2004
There are consultants who are hired by technical companies because they are even more knowledgeable and specialized than the technical who is workigroups own workers, but in general the "consultant" who is working for a tech savvy client is much more likely to be filling the role of a sub-contractor. Which, as everybody is saying, is a perfectly good situation for somebody who is uncomfortable with laymen.
It does seem to me though Timothy, that you were spending so long failing to explain things your clients didn't need and could understand, that you may have failed to explain to them what they did need and could understand. For once I'm 100% behind Philo on this; as far as your customer is concerned a field is where he keeps his prize Anguses, and you should not try to confuse the image or he'll be feeding data to the cows and stuffing hay down the floppy disk drive.
Stephen Jones
Sunday, January 11, 2004
Maybe it's just me, but doesn't this seem just a bit like a shameless plug for his own website that backfired?
كوب
Sunday, January 11, 2004
Yea, looks like he doesn't understand developers either!
I hadn't realized he was the original poster.
Stephen Jones
Sunday, January 11, 2004
> Non-technical clients should be shielded from that stuff completely.
I agree 100% too... to the extent that it's possible.
You do find clients who want to discuss both technical and business details. (Often the money people will delegate to someone like this, since they *seem* to be competent in both areas).
Since these clients, or the people they represent, are the ones who are ultimately paying, it can be difficult to cleanly separate concerns. If you try to focus too much on business requirements, they'll drag you back to the technical details; one of the things that I think is going on is that they are afraid of being BSed unless they hear some technical phrases that they understand. I wish there was a cookbook formula for how to deal with this situation, but AFAIK there isn't.
"Just forget about those clients, they're more trouble than they're worth". They may be trouble, but often dealing with them is quite lucrative.
Portabella
Sunday, January 11, 2004
I am not questioning Timothy's technical knowledge/skills, however, I am amazed that he has been able to land several (significant?) contracts with non-technical clients.
Philo wrote, "The author is thinking in terms of working for project management when he doesn't understand that he IS project management."
Bingo! Give that man a cigar.
Now, perhaps Timothy doesn't need to pursue high-maintainence non-technical customers, however, if he does then he is going need to learn more about the black art of fixed-bid custom software development. Among many other things this entails:
* Spending free time explaining to the client how your billing process works. Note: You might need to provide the client with several variations and allow the client to pick the method they feel most comfortable with. Clients also must be told that you welcome change requests, however, they will need to pay for them.
* Spending free time coming up with a competitive bid. This is where the black art of pricing comes into play. Many high-maintainence non-technical clients won't be willing to pay for the preliminary capture of the high-level requirements. So some firms deal with this fact by establishing a "Pre-Sales Effort" methodology. Basically, this means doing a quick preliminary pass of the first few phases of whatever SDLC your company follows for free. If the customer accepts your bid, then you need to figure out how you are going to recover the time and money spent on the proposal/estimation process you just did for free. If the customer doesn't accept your bid, you eat the cost of what it took to put in a bid.
One Programmer's Opinion
Sunday, January 11, 2004
> I stepped them back and identified the *business* concern <
Unfortunately this is a rare skill. Most people accept what they're told at face value without trying to figure out what the real need or motivation behind it is.
What was the name of that annoying girl on Animaniacs who kept asking "why?" until it drove someone crazy. The example I remember was her asking a painter why he was painting, and eventually got him to say "because I don't want to get a real job."
You're right, the non technical client should be shielded from the technicalities. The problem is, you also have to be good enough to figure out what they really want.
www.MarkTAW.com
Sunday, January 11, 2004
Sometimes the non-technical client tries to dictate technical details to you, even if they don't make sense. Maybe that is the situation that Timothy F. is complaining about.
T. Norman
Sunday, January 11, 2004
> What was the name of that annoying girl on Animaniacs who kept asking "why?" until it drove someone crazy.
Her name was Mindy.
"OK lady, I love ya, bye bye!!!!"
Portabella
Sunday, January 11, 2004
What a mess. The assumptions in this thread are unsettling.
Regarding fields and records, I'm surprised someone woud say that clients shouldn't have to deal with this level, that we should be shielding them from it. I'm not sure what kind of clients you've worked for, but I can't imagine any non-trivial database application that affects multiple parties in a business where the client doesn't have to deal with the "name" field or the "person" record. You might call them objects or attributes or forms or entities, but at some level, the client has to know about this sort of thing.
Of the assumptions above, one that seems to be repeated is that we've failed to educate our clients about our billing procedures, our lifecycle, our project management, etc. We actually do have a standard rap we use that explains all this. It's part of our standard contract, it's part of every proposal, it's part of every initial design discussion. Yet as much as we try (and we do explain things in friendly, non-technical ways), there are some clients that never quite grok it.
As for hiring an account manager, we're talking about requirements analysis and software design. Schmoozing is one thing, divining the client's specific needs is quite another. The less technical the account manager, the greater the chance for miscommunication. Again, I'd love to hear about projects where an account manager made decision decisions with the client without involving the architect.
Timothy Falconer
Sunday, January 11, 2004
Ive been fascinated by the outburst.
<g> it sometimes feels like every few days of work we have a discussion about how little our clients really understand about an area, and how we can either repair or work around that lack of knowledge.
But this one developer says something along those lines out loud and suddenly everyone is...well....accusing him of being an incompetent.
is everyone else out there _really_ finding it so easy to marry the worlds of programming and....people...?
Ive got a 'business mentor' type person with whom I have regular discussions and from whom I have received an impressive amount of much needed advice.
During one such discussion he brought up the occasional need to 'fire' clients, pointing out that some clients are just plain not worth the hassle.
<g> this was a possibility I had _never_ considered before, but I have to admit to loving the idea when I heard it.
Almost immediately I began having fantasies similar to those in the OP's blog, dreaming about limiting my clients to those who were, well, at least vaguely intelligent about techie things
That was unrealistic of course :)
I have since 'fired' two clients and IMO the business is stronger (and more profitable) because of it.
FullNameRequired
Sunday, January 11, 2004
TF wrote, "Of the assumptions above, one that seems to be repeated..."
Well, all we JOS posters can do is make assumptions because your website (http://immuexa.com/services/ - the URL you placed in your blog entry) doesn't go into detail about your billing procedures, your development methodology, your project management practices, etc. and I don't believe it should.
I currently don't understand what exactly some of your non-technical clients aren't quite grokking. Maybe the problem you are running into is that you are dealing with too many companies who simply DON'T have any technical employees for you to talk with! Maybe this is why you wrote your rule #1 the way you did? If so, perhaps you should edit your blog entry to read "Work only for companies that have at least one or two technical people on hand that you can talk to or don't do anything more sophisticated than a static website for these type of companies".
On the other hand, you might simply be dealing with too many clients who are cheapskates (i.e. real estate companies, idependent insurance agents, etc. typically fall into this category).
TF wrote, "Regarding fields and records, I'm surprised someone woud say that clients shouldn't have to deal with this level, that we should be shielding them from it."
Why are you surprised by some of the responses you have received so far? When you are interviewing/communicating with someone like the president and/or owner of a small company you simply can't expect him/her to know or care anything about the technical details associated with custom software development.
Although the person who pays your invoices rightfully should tell you what he/she wants the application you are creating to do and what the user interface should look like, you should always try to stay away from implementation questions. Generally speaking, implementing the project is suppose to be your area of expertise.
FullNameRequired,
Not everybody who disagrees with what Tim has written believes he is incompetent. All some of us did here was comment on a very brief blog entry. Now having said this, when it comes to software development everybody is ignorant or incompetent in some manner. For example, I don't know squat about the computer gaming industry nor do I know anything about game programming (i.e. AI techniques/concepts, the physics of collision detection, etc.).
One Programmer's Opinion
Monday, January 12, 2004
Last year I wrote an application to handle rebate programs for a client. The application was metadata-driven, with one set of database tables establishing the structure of the rebate program and another set containing the data.
If I had even *tried* to explain "metadata" to the client, it's likely his brain would've exploded.
Instead, I provided a full set of interfaces for creating new programs, editing programs, archiving old programs, and an admin interface to manage the program structure (edit the metadata).
Client still doesn't know it's metadata-driven, nor do they need to. They don't know which bits are records and which are fields. They know they have partners, programs, headers, sections, and fields ("Field" in this case being a blob in a table with four FK's, but to them it's just a rebate entry).
Now if I'd coded for one of you guys, then we probably would've gone with a more in-depth discussion of the design ensuring it met your needs.
And as for "whining about clients that don't understand what we do" - I personally never meant that I only want to work for people that can write sort algorithms in C++; I only mean that I'd like an appreciation that programming is not manufacturing, and some understanding of proper development processes. I think that's reasonable and internally consistent.
Philo
Philo
Monday, January 12, 2004
Even clearer: I'm talking about clients that don't yet understand the very concept of a field or a record, that have to be told, "When you type in the email address in Outlook, you put it in something called a field. That thing there is called a field." Then, "Now look at this customer form you gave me, the one you want made into a web page. Each line that people fill in is a called a field. Put together, the filled out form is referred to as a record. These records then get put in something called a database, which is a software program on the website computer."
We've had about a dozen clients like this. All I'm saying is I'd rather work with fellow techs.
Timothy Falconer
Monday, January 12, 2004
And yes, they need to know this, so they can say things like, "Can you put a 'last action' field on the 'contact' form?" It helps. :)
Timothy Falconer
Monday, January 12, 2004
No, they don't need to know it.
For one thing, I'd be interested to see a form that is just one record. At best, it'll be a single record with a bunch of FK's, but odds are it's a parent record with a bunch of child records and possibly some sibling records.
Who cares?
"Here is the form where you enter your data."
"Can you make it so I can save the form and edit it later?"
"Yes I can"
"Can you make it so I can save the form and use the same info in later forms?"
"Yes I can"
"Can you make this part [waves finger at screen] has more lines if I want?"
"Yes I can"
"And here [waves finger at screen] - when I type in the part number, can you make it so the part description is filled in?"
"That's possible, if you have a parts catalog online, and it may depend on how big your catalog is. There are several ways we can do this..."
Trust me, I've dealt with non-technical clients who try to talk in technicalese. I know how to handle them. Apparently you don't. That's fine. It'll come with experience. (Unless you simply avoid learning how to)
Philo
Philo
Monday, January 12, 2004
----""Can you put a 'last action' field on the 'contact' form?"----
Yea, I mean the Arts, the Government, lawnmower manufacters (well at least they know about fields) and the local sweet shop are all run by people who go around saying things like that!
Why don't you give the real rule of engagement. "I will not take on any clients that don't know enough to do the job themselves."
And if that's not practical, hire a Geek-English translator.
And take your next vacation in Reality; it's a nice town, cheap and close to home.
Stephen Jones
Monday, January 12, 2004
our man philo said:
"Trust me, I've dealt with non-technical clients who try to talk in technicalese. I know how to handle them. Apparently you don't."
and then the right honourable stephen jones said:
"And take your next vacation in Reality; it's a nice town, cheap and close to home."
come on guys, reread the article for chrissakes, I really dont understand where you are coming from here.
in the OP blog thingie he makes a few basic points:
"Much of the crisis had to do with mismatched expectations."
tell me you haven't had that experience? its so common it almost amounts to _the_ problem that occurs between software developers and their clients.
"Seems like the less technically comfortable the client, the bigger the problems I have with them"
That pretty much amounts to a fact of life IMO, the level of difficulty can change depending on whether the client is relaxed about not knowing or whether he is one of the "you cant rip me off just because I dont have a clue" kind of guys, but either way there are going to be issues there.
He then goes on to list his 'dream' rules and realises _himself_ at the end that:
"Later that week, when I re-read my rules, it became clear: I don't want to do contract work for clients anymore."
I dont see where Philo gets off assuming that he is better at 'handling' these clients than the OP (although given Philos obvious skills in that area he quite possibly is, but the point is that nothing the OP wrote in that blog could reasonably lead to that assumption)
The bottom line is that the OP is sick of dealing with his unknowledgable clients, that doesn't mean that he cannot do so, it doesn't mean that he isn't good at it, and it _definitely_ doesn't mean that he does a bad job, it just means that maybe its time to change his direction.
<g> and the sarcasm from stephen jones was just plain mean and uncalled for.
FullNameRequired
Monday, January 12, 2004
Yet another example where the JoS crowd will beat you to death claiming you have no people skills.
this sh*t cracks me up
Monday, January 12, 2004
No the sarcasm isn't uncalled for. I have read the original blog and both that and the guy's postings here reveal that he hasn't the least idea how to deal with non-technical customers.
It's a case of mismatched expectations because his expectations are totally unrealistic.
Customers don't know about "fields, tables or transactions". These are specialized database terminology, and there is no more reason for the head of an accountacy fiirm to know about it than there is for a programmer to know about arbitrage or Brady Bonds.
Customers have their own technical terms; they are among others a "thingumijig", a "whatdoyoucallit" a "oneofthose" and a"whatsit". Your job as a consultant is to listen and then try and explain until you are successful and all those terms become subsumed in the only user term you are intersted in, a "thatsit!".
Stephen Jones
Monday, January 12, 2004
Well, I'm done here. I appreciate those who've offered a more balanced view. It's a shame these JoS forums have become such an unwelcome place; I know the tone has nothing to do with Joel or his writings.
To whomever suggested I had some secret motive to get readers for my website, I think it's pretty clear: I posted a quote and a link. Most links mean "click me". The good news is that I've received hundreds of readers from this site since then, many of them reading more than the one article, many that have returned more than once.
This also means that for every negative poster, there's probably a hundred who read silently and form their own opinions. It's really too bad the flamers steal the show. It'd be nice if the silent majority felt more comfortable chiming in, but given the tone in this topic, I can't say I blame them.
Anyway, kindness is necessary, folks. Play nice. It helps.
Timothy Falconer
Monday, January 12, 2004
---"I know the tone has nothing to do with Joel or his writings. "---
Yea, I mean Joel's most famous book is called "How to train your users to grok the command line", closely followed by "What every temporary receptionist needs to know about Boyce-Codd third normalization."
Stephen Jones
Monday, January 12, 2004
Dear Timothy,
Not participating in or visiting this forum any longer will not help you in the least. I can understand your frustration but backing down because 3 or 4 people out of hundreds happen to take what you wrote and criticize it - is like backing down from a bully. If you know in your heart that what you meant when you made those statements does not comply with what these guys are saying about it, then don't even think about it. Stand behind what you think. If you didn't put it into words correctly the first time, try again.
Posting on this forum is like giving a speech in a public place. Some people will like what you have to say, some will heckle you and some people will hate you for it. It's that way every single time you make a statement in a public place. The key is to not back down. Do politicians back down when they say something not quite right? No. They make another parallel statement that attempts to correct what they said or what they meant.
My advice is to keep writing. You'll keep getting better at what you want to say. But always remember people will criticize you no matter what.
Remember when Joel wrote the article about error handling? People went crazy! Everyone has their own opinion. Does anyone give Joel any less respect because he handles errors his own way? I doubt it.
Does anyone give Timothy any less respect because he made a statement that was interpreted wrong by a few people. I doubt it. They would probably respect Timothy even more if he would write another article clarifying his thoughts. (Take Eric Sink's Make More Mistakes article for example.) Even then you will not win everyone to your side.
"If you can meet with triumph and disaster,
And treat those two imposters the same;
If you can bear to hear the truth you've spoken,
Twisted by knaves to make a trap for fools
.
.
.
If you can talk with crowds and keep your virtue,
.
.
.
If you can fill the unforgiving minute,
with sixty seconds' worth of distance run,
Yours is the earth and everything that's in it,
And -- which is more -- you'll be a Man, my Son!"
Rudyard Kipling - "IF"
Anymouse
Monday, January 12, 2004
"Not participating in or visiting this forum any longer will not help you in the least."
I disagree. There are certainly some entertaining characters here (stephen jones, bella, that guy who couldn't tell his coworkers to keep the noise down), however other than entertainment purposes I can't say that reading this forum has helped my career in any way.
In fact, if anything it has been mostly an enormous time sink.
Monday, January 12, 2004
" it has been mostly an enormous time sink"
heh. Anybody else want to form a "JoS warm-chair attrition" group?
;P
Monday, January 12, 2004
What makes you think Timothy's comments have been interpreted wrong.
From both his comments and his web log it seems clear that he is a person who believes that people who do not think the same as he does need training if they are grannies or users, or are quite unbalanced if they are developers or tech savvy laymen who happen to disagree with him.
And how is it hundreds who agree with him, and just three or four who don't. As far as posts go there are half-a-dozen who feel he's barking up the wrong tree , and the same number who feel he has some justification or is being badly treated.
The "hundreds of people" who have visited his web site could quite likely have done so because they wanted to know more about a person who could post such an absurd comment as the one that started this thread.
Stephen Jones
Monday, January 12, 2004
>> "I can understand your frustration but backing down because 3 or 4 people out of hundreds happen to take what you wrote and criticize it"
>> "And how is it hundreds who agree with him, and just three or four who don't."
The poster said 3 or 4 criticize it out of hundreds. That doesn't mean that the "hundreds of people" actually agree with him.
Drove my chevy to the levy, but the levy was dry
Monday, January 12, 2004
Nobody ever suggests that the silent majority might be split along the same lines as the vocal minority, even though that is what often happens.
And the idea that these "hundreds of readers" don;t agree with me, Philo or the Marks is clearly implied.
---"Does anyone give Timothy any less respect because he made a statement that was interpreted wrong by a few people."---
Mind you, I'd love to hear the right interpretation!
Stephen Jones
Monday, January 12, 2004
I have a hard time believing a lot of you people have ever done contracting as a living. I'm not talking about jobs on the side, or going through a recruiter.
"can we add another field on this page"
sure, but it's going to double the cost you've already paid.
"but it's just a little text box like all the others"
but when we went over the data, this model was never assumed.
"i don't believe you, it's just a simple box"
"well, behind this simple box there's ..."
Monday, January 12, 2004
>> "And the idea that these "hundreds of readers" don;t agree with me, Philo or the Marks is clearly implied."
It's not clearly implied because I obviously took it to mean something different.
>> "Mind you, I'd love to hear the right interpretation!"
Read the comments by Joel and others that defend Timothy. This is what Timothy was trying to convey but it apparently didn't come out that way. Understand? AnyMouse is saying that Timothy should make a clarifying post on what he meant. If what he meant is what he said then so be it - that is his choice.
Drove my chevy to the levy, but the levy was dry
Monday, January 12, 2004
I agree with the hecklers and would have added my own two cents except it has been hashed to death.
My initial reaction was, "what a maroon". But realizing that it was probably written in anger/frustration, i've tempered that a bit. Mismatched expectations, yes. But, i think the customer (as always) is right and TF needs to learn how to deal with them effectively or, as he basically has done, avoid them.
TF, I think one of your mistakes in dealing with this forum is the way the inital post was worded. If you put something like, "here is my take on how to deal with clients, what do you think..." I think you would have gotten a more civil response (still negative, but less abusive)
pdq
Monday, January 12, 2004
"But, i think the customer (as always) is right"
Furthering my notion that maybe 1 or 2 people commenting on this thread has ever made a living doing computer consulting or even DEALT with customers in their life.
Monday, January 12, 2004
Well, my experience with non-technical users/clients has generally been fantastic. They come to you with a problem, and some crazy idea of how to solve it. You talk with them a bit, and get the really fine details of what they're trying to do.
A large percentage of the time their problem can be solved with existing tools (frequently available for free). You set the stuff up and they now have their computer performing a task that used to take them hours to do by hand. How can they not be grateful?
And when there's actually a good reason to build a custom app? Well the non-techies love it. They're getting their very own app, just like Microsoft or Adobe makes! They stand enraptured as new forms and widgets appear day after day. They watch over your shoulder and are delighted when a few clicks of the keyboard make something appear how they want it.
--Side Note: being able to deliver a feature instantly is about the best thing you can do to earn confidence and trust.
As for working with techies or pseudo-techies, well I've had bad experiences with them. Generally in the form of their telling me exactly how to write the app. When they feel the need to get that involved in low level details they should be doing it themselves.
Matt
Monday, January 12, 2004
 Recent Topics
Fog Creek Home
|
