I very much like the idea of a "Ruby cooperation". I had a fulltime Ruby on Rails job for 2.5 years. Currently I am freelancing and my main freelance job right now is as a process and issue manager for the implementation of an open source CMS, so right now I'm not doing a lot of Ruby and Rails (I miss it ;-)), but it's my platform of choice.
Although I think the hourly tariff is good, I'm not sure about the idea of working for an hourly tariff. Some programmers are quicker than others, and everyone has his/her own skills. So I'm playing with the idea of splitting a project in different user stories, and writing them down in Cucumber scenarios. Each scenario has an some story points, with a certain value (estimated hours * hourly rate). Programmers can pick the stories that suit them best and fit to their skills, and less experienced and slower programmers using more hours for a lower hourly rate and quicker experienced programmers taking less hours for a higher rate earn a similar amount for a given scenario. Does this make sense?
And what about skills. It would be good to have people with different skills. My prototype skills are pretty good, but I'm less skilled in CSS.
And what is a "qualified" Ruby programmer. I have 2.5 years of fulltime Ruby programming experience but I have no certifications or whatsoever. Are there any? Maybe it would be better to have proper coding standards (no more than 6 lines of code within a function), and use Cucumber and a unit testing suite (Rspec ;-))
Currently I am not fulltime available. I have a freelance job that takes 16 to 24 hours a week at this moment, but might end within a few months. Will it be possible to work less then 40 hours a week? Will it be possible to have an availabilty that varies?
I agree with using Github and Pivotal. But iChat doesn't work on Linux... ;-/
> Q: How much does the member get paid for its contribution? > A: Standard tariff per hour multiplied by the story-points
Of course that still leaves us with the challenge of reaching a consensus in estimating the amount of story-points for a scenario / user-story. Although this will be a decision of the members of the core-team of a particular assignment.
I have no idea for a definition of a so called qualified Ruby developer. And if we follow the payment per scenario it may be not that important, although we need to have (or strive for) coding standards. If I submit a patch to what kind of open source project, there is no-one determining if I'm qualified to submit my contribution. The main criteria is the quality of the code (at that moment for that patch). But the question is maybe about a membership of the co-op. Can 'anybody' be a member of the co-op and who decides? I think that if we have enough critical mass in the number of members with which the co-op starts, it will sort it self out ......
And one benefit of the co-op is that you can participate part-time. Someone's involvement can be on (only one) user-story basis.
Best,
Frank
On May 25, 11:02 pm, jarra <the.voyage.and.the.messen...@gmail.com> wrote:
> I very much like the idea of a "Ruby cooperation". I had a fulltime Ruby > on Rails job for 2.5 years. Currently I am freelancing and my main > freelance job right now is as a process and issue manager for the > implementation of an open source CMS, so right now I'm not doing a lot > of Ruby and Rails (I miss it ;-)), but it's my platform of choice.
> Although I think the hourly tariff is good, I'm not sure about the idea > of working for an hourly tariff. Some programmers are quicker than > others, and everyone has his/her own skills. > So I'm playing with the idea of splitting a project in different user > stories, and writing them down in Cucumber scenarios. Each scenario has > an some story points, with a certain value (estimated hours * hourly rate). > Programmers can pick the stories that suit them best and fit to their > skills, and less experienced and slower programmers using more hours for > a lower hourly rate and quicker experienced programmers taking less > hours for a higher rate earn a similar amount for a given scenario. Does > this make sense?
> And what about skills. It would be good to have people with different > skills. My prototype skills are pretty good, but I'm less skilled in CSS.
> And what is a "qualified" Ruby programmer. I have 2.5 years of fulltime > Ruby programming experience but I have no certifications or whatsoever. > Are there any? > Maybe it would be better to have proper coding standards (no more than 6 > lines of code within a function), and use Cucumber and a unit testing > suite (Rspec ;-))
> Currently I am not fulltime available. I have a freelance job that takes > 16 to 24 hours a week at this moment, but might end within a few months. > Will it be possible to work less then 40 hours a week? Will it be > possible to have an availabilty that varies?
> I agree with using Github and Pivotal. But iChat doesn't work on > Linux... ;-/
Thanks for you're reply. Reaching consensus about the amount of story points is indeed a challenge. I allways found it difficult to relate story points related to a number of hours. I see story points more as a rough estimate. But I think that once you take a tory, you agree with making that work within a given period, and for being paid the given hours. It's entrepeneurs risk if it takes you longer... ;-)
But it would be good as well to schedule availability for our members. So that we will be able to give an estimate to our customers.
I think that if we have certain coding stanards and ask for TDD we sort out the members already. But how wabout having members with different skills. How about the idea of having a member skilled in HTML and CSS for making templates for instance?
And are you obliged to share any Ruby jobs you aquire yourself with the co-op?
>> Q: How much does the member get paid for its contribution? >> A: Standard tariff per hour multiplied by the story-points
> Of course that still leaves us with the challenge of reaching a > consensus in estimating the amount of story-points for a scenario / > user-story. Although this will be a decision of the members of the > core-team of a particular assignment.
> I have no idea for a definition of a so called qualified Ruby > developer. And if we follow the payment per scenario it may be not > that important, although we need to have (or strive for) coding > standards. If I submit a patch to what kind of open source project, > there is no-one determining if I'm qualified to submit my > contribution. The main criteria is the quality of the code (at that > moment for that patch). But the question is maybe about a membership > of the co-op. Can 'anybody' be a member of the co-op and who decides? > I think that if we have enough critical mass in the number of members > with which the co-op starts, it will sort it self out ......
> And one benefit of the co-op is that you can participate part-time. > Someone's involvement can be on (only one) user-story basis.
> Best,
> Frank
> On May 25, 11:02 pm, jarra <the.voyage.and.the.messen...@gmail.com> > wrote:
>> Hi Frank and others,
>> I very much like the idea of a "Ruby cooperation". I had a fulltime Ruby >> on Rails job for 2.5 years. Currently I am freelancing and my main >> freelance job right now is as a process and issue manager for the >> implementation of an open source CMS, so right now I'm not doing a lot >> of Ruby and Rails (I miss it ;-)), but it's my platform of choice.
>> Although I think the hourly tariff is good, I'm not sure about the idea >> of working for an hourly tariff. Some programmers are quicker than >> others, and everyone has his/her own skills. >> So I'm playing with the idea of splitting a project in different user >> stories, and writing them down in Cucumber scenarios. Each scenario has >> an some story points, with a certain value (estimated hours * hourly rate). >> Programmers can pick the stories that suit them best and fit to their >> skills, and less experienced and slower programmers using more hours for >> a lower hourly rate and quicker experienced programmers taking less >> hours for a higher rate earn a similar amount for a given scenario. Does >> this make sense?
>> And what about skills. It would be good to have people with different >> skills. My prototype skills are pretty good, but I'm less skilled in CSS.
>> And what is a "qualified" Ruby programmer. I have 2.5 years of fulltime >> Ruby programming experience but I have no certifications or whatsoever. >> Are there any? >> Maybe it would be better to have proper coding standards (no more than 6 >> lines of code within a function), and use Cucumber and a unit testing >> suite (Rspec ;-))
>> Currently I am not fulltime available. I have a freelance job that takes >> 16 to 24 hours a week at this moment, but might end within a few months. >> Will it be possible to work less then 40 hours a week? Will it be >> possible to have an availabilty that varies?
>> I agree with using Github and Pivotal. But iChat doesn't work on >> Linux... ;-/
About reaching consensus on estimation I suggest a practical approach.
There should be at least three developers who make an estimation. A core member has the final decision if no consensus can be reached. The payment for the feature/user-story is hourly tariff x story-points x factor. The factor should represent the average hours for a story- point (and is a standard factor for all assignments in the co-op). Any member knows at that moment how much he/she gets paid for submitting the feature and it is his or her risk if there is an overshoot (or extra profit in case of an undershoot).
There should be insight in the availability of the members. Good point!
I would welcome front-end developers as members, but they can't submit their contribution the same way as a developer. At least not the basis of a user-story/feature. So it would make things more complicated.
No-one is obliged to share Ruby jobs. (I think it is not about 'jobs' but about assignments or projects.) Every member should have enough incentive to deliver leads to the co-op. If a lead becomes a real assignment, then I propose the member should receive 5 percent of the revenue generated by the assignment in the first year.
My hope is of course that the Ruby co-op will be such a way of working together that one wouldn't want to do his or her own assignments outside the co-op. Otherwise the co-op wouldn't reach enough 'critical mass' in work/assignments/revenue in proportion to its number of members.
Frank
On 26 mei, 07:56, jarra <the.voyage.and.the.messen...@gmail.com> wrote:
> Thanks for you're reply. Reaching consensus about the amount of story > points is indeed a challenge. I allways found it difficult to relate > story points related to a number of hours. I see story points more as a > rough estimate. > But I think that once you take a tory, you agree with making that work > within a given period, and for being paid the given hours. > It's entrepeneurs risk if it takes you longer... ;-)
> But it would be good as well to schedule availability for our members. > So that we will be able to give an estimate to our customers.
> I think that if we have certain coding stanards and ask for TDD we sort > out the members already. But how wabout having members with different > skills. How about the idea of having a member skilled in HTML and CSS > for making templates for instance?
> And are you obliged to share any Ruby jobs you aquire yourself with the > co-op?
> Well, have to hurry now... ;-) > Jarra
> On 05/25/10 23:26, Frank Oxener wrote:
> > Hi Jarra,
> > Thanks for your feedback!
> > I think I wasn't entirely clear on the tariff issue, but it was my > > thought exactly as you propose.
> >> Q: How much does the member get paid for its contribution? > >> A: Standard tariff per hour multiplied by the story-points
> > Of course that still leaves us with the challenge of reaching a > > consensus in estimating the amount of story-points for a scenario / > > user-story. Although this will be a decision of the members of the > > core-team of a particular assignment.
> > I have no idea for a definition of a so called qualified Ruby > > developer. And if we follow the payment per scenario it may be not > > that important, although we need to have (or strive for) coding > > standards. If I submit a patch to what kind of open source project, > > there is no-one determining if I'm qualified to submit my > > contribution. The main criteria is the quality of the code (at that > > moment for that patch). But the question is maybe about a membership > > of the co-op. Can 'anybody' be a member of the co-op and who decides? > > I think that if we have enough critical mass in the number of members > > with which the co-op starts, it will sort it self out ......
> > And one benefit of the co-op is that you can participate part-time. > > Someone's involvement can be on (only one) user-story basis.
> > Best,
> > Frank
> > On May 25, 11:02 pm, jarra <the.voyage.and.the.messen...@gmail.com> > > wrote:
> >> Hi Frank and others,
> >> I very much like the idea of a "Ruby cooperation". I had a fulltime Ruby > >> on Rails job for 2.5 years. Currently I am freelancing and my main > >> freelance job right now is as a process and issue manager for the > >> implementation of an open source CMS, so right now I'm not doing a lot > >> of Ruby and Rails (I miss it ;-)), but it's my platform of choice.
> >> Although I think the hourly tariff is good, I'm not sure about the idea > >> of working for an hourly tariff. Some programmers are quicker than > >> others, and everyone has his/her own skills. > >> So I'm playing with the idea of splitting a project in different user > >> stories, and writing them down in Cucumber scenarios. Each scenario has > >> an some story points, with a certain value (estimated hours * hourly rate). > >> Programmers can pick the stories that suit them best and fit to their > >> skills, and less experienced and slower programmers using more hours for > >> a lower hourly rate and quicker experienced programmers taking less > >> hours for a higher rate earn a similar amount for a given scenario. Does > >> this make sense?
> >> And what about skills. It would be good to have people with different > >> skills. My prototype skills are pretty good, but I'm less skilled in CSS.
> >> And what is a "qualified" Ruby programmer. I have 2.5 years of fulltime > >> Ruby programming experience but I have no certifications or whatsoever. > >> Are there any? > >> Maybe it would be better to have proper coding standards (no more than 6 > >> lines of code within a function), and use Cucumber and a unit testing > >> suite (Rspec ;-))
> >> Currently I am not fulltime available. I have a freelance job that takes > >> 16 to 24 hours a week at this moment, but might end within a few months. > >> Will it be possible to work less then 40 hours a week? Will it be > >> possible to have an availabilty that varies?
> >> I agree with using Github and Pivotal. But iChat doesn't work on > >> Linux... ;-/
> About reaching consensus on estimation I suggest a practical approach.
> There should be at least three developers who make an estimation. A > core member has the final decision if no consensus can be reached. The > payment for the feature/user-story is hourly tariff x story-points x > factor. The factor should represent the average hours for a story- > point (and is a standard factor for all assignments in the co-op). > Any member knows at that moment how much he/she gets paid for > submitting the feature and it is his or her risk if there is an > overshoot (or extra profit in case of an undershoot).
This seems reasonable to me as well.
> I would welcome front-end developers as members, but they can't submit > their contribution the same way as a developer. At least not the basis > of a user-story/feature. So it would make things more complicated.
We have to find a different way of doing that. User-stories are a bit useless here, and I think it wouldn't be a good idea to split the HTML part between more front-end developers. But the ability as a co-op to offer the templating part (and maybe even interaction design) might be valuable for potential clients. WDYT?
> No-one is obliged to share Ruby jobs. (I think it is not about 'jobs' > but about assignments or projects.) Every member should have enough > incentive to deliver leads to the co-op. If a lead becomes a real > assignment, then I propose the member should receive 5 percent of the > revenue generated by the assignment in the first year.
> My hope is of course that the Ruby co-op will be such a way of working > together that one wouldn't want to do his or her own assignments > outside the co-op. Otherwise the co-op wouldn't reach enough 'critical > mass' in work/assignments/revenue in proportion to its number of > members.
Sure, I think it's important to share assignments. But, members might have differnet reasons not to do so, eg: 1.) To have and keep the Dutch VAR-WUO you need to have to bill at least 3 different clients. I suppose the co-op bills the client and a member bills the co-op? That means you need to do at least 2 jobs out of the co-op. 2.) If you're short on jobs, it might be tempting not to share... 3.) Some jobs are simply not shareable, eg if you get hired in-house.
Maybe we can build something in related to availability, e.g. being available for at least X hours a year... Or being availble in weekly blocks? Not sure what will be good here myself... WDYT?
I agree, frontend developers would be an (great) asset to the co-op. But they can't be paid on user/story basis, so that should be hourly or fixed price ?
Your point about the Dutch VAR should be researched. I think this is maybe a case where we have an exception. If you are a partner in a so called 'maatschap' you personally will invoice to only one client (= 'maatschap'). I myself sent only invoices to one BV (mine). I think one argument that counts is: can you prove you're an entrepreneur. I think that will be the case with the co-op, but as I said we need to research it.
Short on jobs will be an issue. During the startup there must be enough trust in the co-op to try it. We need to give to the co-op in order to receive!
On a minimum or regular availability, I don't know yet what the way is to go. Does anyone else have suggestions on this topic?
Best, Frank
On 27 mei, 17:02, jarra <the.voyage.and.the.messen...@gmail.com> wrote:
> Hi Frank,> About reaching consensus on estimation I suggest a practical approach.
> > There should be at least three developers who make an estimation. A > > core member has the final decision if no consensus can be reached. The > > payment for the feature/user-story is hourly tariff x story-points x > > factor. The factor should represent the average hours for a story- > > point (and is a standard factor for all assignments in the co-op). > > Any member knows at that moment how much he/she gets paid for > > submitting the feature and it is his or her risk if there is an > > overshoot (or extra profit in case of an undershoot).
> This seems reasonable to me as well.> I would welcome front-end developers as members, but they can't submit > > their contribution the same way as a developer. At least not the basis > > of a user-story/feature. So it would make things more complicated.
> We have to find a different way of doing that. User-stories are a bit > useless here, and I think it wouldn't be a good idea to split the HTML > part between more front-end developers. > But the ability as a co-op to offer the templating part (and maybe even > interaction design) might be valuable for potential clients. WDYT?> No-one is obliged to share Ruby jobs. (I think it is not about 'jobs' > > but about assignments or projects.) Every member should have enough > > incentive to deliver leads to the co-op. If a lead becomes a real > > assignment, then I propose the member should receive 5 percent of the > > revenue generated by the assignment in the first year.
> > My hope is of course that the Ruby co-op will be such a way of working > > together that one wouldn't want to do his or her own assignments > > outside the co-op. Otherwise the co-op wouldn't reach enough 'critical > > mass' in work/assignments/revenue in proportion to its number of > > members.
> Sure, I think it's important to share assignments. But, members might > have differnet reasons not to do so, eg: > 1.) To have and keep the Dutch VAR-WUO you need to have to bill at least > 3 different clients. I suppose the co-op bills the client and a member > bills the co-op? That means you need to do at least 2 jobs out of the co-op. > 2.) If you're short on jobs, it might be tempting not to share... > 3.) Some jobs are simply not shareable, eg if you get hired in-house.
> Maybe we can build something in related to availability, e.g. being > available for at least X hours a year... Or being availble in weekly > blocks? > Not sure what will be good here myself... WDYT?
