Proposal for a formal (commercial) co-operative with Ruby developers as members to implement/build paid projects for customers.
10 views
Skip to first unread message
Frank Oxener
May 27, 2010, 1:30:56 PM5/27/10
to Ruby on Rails meets the business world
So you're an independent Ruby developer with all the benefits you can
think of. With a lot of freedom. You work from home, you choose your
own assignments, no adjustment to a corporate culture, no managers to
deal with etc.
think of. With a lot of freedom. You work from home, you choose your
own assignments, no adjustment to a corporate culture, no managers to
deal with etc.
But what about the downsides? No feedback on your work (from which you
can learn), not a lot of interaction with other programmers, not easy
to consult a colleague on technical or other matters and sometimes
the
workload is too much or too little.
So that leads me to the question: is there a form of working together
without losing the valued benefits of an independent developer.
Somehow it must be possible to work together on a commercial basis as
individual developers more or less the same way we contribute to an
Open Source project.
Living in a community (on an island) where we have a lot of benefit of
existing co-operatives (for transport by ferry and the delivery of
energy), I of course thought of a formal co-operative as an
organization form for working as an collective.
Benefits:
* Acquisition as a collective.
* More flexible in workload. No more running or standing still. A more
even distribution of the workload.
* Higher occupation on average.
* Share knowledge and practical experience.
* Learn by working together on the same project.
* More change to do what you do best (specialties).
* More change to make some money as a part time ruby developer.
* The co-op will also offer the customer more continuity. A customer
will value the lower dependence on a single developer or a small
company.
Release early, release often:
With this proposal I like to research the possibility of working
together in a formal co-operative. Of course I don't have all the
answers (yet), but I'm hoping that we can together answer a lot of
them.
Let me know what you think. I made a first draft of a proposal on
Github with the following subjects:
* Definitions
* Objectives
* Rights
* Responsibilities
* Obligations
* Financials
* Board
* Workflow
* Examples
I like to invite you to join this discussion and make your
contribution by forking and submitting your patches!
See also:
* http://rubycoop.org
* http://github.com/dovadi/rubycoop
* http://groups.google.nl/group/ruby-co-op
* https://dovadi.lighthouseapp.com/projects/53142-ruby-co-op/overview
* http://rubycoop.talkerapp.com/r/4f39e9
* http://twitter.com/rubycoop_org
Mark Stephan
May 27, 2010, 1:36:28 PM5/27/10
to rails-b...@googlegroups.com
We've been peudo-coop with the Ruby Co-op for a couple of years now.
Calcedon is the company. http://calcedon.com
We haven't become a full-on Coop as the members never seemed to want the benefits a full coop gives to merit the costs and effort to form a legal cooperative.
Right now it's more of a collection of freelancers working together with the same benefits as listed below.
Would love to hear thoughts of others.
- Mark Stephan
--
You received this message because you are subscribed to the Google Groups "Ruby on Rails meets the business world" group.
To post to this group, send email to rails-b...@googlegroups.com.
To unsubscribe from this group, send email to rails-busines...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-business?hl=en.
----------
Mark E. Stephan
Managing Partner / Founder
Ruby On Rails Web Application Development Services
Austin, Texas
Austin Office: +01-512-961-6059
Email: mste...@calcedon.com
IM: markestephan (Skype)
IM: markes...@yahoo.com (MSN/YAHOO)
IM: markestephan (AIM)
IM: markes...@gmail.com (Gtalk)
IM: 63071782 (ICQ)
Twitter (Personal): http://twitter.com/mstephan
Chris Nelson
May 27, 2010, 1:47:16 PM5/27/10
to rails-b...@googlegroups.com
So this is us. Gaslight Software is a software development cooperative comprised of several independent ruby developers that have banded together for our common good in Cincinnati. We share office space, pair program, pair on sales, marketing and other aspects of running a business, and generally have an awesome time. None of us are actual employees of Gaslight, but we can present a unified face for billing and marketing purposes, and it gives our clients many benefits over working with a single independent contractor. We'd be happy to talk about this in more detail if anyone is interested. Gaslight has been around almost a year, and so far we feel like it's been a huge win over doing things by ourselves. Not that it's all easy or a simple, but having other awesome people in it with you is so much better.
--Chris Nelson
David Appelbaum
May 27, 2010, 2:11:52 PM5/27/10
to rails-b...@googlegroups.com
The problems with the collective, both in development shops and agencies, are these:
- Because everyone doing the work is a contractor, everyone is incentivized to do as little work as possible. You take the job, over-promise, go looking for the next paying gig, and then outsource your previous jobs when you are sick of dealing with the client you just angered but under-delivering.
-The people making the sale are incentivized to make the sale, regardless of whether it will end up as a profitable job or not. This is especially true when the people bringing in the accounts take 15-20% and then expect to be able to go sit on the beach.
- Your teams are inefficient. Good development teams are 10x more efficient then your ad hoc team because of their experience working together.
- You don't development reusable code or code that could be developed into its own project. Because there isn't a "company", no one is incentivized to experiment with coding. You focus on your projects, but not on the solving problems that would allow you to develop faster.
- You are perceived as liars. Clients came to you for your expertise, when they find out there is no company and its just a bunch of random coders pretending to be a company, they will be furious with you.
Conclusion: Production shops that are really just conglomerations of independent contractors that have no allegiance to the actual company are most likely stuck in a repetitive spiral of over promising, under delivering, and potentially all-out defrauding their customers. I'm sure this phenomenon exists everywhere, but it is especially prevalent in Los Angeles.
Many times these types of firms are KNOWINGLY defrauding their clients. If your strategy is LOW-BALL BAIT AND SWITCH, then CONGRATULATIONS, you are one of the retards that would rather screw people over in the short term instead of realizing long term success. You can be proud of yourself for being a con-artist, but please don't think you are actually running a successful company.
I will find you. I will expose you. I will educate your clients and tell them never to hire you. They probably will hire you anyway, but your portfolio will be filled with retards rather than real
Oh, did I mentioned you will get sued?
too all of the "collectives" out there that are really just a bunch of disorganized hacks that I wouldn't trust with a potato gun, consider yourself on notice.
/rant
-david appelbaum--
David Appelbaum
dappe...@gmail.com
213.453.8697
- Because everyone doing the work is a contractor, everyone is incentivized to do as little work as possible. You take the job, over-promise, go looking for the next paying gig, and then outsource your previous jobs when you are sick of dealing with the client you just angered but under-delivering.
-The people making the sale are incentivized to make the sale, regardless of whether it will end up as a profitable job or not. This is especially true when the people bringing in the accounts take 15-20% and then expect to be able to go sit on the beach.
- Your teams are inefficient. Good development teams are 10x more efficient then your ad hoc team because of their experience working together.
- You don't development reusable code or code that could be developed into its own project. Because there isn't a "company", no one is incentivized to experiment with coding. You focus on your projects, but not on the solving problems that would allow you to develop faster.
- You are perceived as liars. Clients came to you for your expertise, when they find out there is no company and its just a bunch of random coders pretending to be a company, they will be furious with you.
Conclusion: Production shops that are really just conglomerations of independent contractors that have no allegiance to the actual company are most likely stuck in a repetitive spiral of over promising, under delivering, and potentially all-out defrauding their customers. I'm sure this phenomenon exists everywhere, but it is especially prevalent in Los Angeles.
Many times these types of firms are KNOWINGLY defrauding their clients. If your strategy is LOW-BALL BAIT AND SWITCH, then CONGRATULATIONS, you are one of the retards that would rather screw people over in the short term instead of realizing long term success. You can be proud of yourself for being a con-artist, but please don't think you are actually running a successful company.
I will find you. I will expose you. I will educate your clients and tell them never to hire you. They probably will hire you anyway, but your portfolio will be filled with retards rather than real
Oh, did I mentioned you will get sued?
too all of the "collectives" out there that are really just a bunch of disorganized hacks that I wouldn't trust with a potato gun, consider yourself on notice.
/rant
-david appelbaum
David Appelbaum
dappe...@gmail.com
213.453.8697
Bradley Grzesiak
May 27, 2010, 3:46:39 PM5/27/10
to rails-b...@googlegroups.com
David:
You seem to be full of anger. Try to find out why.
And wasn't it a collective of hackers worldwide that put together Rails? Linux? PostgreSQL? Ghostscript? LaTeX? Thousands of projects on Github?
Cripes, I could go on. No, it's not the same thing as doing custom development. Just please... don't be a hater. Nobody likes a hater.
:brad, co-founder of a regular ol' non-collective rails consultancy
Mark Stephan
May 27, 2010, 7:56:24 PM5/27/10
to rails-b...@googlegroups.com
Wow, what a diatribe.
Well I can't speak for others. But I can speak for Calcedon. None of those items are true. Actually, I very clearly explain to our clients who and what we are, how teams are formed and how we work. I think it's a selling point actually. Our developers work together all the time. We have a VERY high bar for being part of the cooperative. You not only have to be a technical expert, but also a cultural fit. There are no ad hoc teams, but rather teams built around a project of people who want to work together because they have before and trust one another. If developers don't find a project interesting, we don't accept the project. Thus interested developers produce happier code.
Anyways, I suspect you had a bad experience with someone, and I'm sorry for that. But please don't project those feelings in vast generalizations. I can name a couple run of the mill shops that are typically structured companies that do all of what you said below. In the end, unethical people do unethical things. Ethical people, in whatever business model, will always be ethical.
David Appelbaum
May 27, 2010, 7:32:05 PM5/27/10
to rails-b...@googlegroups.com, rails-b...@googlegroups.com
Im not a hater, but I'm skeptical.
There ARE great developers out there, and some great companies. But for every solid company, I could name five that are totally incompetent. I only trust top tier talent. Period.
My skepticism has returned much vaue to me and my clients, I've saved clients tens of millions of dollars by preventing them spending money on fools that can't gaurentee results.
I just decided to speak out because as the outsourced/collective model takes over, quality and management are taking a major nose dive.
I make it my business to educate clients as to the TRUTH. I don't sell the dream I sell honesty. It works by the way.
I could make a whole living just from stealing clients from inept firms. I'll continue to do that, but I'd rather just see fewer companies taking advantage of people.
Look, we've all worked on failed projects- it sucks. All I'm saying is that it's better business to do a good job from the beginning, rather that low ball bait and switch and create angry clients.
David Appelbaum
May 27, 2010, 8:08:07 PM5/27/10
to rails-b...@googlegroups.com, rails-b...@googlegroups.com
Good for u if you aren't one of the retards.
I'm not generalizing and saying the applies to everyone. But you are fooling yourself if u think this type if shadiness doesn't happen.
You can be a part of the problem or a part of the solution- just know that if you are part of the problem, I'm coming at you full speed ahead.
<Calcedon logo sig.jpg>
Twitter (Corporate): http://twitter.com/calcedon
Ruby On Rails Web Application Development Services
Austin, TexasAustin Office: +01-512-961-6059Email: mste...@calcedon.comIM: markestephan (Skype)IM: markes...@yahoo.com (MSN/YAHOO)IM: markestephan (AIM)IM: markes...@gmail.com (Gtalk)IM: 63071782 (ICQ)Twitter (Personal): http://twitter.com/mstephan
Frank Oxener
May 28, 2010, 7:07:47 AM5/28/10
to Ruby on Rails meets the business world
It's great to know that there are already Ruby co-ops that exist!
Frank.
On 28 mei, 02:08, David Appelbaum <dappelb...@gmail.com> wrote:
> Good for u if you aren't one of the retards.
>
> I'm not generalizing and saying the applies to everyone. But you are
> fooling yourself if u think this type if shadiness doesn't happen.
>
> You can be a part of the problem or a part of the solution- just know
> that if you are part of the problem, I'm coming at you full speed ahead.
>
> >> *http://twitter.com/rubycoop_org
>
> > IM: markestephan (Skype)
> > IM: markestep...@yahoo.com (MSN/YAHOO)
> > IM: markestephan (AIM)
> > IM: markestep...@gmail.com (Gtalk)
>
> meer lezen »
Frank.
On 28 mei, 02:08, David Appelbaum <dappelb...@gmail.com> wrote:
> Good for u if you aren't one of the retards.
>
> I'm not generalizing and saying the applies to everyone. But you are
> fooling yourself if u think this type if shadiness doesn't happen.
>
> You can be a part of the problem or a part of the solution- just know
> that if you are part of the problem, I'm coming at you full speed ahead.
>
>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Ruby on Rails meets the business world" group.
> >> To post to this group, send email to rails-b...@googlegroups.com.
> >> To unsubscribe from this group, send email to rails-busines...@googlegroups.com
> >> .
> >> For more options, visit this group athttp://groups.google.com/group/rails-business?hl=en
> >> .
>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Ruby on Rails meets the business world" group.
> >> To post to this group, send email to rails-b...@googlegroups.com.
> >> To unsubscribe from this group, send email to rails-busines...@googlegroups.com
> >> .
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Ruby on Rails meets the business world" group.
> >> To post to this group, send email to rails-b...@googlegroups.com.
> >> To unsubscribe from this group, send email to rails-busines...@googlegroups.com
> >> .
> >> For more options, visit this group athttp://groups.google.com/group/rails-business?hl=en
> >> .
>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Ruby on Rails meets the business world" group.
> >> To post to this group, send email to rails-b...@googlegroups.com.
> >> To unsubscribe from this group, send email to rails-busines...@googlegroups.com
> >> .
> >> For more options, visit this group athttp://groups.google.com/group/rails-business?hl=en
> >> .
>
> >> --
> >> David Appelbaum
> >> dappelb...@gmail.com
> >> .
>
> >> --
> >> David Appelbaum
> >> 213.453.8697
>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Ruby on Rails meets the business world" group.
> >> To post to this group, send email to rails-b...@googlegroups.com.
> >> To unsubscribe from this group, send email to rails-busines...@googlegroups.com
> >> .
> >> For more options, visit this group athttp://groups.google.com/group/rails-business?hl=en
> >> .
>
> > ----------
> > Mark E. Stephan
>
> > Managing Partner / Founder
>
> > <Calcedon logo sig.jpg>
>
> > Ruby On Rails Web Application Development Services
> > Austin, Texas
>
> > Http://www.calcedon.com
>
> > Austin Office: +01-512-961-6059
>
> > Email: mstep...@calcedon.com
>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Ruby on Rails meets the business world" group.
> >> To post to this group, send email to rails-b...@googlegroups.com.
> >> To unsubscribe from this group, send email to rails-busines...@googlegroups.com
> >> .
> >> For more options, visit this group athttp://groups.google.com/group/rails-business?hl=en
> >> .
>
> > ----------
> > Mark E. Stephan
>
> > Managing Partner / Founder
>
> > <Calcedon logo sig.jpg>
>
> > Ruby On Rails Web Application Development Services
> > Austin, Texas
>
> > Http://www.calcedon.com
>
> > Austin Office: +01-512-961-6059
>
>
> > IM: markestephan (Skype)
> > IM: markestep...@yahoo.com (MSN/YAHOO)
> > IM: markestephan (AIM)
> > IM: markestep...@gmail.com (Gtalk)
> > IM: 63071782 (ICQ)
> > Twitter (Personal):http://twitter.com/mstephan
> > Twitter (Corporate):http://twitter.com/calcedon
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Ruby on Rails meets the business world" group.
> > To post to this group, send email to
>
> ...
> > Twitter (Personal):http://twitter.com/mstephan
> > Twitter (Corporate):http://twitter.com/calcedon
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Ruby on Rails meets the business world" group.
> > To post to this group, send email to
>
>
> meer lezen »
Chris Nelson
May 28, 2010, 9:17:19 AM5/28/10
to rails-b...@googlegroups.com
I have no idea what kind of personal problem you have, but maybe you should seek some professional help rather than spewing all over this list. This is completely unacceptable.
Thanks,
Chris Nelson
Gasight Software
Jeremy Weiland
May 28, 2010, 9:41:37 AM5/28/10
to Ruby on Rails meets the business world
I would be thrilled to hear about your business model in more detail.
How exactly does the marketing / sales / billing get shared? Do you
have any administrative or managerial types at work? Is there any sort
of equity or revenues to manage? Does every contractor in the coop
charge the same rate?
Thanks for any details you can provide.
- Jeremy
On May 27, 1:47 pm, Chris Nelson <ch...@gaslightsoftware.com> wrote:
> So this is us. Gaslight Software is a software development cooperative
> comprised of several independent ruby developers that have banded together
> for our common good in Cincinnati. We share office space, pair program,
> pair on sales, marketing and other aspects of running a business, and
> generally have an awesome time. None of us are actual employees of
> Gaslight, but we can present a unified face for billing and marketing
> purposes, and it gives our clients many benefits over working with a single
> independent contractor. We'd be happy to talk about this in more detail if
> anyone is interested. Gaslight has been around almost a year, and so far we
> feel like it's been a huge win over doing things by ourselves. Not that
> it's all easy or a simple, but having other awesome people in it with you is
> so much better.
>
> --Chris Nelson
>
> > .
How exactly does the marketing / sales / billing get shared? Do you
have any administrative or managerial types at work? Is there any sort
of equity or revenues to manage? Does every contractor in the coop
charge the same rate?
Thanks for any details you can provide.
- Jeremy
On May 27, 1:47 pm, Chris Nelson <ch...@gaslightsoftware.com> wrote:
> So this is us. Gaslight Software is a software development cooperative
> comprised of several independent ruby developers that have banded together
> for our common good in Cincinnati. We share office space, pair program,
> pair on sales, marketing and other aspects of running a business, and
> generally have an awesome time. None of us are actual employees of
> Gaslight, but we can present a unified face for billing and marketing
> purposes, and it gives our clients many benefits over working with a single
> independent contractor. We'd be happy to talk about this in more detail if
> anyone is interested. Gaslight has been around almost a year, and so far we
> feel like it's been a huge win over doing things by ourselves. Not that
> it's all easy or a simple, but having other awesome people in it with you is
> so much better.
>
> --Chris Nelson
>
> > *http://rubycoop.org
> > *http://github.com/dovadi/rubycoop
> > *http://groups.google.nl/group/ruby-co-op
> > *https://dovadi.lighthouseapp.com/projects/53142-ruby-co-op/overview
> > *http://rubycoop.talkerapp.com/r/4f39e9
> > *http://twitter.com/rubycoop_org
> > *http://github.com/dovadi/rubycoop
> > *http://groups.google.nl/group/ruby-co-op
> > *https://dovadi.lighthouseapp.com/projects/53142-ruby-co-op/overview
> > *http://rubycoop.talkerapp.com/r/4f39e9
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Ruby on Rails meets the business world" group.
> > To post to this group, send email to rails-b...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > rails-busines...@googlegroups.com<rails-business%2Bunsubscribe@go oglegroups.com>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Ruby on Rails meets the business world" group.
> > To post to this group, send email to rails-b...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
David Appelbaum
May 28, 2010, 12:43:25 PM5/28/10
to rails-b...@googlegroups.com
Hey Guys,
Sorry if my previous emails were a little too forceful for you, I am just being completely honest. The best way, in my opinion, to create a successful dev shop / collective / whatever you want to call it is to confront issues head on.
Collectives are a great way to sell deals when you don't have the capital to get your inhouse team together - I don't dispute that. I just think that from a clients perspective, the collective is often not the best option for quality, reliability, or general level of service.
I'm not here to insult anyone specifically. I don't think thats what I did in my previous emails. I just wanted to very clearly state that part of my approach, as a producer, is to to defend my clients from other development shops that might be trying to take advantage of them. These are the guys that constantly talk about 'selling the dream' and use terms like 'low-ball bait and switch'.
fwiw, the reason why I am even on this list is because I WANT there to be more great development companies. Its a very difficult business. I saw tons of companies go out of business during the bust. I am just trying to share my perspective.
Ok - I'll leave you guys alone for a little bit.
:)
Be well
Sorry if my previous emails were a little too forceful for you, I am just being completely honest. The best way, in my opinion, to create a successful dev shop / collective / whatever you want to call it is to confront issues head on.
Collectives are a great way to sell deals when you don't have the capital to get your inhouse team together - I don't dispute that. I just think that from a clients perspective, the collective is often not the best option for quality, reliability, or general level of service.
I'm not here to insult anyone specifically. I don't think thats what I did in my previous emails. I just wanted to very clearly state that part of my approach, as a producer, is to to defend my clients from other development shops that might be trying to take advantage of them. These are the guys that constantly talk about 'selling the dream' and use terms like 'low-ball bait and switch'.
fwiw, the reason why I am even on this list is because I WANT there to be more great development companies. Its a very difficult business. I saw tons of companies go out of business during the bust. I am just trying to share my perspective.
Ok - I'll leave you guys alone for a little bit.
:)
Be well
To unsubscribe from this group, send email to rails-busines...@googlegroups.com.
Mark Stephan
May 28, 2010, 12:46:36 PM5/28/10
to rails-b...@googlegroups.com
I don't even know what you mean by, 'low-ball bait and switch'
----------
Mark E. Stephan
Managing Partner / Founder
Ruby On Rails Web Application Development Services
Austin, Texas
Austin Office: +01-512-961-6059
IM: 63071782 (ICQ)
Twitter (Personal): http://twitter.com/mstephan
Philip Hallstrom
May 28, 2010, 1:02:10 PM5/28/10
to rails-b...@googlegroups.com
On May 28, 2010, at 9:46 AM, Mark Stephan wrote:
> I don't even know what you mean by, 'low-ball bait and switch'
You bid $10,000 for a project. I bid $5000. Client goes with me. I chew through the $5000 and tell the client, sorry, but the scope has changed or something and I need $7,000 more to finish. Client is angry, but what's he gonna do? Go back to you and pay $3000 *more*???
-philip
Mike Moore
May 28, 2010, 1:06:44 PM5/28/10
to rails-b...@googlegroups.com
Wait, you mean that has happened to someone besides me and the companies I've worked for?!? Almost like it was standard operating procedure for many consulting shops? Sort of like how gyms will continue to take your money not matter how many ways you try to close your account? My mind is blown! :)
Jason Cartwright
May 28, 2010, 1:06:41 PM5/28/10
to rails-b...@googlegroups.com
Another variation might be low-balling on hourly rates... charging $25/hr but then taking 4x as long to create the product, or producing poor results.
Sincerely,
Jason Cartwright
863.242.6531 (m)
www.YourSiteDoneRightNow.com/launch
www.facebook.com/jcartwright
www.twitter.com/iamenspired
"The true entrepreneur is a doer, not a dreamer" ~ Nolan Bushnell
Sincerely,
Jason Cartwright
863.242.6531 (m)
www.YourSiteDoneRightNow.com/launch
www.facebook.com/jcartwright
www.twitter.com/iamenspired
"The true entrepreneur is a doer, not a dreamer" ~ Nolan Bushnell
--
David Appelbaum
May 28, 2010, 1:14:43 PM5/28/10
to rails-b...@googlegroups.com
Philip pretty much nailed it. For those who want more explanation:
Low-Ball Bait and Switch:
This is a term for a sales scenario, it usually pertains to software development projects but it could apply to other projects in the interactive space.
The general premise is this.
Your client has a project and fixed budget. Lets say the project is building a marketplace for people to buy and sell widgets. They have 100 grand (Again, for arguments sake).
You don't know much about the widget space, but you know about apps and marketplaces. You tell the client that you'll look at the needs of their users, maybe even write some user stories or personas, and you tell them you will work iteratively.
You know you don't want to do all of the work to define the project upfront waterfall style - it would cost to much and the real price tag may be over 100 grand. In order to keep the client happy and not scare them with the idea that after they spend their 100 grand, they might not have everything they hoped for, you sell them on flexibility. The other firm, being honest, scoped the project at $175,000. They told the client this, and the client, trying to save money, went with the 100 grand option.
The problem comes in when you near the end of the clients budget, and you aren't where the client expects. You have to go ask for more money to finish. The client thought you would be done by now. You knew that you wouldn't be done, but you wanted the hundred grand, so you over promised and under delivered.
Now you go back to the client and ask for another 75,000.
Outcomes:
The client pays the 75,000 and is happy. This could happen if its not the client money, but its unlikely. Somebody spent that 100 grand and had an expectation of delivering a finished product. In somecases the money just comes out of some big ad budget, and no one minds. But this is rare. If you find a company that will keep paying you whether you are delivering or not, congratulations!
The client pays the 75,000, and is upset. You got paid, but say goodbye to using that client as a referenceable client.
The client doesn't have the 75,000, they give up. You ruined their company.
Mike Moore- i know, shocking, isn't it!? lol. I know everyone works this way, but I refuse to. I think we can do better. Its my personal goal to elevate my own business practices above this. By practicing full disclosure, I've prevented hundreds of entrepreneurs and small to medium sized businesses from blowing money or getting into development contracts that aren't in their best interest. The amount of goodwill I've generated because of that is more valuable than the money I would've made had I taken the contracts and underdelivered.
If someone comes to me with an idea and wants to build it, and they don't have the money, I don't take the job. Its an opportunity cost loss. Rather than wasting time underdelivering and losing a referencable client (and probably not even making that much money), its actually better for me to wait until i have a project that I can fully deliver on.
Your resident psycho,
david
Low-Ball Bait and Switch:
This is a term for a sales scenario, it usually pertains to software development projects but it could apply to other projects in the interactive space.
The general premise is this.
Your client has a project and fixed budget. Lets say the project is building a marketplace for people to buy and sell widgets. They have 100 grand (Again, for arguments sake).
You don't know much about the widget space, but you know about apps and marketplaces. You tell the client that you'll look at the needs of their users, maybe even write some user stories or personas, and you tell them you will work iteratively.
You know you don't want to do all of the work to define the project upfront waterfall style - it would cost to much and the real price tag may be over 100 grand. In order to keep the client happy and not scare them with the idea that after they spend their 100 grand, they might not have everything they hoped for, you sell them on flexibility. The other firm, being honest, scoped the project at $175,000. They told the client this, and the client, trying to save money, went with the 100 grand option.
The problem comes in when you near the end of the clients budget, and you aren't where the client expects. You have to go ask for more money to finish. The client thought you would be done by now. You knew that you wouldn't be done, but you wanted the hundred grand, so you over promised and under delivered.
Now you go back to the client and ask for another 75,000.
Outcomes:
The client pays the 75,000 and is happy. This could happen if its not the client money, but its unlikely. Somebody spent that 100 grand and had an expectation of delivering a finished product. In somecases the money just comes out of some big ad budget, and no one minds. But this is rare. If you find a company that will keep paying you whether you are delivering or not, congratulations!
The client pays the 75,000, and is upset. You got paid, but say goodbye to using that client as a referenceable client.
The client doesn't have the 75,000, they give up. You ruined their company.
Mike Moore- i know, shocking, isn't it!? lol. I know everyone works this way, but I refuse to. I think we can do better. Its my personal goal to elevate my own business practices above this. By practicing full disclosure, I've prevented hundreds of entrepreneurs and small to medium sized businesses from blowing money or getting into development contracts that aren't in their best interest. The amount of goodwill I've generated because of that is more valuable than the money I would've made had I taken the contracts and underdelivered.
If someone comes to me with an idea and wants to build it, and they don't have the money, I don't take the job. Its an opportunity cost loss. Rather than wasting time underdelivering and losing a referencable client (and probably not even making that much money), its actually better for me to wait until i have a project that I can fully deliver on.
Your resident psycho,
david
Mark Stephan
May 28, 2010, 1:26:28 PM5/28/10
to rails-b...@googlegroups.com, rails-b...@googlegroups.com
fm but for arguments sakes this has nothing to do with coops. It has to do with any software business. We quote projects as to what we believe it will take. We never fudge numbers, if anything we add a little more for Murpheys law. If it does meet the customers budget we tell them to change the budget or change the scope.
<Calcedon logo sig.jpg>
Ruby On Rails Web Application Development Services
Austin, TexasEmail: mste...@calcedon.comIM: markestephan (Skype)IM: markes...@yahoo.com (MSN/YAHOO)IM: markestephan (AIM)IM: markes...@gmail.com (Gtalk)IM: 63071782 (ICQ)Twitter (Personal): http://twitter.com/mstephan
--You received this message because you are subscribed to the Google Groups "Ruby on Rails meets the business world" group.
To post to this group, send email to rails-b...@googlegroups.com.
To unsubscribe from this group, send email to rails-busines...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-business?hl=en.
--
William Bridges
May 28, 2010, 1:27:57 PM5/28/10
to rails-b...@googlegroups.com
Obviously every project should be bid at 1 million dollars. (-: Just in case... cause you know... scope never changes.
--
--
Thanks,
Will Bridges
Will Bridges
<Calcedon logo sig.jpg>
David Appelbaum
May 28, 2010, 1:35:47 PM5/28/10
to rails-b...@googlegroups.com
I respectfully disagree that this has nothing to do with coops - i see the two issues as linked.
I think pricing/delivering gets harder in the coop model. Your team may not be committed to the company, they are each on their own contracts. This fundamentally changes how the project must be managed. You know have to define scope for your team in addition to the client, and if you don't set internal expectations correctly, your own team will low-ball bait and switch YOU as you are trying to low-ball bait and switch the client.
I think pricing/delivering gets harder in the coop model. Your team may not be committed to the company, they are each on their own contracts. This fundamentally changes how the project must be managed. You know have to define scope for your team in addition to the client, and if you don't set internal expectations correctly, your own team will low-ball bait and switch YOU as you are trying to low-ball bait and switch the client.
Robert Dempsey
May 28, 2010, 2:09:09 PM5/28/10
to Ruby on Rails meets the business world
This discussion appears to have gone a bit off topic from the original
proposal to form a co-op. However there is some interesting
discussion. Here's my $0.02 on some of it.
For the low-ball bait and switch issue - this can be done by any
company. If someone is unethically and purposefully low-balling
clients just to get work (and the only way we would know this 100% is
to have someone telling you honestly that they are, or we can read
their mind) then they suck and will hopefully be Darwined out of the
business world. I find these people don't tend to last too long. I
think there is a fairly equal chance of this happening at a company as
it would in a co-op situation. It's up to the morals of the people in
this instance.
As for estimates, they are just that - a best guess at the time and
cost of a project with the current knowledge and understanding we
have. This needs to be communicated to a client in the beginning of
the project. If not, incorrect expectations are being set. We're
working with software here - it's highly complex, the requirements are
never 100%, and we need to deal with change. Enter in Agile methods of
project management to help with this.
I can say that when I first got into project management, my estimates
of both time and cost were off. And from project to project, unless I
am dealing with the exact same variable, technologies, requirements,
etc. (in other words doing the exact same project again) I cannot
estimate with any high degree of certainty.
It sounds David that you had a very bad experience with a co-op of
folks, or someone acting in this way. It's sad that there are those
people out there. It's a fact we all deal with. Sometimes too it comes
down to communication between the team (of whatever description) and
the client. Clients need to be highly involved in the process from the
beginning and understand that that need is there - and they need to
commit their time to it. At the same time, the team needs to keep the
client informed, on an on-going basis - say every week or two - of the
current state of the project. All if it needs to be 100% visible to
both parties.
Also, if the people doing the work are shielded from the discussions
of scope (or simply requirements) then the project is doomed from the
get-go.
- Rob Dempsey
proposal to form a co-op. However there is some interesting
discussion. Here's my $0.02 on some of it.
For the low-ball bait and switch issue - this can be done by any
company. If someone is unethically and purposefully low-balling
clients just to get work (and the only way we would know this 100% is
to have someone telling you honestly that they are, or we can read
their mind) then they suck and will hopefully be Darwined out of the
business world. I find these people don't tend to last too long. I
think there is a fairly equal chance of this happening at a company as
it would in a co-op situation. It's up to the morals of the people in
this instance.
As for estimates, they are just that - a best guess at the time and
cost of a project with the current knowledge and understanding we
have. This needs to be communicated to a client in the beginning of
the project. If not, incorrect expectations are being set. We're
working with software here - it's highly complex, the requirements are
never 100%, and we need to deal with change. Enter in Agile methods of
project management to help with this.
I can say that when I first got into project management, my estimates
of both time and cost were off. And from project to project, unless I
am dealing with the exact same variable, technologies, requirements,
etc. (in other words doing the exact same project again) I cannot
estimate with any high degree of certainty.
It sounds David that you had a very bad experience with a co-op of
folks, or someone acting in this way. It's sad that there are those
people out there. It's a fact we all deal with. Sometimes too it comes
down to communication between the team (of whatever description) and
the client. Clients need to be highly involved in the process from the
beginning and understand that that need is there - and they need to
commit their time to it. At the same time, the team needs to keep the
client informed, on an on-going basis - say every week or two - of the
current state of the project. All if it needs to be 100% visible to
both parties.
Also, if the people doing the work are shielded from the discussions
of scope (or simply requirements) then the project is doomed from the
get-go.
- Rob Dempsey
David Appelbaum
May 28, 2010, 2:21:39 PM5/28/10
to rails-b...@googlegroups.com
Rob,
great post. completely agree.
yup, I've seen my share of bad experiences. My only reason for voicing my opinion on this board is to share what I've experienced and to prevent others from going thru the same thing.
david
great post. completely agree.
yup, I've seen my share of bad experiences. My only reason for voicing my opinion on this board is to share what I've experienced and to prevent others from going thru the same thing.
david
--
You received this message because you are subscribed to the Google Groups "Ruby on Rails meets the business world" group.
To post to this group, send email to rails-b...@googlegroups.com.
To unsubscribe from this group, send email to rails-busines...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-business?hl=en.
Rob Biedenharn
May 28, 2010, 3:03:30 PM5/28/10
to rails-b...@googlegroups.com
It seems like so much of the problem stems from a lack of feedback.
Begin forwarded message:
The problem comes in when you near the end of the clients budget, and you aren't where the client expects. You have to go ask for more money to finish. The client thought you would be done by now. You knew that you wouldn't be done, but you wanted the hundred grand, so you over promised and under delivered.
Now you go back to the client and ask for another 75,000.
If the developer(s) burn through $100,000 before the client has feedback, *THAT* is the first problem.
Here's how Gaslight Software would handle this: The initial contact would specify weekly or bi-weekly iterations at which time the client would be able to see what progress was made. The client would know the maximum that the first iteration would cost (either because the *first* iteration is quoted at a fixed price [bounded by time] or the hourly rate can be multiplied by 40 x developers [typically 1 or 2]). Furthermore, if we are encountering potential roadblocks or ambiguity in the requests being worked, we will contact the client for direction or clarification.
Begin forwarded message:
On May 28, 2010, at 9:46 AM, Mark Stephan wrote:I don't even know what you mean by, 'low-ball bait and switch'
You bid $10,000 for a project. I bid $5000. Client goes with me. I chew through the $5000 and tell the client, sorry, but the scope has changed or something and I need $7,000 more to finish. Client is angry, but what's he gonna do? Go back to you and pay $3000 *more*???
-philip
The scope can't change without involvement from the client. The understanding of the *effort* required to deliver on the known scope may grow to exceed what was originally estimated, but that's one of those times to check in with the client.
If the expectation is confined to "fixed bid" projects, then we're talking a very different kind of project.
If the $5,000 was an estimate, then that was presumably based on some known description of the features desired in the project. As soon as it was clear that $5,000 wasn't going to cover the scope, the client needs to be brought in and decide whether to reduce the scope to fit the budget or expand the budget to meet the scope.
-Rob
David Appelbaum
May 28, 2010, 4:31:18 PM5/28/10
to rails-b...@googlegroups.com
Interesting.
I still see it as a matter of setting correct expectations, but yes I agree frequent feedback is critical.
I still see it as a matter of setting correct expectations, but yes I agree frequent feedback is critical.
--You received this message because you are subscribed to the Google Groups "Ruby on Rails meets the business world" group.
To post to this group, send email to rails-b...@googlegroups.com.
To unsubscribe from this group, send email to rails-busines...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-business?hl=en.
David Appelbaum
May 28, 2010, 4:40:20 PM5/28/10
to rails-b...@googlegroups.com
So does everything still think I have deep seeded personal issues or can we agree that there is actually a discussion to be had here? :)
at least my rant got the conversation started, right?
at least my rant got the conversation started, right?
Julio Javier Cicchelli
May 28, 2010, 4:47:27 PM5/28/10
to rails-b...@googlegroups.com
Rants usually have conversations started, wherever they are good or bad ones. ;)
Rock On!
Javier.-
--
Software Engineer ~ Rock & Code
T. +31207790273
M. +31611519588
W. http://rock-n-code.com
G. http://github.com/mr-rock
T. http://twitter.com/monsieur_rock
L. http://www.linkedin.com/in/javiercicchelli
--
Software Engineer ~ Rock & Code
T. +31207790273
M. +31611519588
W. http://rock-n-code.com
G. http://github.com/mr-rock
T. http://twitter.com/monsieur_rock
L. http://www.linkedin.com/in/javiercicchelli
--
|
Mr.
Julio
Javier
Cicchelli
Technology and Engineering
Bloedstraat 17C
1012BS
Amsterdam
The Netherlands
Te/Fax
+31207790273
Mobile
+31611519588
|
Frank Oxener
May 30, 2010, 6:53:50 AM5/30/10
to Ruby on Rails meets the business world
After the dust settled down a little bit, I think it's time to respond
to the conversion from the past few days.
I mainly see this discussion as off topic, the problem with fixed
price projects has nothing to do with the legal or organization form
of a contractor/supplier.
But I feel there is one point touched that made me think. And that is
the duality of the client and the contractor.
For me the starting point of the Ruby co-op 'initiative' is the
question: why is the way of working in an Open Source project so
different from a commercial software development project? In
successful OS projects (like Rails) we see so much agility, quality
and innovation.
I do not pretend to have the answer, but my suggestion is that a co-
operative can bridge the gap, mainly because of the possibility of an
increased number of participants in a project. Of course this ideal
situation is only possible if there is enough "critical mass" in the
co-op and with a less stereotype role of a client (as we all
experience and know from fixed price projects).
The duality between the client and contractor arises because off the
difference/polarity between a client who wants to buy something (with
real money) from a supplier. The client who is buying wants to know
how much it will cost and when it will be delivered. But if the client
had its own team of developers, will there be a different
relationship? I think there is a subtle but important difference. Of
course there will be a management that wants to control the
expenditure. But if everyone is convinced of the benefits of agile
software development practices there will be more willingness to
manage more iteratively.
In an open source project there is not such a duality. The contract/
supplier is also the client. The leads me to the following question.
Can a co-op have two 'kind' of members: client and suppliers/
developers?
If I think of all the Rails projects I was involved in, I never
experienced a clear cut end (scope) of a project. As long as the
application is used, there are changes and maintenance needed. The
only projects I know of with a clear cut end are the ones who are
killed because the usage was not what was expected and a longer
investment was stopped or the client went bankrupt.
A client becomes a member of the co-op because it wants and needs a
long term relationship with the 'developer(s)". A client-member will,
like the developer-member , share in the (financial) profit of the co-
op.
What do you think? Will this be feasible?
Frank
On May 28, 10:31 pm, David Appelbaum <dappelb...@gmail.com> wrote:
> Interesting.
>
> I still see it as a matter of setting correct expectations, but yes I agree
> frequent feedback is critical.
>
>
> > *Date: *May 28, 2010 1:14:43 PM EDT
>
> > *Date: *May 28, 2010 1:02:10 PM EDT
>
> > *
> > *
> > .
> 213.453.8697
to the conversion from the past few days.
I mainly see this discussion as off topic, the problem with fixed
price projects has nothing to do with the legal or organization form
of a contractor/supplier.
But I feel there is one point touched that made me think. And that is
the duality of the client and the contractor.
For me the starting point of the Ruby co-op 'initiative' is the
question: why is the way of working in an Open Source project so
different from a commercial software development project? In
successful OS projects (like Rails) we see so much agility, quality
and innovation.
I do not pretend to have the answer, but my suggestion is that a co-
operative can bridge the gap, mainly because of the possibility of an
increased number of participants in a project. Of course this ideal
situation is only possible if there is enough "critical mass" in the
co-op and with a less stereotype role of a client (as we all
experience and know from fixed price projects).
The duality between the client and contractor arises because off the
difference/polarity between a client who wants to buy something (with
real money) from a supplier. The client who is buying wants to know
how much it will cost and when it will be delivered. But if the client
had its own team of developers, will there be a different
relationship? I think there is a subtle but important difference. Of
course there will be a management that wants to control the
expenditure. But if everyone is convinced of the benefits of agile
software development practices there will be more willingness to
manage more iteratively.
In an open source project there is not such a duality. The contract/
supplier is also the client. The leads me to the following question.
Can a co-op have two 'kind' of members: client and suppliers/
developers?
If I think of all the Rails projects I was involved in, I never
experienced a clear cut end (scope) of a project. As long as the
application is used, there are changes and maintenance needed. The
only projects I know of with a clear cut end are the ones who are
killed because the usage was not what was expected and a longer
investment was stopped or the client went bankrupt.
A client becomes a member of the co-op because it wants and needs a
long term relationship with the 'developer(s)". A client-member will,
like the developer-member , share in the (financial) profit of the co-
op.
What do you think? Will this be feasible?
Frank
On May 28, 10:31 pm, David Appelbaum <dappelb...@gmail.com> wrote:
> Interesting.
>
> I still see it as a matter of setting correct expectations, but yes I agree
> frequent feedback is critical.
>
> On Fri, May 28, 2010 at 3:03 PM, Rob Biedenharn <rob.biedenh...@gmail.com>wrote:
>
>
>
>
>
> > It seems like so much of the problem stems from a lack of feedback.
>
> > Begin forwarded message:
>
> > *From: *David Appelbaum <dappelb...@gmail.com>
>
>
>
>
>
> > It seems like so much of the problem stems from a lack of feedback.
>
> > Begin forwarded message:
>
>
> > *Date: *May 28, 2010 1:14:43 PM EDT
>
> > The problem comes in when you near the end of the clients budget, and you
> > aren't where the client expects. You have to go ask for more money to
> > finish. The client thought you would be done by now. You knew that you
> > wouldn't be done, but you wanted the hundred grand, so you over promised and
> > under delivered.
>
> > Now you go back to the client and ask for another 75,000.
>
> > If the developer(s) burn through $100,000 before the client has feedback,
> > *THAT* is the first problem.
>
> > Here's how Gaslight Software would handle this: The initial contact would
> > specify weekly or bi-weekly iterations at which time the client would be
> > able to see what progress was made. The client would know the maximum that
> > the first iteration would cost (either because the *first* iteration is
> > quoted at a fixed price [bounded by time] or the hourly rate can be
> > multiplied by 40 x developers [typically 1 or 2]). Furthermore, if we are
> > encountering potential roadblocks or ambiguity in the requests being worked,
> > we will contact the client for direction or clarification.
>
> > Begin forwarded message:
>
> > *From: *Philip Hallstrom <phi...@pjkh.com>
> > The problem comes in when you near the end of the clients budget, and you
> > aren't where the client expects. You have to go ask for more money to
> > finish. The client thought you would be done by now. You knew that you
> > wouldn't be done, but you wanted the hundred grand, so you over promised and
> > under delivered.
>
> > Now you go back to the client and ask for another 75,000.
>
> > If the developer(s) burn through $100,000 before the client has feedback,
> > *THAT* is the first problem.
>
> > Here's how Gaslight Software would handle this: The initial contact would
> > specify weekly or bi-weekly iterations at which time the client would be
> > able to see what progress was made. The client would know the maximum that
> > the first iteration would cost (either because the *first* iteration is
> > quoted at a fixed price [bounded by time] or the hourly rate can be
> > multiplied by 40 x developers [typically 1 or 2]). Furthermore, if we are
> > encountering potential roadblocks or ambiguity in the requests being worked,
> > we will contact the client for direction or clarification.
>
> > Begin forwarded message:
>
>
> > *Date: *May 28, 2010 1:02:10 PM EDT
>
> > *
> > *
>
> > On May 28, 2010, at 9:46 AM, Mark Stephan wrote:
>
> > I don't even know what you mean by, 'low-ball bait and switch'
>
> > You bid $10,000 for a project. I bid $5000. Client goes with me. I chew
> > through the $5000 and tell the client, sorry, but the scope has changed or
> > something and I need $7,000 more to finish. Client is angry, but what's he
> > gonna do? Go back to you and pay $3000 *more*???
>
> > -philip
>
> > The scope can't change without involvement from the client. The
> > understanding of the *effort* required to deliver on the known scope may
> > grow to exceed what was originally estimated, but that's one of those times
> > to check in with the client.
>
> > If the expectation is confined to "fixed bid" projects, then we're talking
> > a very different kind of project.
>
> > If the $5,000 was an estimate, then that was presumably based on some known
> > description of the features desired in the project. As soon as it was clear
> > that $5,000 wasn't going to cover the scope, the client needs to be brought
> > in and decide whether to reduce the scope to fit the budget or expand the
> > budget to meet the scope.
>
> > -Rob
>
> > Rob Biedenharnhttp://GaslightSoftware.com
> > On May 28, 2010, at 9:46 AM, Mark Stephan wrote:
>
> > I don't even know what you mean by, 'low-ball bait and switch'
>
> > You bid $10,000 for a project. I bid $5000. Client goes with me. I chew
> > through the $5000 and tell the client, sorry, but the scope has changed or
> > something and I need $7,000 more to finish. Client is angry, but what's he
> > gonna do? Go back to you and pay $3000 *more*???
>
> > -philip
>
> > The scope can't change without involvement from the client. The
> > understanding of the *effort* required to deliver on the known scope may
> > grow to exceed what was originally estimated, but that's one of those times
> > to check in with the client.
>
> > If the expectation is confined to "fixed bid" projects, then we're talking
> > a very different kind of project.
>
> > If the $5,000 was an estimate, then that was presumably based on some known
> > description of the features desired in the project. As soon as it was clear
> > that $5,000 wasn't going to cover the scope, the client needs to be brought
> > in and decide whether to reduce the scope to fit the budget or expand the
> > budget to meet the scope.
>
> > -Rob
>
> > r...@GaslightSoftware.com
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Ruby on Rails meets the business world" group.
> > To post to this group, send email to rails-b...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > rails-busines...@googlegroups.com<rails-business%2Bunsubscribe@go oglegroups.com>
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Ruby on Rails meets the business world" group.
> > To post to this group, send email to rails-b...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/rails-business?hl=en.
>
> --
> David Appelbaum
> dappelb...@gmail.com
> >http://groups.google.com/group/rails-business?hl=en.
>
> --
> David Appelbaum
> 213.453.8697
Robert Dempsey
May 31, 2010, 7:48:34 PM5/31/10
to Ruby on Rails meets the business world
A recent edition of Inc magazine had an interesting article on this
topic as well: http://www.inc.com/magazine/20100201/starting-a-new-business-cooperative.html
- Rob Dempsey
topic as well: http://www.inc.com/magazine/20100201/starting-a-new-business-cooperative.html
- Rob Dempsey
Reply all
Reply to author
Forward
0 new messages