On Wed, Apr 8, 2009 at 3:07 PM, Maurício
Hi, ... Are there ways already accepted by practice on how to write software contracts? It's a small program to acquire and show data from a device, a one person, two months work. I like the guy we are going to hire, and much to my surprise he sugested using Haskell for the task. But he also do not have experience writing such documents.
It depends on how clear and stable are the requirements for the application that must be developed. If they are very clear and you think they're not going to change during development, then you can go for a contract having the product itself as the subject: you'll describe the application, stating all the requirements and the acceptance tests for each of them. But be careful: requirements in the software field are very hard to state clearly and you might end up with yourself spending a lot of time and effort just to figure out which are to be included and how they're best described. On the contrary, if you have only a vague idea of what the software should do, then I advice you to hire the person for a certain amount of time. Hence, you're supposed to collaborate closely with this person to get the job done, mostly controlling the development. In order to incentivate the person to finish the job before the end of the contract, I'd put a big bonus if the software satisfies you. The downside is that you must spend a lot of time in the project and be competent in evaluating the person's skills for the project, otherwise you'll end up with paying a person who is basically useless to you. Maybe you can get help in evaluating the programmer from a friend or a collegue. Anything between these two forms of contracts is likely to fail. My 2 cents. Cristiano