Fork me on GitHub
#jobs-discuss
<
2018-01-10
>
qqq12:01:03

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

vemv12:01:39

as in, fixed contract durations?

qqq12:01:31

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

qqq12:01:35

or contracts that take 1 year

qqq12:01:56

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"

vemv12:01:57

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

vemv12:01:19

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

qqq12:01:47

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

qqq12:01:45

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?

vemv12:01:45

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

vemv12:01:11

hourly rate + soft delivery schedule + 'agile'

qqq12:01:23

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?

vemv12:01:14

you are either overpaying or you will run out of schedule

qqq12:01:36

what does 'run out of schedule' mean ?

vemv12:01:13

you burned agreed budget and product is not done yet

qqq12:01:26

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

qqq12:01:59

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

vemv12:01:38

then with this arrangement, someone loses

vemv12:01:52

in almost all cases

vemv12:01:01

(losing = overpaying or not being paid)

vemv12:01:26

seems a tense arrangement

vemv12:01:36

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

qqq12:01:02

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

vemv12:01:07

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

vemv12:01:25

(or other signals of trust)

vemv12:01:57

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

nilrecurring13:01:05

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.

nilrecurring13:01:25

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)

nilrecurring13:01:49

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

qqq13:01:03

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

qqq13:01:25

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

nilrecurring13:01:08

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

nilrecurring13:01:43

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

qqq13:01:32

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

qqq13:01:21

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

qqq13:01:52

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

qqq13:01:26

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

nilrecurring13:01:27

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

nilrecurring13:01:49

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

nilrecurring13:01:01

And this is different for any given project

nilrecurring13:01:28

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

nilrecurring13:01:51

Market is adjusting, but against this kind of projects entirely

jgh15:01:57

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