My 2cents on this is. Make sure you use the most appropriate programming language for the task you want to achieve, and hire a programmer  who knows the language really well. Make sure they are productive. i.e. They can type at a fast rate. They know the editor  really well. i.e. They know all the obscure features of ViM, such as abbreviations,functions,keyboard mappings. They know how to create a Make file. As they will know the language really well, they will be able to quickly interpret compile time errors.  As they know the language well, they will be able to work with you creating a really good detailed design. e.g. Abstracting any required objects and their methods. as this is a Haskell list, functions structure. A program design always changes during the implementation as you go through the learning curve of needs. You, the programmer and the customer  will have a fairly continuous dialog  of questions.  Write all these down in such a way you can ensure the programs being written encompass them.  Things will go best if everyone has trust in each other and a commitment to producing  a top quality product.
--
Andrew in Edinburgh,Scotland

2009/4/11 Henning Thielemann <lemming@henning-thielemann.de>

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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe