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
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
