On Wed, 8 Apr 2009, Maurício wrote:
Hi,
I'm an engineer, and as a programmer I'm just an amateur. This easied things to me, since I could take decisions about practices based on what made sense to me. But now I need to take responsability for some formal programming tasks, and I don't know which examples to follow.
I need, for instance, to write a contract with a programmer we are hiring for a task. But the only example I have of such contracts seemed to me (as I said, an amateur. I may be completely wrong) impractical. It was a 150 pages document with every possible user action and every imaginable allowed consequences. But it would be easier to me write the software than such contract itself.
I think such a contract won't help you, because after writing and using the software, you will always find things, that you now like to do different from what you wrote into the contract. I think the best to do is to divide the project into small pieces. If the programmer is not the right one, this should turn out after the first piece and you can try another one. I don't expect that you can turn an inappropriate programmer into a better one using a tight contract.