home

home
Merchant
    Part 1
    Part 2
    Part 3
FAQ
Links
News
Rants
Info
 
Warning: Most of this page was written before I started selling my own services in the Miva world. Not that it changes anything, just thought it ought to be said. Developers and clients are welcome to send comments, suggestions and complaints here.

Selecting a Software Developer for Miva or Merchant Work

Picking a developer to either create or maintain Miva Script applications can make you feel like a monkey wandering the midway at a carnival. There are lots of pretty lights, bells & whistles which can easily distract your normally-operating common sense. I've received a few horror stories since this site went up, along with requests to recommend one developer or another for a project. After hearing about a particularly screwed Merchant client once I figured this page might have a place in the world.

So what follows is what I "tell all my friends" about selecting a developer for any software project. Please remember, I do not endorse one developer over another based on anything but personal opinion and experience, and I mention none of them here.

Know Who They Are -- The Miva community is small and rather tight-knit. Anyone who is active in the community will know "who the players are". If you are considering a particular Miva or Merchant developer, try asking active members of the Miva mailing lists about the candidate person or agency. Or if you come across a particularly entertaining modification or module add-on, find out who wrote it and ask other folks whether they've used their services or not.  Search the developer's name or company through the Miva mailing lists. Read all the messages they have posted on the Miva mailing lists and see just how competent and friendly they are.  If they are not friendly and approachable on a public mailing list there is no reason to assume they will be any more polite in private. Manners count, no matter who you think you are or where you're from. Nice people are easier to work with than nasty one's.

A Miva developer should have a tangible footprint in the Miva community. If you find no signs of them on the Miva mailing lists, I would suggest that they lack a credible sense of responsibility to the Miva community as a whole. If a developer tells you they do not participate in the Miva mailing lists "because of all the stupid questions" then what makes you think your own questions to them will be regarded with any more patience or compassion? 

HTML Does Not Equal Miva Script -- There are a few 'fly-by-night' amateur HTML coders who believe themselves to be Miva developers. Remember: "a pretty HTML page does NOT a Miva script make!". Miva Script resembles computer language much more than HTML.  It cannot be generated by a code interface tool, and it is not a script language which is particularly compatible with web development systems. Just because an HTML coder can edit a few lines of someone else's source code does not mean they know what they are doing. Do not hire a person based on what their web pages look like; unless that is all you are buying from them.

Ask For References -- If you cannot establish the credentials of someone, or they cannot offer you a specific example of where they addressed your same problem/project before, ask them for references or their own unique code samples (not re-hacks of someone else's source code).  If they cannot provide specific reference examples to work very similar to what you want them to do, ask yourself why. If they claim grandiose references that 'must be kept confidential', start looking for the stink bomb that's about to go off under the table.

But just because a developer cannot offer exact examples of what they can do for you does not mean they are fraudulent. Maybe they are just getting started. Maybe they are obligated under previous contracts to not show a client's work in a portfolio. But if all their references are 'covert' a small bell ought to start ringing in your head indicating the bullshit meter just went off the scale.

Proof Is In the Code -- If they cannot show tangible examples of previous work, ask them to prove their skills. Ask them to take the job on commission and defer payment through a staged approval process. It is not wrong for a developer to request a deposit on a job (sometimes I am paranoid if they accept a custom project and do not ask for $$ up front); but if they are just getting started, why should you pay for their learning experience? If you are taking an unproven risk on them, they darn well ought to be willing to take a risk on you. It is the developer's right to expect payment for services rendered; but it is their responsibility to prove they will earn your money honestly and capably.

Look for Longevity -- Like mentioned above with the "HTML Does Not Equal..." stuff, the same applies to the term of experience the developer is bringing to the table. If someone claims "years of Miva experience" try searching the Miva mailing list again and see how long they have been in the community. If you find messages from the 'developer' asking stuff like "What is miva?" just a couple of months ago, are you sure they have the experience level you need?

It can be fun to read old list archives and follow a developer's progress. Everyone starts at some sort of "How do you..." level. Everyone has to start somewhere (proven by some of my own brilliantly stupid postings to the lists!).  If your candidate cannot be found in old archives as participating in the community, be concerned. Where exactly did they turn to for code advice as they were learning the language?  Why have they not participated in the Miva community if they are so good at Miva scripting?  If you look at undisturbed sand and see no footprints, it is usually pretty safe to assume that no one has walked there, eh?

Do Not Switch Horses Lightly -- If you find a developer who performs for you, and at a reasonable price, do not jump ship on a whim. Bill Gates aside, developers are regular 'ol normal people. Some of the most talented are genuinely eccentric too. I know a guy who can type assembler code free hand -- but only on a laptop on his porch or in the bathtub, and only in sunny days.  Try to be  forgiving of personal quirks and oddities and keep your eyes on the resulting code. Do not expect someone to change their lifestyle just for you; but do not permit them trample on your own.

If you think a developer has not met your requirements, raise the flag then -- not later. Expect bumps and mistakes, and do not jump ship when you encounter them. Good quality code takes professionalism and patience. But also remember that absolute perfection is hard to achieve.

Know What You Need - Not What You Want -- If you cannot write a simple, few sentence description of your project do not expect a developer to perform as well as they could. You must be able to concisely say what feature, attribute, or action you are interested in buying. You cannot ask a developer to "Change my Merchant product display to 2 columns, drop the left navigation bar, and throw away the product list".  And then a week later say "You know, that product list might come in handy for...". When you cannot describe exactly what you want, the developer is only guessing; and on your dollar. If you want to add or subtract components expect to pay more.  It will cost to change your mind. Sometimes it will cost more to change something than it did to write in the first place.

I worked in the world of pre-press and typesetting for many, many years. It is common in the pre-press industry to charge highly for 'alterations' or changes after-the-fact. We usually charged (some 15 years ago) a minimum of $1 per alteration. I had one $75 job turn into an $1200 alternation job.  We earned every bit of it, and they had to pay for it. Know what you want before you order it or don't order it in the first place. Code mistakes can be costly.

What About Upgrades? -- Almost all packaged Miva Script modules come with a defined upgrade policy; and the policy is that you will have to pay for major-version upgades. Each major release version of Merchant (or most other programs for that matter) will require updating or upgrading the modules that attached to it. Its a fact of life. Do not whine and moan that you just bought and installed Merchant v2.0 a couple of months ago, bought 10 modules and didn't even install them all, never used it, etc. -- and now there's a brand new version with really cool bells and whistles. Expect that you might have to take out your checkbook.

Many/most Merchant modules are written for a specific release version. Like v1.x or v2.x or (now) version 3 of Merchant. I do not know of any modules written for one release version will work with another release version. So when you contact your developer for an upgrade, unless you know you are covered under an existing agreement or support plan it is realistic to expect money to change hands again. The next time a faster Pentium chip is released, try contacting the people you bought your computer from and telling them you expect a free upgrade to a higher speed. Think about it.

Support Does Not Mean Pantyhose Clearly understand what the support options are. Many add-on components are sold "as-is" becaue they are known to work with specific release versions of a parent product. Others are sold with installation included. Some have 30-days of support (or less) just to ensure you've had an opportunity to install and test the piece you bought. Ask what is included before you buy.

Ask Who Owns The Code -- If you are buying code you had better ask who owns it. Just because you purchase the work of a developer does not entitle you to re-sell the code.  You should ask for all source ownership to be clearly stated up-front before any work is performed. On the one hand it might be ethical for a developer to charge a client $4,000 for a custom Merchant module; and then re-sell the same source to 500 others for $50. On the other hand a client may purchase a $10,000 code job with the intention of re-selling it to 10 others at $100 a piece to break even. This should never be left up to question.  If the developer does not raise this matter - you should. There is no right or wrong on code ownership; it all depends on the developer.

Do not complain if the developer charges a substantial premium, or requires a verified commission, for any resale of what they write for you. Copyright ownership of code sometimes (usually) comes at a hefty premium. Do not freak out if a developer asks for 10 times the original source cost for transferring copyright ownership. Gets even weirder in the world of ASCII applications, which is what you are buying in a Miva script. It is much better to ask up front than risk legal liability later.

Let's say you hook up with a developer named Beelzebub. He seems a talented person, and all his references sound up to snuff. You buy a highly customized Merchant UI file which also includes another 4-5 add-on modules in the package. You pay $50 for it, and think you're running the coolest Merchant site around. Then about 5 months later you get a registered letter from an attorney which presents you with an invoice for $15,000 (plus legal fees, of course) for the custom UI you are running; which was actually written by Developer XYZ for client ABC. As it turns out Beelzebub had simply ripped the UI off one of his other clients, edited a few lines (to delete the copyright info) and resold the package to you. And now Beelzebub's phone number connects you to a roadside coffee stand in Bosnia. Now wouldn't that be fun!

Know Your License -- most modules and licenses sold for Miva Merchant are of the single-store type. This means that regardless the cost of the module, just because you bought it does not mean you can use it in another store or give it to a friend. Many Merchant modules are written with license checking or fingerprinting code built-in to prevent pirating. Don't assume you will not get caught duplicating or sharing paid-for modules. You'll be surprised.

And do not assume that it is OK to take a paid-for module, add a few features to it and resell it to someone else. Most free modules won't permit this either. If you do not write the overwhelming majority of the code yourself, you'd better be sure you know who did. You won't get shot for using a one or two line snippet from a factory-sample; but ripping off a module is theft.

PAY YOUR BILLS! -- you cannot expect a developer perform their best unless you demonstrate you meet your side of the obligations. If you agreed to a third-third-third contract, you are expected to meet the payment schedule that entails. Do not ever post or actively use work that the developer has created for you but has not yet formally approved. Many times a developer or deisgner will provide you with mock-ups and/or demonstration scripts. Resist the temptation to use the samples -- in any manner -- without the developer's specific permission. If your contract with the developer is not concluded you may open yourself to great liability exposure. You also run the big risk of running beta code which is not yet bug proof and may actually damage your site.

Check Them Out With The Home Office -- If they claim to be a licensed Miva developer they most likely are. So it should be no large task to ask the folks at Miva Corp if the developer is in good standing with them. Ask for the date of their current license agreement with Miva.


So generally it is like all else on the internet: caveat emptor. Check into these sorts of things before you hire a developer and not after.  By then it may be too late.