thoughts on a Ruby coop

[jarra]

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... ;-/

Jarra

[Frank Oxener]

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.

See also http://rubycoop.org/workflow.html where I wrote:

> 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:

[jarra]

Hi Frank,

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

[Frank Oxener]

Hi Jarra,

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:

> Hi Frank,
>
> 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.
>

[jarra]

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?

Best,
Jarra

[Frank Oxener]

Hi Jarra,

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: