Slashdot Mirror
Attitudes in IT - Mediocrity Wins?
podo asks: "I've spent the past two months of my life working almost full time on a PHP/MySQL based web site for a client. Today I received an e-mail from the client point me to a similar web site set up by a competitor. 'Doing exactly what we are doing.' The site in question is not doing what we are doing, they have no dynamic content, no web forms, just e-mail addresses. They scarcely have any content (I counted only four HTML pages) at all. The client is chastising me for taking a long time and because the other site is 'much more impressive visually' than ours. Has anyone else found themselves in a situation where their painstaking work is compared to work which is a showcase for mediocrity? How have you dealt with such clients who fail to see the difference between a shoddy rush job and real quality?"
It's called The New Jersey Approach.
pb Reply or e-mail; don't vaguely moderate.
The site in question is not doing what we are doing, they have no dynamic content, no web forms, just e-mail addresses.
Yes, but was that in the specs? Or was that something you voluntarily done for your client? If the client's requirement was "a simple Web site showcasing our products and allowing people to contact us", then he's right in pointing out that some things can be done cheaper and faster. You might have implemented scalable multi-processor algorithms for error-checking the text in the Web form, what does he care?
Keep in mind that clients rarely know what they want until they seem something tangible, be it something you develop for them, or something they see.
Regardless, satisfying a client without a very detailed spec (which they sign off on) is a very difficult thing. It's never good enough, or is never matches their conception of what they were looking for.
Always, always, always, have a spec document that details exactly what they're getting for their $$$. Then, when they bitch and moan about what you gave them, point at the document. It's not a fail-safe way to do business, but it will help you not get sued. It also helps prevent scope creep, which if allowed will impact *your* bottom line, not theirs.
In my opinion, this points to a decided lack of a proper design phase in you development process.
Does the client really not know enough about the design of what you are building for them, that they have made such an 'obvious' mis-comparison with the other project?
Design is more than just 'its going to work this way', its also 'its going to work this way, because'
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
I think you missed a word: visually. A good layout and visuals are not about coding and they require a totally different set of skills.
Only a plumber would care mostly about plumbing when buying a house. Most people will first judge on how it looks and how they feel it would be like to live in it.
Could it be that your client is right? I mean, if your pages have a beautiful back end, but a front end that looks like processed yak's droppings, isn't there a good chance that a prospective customer will go for the more 'professional' website?
You might have an amazing database engine, but if it is not visually appealing, there is still a major issue.
To sum up: Customers like shiny things. Make it pretty.
Objects in the blog are closer then they ap
The best lesson any developer can learn is to make sure you have a good graphic designer on your team.
:S
Sadly, it has been my experience that flash always beats substance. My bosses/clients have always spent all their time niggling about design, layout, and color selection, rather than the actual functionality
That way everyone is happy.
Oh, yeah. It's happened to me many times in the past. The key is to:
1) Write a report explaining the importance of each and every piece of your project;
2) Schedule partial presentations at least every other week;
3) Write another report showing the weaknesses of your competitor, and providing information as to why your project (and in consequence, your client's project) is technically superior.
But don't forget that from a layman's point of view, prettier is almost always better (and the case is not necessarily true).
Utinam logica falsa tuam philosophiam totam suffodiant!
Then you can explain to the client in question why "visually impressive" means absolutely nothing if the site is functionally inadequate.
Have fun.
This sig no verb.
No -- it's not.
As many others have already pointed out, this was a design flaw. Apparently there is some disconnect from the user (client) and the developer. The developer is creating something different from what the user is expecting, wasting lots of time.
If the above isn't true, then the developer hasn't created a valid requirements spec which can be shown to the user to explain the difference between "crap product X" and "your product". Needless -- it sounds liek the client/user isn't being involved nearly enough.. where's the ongoing UAT?
Are you confused about the difference between "quality" and "features"?
"Quality" and "features" are not exclusive.
Negative extremes of these two are "over-engineered" and "bloated"
Would you code in triggers even if your project didn't need them, or merely insist your DB had them in case you might need them? (Smells like over-engineered)
Sam
blog.sam.liddicott.com
For example, you state they only have 4 pages of content - how many do you have, etc.
There are a number of things about your post that strikes me as a bit odd. For example... when we bid projects we give a firm one-time price and a firm one-time delivery date. These are always adhered to - come hell or high water. Of course, changes to the specification can cause changes to the price and timeline, and our clients are aware of that - but as long as no changes are added to the original requirements document we ALWAYS meet our deadlines. Your post tends to leave that kinda open ended (I've given two months of my life - well, didn't you SPEC THAT OUT?).
Secondly, a MAJOR part of our client relationship is TEACHING THE CLIENT what a good website is, etc. Since almost 100% of the sites we do are heavy cgi-bin coded sites (C) with database handling, image processing, etc... there are many factors in such sites that require us to teach the client why one approach is better than another approach. THIS SHOULD BE DONE UP FRONT - NOT AT THE END. You have committed to an approach, but it doesn't strike me that you have educated your client as to the pros and cons of your approach.
Step 1: Discuss the clients needs with the client and show them examples of a number of solutions and outline to the client why each solution is better/worse than the others.
Step 2: Have your client give you feedback on which approach they wish to take, and why. Keep in mind how the site might progress in the future.
Step 3: Deliver to your client a detailed specification that outlines the site, the engines, how they work, how navigation works, how the site graphics look and feel, firm FIXED price and timeframe to delivery. Include periodic goals to show the client (we actually allow the client to critique the design while it is in progress)
Step 4: Create said site, in said timeframe and for said price.
At this point, it doesn't matter what the competitor does or did - the CLIENT was offered all the solutions and all the pros and cons and was properly educated as to why each was good / bad. OBVIOUSLY the competitor also selected one of those solutions - if they didn't, you left one out of your explaination. But assuming that you did your work correctly - than the client will ALREADY know the competitors site sucks (or cost a boatload more) and they will know why.
Most likely the call you will get from your client is *hahahahaha, check out the crap that the competitor did - man are we glad we went with you*.
Yeah. It's not like I'm paying your money or anything, so why in the hell would you want to do what I say?
The arrogance of programmers is only exceeded by their snottiness.
You can tell a great deal about the character of a man by observing those who hate him.
And the resolution is the same in every case: either the consultant over-estimated what the client wanted (in which case, the consultant is in trouble), or the consultant has to explain to the client that his so-called alternative really isn't that great.
Nothing to see here ... move on.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
Then concentrate on layout, but in the first place:
Make shure you have the fsck**g content for the site.
Then go back to refining the layout.
The backend should never take two whole manmonths for a single customer.
No wonder you have bitching customers.
Yeah. It's not like I'm paying your money or anything, so why in the hell would you want to do what I say?
If you are willing to hire someone to do work you don't know how to do, you should be willing to listen to them.
Example: Lets say a client comes up to me and asks about upgrading his CPU in an AMD 1.13GHz/64MB machine because his machine is too slow.
I'd ask him what he was doing and probably suggest upgrading the memory instead.
The problem is when he ignores my suggestion and goes with the CPU -- in the end, his machine will be slow, he won't be happy, and it will look like I did a crappy job.
Speaking as a long time consultant who runs into this all the time - it's not a case of quality vs mediocrity, it's a case of ignorance. :)
The problem is conveying the value to someone with no foundation of knowledge to build on.
In this particular case I would use real-world examples of how your implementation is better. E.g. "If you decide to do XYZ or ABC or whatever down the road you can with my design because I've taken the time to analyze your needs and plan for the future. The site you're looking at would cost more in the long run because of the lack of forward-looking infrastructure."
That said, I would definitely see about partnering with a good graphics designer to make your site just as pretty (or more so).
Looks sell, ask any beautiful woman!
However, to hopefully help you out of this mess, here is some light reading that you might find useful:
1) Read Don't Make Me Think (not on safari yet) by Steve Krug. It's the best web usability book out there and will take you all of two hours to go through. His usability testing alone would have found your problem earlier.
2) Read Eric Meyer on CSS(no safari) to find out how to make your site look better. If you can find/afford a designer, use them, but learn how to abstract your design from your code and your life will be much easier. (If you like it, there is More Eric Meyer on CSS (safari) as well.
3) If you're trying to do public sites, I've found Submit Now (safari)by Andrew Chak to be an excellent read. It's common sense, but its good to be reminded.
I hope this helps, and good luck salvaging the gig.
Yes I've dealt with this one.
First, if your client doesn't appreciate what you are giving them, you are either giving them too much or not selling them on what you're giving them.
Giving them to much - there is no point in giving your client something they will not appreciate. If you can't get them to appreciate it, it's not worth your time to develop it.
Not selling them - If you are dead set on giving your client something they don't value, you have to convince them that they need what you are offering. This is an uphill battle, this can be a full time job.
They key is to find out what your client truly wants, and then build that for them. When a client doesn't know what they want, you're in big danger, those are the kind of clients who won't appreciate what you give them (they can't appreciate it if they don't know they want it) and who will come to you with new bizarre requirements late in the project (they feel they haven't asked for much up to this point).
---
I support spreading santorum
Put together a list of differences between what you are putting together and what is on the website in question. Make the list detailed as possible, things that are obvious to you are clearly not so obvious to them. E-mail the list in a polite manner to inform the client of the differences, and that yes, if they want to drop any of these features it will simplify and speed up the development process. Then they can decide if the extra features justify the extra time.
User error, execute?
I wish I had clipped and saved the column I saw some years ago in a controlled-circulation publication, I believe it may have been Industrial Photography. It's a very old problem. The columnist described it as how to deal with the client who insists that you could save very large amounts of time and money if you would only provide just very slightly shoddy work.
His answer went something like this: "I am a professional. I am exactly as good as the last job I have delivered. All my work is of professional quality, always, and I do not compromise or scamp my work for anybody, ever, because that is not what professionals do."
He went on to say that a professional must never do shoddy work and must always be willing to risk his job when asked to. He argued that it was committing career suicide to ever have shoddy work in public view with your name on it.
One of the characteristics of a professional is a sense of responsibility to "the profession" and to fellow professionals, as well as to the person who is writing the check.
I expect to get flamed by replies from people who write checks or who have been indoctrinated by people who write checks, and I don't say he was 100% right, but there is an ethical dimension to professional work.
"How to Do Nothing," kids activities, back in print!