* The Business of Software

A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

We're closed, folks!

Links:

» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)

Moderators:

Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

WANT 2 BUY: RENTACODER CLOEN RITTEN IN VB-SCRITP 4OR $50!!1

Okay, the title of this entry is a misnomer; I don't ACTUALLY want to buy a clone of RentACoder.  I want to write one.  Or more specifically, I want to write a RentACoder-like application That Doesn't Suck(tm).

This is a thought that's been rattling around inside my head for quite some time, as I indicated in an earlier post ( http://discuss.joelonsoftware.com/default.asp?biz.5.63492.16 ) on this topic.  I've got what I feel are some solid ideas, but I'd like some feedback on them, AND I'd like to hear what other people would like from a RAC-type site.

To summarize: RentACoder allows a Buyer to post a Project.  Ideally this Project should be a specific document, detailing exactly the finished software product required.  Typically, it's a four-page word document wherein three pages focus on the colour scheme, and line four on page two mentions "should implement RDBMS standards."  Nevermind that this project is for a Diablo 2 Character Editor.

After the Project has been posted, Coders post fixed-price quotes on the project.  At this point, a Buyer chooses a coder (either by picking the lowest price, or by throwing a dart at a spinning dartboard), escrows the funds, and ideally the two work together until they have a finished software product, but typically things spiral out of control and go straight to hell.

THIS is the typical project lifecycle in the "Rented Coder Outsourcing" world.  It really doesn't matter which site you visit, as they typically follow the same format.  Some show the quotes the coders give, some don't.  Some have fancy CSS prettying up their site, some don't.  Some crash every five minutes yet still remain in business, some don't.

I want to break this cycle.  I want to smash it to pieces on the floor.  I want to get it out of the way, and when this is done, I want to put one in its place that WORKS.

My theory is simple: We are missing the middleman.

What is the number-one maxim when dealing with customer relations in a coding shop?  Simple: You don't let coders talk to clients.  I will grant that yes, there are exceptional coders out there who can make themselves understood to clients and then run back and code up Google on their lunch break, but such coders are far and few between.  More often than not, you have a coder who is good at taking specific instructions, coding them, and reacting to specific comments on that code.

I'm not trying to talk down on coders.  Coding is a difficult skill.  Men and women the world over spend their entire careers polishing this skill and getting it down-pat.  But coders know the specifics of their job.  They're REQUIRED to.  When a client tells them to "make it look happier", they don't know what to do.  (On average) they don't know what questions to ask to clarify the matter.  Some do, but most don't.

This is compounded when dealing with the Rented Coder Outsourcing world.  These coders are under extraordinary pressure to complete their projects as quickly as possible and get paid.  The faster they get done, the quicker they can get paid and move on to the next project, thereby increasing their earnings/month.  So when a client asks to make it look "happier", they can't spend time ASKING, that wastes precious time.  They drop a smiley-face icon on the form, recompile, and send it back.  What the client actually wants may be a complete overhaul to the UI (which really should have been spec'ed out in the beginning, but we'll leave that for now).  They don't know, but asking wastes time and that is unacceptable in the marketplace as it exists.

So you need someone in the middle.  Someone who facilitates communication between Coders and Buyers.  For now, I call that person a Facilitator because a) I'm not feeling too creative about this name just yet and b) the role isn't 100% nailed down yet.

A Facilitator's job is to take imprecise client Proposals, work with the clients on them, turn them into precise Specifications, and pass those off to Coders, who write the code and finish the job.

So to recap:

* Buyer writes Proposal
* Buyer chooses Facilitator
* Buyer + Facilitator write Specification
* Buyer +/ Facilitator choose Coder
* Coder writes code according to Specification

Issues arising from this:

* Projects will cost more.

Two people are involved now instead of just one, so by necessity the cost is higher, but ALSO, Facilitators are cross-trained individuals who know technology AND how to talk to clients, but do not specialize in either to the exclusion of the other.  Without trying to generalize or appear racist, these are going to be the kinds of people who are upset that the prices for RAC and the like are so low, i.e. North American Coders -- who will want enough money to make a living in North America.  They speak the same language as Buyers (typically), share the same cultural values (typically), and tend to be cross-trained as far as education goes.  I find (on average) that off-shore coders know one or two programming languages and how to implement things in them specifically.  I find (on average) that on-shore coders that get disgusted with and leave RAC are the kind that are multi-talented and flexible due to this.

(It's hard to explain this without appearing racist.  I'm not, believe me.  I work with all kinds of wonderful people whose skins are "brown", "black", "yellow", or who are just different in terms of ethnicity.  They're smart and easy and fun to work with.  But they share my cultural values.  They know the idioms of my language.  They have been trained in many things and are very flexible.  These are not the kinds of coders offering their services for $200 for a four-week project on RAC.  They have had an entirely different education from those people and it turns them into different individuals with different skillsets.)

* Projects will take longer.

The added overhead of having an extra person to communicate with will draw the project out longer.  Also, this design focuses on the COMPLETENESS of the Specification before moving on, so as to reduce misunderstandings and reduce rework.  The benefit, however, is that instead of having to post the same project six times, the first five of which fail quickly and the sixth of which manages to cough over the finish line and collapse at a moderate pace, you have one longer project which Just Works.

* Projects will be completed.

Instead of going out in the horrible flames of confusion, Buyers, Facilitators, and Coders will be able to communicate with each other (given that Buyers can talk effectively to Facilitators and Facilitators can talk effectively to Coders).  Issues that are glossed over nowadays due to the way the system is implemented (like anything other than the colour of the home page icon) will be ironed out by the Facilitator before the Coder even sees it.

I also have other things I'd like to focus on that are additions to this basic idea:

* Changes are integrated into the Project workflow.

In RAC, a change is treated like a rare thing.  We all know this isn't true.  In RAC, a change is difficult to negotiate and record.  It shouldn't be this way.

* Communication is a primary focus.

RAC restricts communication, even going so far as to not allow you to give out your email address.  Their stance on this is that they are protecting their service, which is the matching of Coders and Buyers.

The service being offered shouldn't be the matching of Coders and Buyers.  It should be safety, security, and assurance that the project will be completed.  Certainly all conversations should be recorded or summarized and signed off, but restricting communication actually INCREASES the chance the project will fail and REDUCES the value of RAC-like services.

I'm working on implementing tried and true project workspace practices, and encouraging IM conversations, email conversations, and heaven forbid -- PHONE conversations into the communications avenues available.

I'm taking the approach that "ideas are meaningless, it's the WORK that's valuable" here.  These are my ideas.  They are good, but only valuable if they are put into practice.  I am willing to put them into practice, but I would like some feedback about them before I go running off into the hills.

Am I completely whacked here, or do I know what I'm talking about?  Does this sound right to you?  Am I missing something?  Is there something you wish RAC or its sister sites did but don't?  What would YOU look for in a service like this?  Am I missing any glaring problems?

In short, what do you think?
Dan Hulton Send private email
Thursday, February 03, 2005
 
 
I think you've got the right spelling and style on your subject line. Now go post your RFP to Rentacoder and get an Elbonian who spouts a tirade of alphabet soup about his skills to develop it.

Okay, okay. I kid.

Seriously: Rentacoder and its ilk have plumbed the depths of rate structures. I submit that there is simply *no money* to be made by a middleman at this level of service.

I get occasional calls from agency and bodyshop recruiters. These folks DO have the money available to function as middle-persons, but all agencies are inherently mindless and exploitative. Most important: NONE, I repeat, absolutely NONE take ANY responsibility for a specified result. Their specialty is placing a coder or other "IT commodity" at a client site, collecting the billings, and paying the worker (usually far, far) less.

Project based consulting is a difficult sale all around. Clients like fixed cost projects when they feel an assurance that they are locking in a result for a price. Clients like fixed cost projects a lot less when the price is "too high". "Too high" in many clients' eyes is a level reached and exceeded when you have added in a burden for project management.

The short form of my rebuttal: if there were money in what you are proposing, somebody would already be doing it.
Bored Bystander Send private email
Thursday, February 03, 2005
 
 
Had another thought.

In my opinion, what is REALLY broken about Rentacoder is the braindead notion enforced by that site's construction that a $20 Perl script job has exactly the same contract controls and due diligence requirements as a $5000 software application development.

I believe that the RAC model actually works pretty good for low budget projects, under a couple of hundred dollars. When you're talking about thousands of dollars and days or weeks of work, I don't believe that this format is really useful or helpful.

I think a website/blind bid format is fundamentally unworkable for substantial projects. My guess is that if you tried to launch a "premium contract" website with adequate controls and due diligence, much of your costs would consist of studying and vetting RFPs and proposals that you had no technical feel for, nor understanding of the seriousness and reliability of either the client or the bidder. I'd also say that you would work on 5-10 RFPs and numerous bids for every successful "pairing". In other words, you would be absolutely killed by the overhead of performing the due diligence work.

I like to know whom I am negotiating with. When a web site comes in between us that's very difficult. And as a vendor, how would I know that I could trust the middleman to be accurate *and* trustworthy?
Bored Bystander Send private email
Thursday, February 03, 2005
 
 
Whatever you do, approach this project like you would a program:  get an early functioning prototype working and then just keep making improvements.  That's the BEST, most EFFICIENT way to make sure it meets your customers needs.
Mr. Analogy {ISV owner} Send private email
Thursday, February 03, 2005
 
 
Ok, I actually read the original post.

I've never used RAC, but considered it. (Ask BankStrong for feedback. He's used RAC).

I agree that RAC is missing the middleman. It doesn't have to be a be a middleman, just someone that can bridge the gap of the "idea" and the "spec".

BankStrong (Mike) is a programmer who's used RAC. Found a good russian programmer and hired him full time.

I've LOOKED at RAC (I'm a programmer too) and considered it. I think the tools could be better. And CERTAINLY you need to know how to write a spec (functional and technical) to use RAC.

A SIMPLE WAY TO START
Have you considered just hiring yourself out as a RAC consultant?

OR, you hire yourself out to create a project and then turn around and user RAC?  (Essentially you're a wrapper around RAC)

OR, look at reasonable but not well spec'd projects on RAC and offer to manage the project.  But that means GUARANTEEING the result or you don't get paid.  Your fate rests in the hands of the programmer.
Mr. Analogy {ISV owner} Send private email
Thursday, February 03, 2005
 
 
Pythonic Send private email
Thursday, February 03, 2005
 
 
Since a friend and I independently came up with the concept of "software general contractor/project manager" based on RAC, and now I see you have also, the idea is probably viable. But I think it's only viable if you're getting business by *visiting* companies in Western Europe/North America, and farming it out to coders who can program at $10/hour.
Humans like to look at each other. Actually seeing the person you're doing business makes a tremendous difference to most people.

BoredBystander points out the problem. How do you build trust in a complete stranger you haven't even laid eyes on to handle your US$8k project? And realize that this trust has to work both ways.

I've been emailing a buyer on RentACoder for about 3 weeks now about his project. He needs to be educated about some things and I do that; he accepts that there's a lot he doesn't know and I explain the alternatives. I want the job, since it's potentially quite lucrative over the long term, so my engineer hat's been tossed into the corner and my salesman's hat is firmly on my head. But every time I explain something to him, I have to remember that he's probably (if he's smart) using what I teach him to strengthen his discussions with some guy in Kazakhstan that can work for 1/10 what I'm willing to do. He now has a much better idea of the actual requirements due to all my work -- which has been free up to this point.

Short of having money in escrow to even begin a discussion, I don't see a way around this problem.

For small jobs RAC seems to work well because trust isn't as much of an issue. People who can compete on price alone will continue to do well. More power to 'em!

The real problem isn't RAC itself (other than the annoying unreliability of their servers), it's that most buyers either don't know how much good software costs; or they do, but they're trying to get it as cheap as possible. The first class is the only one that can support a better-paying alternative.

So here are my ideas:
1) Audit all bids for sufficient requirements. If the problem is obviously insufficiently specified, send it back to the buyer or implement (2)
2) Allow not just coders, but project managers to bid on rewriting the requirements.
3) Minimum job $1000. Weeds out people who aren't taking it seriously.

The way (2) would work is a potential PM would look at the new bid requests and tell the buyer he can clean up the requirements for a certain amount. Once buyer and PM agree on requirements, the buyer pays the PM and the coding bids are allowed to continue in the normal fashion, but to the new verifiable requirements.

Hope you read this far ;-)
lw Send private email
Thursday, February 03, 2005
 
 
Just so I don't look like a total idiot:
I noticed that I repeated some ideas you already had. Sorry about that: I was interrupted for about 2 hours while responding and when I got back to it I had forgotten you mentioned some of what I was thinking.
lw Send private email
Thursday, February 03, 2005
 
 
I think we can all spot the obvious faults of RAC.
* Coders submit horrible code
* Coders bid unrealistically low prices
* Coders bid on projects without putting any thought into it
* Buyers don't specify their requirements
* Buyers have unrealistic expectations about price and quality

Putting a middle man in between to steer the process in the right direction is an obvious solution, but I don't think it's a feasible one.

The middle man has to be capable of writing and understanding requirements. He must have good communication skills. And he mustn't mind not getting any real pay.

The programmer must be capable of writing decent code (yes, that includes error handling and documentation), otherwise no sane middle man would want to represent him.

As a result, the buyer has to pay more. Lots more. And the buyer can go to RAC instead, where he can get cheaper labour.

Despite RAC's flaws it seems to be fairly popular, and financially feasible for the site's founders. This can only be because of the utterly simple concept.

There are competent programmers who'd like to write some quality software for a fair price in the weekend. (Check codeproject.com and search for RAC). I think the real problem is attracting *those* people to your site. If the programmers write solid code the buyers will be happy and the rest will fall into place.

Perhaps this goal can be met by just applying some strict moderation. Make sure *all* communication between coder and client is logged, and check both parties on professionalism. If they don't meet your standards you'd be better off without them. If you feel one of the parties is showing a high level of professionalism give him/her an 'approved' status. Hopefully this will make people look at your site and contractors using your site in an entirely different way. No code monkeys, but *professionals*. Gradually, more serious buyers will start taking an interest.

Of course, doing all this moderation work takes a lot of time, but that's no problem, because 'approved' members don't get moderated and can moderate others.

This way you should also be able to guarantee that decent software is delivered. This too will attract better people.

Anyway, it must be fairly obvious by now that I don't really know how everything comes together.
Zorg
Thursday, February 03, 2005
 
 
Zorg and lw, excellent points.

The problem with imposing a management structure on the "RAC model" is that you greatly limit the market. RAC's success, IMO, is due to their extraordinarily low bar for entry. Anyone can bid, anyone can post an RFP. So RAC builds volume and name-recognition by being super-accessible. I can see how the bootstrapping of RAC probably didn't take a whole lot of money, but now it's rolling.

On the other hand, the "professional" version of RAC will be of interest and of use to a far, far smaller cross section of clients, simply because you're limiting such a service to a minimum spend.

This *will* represent a bootstrapping dilemma. Venture capital would probably be necessary to carry it for awhile in order to build the visibility. And that would be a risk - it may bomb anyway.

And many, many "traditional" professional IT consulting services of all types have been in the tank for years. For the exorbitant fees that the consulting companies charge their clientele, they sure have a problem turning a profit.

I tend to agree that the best use of RAC for a professional IT consultant is as a pool of cheap coding labor, where the IT consultant performs the customer-facing aspects of the business and uses the "broken" RAC to get work done for peanuts. So in this instance, the RAC "overhaul" functions are being done essentially on a case by case basis by private entrepreneurs.
Bored Bystander Send private email
Thursday, February 03, 2005
 
 
I've been on both sides of RAC transactions and even considered this myself.

After some market analysis with a buddy of mine, we determined that the market is nearly saturated.

Seriously, go check it out and see how many freelancing/offshoring/etc sites there are out there...
KC Send private email
Thursday, February 03, 2005
 
 
One of the things I had thought about was an auditing process like was discussed above, however, it was more of an optional thing.  Facilitators would submit themselves for auditing, and I would physically call them and run them through a technical interview, asking questions like "How many gas stations are there in Los Angeles?" and the like.  Basically, test their communications skills and critical thinking skills primarily.  Also, throw some basic "problem proposals" at them and see how they try to turn them into specs, what questions they ask and the like.

I thought for a while about trying to make a "wrapper" for RAC.  Buyers post proposals which are refined into Specifications by Facilitators, and then the Buyer goes to RentACoder to finish off.  It feels... unclean, you know?  There's no-one doing due diligence on the actual code itself, so there's no guarantee that it will be any better than what they could have gotten at RAC in the first place.

And when you get up to the US$8k mark, I'd really imagine people preferring to form relationships with people.  So they'd pick a Facilitator, work with him a couple of times, know he's quality, and then cut this site out of the loop by going to him directly (possibly).

All good thoughts I hadn't thought about, to be honest.  I'm half-tempted to scrap the idea of middlemen and offer "a cleaner, better RentACoder".

Now that's almost a thought, actually.  Make that "Specification Revision" a project category?  Since the admins at RAC have to approve of every submission anyway (I'm told), I would get ample opportunity to tell people that their specification is weak and unlikely to turn out the way they'd hoped, and suggest they post it in the "Specification Revision" category to get it refined first.

Damn, that sounds better the more I think about it.  Cleaner, easier, lower barrier to entry...  Someone shoot holes in that please?
Dan Hulton Send private email
Thursday, February 03, 2005
 
 
Instead of shooting holes through your idea... how about a different idea: set up a consultancy that uses RAC for performance of deliverable work, but does the customer based marketing and sales itself. IOW, a Rentacoder "broker" who provides the project and client management and direction, and relies upon RAC for economy of operation.

This is close to your "wrapper" concept but cleaner in that ultimately, *you* are the quality control.

My inspiration: I saw a guy driving around town yesterday in a van that was garishly painted with the Ebay logo - the guy's business is apparently the bundling of Ebay auction services for the computer-unknowledgeable - an "Ebay broker", so to speak. And I've heard of people doing this in other areas. (no idea how successful the Ebay middleman concept is.)

I think it's a valid analogy - most clients who don't speak geek would have no idea of how to manage a remote or offshore developer.
Bored Bystander Send private email
Thursday, February 03, 2005
 
 
Very interesting topic.  Finally, someone who doesn't assume that just because a foreigner works cheap, he must be an idjit.

I believe that RAC has been sporadically trying something like what you're talking about - placing project managers to act as middlemen.  I suspect that a fair part of the problem is the same issue that makes a middleman useful in the first place.  A truly good middleman does not necessarily have better tech skills than the coders, but can also communicate effectively with the customer.  This may mean being local and available for face-to-face.

But with or without it, who cares?  You don't need to compete with RAC - there are nuggets of gold waiting to be picked here by Americans.  There are plenty of foreigners who can code and who are thrilled to make a fraction of American wages.  Building on the value that the OP pointed out, how do you translate your Americanness into dollars?

There has never been a lower barrier to entry to start up an ISV than right now if you can specify and manage.  And supposing you don't have any great ideas to exploit right now?  Build a company that takes on projects from American companies.  You manage the project for a fixed cost and get good, cheap coders from RAC.
N. Elk Send private email
Friday, February 04, 2005
 
 
Elance http://www.elance.com is a site just like Rent A Coder but with the following differences:

- bidders must pay a fee to be able to bid
- they certify bidders
- they show all the bids of a project
John
Friday, February 04, 2005
 
 
Yes, eLance used to be fantastic years ago, but more recently seems to have gone down the toilet, much like the others, like RAC, etc.
Bideford Send private email
Friday, February 04, 2005
 
 
And there's Guru.com. Also, there's Prosavvy, which has very few independently verifiable success stories associated with it, and steep startup fees (~$5000) for the consultant that many complain are never repaid with viable job leads.

This segment has gone through some consolidation - itmoonlighter.com (active as late as summer 2002) has been absorbed by Guru.com.

I keep going back to the assertion: if there were money in this segment of the market - running an IT services bidding site "professionally" - someone would be doing it already.

I agree with N. Elk that the barriers to starting a specific type of outsourcing service have never been lower. I just haven't figured out how to sell the proposition effectively to clients.
Bored Bystander Send private email
Friday, February 04, 2005
 
 
Bored -

I would start by explaining in all the important ways (web site, brochure, etc.) why what you are doing is so terrific:


- Why RAC is so great - and who it is great for
- What RAC is scary for
- Why using a middleman is so important
- What the benefits are of using RAC + middleman vs. RAC, traditional outsourcing, traditional in-house, etc.
- What are your qualifications for acting as a middle man?
- What will you do for the customer?
- Why should they risk doing business with you?  What kind of case studies, referrals, guarantees can you offer?
- What should they imagine themselves to be when they are done with the project?
N. Elk Send private email
Friday, February 04, 2005
 
 
I will believe in the viability of "rent-a-coder" type models for anything other than very commoditized style black box components when someone starts having success with:

rent-a-doctor
rent-a-lawyer
rent-an-accountant
rent-an-obgyn

Ill be waiting.
SourAaron Send private email
Friday, February 04, 2005
 
 
First, RAC sucks. As a programmer, I've kept food on the table a couple of times with jobs from guru.com.

Second, what we need is a way to do software about 100x better than "traditional" methods (including XP). if you can create a layer between programmers and clients that delivers value, you will succeed.

Last, I think you need to think outside the box re your pricing model. Say for example a client wants to pay $5k for a industry standard app, and this is a one programmer project. What if the PM gets $5.5K and the programmer $4.5 with $1k in escrow that can only go to the pm if BOTH the client and programmer agree value was received.

Risky, true. But think of the high moral ground you could stake out!

IMHO.
Bob Walsh Send private email
Friday, February 04, 2005
 
 
You're living in typical programmer dream land. If there was a middleman involved, he would get $9,000 and you would get $1,000.

Saturday, February 05, 2005
 
 
This idea is as interesting as domain squatting or making a website to aggregate bogus search results. The reason why sites like rentacoder exist is because on both sides of the deal you have people who are too stupid to figure out that they could both be making more money selling trinkets on ebay.

Saturday, February 05, 2005
 
 
I always looked at Rentacoder as a way of streamlining the process of matching up Samirs with Lumberghs. I guess you are proposing a way getting the two Bobs involved in the process?

Saturday, February 05, 2005
 
 
It's not quite that simple.

I know of developers who use RAC just to get their foot in the door. Once they've done a good job on small to medium sized projects they've made a good first impression. The next time the company is looking for a contractor they'll be at the top of the list. And this time they *do* get paid real wages.
Zorg
Saturday, February 05, 2005
 
 
The name for your middleman is already invented long time ago. It is system analyst or colloquially speaking  requirements guy. This person “extracts” requirements from the customer.
The problem with RAC is that it taps to the lowest rates. It attracts customers who cannot (or do not want) to pay more.
If somebody wants quality and more or less predictable results, they go to professional consulting companies (either on-sore or off-shore). There is no miracle with RAC, you get what you paid for. Good developers and good off-sore outsourcing companies have rates cheaper than US rates but not that cheap.

When innocent customer goes to RAC, all developers look the same (same alphabet soup of technologies but no effective way to verify credentials) and I assume many go for the cheapest deal.
RAC has one web site, which gets fees from thousands of its clients. Your middleman will be able to work on one or two projects and you have to pay him/her US salary. Have a look at traditional software shops. Even with ability to control what is going on within their development team, practicing different development processes like XP, UP, SCRAM and plenty of others, they still have challenges delivering software. In your case, you will make it shakier by introducing more variables.

RAC model is cheesy because it enforces customer to write requirements and very often customer cannot do it satisfactory (hey, it is not regular non-IT customer job). And developers (not just coders) who potentially can elaborate requirements cannot compete well in that framework.
Consider hypothetical exchange:
Customer RFP: “"should implement RDBMS standards."
First bidder: “We need to elaborate requirements before I can give my estimates”
Second bidder:  “I can do it for $100”
Who do you think will win the contract?

I think, more feasible idea is to start consulting company with head office in US and development team(s) off shore. Create a bank of such teams or even create such teams yourself and handle US projects there. In this case, you will always know who your developers are.
Eugene
Monday, February 07, 2005
 
 
As Mr. Analogy mentioned, I hired a Russian programmer using RAC.  I bid out a small project, found someone good (I asked him programming and design approach questions and looked at his old feedback).  I fed him larger projects and eventually hired him on.

I couldn't be happier with this guy's performance.  He's a very hard worker, very smart, and very happy to be working for me. 

Granted, the guy is ranked in the top 0.1% on rentacoder, but I'm telling you that there is good talent out there.  RAC has neatly organized it for you.

Mike
Bankstrong Send private email
Tuesday, February 08, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz