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

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

On 11 Apr 2009, at 1:40 pm, Maurí cio wrote:

But I have an additional concern: to fit in burocracy. I need to write a contract that someone else, who understands just office applications, not software writing, will need to feel safe enough with to sign it. It's not that important to have a good contract, but actually to be able to say "someone else did it like this, and had no problems". Then I can save that contract and forget about it. I need something that won't hurt, more than something that will help development.

So "contract" here means "legal document", not "specification". The really important thing here is the level of trust between the two parties. If you have a high level of trust, something along the lines of "You will do something nice for me and I will pay you a fair price and we'll keep in touch while this happens" on the back of a paper napkin will do fine. If you have a low level of trust, you'll need a great level of detail, and it still won't help. I suspect you're somewhere in the middle. In that case, what you really need to do is to agree on a process that will _build_ trust, step by step. Maybe you can't explain to each other what the final product should be like. Can you agree on a _first_ step, to be done in a couple of weeks, where neither of you has much to lose? Sign a contract for that. Because it is by intent a small step, where nobody has much to lose if you just abandon the whole thing, you shouldn't need a heavyweight legal document. Showing that you understand the other side's need to manage risk will help to build trust. I don't want to go into details, but heavyweight up-front agreements can come unpleasantly close to killing a company.

There's one sentence I remember from some Extreme Programming books I read: "the customer only knows what he wants when he gets it" :-) On Tue, Apr 14, 2009 at 11:27 AM, Achim Schneider wrote:

"Richard O'Keefe" wrote:

...

If you have a low level of trust, you'll need a great level of detail, and it still won't help.

Heh. Keep your friends close, your enemies closer.

Freelancing, I was always paid per hour, not per feature. From my experience, writing something like "The contractor will work closely with an employee designated by Foo to ensure formal and informal, known or yet to be discovered, specifications are implemented" is the best thing you can do. If you have it, mention your QA and its guidelines. If you don't have it, get both. [1]

It's more than enough to boot a bad teamplayer out of his contract, doesn't induce frowns in top coders (SNAFU, as those are the ones you want to hire), does not risk mis-specifying requirements (which, with legal backing, is also SNAFU) and doesn't take longer and/or cost more to work out than the program itself (SNAFU, again). Be sure that not only bugs are fixed, but the reasons they appeared in the first place, too: That's the secret people writing space shuttle control software and similar use.

[1] Even if it's just one guy working out things like "Every function must be documented" and me getting a bug report saying "Help text does not mention how to display help text". -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe