for those who do contracting work, what are the ideal time durations ?

as in, fixed contract durations?

I suspect most devs don't wnat contracts that are 1 hr in duration

or contracts that take 1 year

so there must be some optimal spot of "long enough to be worth doing; but not so long it becomes like a full time job"

dunno if the USA/UK world is different, but I've never taken a fixed-time contract (and I've done around 10)

if the pay is good and the used tech too, why not go for stability?

I may be mis-using the term "fixed time contract"

what I have in mind is: * here is the payment amount * here is the spec * if you deliver within 2 weeks, we pay == do you consider that 'fixed time contract?

thankfully I've never engaged in such a setting, although of course there are people who are willing

hourly rate + soft delivery schedule + 'agile'

all the work we have handed out on upwork / codementor is of the above format: * We need X done by time T. * We are willing to pay Y for working code Contracts seem fine with that. In your experience, what is wrong with the above?

you are either overpaying or you will run out of schedule

what does 'run out of schedule' mean ?

you burned agreed budget and product is not done yet

I'm fine with 'overpaying' in exchange for on-demand availability, in the same sense that 'aws lambda' prices is overpaying vs running colo

why would this cause 'burned agreed budget and product is not done yet' ? contractor does NOT get paid unless working code is delivered on time

then with this arrangement, someone loses

in almost all cases

(losing = overpaying or not being paid)

seems a tense arrangement

if you don't mind overpaying, you can also go for a non-fixed contract

we don't mind overpaying (in exchange for on-demand flexibility), but we want to pay per unit work, not per unit time

in the end you either trust a dev or not, and either he's good or not. I don't think there's a perfect Upwork-like setting that can kill the need for a video interview

(or other signals of trust)

anyway that's just my input, someone else may have the n you are looking for

I can +1 on everything that @vemv said. As a consultant I did many of these “fixed time fixed delivery” contracts, and always had to put in way more time than agreed, or get no money. This is very stressing, and stressing out people is NOT the way to get working programs.

So the way to go is hourly rate + soft delivery schedule + ‘agile’ + constant product management from the product owner (so that schedule, budget, scope and expectations can be adjusted as needed as often as possible)

And this is more convenient from the point of view of the owner as well

@nilrecurring: why didn't 'time estimates' adjust?

given that both client + consultant are free to work with others, it seems like this should converge to fair market price

Because you sign a contract for the original time estimate, and renegotiating that one ranges from “difficult” to “impossible” (IME)

If you’re using a flexible arrangement in the contract, you’re basically going for hourly rate

no, I meant why didn't estimates adjust across different projects

so my logic is: if I post a spec + price + deadline, and I get no responses, it's the market telling me "you're unreasonable", so I have to adjust (atleast one) of the three

on the other hand, if there is someone willing to deliver at the spec + price + deadline, all appears fine

thus, gradually, through projects that succeed + projects that I find no contractors for, it'll converge to market price

In 50 years of software engineering, we didn’t yet find a reliable way to do correct estimates

So it happens that you don’t know if an estimate is correct until you actually build the thing

And this is different for any given project

This is the reason why the assumption that market will adjust doesn’t hold

Market is adjusting, but against this kind of projects entirely

ive done a couple of fixed contracts back when i was younger and i would never do that again.