|
"Rules of Engagement" and custom software
I have found the naivete' of the many haughty pronouncements of Timothy Falconer as essentially incompetent, to be laughable. I've walked in the same shoes for a living and it's not easy.
I have worked independently for over ten years and I have formed the following opinions of custom software development based upon this experience.
Most custom software development is a waste, especially for smaller businesses. The cost effectiveness is simply not there. There are extremely few situations wherein the client can conceivably be rewarded with profits in excess of the investment in custom code. So this generally leads to blaming (of the consultant) and tension in the relationship. I myself find it very uncomfortable to work on projects that are self evidently unrealistic, especially when the client has stoked themselves on the Second Coming as realized in a new application program.
Outsourcing is ALWAYS awkward, even if you're in the same building with the client. The basic problem is mismatch of the goals of the relationship. Each side is trying to maximize the money it will have on hand at the end of the project. Also, you can't read the client's mind but you are running up their bill in the attempt to do so. Or if you are on a fixed cost project, the client will see no necessity for discipline in requesting changes or in changing their mind.
Custom software can be a point of vanity for many clients. IE: they believe that their needs are so unique, that they are such special snowflakes, that only custom applications can work in their business. In that context, the consultant is often treated like lackey, the "helping hands" doing the bidding of the self defined client uberminds.
End users can be extremely difficult to work with because the "cognitive separation" between the terms in which they think and in which we think is so different. The client sees sales, commissions, inventory, costs, income, part counts, hours billed, salary in arrears. We see tables, objects, methods, vtables, etc. When the client changes their assumptions mid course, it is extremely difficult to show them what the costs of change will be. Which I suspect is part of Timothy Falconer's problem. Which I have no silver bullet for.
Another bane is the "some knowledge is a dangerous thing" conundrum. I don't necessarily want dumbasses as clients, but I also don't want the client to second guess me constantly. The worst people to work for are hobbyist level and casually informed types who want to argue about your design decisions with you because they read on the internet or read in a magazine somewhere that XYZ was the best way to do something.
The *only* thing that allows this kind of relationship to succeed is an excellent long term relationship with the client. In that context they trust your decisions and judgement and you have a good enough rapport to infer their needs.
However, many times I have found in this business that the client just doesn't *want* a relationship because they literally do not see a programmer as a candidate for peer equality and/or they believe that the task does not merit that degree of effort. Instead they just want simple little application XYZ to be done perfectly with no internal complexity like a baked potato, and they want to find a stooge who will shut up, wave his hands, and magically deliver with no delay or or effort on the client's part. (clients who spurn "relationships" and just want a "thing" done can be an entirely separate thread.)
IMO, a successful freelance software developer (I didn't say I was successful :/ ) has to be an accomplished armchair psychologist. Gerry Weinberg ( http://www.geraldmweinberg.com/ ) has made a career out of this issue.
Bored Bystander
Monday, January 12, 2004
So what? boring thread if you ask me.
Keen observer
Monday, January 12, 2004
That's it! Now I'm angry!
.
Monday, January 12, 2004
It's not a boring thread.
The man has been attacked for no reason.
If it's boring, don't read it!
MX
Monday, January 12, 2004
When it comes right down to it, it's all about personal relationships not communication of technical issues. It's an emotional thing for a client to invest in you. They want you to make all the right soothing noises and pat their hand at the appropriate intervals. That's what 90% of business level communication is about, making people feel good while you've got one hand on their wallet.
When I realized this, I also realized that despite having the skills that might otherwise make a good consultant, I had absolutely no future in consulting.
ex consultant
Monday, January 12, 2004
I love it when I can use a Usual Suspects reference :)
You're welcome to pick whatever limits on clients you want. But when it comes down to it, sometimes success is about being willing to do what the other guy won't.
Richard P
Monday, January 12, 2004
Making money as a consultant is pretty much exclusively about establishing the relationship. I've seen some of the worst business flimflammery used in consulting based on the strength of the relationship. The consultant stroked the client in all the right ways, even though the consultant himself knew about as much about running a profitable business with a stable cash flow as my cat does. I am happy to say that I am no longer with that firm.
I've seen custom software work, and work well. I've seen it pay for itself in savings within a single year. I've seen clients manage the same production on a third the staff, and because of increased quality and reliability, increase their business enough to hire back that staff within two years.
So it might be that some individuals don't have the personal skills necessary to make custom programming a viable option, but with the right mix of personalities it can work very well.
Clay Dowling
Monday, January 12, 2004
BB wrote, "I have found the naivete' of the many haughty pronouncements of..."
If I recall, only 1-2 posters in that thread used the word "incompetent". Most of us so called naysayers, simply didn't agree with Timothy's attitude/approach to the problem of how to deal with non-technical clients.
Imo, you are making it sound as if some of us are nothing more than theoreticians who spout their opinions from ivory towers, but have rarely, if ever, had to work on real projects.
If doing custom software development for non-technical clients was an easy thing to do then everyone would not only be trying to do it but they would be doing it successfully!!!. Custom software development is a tough business to try and make a living in. I personally know of several companies that had their shit together in various ways, yet, all of them eventually folded before reaching their tenth year of operations.
If I am understanding you correctly you are primarily defending Timothy because you believe your work background is somewhat similar to his and you have had many of the same client experiences he seems to have had. If this is true, then I am somewhat confused because Timothy seems to be promoting his company as a total solution provider while you seem to be a hired gun who attempts to find work at the best hourly wage that he can get.
BB why do you believe that just because someone has good programming skills/technical knowledge this means they should be good at running their own custom software development business? Yes, I know you haven't explicitly stated this, however, this is the impression that I am getting from the posts you have made so far. Let me clue in on two items that don't seem to be obvious to you.
* Most non-technical clients do not want (nor do they have the ability) to manage a software development project.
* Most non-technical clients won't pay a higher rate for your services over those of Bob the next door neighbor kid just because you have your own business, studied design patterns, have previous OO development experience under your belt, etc. They will pay a higher rate for services that the next door neighbor kid can't provide provided they feel they need them. Sometimes you have to convince them that they need your unique services and sometimes you don't.
One Programmer's Opinion
Monday, January 12, 2004
>> they just want simple little application XYZ to be done perfectly
Maybe it's the way computers work in TV shows?
I don't think I ever saw one that didn't *beep and squeal* the whole time.
Alex.ro
Monday, January 12, 2004
The most cogent response so far is Clay Dowling's. I've simply had much different experence with cost/benefit tradeoffs but I agree with all you say.
Now, "One Programmer's Opinion": I am not exactly defending Timothy's rant nor his approach. All I did was enumerate the many ways in which custom software outsourcing can be incredibly challenging or outright fail, which in my experience bear out most of TF's contentions.
I got the vibe from others' responses in his thread that his analysis of his experience had no credibility. It seems that to some people, *anyone* remotely willing to pay for technical services should be worshipped as a demi-god. It's as though the party at one end of the transaction (the service provider) has no right to an opinion. It's QUITE possible for someone with money to be a bozo, to have an erroneous idea of what needs solved, and/or to be quite disagreeable to work with on the project that is to help them. I also don't think that someone in this business should dwell on this possibility. Just acknowledge it as a possibility.
The customer isn't always right - is probably my single most important point. The customer, in fact, may require tactful guidance and a degree of firmness in order to cop the logic of a situation. Clients generally need to be controlled at some point, often without their knowledge or explicit consent. Lawyers, doctors, and other professionals control their clients by setting expectations and by selectively passing along information.
And let's not forget another important point: knowing when to decline to work with a client.
>> Let me clue in on two items that don't seem to be obvious to you.
Oh gee, yah think...
>> * Most non-technical clients do not want (nor do they have the ability) to manage a software development project.
Oh, this is good! ;-) In my experience, many end users WANT to manage the technical project even though it's beyond their inherent skill level - if only by changing their minds on deliverables. And/or they want to control the implementation or the delivery of the work. Or they get caught up in tweaking look and feel.
Anyway - my guess is that no matter how many warts that Timothy's apparent "attitude" has - he may have a better shot at making clients happy than most of those who were very eager to render a negative opinion. The guy groks the nature of this business.
Bored Bystander
Monday, January 12, 2004
It's amazing so many people missed the overriding point of Tim's post-- dealing with fundamentally clueless clients, people so clueless that no matter what you say, they'll never get it.
Oh wait, it's not amazing at all.
Crimson
Monday, January 12, 2004
so, what exctly is your point?
he he
Monday, January 12, 2004
Hi BB,
I apologize if my first post to this thread sounded condescending. When I wrote it I was a little pissed at what you wrote because to me it seemed like you were lumping everyone who didn't agree with Tim into the same bin bucket. Thanks for clarifying your POV. For the most part I agree with you.
BB wrote, "Anyway - my guess is that no matter how many warts that Timothy's apparent "attitude" has - he may have a better shot at making clients happy than most of those who were very eager to render a negative opinion. The guy groks the nature of this business"
I agree. I tried making a go of it (by primarily pursuing non-technical business owners) several years ago and failed. :-(
The biggest obstacle I ran into with the small business owners that I contacted/marketed to is that most of them were happy doing business with Bob the next door neighbor's kid or already had some type of service-level agreement with a local consulting firm.
One Programmer's Opinion
Monday, January 12, 2004
OPO - no problem, I flamed wholesale at the start and I deserved it. I think we agree on... something... such as: making a living at software consulting is extremely hard.
Bored Bystander
Monday, January 12, 2004
My summation of Tim's article was:
"I've learned two things the hard way:
1. This business is very difficult.
2. I'm not very good at it."
Most of the things that he (and BB) say about the business are true. Anyone who is in this business understands this.
Where I think Tim got off-track is he blamed the clients for the problems rather than accepting the fact that it's a damn tough business and if you don't have the proper client-management skills, then you shouldn't be in it.
Huh?
Tuesday, January 13, 2004
" I'm not very good at it."
?? but he never said that.
he said he didn't like it much, but thats an entirely different thing.
FullNameRequired
Tuesday, January 13, 2004
"Where I think Tim got off-track is he blamed the clients for the problems rather than accepting the fact that it's a damn tough business and if you don't have the proper client-management skills, then you shouldn't be in it."
no he didn't. He complained about certain types of clients, listed his dream attributes his fantasy client would have, and then at the end stated that he realised that the biggest problem was that he was sick of working for his clients.
He _must_ have been pretty damn good because he has the choice after 6 years of continuing on or stopping.....if he was hopeless he wouldn't have had that choice because his clients would all have left by now.
FullNameRequired
Tuesday, January 13, 2004
im finding myself more and more bemused at the enthusiasm with which people are criticising Tim.
Even people Ive tended to have respect for such as philo and stephen jones appear to be ignoring what he actually wrote in their enthusiasm to put him down for daring to say that he would _really_ like his clients to be more tech savvy.
I mean, wtf? ok, we all know that clients just aint like that and that its a pipe dream...tim included.
but surely theres no harm in doing what Tim was doing....dreaming aloud...
FullNameRequired
Tuesday, January 13, 2004
seriously, go back and reread his article he said _nothing_ that could be taken as a reasonable sign that he wasn't good at his job.
FullNameRequired
Tuesday, January 13, 2004
Ok, I have read the original Rules of Engagement thread more closely and I saw this:
TF>> 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."
TF>> We've had about a dozen clients like this. All I'm saying is I'd rather work with fellow techs.
While I am a hard boiled career techie (EE, etc.) and I am exasperated by end user cluelessness, I also find TF's contention here somewhat "insane". In my experience, you simply don't *talk* to end users about fields and records. You just, simply, absolutely, positively *don't*. It is a textbook definition of beating head against brick wall.
How I would handle an interaction like this:
Scenario #1: "Mr. Customer, show me how each piece (1) of information on your current paper form (2) should be handled. Show me how a customer fills it out. ... OK, which pieces (3) of information should be saved? Do we need more places (4) to fill in information beyond what your form (2) provides?"
1, 3 and 4) - field/fields
2) - record definition
Scenario #2: On the subject of tables: "Mr Customer, you are asking me to store your form #ABC and your form #YYZ in the same way. I can't do that. We need to walk through how you use form #XYZ first. Ok?"
This translates roughly to guiding the customer toward implementing a portion of first normal form, IE: create separate tables for each group of related data.
And so forth. I'm no expert and this kind of slow pace can make me rip my hair out, but insisting upon talking about fields and records to an end user is like yelling loudly at a non English speaker so that they "understand" your English.
So, if I could make a constructive suggestion to TF, it would be that you have to deal with wherever your customer is coming from.
Which leads to my final point - personally, I don't like working with techs and technical management. Why? They generally know "so much better" how to do the job they've given me that IMO they can f***ing well do it themselves.
Hence, I don't "court" technology companies anymore. End users are truly less aggravating in some ways.
Bored Bystander
Tuesday, January 13, 2004
Dude seems to ok for himself no matter what he thinks or says or does. Did you see the pic of that house he built? Sheesh. Looks like he's in the midwest somewhere...
Tuesday, January 13, 2004
Philo gave a stunning explanation about how you explain things to non-techies. Just to read it tells you MS did hire the best.
TF's gripe can better be summed up this way.
1) It's difficult to explain programming technicalities to users from other specialities.
2) I'm not very good at it.
3) It's their fault
4) Anybody who tells me I am barking up the wrong tree is unwelcoming and unbalanced, but luckily a minority within the community.
If you go to TF's blog site you see the same thing. He talks about the problems his granny has with files and folders, correctly says that many people do not understand the metaphor and then suggests people need training in files and folders (a reasonable suggestion thougn Alan Cooper, who raised the same point suggested that what we should do instead is scrap the metaphor). And then the "haughtiness" comes out; this is not because the metaphor is broken or inadequate, but because there are people who are disorganized, and people who aren't and are so morally corrupt that they expect other more organized people (aka consultants like Tim) to go around and find their lost documents and keys for them. This is rubbish; I understand files, folders, directories and sub-directories perfectly, but I can never find my keys or my glasses in the morning and all my papers are strewn all over the place and the cleaner both at home and work has instrutions to lift up and dust under but never move; in fact I took up computers with a passion because they allowed me to be superoranganized. I knew a lawyer whose filing system consisted of piles on the floor of his offices; he on the other hand had no trouble finding any document among them in a matter of seconds.
Stephen Jones
Tuesday, January 13, 2004
"In my experience, you simply don't *talk* to end users about fields and records. You just, simply, absolutely, positively *don't*."
Im interested in what your experience might be?
Im a contract developer with a surprising number of custom projects underway for various clients.
_sometimes_ tradeoffs are required that are going to affect how they do things.
My job is, in a nutshell, to work out how they do things now, then to work out how they _should_ do those things and then to write the software to, as gently as possible, shuffle them along the right path.
If this is going to require changes in their processes I _need_ to have the clients on board before we go down that route, this means that I _need_ to get agreement about the way things should be, and _that_ fairly often requires that I make at least _some_ explanation of the alternatives and the tradeoffs.
I _cannot_ just write the software and force them down the path I want them to go because (a) I might be wrong about it being the best way (b) I may be right but they may be stubborn-ass mules and (c) If I make the wrong choices it may actually send them bankrupt.
If you are seriously making decisions like these for your clients without any input from them then IMO you are guilty of a far more heinous crime than merely attempting to teach them about records and fields.
FullNameRequired
Tuesday, January 13, 2004
"TF's gripe can better be summed up this way.
1) It's difficult to explain programming technicalities to users from other specialities.
2) I'm not very good at it.
3) It's their fault
4) Anybody who tells me I am barking up the wrong tree is unwelcoming and unbalanced, but luckily a minority within the community."
no, it cannot.
(1) he definitely says that.
(2) he _never_ says that
(3) he _never_ says that
(4) he _never_ says that
seems to me that you are projecting your own issues onto his blog stephen jones.
FullNameRequired
Tuesday, January 13, 2004
#2:
When I'm dealing with someone who asks, "Which one is the web browser?", I'm in trouble,
#3:
As much as we explain to the client how we schedule, as often as we say, "You're the gas and the brakes", there are some who just never understand the approach, and so use our firm less effectively.
Note how this paragraph is about the *client* misusing the relationship.
#4 is more from his defensiveness in the thread, instead of saying "you're right, it's about my lack of flexibility as a contractor" it becomes an issue of us either not having the competence or not understanding the words coming out of his mouth.
Maybe it's just me, but something about his tone in the article really gives me the feeling of "I shouldn't have to deal with stupid people."
Now a disclaimer: if his rant had been about nontechnical clients who INSIST on making technical decisions, I'd be with him 100%. IMHO that is a no-win situation for a contractor. But if we're simply talking about dealing with clients who aren't technical, then so long as they're willing to work with you, it's not a problem.
Philo
Philo
Tuesday, January 13, 2004
Hi Philo,
"When I'm dealing with someone who asks, "Which one is the web browser?", I'm in trouble,"
<g> and _that_ isn't the truth?
I had a client once who called me most confused. Apparently he had 'turned off' the internet but my program was still able to do the internet database stuff.
he was quite worried about this, he was wondering whether maybe a virus had infected my program causing it to be able to connect to the internet even though it was 'turned off'
My heart sank as he explained all this.
(to make a longish story short, he had 'turned off' the internet by quitting internet explorer)
my point? He was trouble all the way through, his total lack of a reasonable understanding of _any_ facet of the computing world was a real handicap.
to me the sentence "When I'm dealing with someone who asks, "Which one is the web browser?", I'm in trouble,"
doesn't mean Tim isn't any good at his job, it is a _simple statement of fact_
"Note how this paragraph is about the *client* misusing the relationship."
again, I understand where he is coming from. We are a small company and genuinely do not have the resources to make ourselves entirely available to every client on their terms.
<g> whether doing so is a good practice or not is entirely moot as its just plain not possible.
What that means is that as much as possible we encourage our clients to request new features early, to assume that nothing is decided unless the communication took place via email or snail mail.....a phone conversation is not a decision.
And so on and so on, the relationship between us and our clients is very much a mutual thing with give and take on both sides, our 'best' clients are those with the intellect to understand this and take advantage of it.
our worst clients dont really get it, they ring every 5 mins and request small feature requests over the phone and call back 2 days later and change their minds, they insist on talking to the programmers directly and often provide detailed (and wildly bad) instructions on how a feature is to be implemented, etc etc etc
Now, obviously as a contractor its a part of my job to handle these people and I do so (IMO I handle them fairly well), I handle them by slowly and carefully training them and teaching them how to use us to their best advantage.
So when you say: "Note how this paragraph is about the *client* misusing the relationship."
I dont see a problem with that....clients _can_ misuse the relationship and merely mentioning that does not prove much to me one way or another.
"#4 is more from his defensiveness in the thread, instead of saying "you're right, it's about my lack of flexibility as a contractor""
thats because its _not_ about his lack of flexibility as a contractor.
Again I say, you do not have sufficient information to judge his ability one way or another and by doing so you are, IMO, being grossly unfair.
Its often not possible for small support companies to be sufficiently flexible to handle difficult clients. Its hard work, it takes time, and (possibly like him) I am increasingly of the opinion that doing so is more destructive than positive.
the relationship between a developer and a client is a 2 way thing, both sides have responsibilities.
FullNameRequired
Tuesday, January 13, 2004
Like I said, when *I* read his article, it sounded to me like an Angry Coder rant - nuggets of truth embedded in a panorama of "why can't the world be the way *I* want it to?"
Consider if Joel had written an article about the same thing - I suspect it would've been advice regarding dealing with nontechnical clients and the advisability of working with them on their terms instead of trying to drag them around by yours.
IMHO, two words sum up the difference of the approaches:
- wisdom
- experience
My $.02, YMMV
Philo
Philo
Tuesday, January 13, 2004
"Like I said, when *I* read his article, it sounded to me like an Angry Coder rant - nuggets of truth embedded in a panorama of "why can't the world be the way *I* want it to?"
<g> truly weird....it makes me genuinely wonder whether we were reading the same article.
ah well.
how goes your day job Philo?
FullNameRequired
Tuesday, January 13, 2004
FullNameRequired said:
>> >> "In my experience, you simply don't *talk* to end users about fields and records. You just, simply, absolutely, positively *don't*."
>> If you are seriously making decisions like these for your clients without any input from them then IMO you are guilty of a far more heinous crime than merely attempting to teach them about records and fields.
You misunderstood my post. My point was that the language one should use to an end user shouldn't contain many (or any) "technical" terms. I provided alternate wording and approaches more suited to the end user's P.O.V..
I'm not saying "make all decisions for them". I'm suggesting that one play the role of a translator and metaphor-generator.
I think it's possible to talk to end users without snowing them with formal CS terminology. In fact, I think it's absolutely essential to communicate with end users in terms they can readily understand.
Bored Bystander
Tuesday, January 13, 2004
"I'm not saying "make all decisions for them". I'm suggesting that one play the role of a translator and metaphor-generator."
which, of course, is what all of us who deal with the public have to do, but...
"I think it's possible to talk to end users without snowing them with formal CS terminology. In fact, I think it's absolutely essential to communicate with end users in terms they can readily understand."
yeesssssishh.
<g> for a start, talking about 'records' and 'fields' is hardly 'snowing them with formal CS technology'
But even if we decide it is, _some decisions our clients must make require more than an absolute minimum of knowledge_ If they are unable to grasp anything sufficiently well to make those decisions then _they are going to be hard to work with_
Thats a fact of life :) stating it does _not_ cast doubt on my ability to deal with clients.
But either way I suspect basically we are all agreed on the basics, clients need to be treated with love and care, told exactly what they need to know (but no more or less) and pay up as soon as the job is done :)
My main point is that AFAICT from reading his blog, tim knows that as well as anyone...he was letting off steam and any negative judgment based on that blog and his postings since are being grossly unfair.
He may be an incompetent fool, he may also be a client-handling genius, trying to guess which is the case merely from reading that blog is simply not possible.
FullNameRequired
Tuesday, January 13, 2004
FullNameReq'd -
If you can talk to your clients about records and fields, more power to you.
Here's where I am coming from. What I find in most circumstances is that when someone hears a term that they aren't familiar with in the course of a conversation, they become confused and stop listening from that point forward, to an extent.
I can remember times in my own past when someone was trying to "run rings" around me by deliberately BSing with some jargon thrown in that they knew was not familiar to me. The effect is that you stop understanding because you feel that the word may have some bearing on what follows.
IOW, an unfamiliar word becomes a distraction. And NOBODY has ever consented to learn my glossary, as industry-standard and correct it may be.
Part of being an IC is learning to deal constructively with ongoing "slights" like clients who won't learn your terminology *almost* seemingly in an effort to taunt you with their denseness.
Bored Bystander
Wednesday, January 14, 2004
FullNameRequired - so you're saying that nobody can buy a custom house unless they know what a joist is? That you can't have a deck installed unless you have a strong background in concrete mixing?
That no company in the country has network wiring unless someone on payroll could talk intelligently about CAT5 vs. plenum and the connectivity issues of fiber?
Come on - experts create custom work for laymen all the time without requiring them to understand the technical underpinnings; it's part of the reason we pay them so much. When the builder asks if you want a large bathtub in the upstairs bedroom you'll probably never know that the cost issue is whether or not he puts in a steel girder.
Fields vs. Records? You're doing it wrong.
Philo
Philo
Thursday, January 15, 2004
 Recent Topics
Fog Creek Home
|
