Copyright 2005 Ross LambertI’ve heard several prominent web marketers mention in their classes and public forums how easy it is to create your own software. Why, all you have to do is run over to Elance.com or RentACoder.com and have some poor shmoe from Outer Slobvia whip out what you want. And all for
price of a few trips to Starbucks.
Uh, not quite.
Is that a spec in your eye? -----------------------------------
First of all, there is
matter of specifications. A spec is a description of what your software should do. The more specific your desires,
more detailed your specification needs to be. Even
most malnourished coder in Slobovia is going to balk if you say, “Try a gray background–oops, no, don’t like that. Let’s try light blue… Oh, that’s not right, either. Let’s try mauve.” If you just want to specify “the important stuff”, you have to be prepared to accept all
“unimportant stuff” however it is handed to you.
By
way, both RentACoder.com and Elance.com have provisions in their process and terms of use that protect their developers from vague specifications. The good news is that there are also provisions to protect you,
publisher. Regardless,
more detailed your specification,
greater
chance of a happy outcome. Ah, but writing those darn specs takes a lot of time… far more time than it sounds like when
gurus tell you how easy it is.
This was only a test… ----------------------------
There’s also
small matter of testing. Once you accept a developer’s work, they get paid and get on with their lives. You, however, must live with
software. If you don’t find every bug that must be fixed before you pay
coder, you either have to put out another project for bid to repair things or live with
problems until you do.
Therefore, you must test your software upside down and backwards, on a variety of machines and different versions of operating systems. You must also test
installer and
help system… oh, you forgot to specify those? Too bad, those tasks now require an additional project. Since they are radically different in nature (one is technical, one is not), you probably need two different people to do
work. Coders are rarely proficient enough writers to create an effective help system. I’m being kind, so let me emphasize this point without getting nasty: Don’t let your programmer touch your documentation. Period. Never. Ever.