Click here to monitor SSC
  • Av rating:
  • Total votes: 70
  • Total comments: 22
Damon Armstrong

Contract Coding: Ensuring your Client pays up

26 September 2006

I remember talking to a business owner who provided me with this bit of insightful wisdom: 'Everyone is happy as long as everyone is making money.' As it turns out, he screwed his employees and business partners out of every dollar he possibly could, leaving everyone pissed-off and miserable. So you can say that he proved the statement to be true, using reverse induction. Suffice it to say, it’s not fun when someone refuses to compensate you for your hard work.

I had an object lesson in non-payment during my freshman year in college. A local business contacted me about building them an e-commerce website. This was during the 1990s, so 'e-commerce site' loosely translated into today’s technology would be 'crappy shopping cart,' but at the time it was a high-tech endeavor. They were based out of a rickety old house in a shady neighborhood just on the outskirts of Dallas. They seemed nice enough, and, after hashing out exactly what they wanted, we settled on a price: one thousand dollars. It was a small fortune for a college student, and I had big plans to use that cash to break my dietary dependence on Ramen noodles, and undertake other grand plans that seemed fairly epoch to me at the time but the details of which now elude me. I swaggered home and labored for a month to build the site.

Once I'd built the application exactly to specification, I went to deploy it on their server and give them a run-through on how to use it. The installation went fine. The demo went fine. Everything was working and working well. Then came the question: 'Where is all of our product information?' They had hundreds of items they wanted to sell, hundreds of photos to go along with those products, and lots and lots of product descriptions. And apparently they had gotten the extraordinarily incorrect impression that I was going to be the one who entered all of it into their database. I told them that I originally took all of their product information so I could build out an appropriate database schema to hold the information, but that we never discussed anything about data entry. I might have considered importing the data if it had been in electronic form, but they only had hard copies of the information. After a bit of arguing, they begrudgingly gave me the check, and I went home a thousand dollars richer. Or so I thought.

I found out later that they had called up their bank and canceled the check, leaving me with only a worthless piece of paper. They also left me a voice mail a few days later, informing me that they had reconsidered the situation and had come to the extraordinarily incorrect conclusion that I should have done the data entry. I attempted to call them back, to work something out, but I got no answer. Apparently they also thought that they should take my application and not pay me either. Now, you might think that not getting paid has left me somewhat bitter, but I want to assure you that that is simply not the case. What really left me bitter is that I deposited their check before they called me, and my bank charged me $25 bucks after it bounced. Talk about adding insult to injury!

I have to say, in their defense, that I do not think that the little company being run out of a rickety old house in a shady neighborhood just on the outskirts of Dallas had premeditated plans to steal my application and make off like bandits without paying me. There was obviously a lack of communication about the scope of the project, and I’m sure they felt justified in taking the action they did. But the reality is that they had my code and I had nothing. No contract. No documented scope. No emails to back up my claim. No way to collect on my botched deal. No nothing. It was quite a learning experience and one that I learned hard and well. Over the years, I’ve talked with a lot of people who do contracting work on the side, and this article outlines some of the ideas and insights I’ve gathered on avoiding nasty situations and ensuring that you get paid for the work you do.

Contracts and scope definition

You’re called a "contractor", right? As such, it seems that you should have an actual contract, for the sake of propriety if nothing else. The reality is, however, that most contractors start contracting without ever actually making an official contract, or even fully defining the scope and deliverables for the project they are undertaking (guilty as charged!). Clearly, this can lead to serious problems down the line.

Project scope definition

One of the first things you need to do is to define a clear set of objective deliverables for the project. Normally, you define deliverables in a 'scope' document, which outlines the extent of the work you are agreeing to complete. You can also think of the scope document as a high-level 'design' document on which your client signs off – just like a contract.

When you create your scope document, you are essentially defining what needs to be done in order for the project to be considered 'complete'. Outline each item that you are going to complete, and attempt to be specific about what 'complete' means. If you are building a website, make sure to identify all of the pages in the site and the specific functionality for each page. The more detailed you are, the better off you are if you have a disagreement with your client over part of the project.

Also, remember to include a statement that indicates you are only responsible for items specifically designated as deliverables in the scope document. This helps protect you from any assumptions the client makes, but which he forgets to tell you about. For example, if you deliver an e-commerce site and your client comes back and says that you are responsible for all the product data entry, you can point them to this clause in the scope document and tell them that, since the data entry was not a deliverable, you are not responsible for its completion. If you want to be doubly-protected, you should also include a section outlining specific project items you are not going to deliver. This may seem a bit redundant, but specifics are always better than generalities.

Alongside the scope document, you also need to prepare a formal contractual agreement for the work you are about to undertake.

Writing up the contract

There are many tangible benefits to be gained from establishing a written contractual agreement. Hashing out a contract forces you and your client to outline all of the terms of your engagement, and it legally binds both to the fulfillment of those terms (at least, it does if you do it right). If you complete all the work outlined in the contract and your client fails to remunerate you in the method specified, then you have a means by which to pursue payment in court. Of course, it also means that you need to do a good job of outlining specifics, because ambiguity can only harm you.

So, the question is: what do you need to have in a contract? Here are some of the things that you will definitely want to consider:

Project deliverables

As described in the previous section, you and the client should formally agree and sign off on a scope and deliverable document, which can then be explicitly referred to in the contract.

Project timelines

You need to define how both sides handle time-sensitive situations and deadlines. Is there a deadline for finishing the project? Is there a penalty for finishing the project late? A bonus for finishing the project early? And, perhaps most importantly, what happens when the project timeline shifts because the client fails to provide a time-sensitive deliverable? I’ve seen too many clients say they need something in a month, wait three weeks to give you what you need to start on the project, and expect you to have it done in a week. Always include something about delaying the project timeline in response to delays for items on which you depend, but the client fails to provide. You will be amazed at how quickly you can coax your client into getting things done when they know there are defined consequences for delays. You may also want to specify how you are going to bill clients during a period when you are waiting on a dependency.

Compensation

You need to define all aspects of how you will be compensated for your work on the project. Are you paid based on an hourly rate? Are there limitations on the number of hours you can bill in a given time frame? Is it a fixed-bid project? How, when, and to whom do you submit invoices? How much time does the client have to pay an invoice once it is received? What happens if the client fails to pay an invoice?

Travel time / expenses

If you need to travel out to the client for any reason, can you bill your travel time? Can you expense the mileage? And how do you handle other ad hoc expenses that come up during the course of the project?

Prerequisite needs

If there is something that you know you will need, in order to be successful on the project, make sure you include it in the contract. For example, if you expect to have VPN access to their network, or need a specific piece of hardware or software, then outline it specifically. This helps you avoid assumptions about your environment that may hinder your ability to complete a job on time and on budget.

Third-party software / licenses

If you know that you need to use any third-party software, you should outline who is going to pay for those tools, and who will own the licenses for them when the engagement is over. Even if you are not planning on using third-party software, it may help to have a clause in your contract that states that the client is responsible for paying for any third-party tools that are deemed necessary for the project. And then you will need to define how 'deemed necessary' is determined, because you do not want it to be ambiguous.

Communication

If you want to keep your sanity, be sure to define the process by which the client contacts you with questions, concerns or additional information about a project. If you do not want the client calling you during the day while you’re at your real job, then put it in the contract. To drive home the point, you can even put in a clause that allows you to charge them a premium if they do call you during a restricted time.

Maintenance

Almost every project you work on will have bugs, but you cannot provide indefinite support for an application. Make sure that you outline, in your contract, how you plan on handling maintenance with your client. This is a touchy subject, because clients quickly find issues with an application once it is deployed, and usually want those fixed as part of the original cost of the project. Normally, you will want to include the cost of a few maintenance hours in the original cost of the project, so you can stick around and fix problems for a little while after deployment. But you also want to protect yourself from a ceaseless stream of minor requests like changing the text of a label from this to that, moving a textbox from here to there, using a different shade of blue as a background, etc.

Liability

Cover your butt. I’ve heard of clients going after developers for a myriad of reasons, like lost employee productivity or even lost revenue due to glitches in software. There are a lot of things that can happen on a project and you need to have a broad-sweeping statement that attempts to cover the unforeseen. The more specific you can be about the things that can go wrong, the better off you are. For example, if you are building a billing system, then you should probably have a clause indemnifying you of the cost of any lost revenue due to billing errors, system down time, and so on.

Anything is better than nothing when it comes to contracts, so writing a contract yourself is a far better option than having nothing to go on at all. But you should be keenly aware of the fact that a professional contract lawyer is far more qualified than you are at writing contracts, so you should seek assistance from one, to help you write a solid contract. Writing contracts is a mysterious journey into the complex art of legal prose, most aptly scribed by a professional who actually understands the ramifications of what they are putting to ink. You may think your contract writing skills are akin to the works of Thoreau, but when you come up against a really good lawyer, you will quickly find they are more on par with Curious George gets his Ass Handed to Him In Court. Normally, you can ask a lawyer to write up a fairly generic contract that you can use for most of your engagements, so it’s well worth the investment.

Layers of Protection

A wise man also once told me that a contract is just an invitation to a fight. If you get to the point where you need to enforce something in your contract, then you need the help of the court system. And that course of action normally requires spending a lot of time, energy, and money on the legal process. So it’s also good to avoid a protracted legal battle by protecting yourself in other ways.

Full up-front payments

One way to make sure you get paid for your work is to get paid before you start working! However, negotiating a full up-front payment is a fairly difficult task, because it creates a risk reversal for the client. Instead of you taking on the risk of not getting paid for your work, the client takes on the risk of not getting the work for which they have paid. Some companies are willing to take that risk if you have a good reputation and they trust you. Some companies are so desperate for help that they will agree to anything. You should always check into a desperate client to see the source of their desperation. It may be that they need someone quickly and are willing to pay up-front to secure a qualified contractor. It may be that the project is a complete mess and they cannot get anyone in their right mind to touch it. Knowing their reasoning can help you determine if a project is really worth your time and effort.

One downside to accepting a full up-front payment is that some clients may feel cheated when you declare a project complete while there are lingering issues which the client feels you should resolve. But it’s far better, in this situation, to have the money in hand, because this is the point in time when some clients would refuse to pay you until you fixed those issues. It also illustrates the need for appropriate project scope definition, outlining what deliverables are covered in your fees and how to handle maintenance after finishing the project.

Partial up-front payments

A more common alternative to a full up-front payment is a partial up-front payment. This reduces the overall feeling of risk for a client, because they are not paying for everything up front. Most businesses understand the importance of an initial investment in a project, as a way of demonstrating a commitment, both to the project itself and to maintaining a healthy client-contractor relationship. When defining partial payments, you need to outline the specifics of how such payments are to be made. Normally, the client pays an up-front amount and then makes additional payments as you provide them with project deliverables. This creates a cycle in which you finish a part of the project and are paid for that part. It also sets up an easier environment for billing your client for additional work that arises in the middle of a project. If they want to add something to the project, or keep you on longer for maintenance purposes, then you can simply schedule additional payments for the additional work.

Maintenance and buckets of time

Most contractors accept a project, thinking that they are going to write some software, send it to the client, get a paycheck, and be done with it forever. But that is rarely the case. Business processes change over time and, when they do, your client may need to update your application to account for that change. And guess who they are going to call! Sometimes the requested changes are so significant that you can simply treat it as a completely new project. Often, however, you will get a client who has lots of little changes that come up sporadically. One tactic for dealing with this situation is to establish a maintenance time-bucket. In this situation, the client pays you for a certain number of maintenance hours (say 5 hours). They can call you and request any changes that they want and you can deduct the time you spend on the fix from the time-bucket. When it starts getting low, the client simply refills the time-bucket by paying you for another set of hours.

Another suggestion is to establish an initial maintenance time-bucket for your project, and explain the concept to your client. Tell them that you will be available for this many hours after the project, and that, if they want to retain you for minor fixes, they can refill that bucket as needed. It’s a seamless way to move from project completion into a maintenance billing cycle.

Binary-only deployments

You may not be able to protect yourself by negotiating an up-front payment on each project, but you can still protect your development efforts with other strategies. When you compile a project, your easily readable source code is reduced to an economically indecipherable jumble of machine language. So, one option for protecting your code is to give your clients only the compiled form of your work. Binary deployments allow the client to interact with your work and even deploy it into a production environment, but also allow you to retain a bargaining chip if the client fails to pay you for the work you have completed. Most applications have bugs and eventually need changes, so the source code is important for the client to ultimately acquire.

Licensing and trial periods

Although source code is important, some clients can still find ways to abuse a binary-only deployment scenario. I spoke with one contractor who deployed his solution, only to have the client turn around and demand that he add additional reporting functionality to the application before they would pay him. It put him in a bad situation because, if he walked away, the client could continue to use his application as it was, or until they found someone else to rebuild the system, using his work as an example. You may even encounter some clients who lose their sense of urgency and, once they have a working solution in place, drag their feet when it comes to paying you. So how do you protect your binary-only deployment? By programming your application to quit working after a certain trial period!

Adding trial-period support into your application can be as simple or complex as you choose. You could add a full-blown licensing system to your application that checks a license key to determine if your software has been paid for or should run in trial mode. You could throw if-then statements around important sections of code that disable the application after a certain date. If you choose the latter, which is the cheapest and least difficult route, I highly recommend centralizing your date-checking logic so you can easily disable the date checks. If you have scattered checks throughout your application, then you are bound to miss one of them and incur the wrath of an angry client when the application they paid for suddenly stops working.

You may also want to consider targeting specific pieces of functionality instead of the application as a whole. For example, if you build a web application that has a customer-facing front-end and a back-end system that the business uses to manage the website, consider disabling the back-end system before disabling the front-end. Disabling the back-end system does not affect the customer’s ability to make purchases, but it does affect the client’s ability to process those orders. When you re-enable the back-end system, the client can process the backlog of customer purchases without losing any sales during the downtime. It’s an effective means of getting the client’s attention, without making too much of a negative impact on the client’s bottom line.

Never use trial period protection as a last-ditch act of revenge against a client who fails to pay you for your services. You will damage your reputation, and you may leave yourself legally liable for losses the client may incur as a result of their application suddenly ceasing to function. Always outline the trial period in your contract to let the customer know, in advance, that a trial period exists and exactly when the trial period expires. You should also refrain from displaying inappropriate comments to the client when your trial period expires. It may seem like fun to write a nasty message about how they should have paid you, but simply informing the user that the application is unavailable is much more advisable. Remember, if you mess up and accidentally display the expired trial message, it’s much easier to explain away an 'Application Unavailable' message than an expletive-laced tirade.

Informing your clients of all protective measures

You should expressly outline any measures you plan to take to protect your work (such as binary deployments, trial periods etc) in the contract, and discuss them with your client at the beginning of a project. By outlining the specifics, you help protect yourself from legal liability in the event that the client feels your protective measures damaged their business in some way. If you suddenly inform the client of such measures at the end of the project, then you are much more likely to get yourself into trouble and upset your client.

After my incident in college, I made it a point to not release my source code until I received payment for my services, but I never really thought of communicating that point to my clients before the project began. I figured it was just a handy way to ensure I got paid. This came back to bite me one day, when a client requested the source code for his project so his developer could take over maintenance. I had yet to send him the invoice, so I told him I would send the invoice and that he would receive the source after I received the payment. I got paid very quickly, granted, but in doing so I unwittingly called his integrity into question, and lost a good client.

In conclusion

Remember, the most important thing you can do as a contractor is to establish an actual contract with your client. Effective communication is essential for a project to run smoothly. The process of hashing out a contract forces you to communicate openly with your client about topics most people seem too squeamish to bring up in normal conversation. Money and failure seem to be taboo subjects, but the finality of a contract makes it easy to discuss delicate financial matters and what happens if anyone fails to live up to their side of the bargain. Every client you encounter is going to be a bit different, so use your judgment in determining the best approach for payment options and source code protection.

Oh, and Tony, if I don’t get my check for this article on time, I’ve rigged all the text in this article to turn into a virtually indecipherable dialect of Sanskrit!

[TD: Sounds cool. I might have to withhold payment just to see it! :-)]

Damon Armstrong

Author profile:

Damon Armstrong is a Senior Engineering Team Lead with GimmalSoft in Dallas, Texas, and author of Pro ASP.NET 2.0 Website Programming. He specializes in Microsoft technologies with a focus on SharePoint and ASP.NET. When not staying up all night coding, he can be found playing disc golf, softball, working on something for Carrollton Young Life, or recovering from staying up all night coding.

Search for other articles by Damon Armstrong

Rate this article:   Avg rating: from a total of 70 votes.


Poor

OK

Good

Great

Must read
Have Your Say
Do you have an opinion on this article? Then add your comment below:
You must be logged in to post to this forum

Click here to log in.


Subject: Scope definition
Posted by: nigelrivett (view profile)
Posted on: Wednesday, September 27, 2006 at 4:32 AM
Message: Good points but one problem is that most clients (even large companies) don't really know what is involved in a project and the scope definition is often a lengthy process and should maybe be considered a paid project on it's own. I've often charged a couple of weeks at an agreed rate to define the scope. The good thing about that is they get an idea of how valuable you are and you can set the cost of the real contract at a more reasonable rate. Also while defining the scope you can get the client used to you working off site (at home) writing up plans and such.

Subject: scope creep
Posted by: Adam Machanic (view profile)
Posted on: Thursday, October 05, 2006 at 9:56 PM
Message: Recently I was given a fairly thorough set of specifications, and was asked by the client to specify the maximum amount of time the project would take. I thought it would take no more than 20 hours, so I told them 25. We wrote up a contract in which it was stated that I would deliver per the specifications in 25 or less hours.

I spent a couple of days toiling away, when I got a call. There were a few small changes--"nothing big". Well, I didn't fight said "small" changes (which ended up turning into much larger changes) and ended up completing the project in around 37 hours.

When the client came back with another project, I refused a ceiling and now have an open hourly rate with them. But I lost that 12 hours, and it taught me a good lesson -- you either need to get open-ended contracts, pad your estimates way, way out to compensate for creep, or be a real stickler for the agreed-upon specifications.

The problem is that padding makes you look slow upfront and being a stickler may anger the client and make you lose future work. So my strategy henceforth will be to always go for open-ended deals.

Subject: scope creep
Posted by: Anonymous (not signed in)
Posted on: Friday, October 06, 2006 at 8:45 AM
Message: Scope creep is a problem in all software projects. On small projects like the 25 hour one, Adam was right to eat the cost, consider it marketing cost. Notice that he now has an hourly arrangement with them. That wouldn't have happened had he fought them over their "little changes" when they became an almost 50% increase in scope on a piddly little 25 hour project.

The best thing to do, as Damon points out, is to clarify what happens up front with the client. Make sure that they understand your commitment to delivering a product with which they are happy and make sure that there is a clear understanding (well defined in the contract too) about what happens when they want to change things. This is sort of an art, since you don't want to impune your client's integrity or create a burdensome process that causes the client use someone else. I like to set a threshhold, beyond which there are costs for changes. On the 25 hour project, it would have been 8 hours. On larger projects it is usually around 10-15%.

Subject: Partial Payment
Posted by: Anonymous (not signed in)
Posted on: Friday, October 06, 2006 at 11:40 AM
Message: I have also learned this lesson the hard way. What I do now is to build the application on my web server and grant the client a secure access in to monitor my progress.

Once they agree that the project is two-thirds complete I ask for 50% of the payment. It's a relatively easy case to make. I'm sure some who read this may say, why not ask for 66% of the payment. I like to make it VERY easy for them to agree payment. At this stage they are still excited at what they are seeing.

Once the project is 100% working (still on my webserver) I ask for another 40% of the payment. I leave about 10% good-grace so that the client knows I haven't got all of my money, but if they decide to screw me in the meantime I have 90% of their money, plus I can say I wasn't fully paid.

Designing on your own webserver is the safest method IMO. An added clause I like to add at the beginning is that I own the rights to this application until payment is made in full.

Great article!

Subject: Scope Document
Posted by: Anonymous (not signed in)
Posted on: Friday, October 06, 2006 at 6:27 PM
Message: I've handled contract projects in many different ways. One time, I had a project where the person appeared super strict on the project hours/timeline so I wanted to learn as much of the scope as possible prior to delivering the estimate. Well.. during this time and several evenings at Starbucks, I hashed out their initial project design document and gave numerous suggestions in the design process for future growth, etc.. Anyways, after I offered the estimate, they wanted it for much less. I walked away from the deal and lost all that time in the design process and *free* design consulting to help me make a solid bid/estimate. Any thoughts on this? What were your experiences in the juggle between offering an estimate vs not understanding the full scope. Of course, the underlying principle rule before engaging a project is on-time/on-budget.

P.S. Great Article Damon!

Subject: RE: Scope Document
Posted by: Damon (view profile)
Posted on: Wednesday, October 11, 2006 at 9:46 PM
Message: Your scope document can be viewed in one of two ways: as an engagement or as a marketing expense. As Nigel Rivette pointed out, some scope definitions are lengthy enough that they should be considered an entire project in their own right. If the client sees value in your doing a paid assessment, then you are in luck.

If they are not up for it, then you may have to take on the risk of doing a lot of work for free and hoping that your endeavors pay off in the form of a signed deal later. But it can be a double edged sword, because once a project has been scoped out, some customers see how much they were underestimating it and decide to put it off.

You just need to figure out what your time is worth, take a SWAG (silly-wild-ass-guess) at how long it will take to write out a basic scope document, and make a judgement on whether you want to take that on yourself or try to pass all or some of the cost off to the client.

Subject: RE: Partial Payment
Posted by: Damon (view profile)
Posted on: Wednesday, October 11, 2006 at 9:51 PM
Message: Having your own demo environment is also a great way to avoid risk of not getting paid! If you plan on doing a lot of contracting work then it may be beneficial into looking at borrowing some space on a friend's server or getting something of your own. Great idea.

Subject: Compensation
Posted by: Anonymous (not signed in)
Posted on: Friday, October 27, 2006 at 10:22 AM
Message: First off, the article is well done and gets both sides thinking about the overall process. I would add one more avenue for payment & code turn over. That is an escrow service. This can be particularly useful when dealing with larger clients or longer duration projects. You place your versioned code into escrow at a specific point in time. Larger corporations can be notoriously slow payers. The independent escrow company helps defuse a non payment scenario and helps your credibility in the long run. If the soliciting organization is a non pay, you then work with your tax accountant (which you hopefully have if you are doing any number of engagements). They can determine the write-off potential of this loss (even if you get payment at a later date). Does it take the sting out of not getting paid, no but it is also a profit reduction point in your IRS filings. Don’t under estimate the benefit of your tax filings as it can take the sting out of a bad payment situation.

I fully endorse the above mentioned 50-40-10 payment under 'scope creep'. And don’t forget to iron out your rights to things developed. Don’t get caught out by intellectual property rights if you created a nice reusable widget. Carefully review any non-disclosure agreements you sign. Stating your non-exclusive rights to these widgets upfront in your contract solves headaches down the road.

Subject: Standard Fixed Price T&Cs
Posted by: Anonymous (not signed in)
Posted on: Tuesday, October 31, 2006 at 6:16 AM
Message: For a long term fixed price contract the standard payment structure (where I come from, in any case) is -
40% up front (you have to live, eat, pay rent/mortgage while this is going on)
40% on delivery to customer
20% on customer sign-off.

All rights remain with the developer until sign-off, so use in a production environment is unlicensed use of the product and actionable in court.
For the first 90 days after sign-off (and payment) all bugs fixed for free.
After the 90 days the customer gets the source code and further bug fixing is the subject of a new support contract.

Subject: You should have sued
Posted by: Anonymous (not signed in)
Posted on: Wednesday, December 06, 2006 at 11:47 AM
Message: You should have sued them for the bad check in small claims court and related damages. Would have almost certainly been a slam dunk.

Subject: Green as grass
Posted by: Anonymous (not signed in)
Posted on: Tuesday, March 13, 2007 at 3:28 AM
Message: Interesting article...
Doing work for someone living on the shady side of town is the 1st warning signal.
Delivering the code without any form of payment 1st - 2nd warning signal

Bounced cheque- you are a jerk!

Speaking from experience, the last person who didn't pay me had his office emptied by two "friends" of mine- slightly illegal yes, but I doubt he did it to anyone again. The courts are a waste of time & money, start by only doing business with people that have impeccable references. As for slow paying large corporates- just work on a time & materials basis, if they don't like that- go elsewhere or get your bank to factor your invoices (this will cost you but they will also tell you whether or not to do business with the company in question). The good news is that there are a lot of people willing to pay good money for a fair days work.

Subject: "should have sued"
Posted by: Anonymous (not signed in)
Posted on: Tuesday, March 13, 2007 at 4:37 AM
Message: And by the way...
Attempting to sue people who havn't got any money might make you feel like you are in charge- you're not. People with court judgements against them are just that, it does not automatically make them pay you.


Subject: "should have sued"
Posted by: Anonymous (not signed in)
Posted on: Tuesday, March 13, 2007 at 8:53 AM
Message: And by the way...
Attempting to sue people who havn't got any money might make you feel like you are in charge- you're not. People with court judgements against them are just that, it does not automatically make them pay you.


Subject: I want the contract
Posted by: Anonymous (not signed in)
Posted on: Sunday, March 18, 2007 at 12:30 AM
Message: I want the contract of any data entry works. Because I want to more money.

Subject: source code
Posted by: Anonymous (not signed in)
Posted on: Monday, April 02, 2007 at 8:24 AM
Message: I need the source code of any tour guide system developed by vb.net while i prefer the code of the tour guide system of newyork city

Subject: Professional Coding Compliance Reviewers known as PCCR owned By Chis Bazucha
Posted by: Anonymous (not signed in)
Posted on: Thursday, January 17, 2008 at 1:15 AM
Message: I am looking to see if he is in business again. He started his company in Fort Worth about 4 years ago. He was injured in acar accident and lost his clients, but 2 years ago he tried to restart his business and I am a personal griend of his and I lost toouch with him a little over 2 years ago and wanted to know if you might know him or anything about his business. Thank you for your consideration in this matter. My E-mail is going2hi4ever@yahoo.com. Once again thank you. Sincerely
Karen Roberts

Subject: nice read...until
Posted by: Anonymous (not signed in)
Posted on: Friday, April 25, 2008 at 2:21 AM
Message: Aww, man! I just loaded my boxers... Damn. Stupid milk allergy!!

Subject: nice read...until
Posted by: Anonymous (not signed in)
Posted on: Friday, April 25, 2008 at 2:22 AM
Message: Aww, man! I just loaded my boxers... Damn. Stupid milk allergy!!

Subject: nice read...until
Posted by: Anonymous (not signed in)
Posted on: Friday, April 25, 2008 at 2:22 AM
Message: Aww, man! I just loaded my boxers... Damn. Stupid milk allergy!!

Subject: nice read...until
Posted by: Anonymous (not signed in)
Posted on: Friday, April 25, 2008 at 2:22 AM
Message: Aww, man! I just loaded my boxers... Damn. Stupid milk allergy!!

Subject: nice read...until
Posted by: Anonymous (not signed in)
Posted on: Friday, April 25, 2008 at 2:22 AM
Message: Aww, man! I just loaded my boxers... Damn. Stupid milk allergy!!

Subject: GUESS
Posted by: Anonymous (not signed in)
Posted on: Tuesday, May 13, 2008 at 7:56 AM
Message: A project is always a guess(intelligent)..no contract can capture everything.......

 

Top Rated

We don't need Source Control: we're Database Developers
 As part of our long-running series of articles where we ask working database developers how database... Read more...

The Proposals Conundrum
 When you work for a small software development (or any services) company, one of the major challenges... Read more...

David Heinemeier Hansson: Geek of the Week
 Ruby on Rails, the open-source web application framework, grew out of David Heinemeier Hansson's work... Read more...

Alex Payne: Big in the IT Business
 Alex Payne worked on developing Twitter for three years. When he started, it was a small side-project:... Read more...

Seth Godin: Big in the IT Business
 Seth Godin has transformed our understanding of marketing in IT. He invented the concept of 'permission... Read more...

Most Viewed

The Future of Reflector
 Simple Talk asked freelance writer Bob Cramblitt to sit down with the two people behind the agreement... Read more...

Linus Torvalds, Geek of the Week
 Linus Torvalds is remarkable, not only for being the technical genius who wrote Linux, but for then... Read more...

Bad CaRMa
 From hope and euphoria, to desperation, firings and the ultimate demise of a company. Tim Gorman charts... Read more...

Driving up software quality - the role of the tester
 Have you ever wondered what a software tester does? Helen Joyce, test engineer at Red Gate software... Read more...

Don Knuth and the Art of Computer Programming: The Interview
 Fifty years after starting the 'Art of Computer Programming', (TAOCP), Don Knuth is still working hard ... Read more...

Why Join

Over 400,000 Microsoft professionals subscribe to the Simple-Talk technical journal. Join today, it's fast, simple, free and secure.