Rails - Dec 2006 - How do you estimate the price of a RoR application

Hi all

how do you estimate the price of a RoR application.

Do you calculate the value:
  - counting the days or hours you worked in, and multiply that by a
rate?
  - estimate a price for the whole applicatiion using other criterias?


Pepe

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Well this is more of a matter of opinion than anything. It really also
depends on what purpose you''re trying to evaluate it for. If
it''s for a
single one time sell to another business you would calculate the worth of
the application based off the potential income it will bring to that buyer.
If you''re trying to determine the value of an application as far as
what it
would cost to duplicate it - you would base it off a formula of hours * avg.
industry pay rate * 50% (overhead). You might also base the price on the
current income it''s generating * 4 years.

-----Original Message-----
From: rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
[mailto:rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org] On Behalf Of
Jose Pepe
Sent: Friday, December 29, 2006 4:24 PM
To: rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Subject: [Rails] How do you estimate the price of a RoR application


Hi all

how do you estimate the price of a RoR application.

Do you calculate the value:
  - counting the days or hours you worked in, and multiply that by a
rate?
  - estimate a price for the whole applicatiion using other criterias?


Pepe

-- 
Posted via http://www.ruby-forum.com/.



-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.15.29/608 - Release Date: 12/29/2006
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.15.29/608 - Release Date: 12/29/2006
 



--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

The method for calculating the price of a ROR app isn''t any different 
than calculating it for any other web app. In my view, since developing 
time is shorter than other frameworks/languages, I can charge more per 
hour than say a PHP or .NET application. That''s if you choose to charge
based on estimated development time.

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Dec 29, 2006, at 3:23 PM, Jose Pepe wrote:
>
> Hi all
>
> how do you estimate the price of a RoR application.
>
> Do you calculate the value:
>  - counting the days or hours you worked in, and multiply that by a
> rate?
>  - estimate a price for the whole applicatiion using other criterias?
>
>
> Pepe
Hi Pepe,

The subject is so complicated, I don''t think a good answer is  
possible without referring you to other sources. (e.g., the book,  
"Eric Sink on the Business of Software" is a good one.)

With that said, I''ve been doing this for a few years.  Here''s
some
stuff to think about:

* What are your competitors charging?  Adjust your prices to how much  
better or worse you are than them.  For example, if you''re 50%  
better, charge 50% more.  It''s not perfect, but it''s a
reasonable
place to start.

*  Almost everyone equates price with quality.  Cheap = bad.   
Expensive = good.  If you undercut your competitors because you  
really need the money, your customer is going to second-guess  
everything you do and expect you to work weekends and nights.  If  
you''re expensive, they''ll let you work in peace and when you
make
suggestions, they''ll actually listen to you.

* Some corporations have rules that require them to take a discount  
if one is available.  You can use that to your advantage by offering  
a discount if they pay in advance.  Most of my bids are paid for in  
advance.  (I offer 15% off.)

* Per hour rates are scary for clients.  What''s to stop you from  
taking your time?  It''s like a blank check.

* A flat price is much easier to get accepted.  It''s  
straightforward.  But it''s dangerous for you.  You''re going to
have
to really protect yourself.  Specify exactly what is going to be done  
for that price.  Don''t be vague about anything.  Because in the  
middle of the project, when they ask for something not in the  
original agreement, you''re going to have to be firm from the start.    
Say something like, "That''s a great idea.  But I''m going
to have to
run some numbers and get back to you on what it''s going to cost." 
If
you give them anything free, they''ll ask for something else, then  
something else, then something else, then the next thing.  And  
there''s going to be hurt feelings when you finally put your foot  
down.  You can avoid all of that by being firm the first time they  
ask, then they''ll respect you as a professional.

Good luck!

- Michael Judge


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Micahel''s got a lot of great points.

We tend to do it one of two ways: Lump sum or in phases.

With lump sum, we feel that the requirements are complete enough to
give them a hard bid for the deliverable. We are picky about ANY change
to the scope as clients love to creep the scope. If the client doesn''t
know the scope enough, they usually know the basic core. So we say
we''re going to do the work in phases with very high level phases
(releases) mapped out. This also gets something released in the
client''s hands faster.

They can spend money to a point they''re happy with (a few thousand vs
$20k +) and have something to show for it that allows them to get more
funding. We find this to be a big problem in the non-profit world,
where a non-technical person budgets a tech project and the project
manager''s hands are tied for that fiscal year.

We have a good working relationship with a non-profit in town so that
they call us and ask us to help them scope a project. We''ve done about
8 different database driven sites for them in the past few years, one
of which was a massive content site that we bid poorly. Client got a
great deal. But we learned the hard way.

-John
www.boboroshi.com | www.meticulous.com


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Michael, John thank you very much for you advice.

One of the big limitations in our job  developing RoR or other IT 
applications- is that requirements are rarely complete. And it is hard 
to find customers that are able to specify them clearly. Also new Agile 
development techniques, explain that requirements do not need to be 
completed before starting a new project, and are part of the iterative 
process where requirements, analysis, design and coding loop until the 
project is completed, creating releases, milestones and versions.

Do you apply any Agile to estimate the cost of a project?

Do Agile methodologies help you estimate?

Pepe

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Jose Pepe wrote:
> 
> Do you apply any Agile to estimate the cost of a project?
I am not sure what you mean? what is Agile method has to do with 
pricing? Seems like you are trying to sell consulting services. Tell 
your customer X number of hours needed for Y and then charge the amount. 
I prefer to be honest with customers cos that customers keep coming back 
for more... Which is far more important then another extra 20%.. If you 
are trying to make a one shot delivery and don''t want to see your 
customer thats another story..
> 
> Do Agile methodologies help you estimate?
NO.. Agile is not a life saving method.. its a way of 
developing/delivering projects thats all.
> Pepe

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Where can I get any information about the average industry pay rate for 
developing RoR applications?

How do you know that when equating price with quality, that you are not 
on the Cheap = bad level?


thank you
Pepe

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

An example ..

http://www.payscale.com/research/US/Industry=Consultant/Hourly_Rate

Cheers

On 12/31/06, Jose Pepe
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
> Where can I get any information about the average industry pay rate for
> developing RoR applications?
>
> How do you know that when equating price with quality, that you are not
> on the Cheap = bad level?
No clue.. something you have to learn by doing ..
>
> thank you
> Pepe
>
> --
> Posted via http://www.ruby-forum.com/.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Dec 31, 2006, at 5:33 PM, Antonio Eggberg wrote:
>> Do you apply any Agile to estimate the cost of a project?
>
> I am not sure what you mean? what is Agile method has to do with  
> pricing? Seems like you are trying to sell consulting services.  
> Tell your customer X number of hours needed for Y and then charge  
> the amount. I prefer to be honest with customers cos that customers  
> keep coming back for more... Which is far more important then  
> another extra 20%.. If you are trying to make a one shot delivery  
> and don''t want to see your customer thats another story..
Problem with agile methodologies is they assume the project takes  
shape via short iterations, they are more adaptative. That''s the  
selling point. Nobody knows in advance enough about the project to be  
able to give a price based on features/effort. You have a more or  
less vague high-level vision of what they want, and perhaps a time  
constraint, and start working from there. Less docs, less formal stuff.

The answer to that is that since the client gets involved and sees  
the evolution of the project by first hand, (ideally) they will  
reasonably agree about the scope within the price as the project  
takes shape.

-- fxn


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Dec 31, 2006, at 8:39 AM, Jose Pepe wrote:
> Where can I get any information about the average industry pay rate  
> for developing RoR applications?
>
> How do you know that when equating price with quality, that you are  
> not on the Cheap = bad level?
There''s absolutely zero need to know the average industry pay rate.

The *only* important metric you need to know is how much you can get  
for a given job from a given customer.

This information is not easy to come by.

Basically no amount of research will help you determine it, other  
than getting in from of potential customers and finding out how much  
they''re willing to pay you, and how much you can convince them to pay!

This discussion comes up in development forums all the time, and I  
always see technical people giving technical answers. These answers  
are often detailed, logical, based upon (their) experiences, and are  
almost always *dead wrong*.

The question you''re asking is *not* a technical question. It''s
largely a question of (gasp!) sales and marketing.

Assuming you live and work in a free market economy, the *only*  
correct answer to the general question "How much should I charge for  
a job?" is the simple and painfully obvious "As much as you can."

My answer will likely get flamed, as it tends to make technical  
people very nervous because it makes obvious the *truth* that the  
question does not have a technical answer, only a social answer. :-)

If you try to apply a technical answer to this problem, there''s a  
very high likelihood that you''ll either charge too little, or not  
work enough, to make ends meet. You''ll be continuously befuddled how  
other companies that you know, who are far less technically adept  
than you are, continuously win the juiciest bids and live in the  
nicest neighborhoods. :-)

-- 
-- Tom Mornini, CTO
-- Engine Yard, Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Dec 31, 2006, at 8:20 AM, Jose Pepe wrote:
> Michael, John thank you very much for you advice.
>
> One of the big limitations in our job – developing RoR or other IT  
> applications- is that requirements are rarely complete. And it is  
> hard to find customers that are able to specify them clearly. Also  
> new Agile development techniques, explain that requirements do not  
> need to be completed before starting a new project, and are part of  
> the iterative process where requirements, analysis, design and  
> coding loop until the project is completed, creating releases,  
> milestones and versions.
>
> Do you apply any Agile to estimate the cost of a project?
>
> Do Agile methodologies help you estimate?
>
A fully Agile development shop would, almost by definition, charge by  
time and materials.

Truly agile development means there''s no way to estimate time and  
energy in advance.

-- 
-- Tom Mornini, CTO
-- Engine Yard, Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I agree with Tom in large measure. I don''t estimate Rails apps any
differently than C++ or whatever. I charge time & materials at a rate I can
live with (and I don''t refer to what anyone else is making). When a
client
wants to know what it''s likely to cost, I (at their expense) break out
stories (components of functionality) as well as startup, design, outside
dependencies, configuration, and deployment. I make some adjustments to
include having good tests. Then I apply the usual arithmetic and attach the
BIG CAVEAT that depending on the way the project goes, it could be less or
more but this is a dart at the wall.

Back to what everyone else is making. As a consultant, you may want to
consider this in determining your hourly rate, but I recommend against it.
Again, if you decide you are worth $x because you''re a good developer
and
have experience in lots of problem domains, then if someone balks at it,
that might be business you don''t want. How would that potential client
react
to you if you didn''t bring the project in on budget? Shopping for a
developer is not like shopping for detergent where the best price wins. Low
cost solutions can turn into high cost ones very quickly if the wrong people
are applied to the task.

Just my $.02



Zaheed Haque wrote:
> 
> 
> An example ..
> 
> http://www.payscale.com/research/US/Industry=Consultant/Hourly_Rate
> 
> Cheers
> 
> On 12/31/06, Jose Pepe
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:
>>
>> Where can I get any information about the average industry pay rate for
>> developing RoR applications?
>>
>> How do you know that when equating price with quality, that you are not
>> on the Cheap = bad level?
> 
> No clue.. something you have to learn by doing ..
>>
>> thank you
>> Pepe
>>
>> --
>> Posted via http://www.ruby-forum.com/.
>>
>> >
>>
> 
> > 
> 
> 
-- 
View this message in context:
http://www.nabble.com/-Rails--How-do-you-estimate-the-price-of-a-RoR-application-tf2896999.html#a8110106
Sent from the RubyOnRails Users mailing list archive at Nabble.com.


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi,

On Dec 31, 2006, at 8:20 AM, Jose Pepe wrote:
> Michael, John thank you very much for you advice.
>
> One of the big limitations in our job – developing RoR or other IT  
> applications- is that requirements are rarely complete. And it is  
> hard to find customers that are able to specify them clearly. Also  
> new Agile development techniques, explain that requirements do not  
> need to be completed before starting a new project, and are part of  
> the iterative process where requirements, analysis, design and  
> coding loop until the project is completed, creating releases,  
> milestones and versions.
(I don''t know anything about the Agile methodology.   But I  
understand what you''re saying.  Not every project you''re asked
to bid
on has clearly defined requirements [e.g.,  how much would it cost to  
make a web 2.0 community website for _____ who are interested in ____?])

These kinds of projects have always been disasters for me.

It makes sense now that I think about it.  I''m a developer.  I make  
people happy by selling solutions to problems.  When the customer  
can''t describe their problem, how am I supposed to solve it?  How  
will we both know if I succeed?  What if it''s not a real problem, but  
a hypothetical one, meant to be sold to hypothetical people, in a  
hypothetical market, and the customer doesn''t know anyone real who  
has experienced the problem, so we can''t even ask anyone about it?   
That''s madness.

Kind regards,

Michael Judge
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Dec 31, 2006, at 2:37 PM, Michael Judge wrote:
> On Dec 31, 2006, at 8:20 AM, Jose Pepe wrote:
>
>> Michael, John thank you very much for you advice.
>>
>> One of the big limitations in our job – developing RoR or other  
>> IT  applications- is that requirements are rarely complete. And it  
>> is  hard to find customers that are able to specify them clearly.  
>> Also  new Agile development techniques, explain that requirements  
>> do not  need to be completed before starting a new project, and  
>> are part of  the iterative process where requirements, analysis,  
>> design and  coding loop until the project is completed, creating  
>> releases,  milestones and versions.
>
> (I don''t know anything about the Agile methodology.   But I   
> understand what you''re saying.  Not every project you''re
asked to
> bid  on has clearly defined requirements [e.g.,  how much would it  
> cost to  make a web 2.0 community website for _____ who are  
> interested in ____?])
>
> These kinds of projects have always been disasters for me.
>
> It makes sense now that I think about it.  I''m a developer.  I  
> make  people happy by selling solutions to problems.  When the  
> customer  can''t describe their problem, how am I supposed to solve
> it?  How  will we both know if I succeed?  What if it''s not a real
> problem, but  a hypothetical one, meant to be sold to hypothetical  
> people, in a  hypothetical market, and the customer doesn''t know  
> anyone real who  has experienced the problem, so we can''t even ask
> anyone about it?   That''s madness.
This is what time and materials is all about.

I''ve recently come to realize that project based billing makes no  
sense! It guarantees, even under the best of circumstances and  
customer relationships, that you and your customer are at odds from  
day one, regardless of how well you perform.

You want to finish the job as soon as possible, which maximizes the  
value for you. The customer wants as many features and polish as  
possible, which maximizes the value for them.

And if the situation is less than ideal, there''re problems as well.

If you''re early, the customer will, in a sense, feel cheated. Even  
though they decided to pay X amount for Y project, if the hourly/ 
monthly/yearly income that generates for you seems too high to them,  
they''re going to feel gouged.

And, if the project goes over time, the customer is pissed because  
it''s late, and you''re pissed because your income is dropping
below
expectations.

The *only* way that project based jobs can be entirely successful is if:

1) You estimate the time time and value perfectly
2) That time and value match the customers'' expectations
3) Your value matches the customers expectations of your value.
4) You have a perfect plan at the beginning
5) The customer is satisfied when you execute the plan perfectly.  
This seems like it would be a truism, but rarely is! Very often, if  
you produce what the customer communicated, they *will* end up unhappy.

Now, as previously stated, you must realize that what''s right
isn''t
necessarily what works. :-)

The Rails community would do the web development a larger favor  
bringing in time and materials billing, based upon Agile development  
practices and the Getting Real business mechanics, and leave fixed  
bid billing far, far behind.

I do not expect this will happen, however.

-- 
-- Tom Mornini, CTO
-- Engine Yard, Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Thank you for all these excellent answers. They cover aspects that I
have not though about, before I read them.

I am currently working in a group that is trying to define standards for
IT people that are involved in software development. We already had
several meetings where we decided that the subject must be split in
three different parts
  Technical standards: such as coding conventions, database naming
conventions, web application templates, and other tools that can
simplify development tasks
  Software life cycle standards, that cover requirements, analysis,
design, coding, testing, delivery, and maintenance
  Project life cycle, where aspects of cost, time and quality (scope).

One of the major questions is about how to estimate the cost, duration
of a project, and also when several projects are in a waiting list, how
to define priorities to select one versus the other.

UML, UP and Agile methodologies can help implementing a project, but
stay in my opinion very confusing in the beginning of a Project to
initiate and plan the famous iron triangle: cost, time, quality.

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Jose Pepe wrote:
> UML, UP and Agile methodologies can help implementing a project, but stay 
> in my opinion very confusing in the beginning of a Project to initiate and 
> plan the famous iron triangle: cost, time, quality.
UML is not a methodology, and UP can be used as an Agile methodology.

They are confusing around the project estimation "phase" because they
don''t
lie (unlike some methodologies). Instead, they cast light on just how 
confusing this topic is. You cannot set a quarterly schedule for 1,000 
features, and then hit your ship date. You must estimate in terms of 
"horizons", where the near-term features are specified in detail, and
the
long-term ones are just general goals.

Sort features by business priority, do the highest value ones first, 
demonstrate them to your goal-donor early and often, and let them calculate 
your velocity and make the predictions. The best estimate is a measurement.

The iron triangle looks like this:

 - Time
 - Treasure
 - Talent
 - Technique
 - Target

You should only try to vary Target (scope). Your goal-donor''s job is to
intercept and censor as many requirements as they can. If you think you need 
a tree-view, they will order you to get by with a simple list box, for 
example.

To keep your velocity fast, over time, you must keep your Technique 
(quality) as high as possible. In Rails, that means adding tests, in every 
test rig, for every feature, no matter how trivial.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!! 


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Phlip,

very interesting. Thank you!!!

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Jose Pepe wrote:
> very interesting. Thank you!!!
Read one of the Lean Software Development books by the Poppendeicks.

-- 
  Phlip


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Michael Judge wrote:
> *  Almost everyone equates price with quality.  Cheap = bad.
> Expensive = good.  If you undercut your competitors because you
> really need the money, your customer is going to second-guess
> everything you do and expect you to work weekends and nights.  If
> you''re expensive, they''ll let you work in peace and when
you make
> suggestions, they''ll actually listen to you.
This piece of advice is gold, as it took me a long time to appreciate.

Several times in the past I submitted very low bids to projects I wanted 
to ensure winning. I learned the hard way that if you charge too little, 
your customers won''t respect you.

By charging too little, you are communicating that:

1) You are worth less. Your work''s quality is less than your 
competitors''. Which can naturally lead to the customer thinking he can 
and even must supervise you, with his own IT department or even himself. 
Also, think for a second: do you really want to work with someone who 
aims for low-quality product for (usually relatively insignificantly) 
lower cost? Most serious enterprises would pay a lot more for a quality 
product. Usually, paying the developer even the best salary would still 
be chump change compared to what they stand to earn off your work 
assuming it is good.

2) You are somehow weak, or in difficulties. Or both. Which, amazingly 
enough, leads him to be more neglectful of your meagre pay than what he 
would have been if you charged more. They do that either because these 
sums are so small, they can''t possibly be important to you. Or because 
they assume you make too little to be able to legally threaten them with 
lawsuits, especially over such relatively small sums. Or because they 
generally disrespect you. If you are in financial difficulties, and this 
project is the only thing that stands between you and the street. Which 
leads to the next point -

3) You will put up with abuse. They assume you are less important than a 
normal developer; therefore you are not a factor in their 
considerations. They won''t listen to you, on the contrary:
they''ll
happily hurl many arbitrary decisions at you, without consulting you. 
Specs would change more often, without proper notice. You will be put in 
inconvenient situations, and nobody would bother or care to make you 
feel better about anything. In particula:

4) Your time is less valuable. In fact, they''ll totally disregard the 
amount of your time anything takes: your time has become a free, 
unlimited resource. I usually throw in an extra 5%-10% uncharged time to 
good customers. They usually appreciate it a lot, and it''s very much 
worth it in the long run; the customer will feel good that you gifted 
him with 10-20 hours of your expensive (!) time for free, and next 
project would accept a higher bid from you since he enjoyed the 
experience. But if your time is very cheap, what''s to appreciate? 
Moreover, because of 1 and particularly 2, they''ll assume you
can''t cut
off. So you easily end up working 150%-200% or more of the time in the 
original bid, for the same bad pay. And the icing: they won''t
appreciate
it. At all. Hey, your time is virtually free, why would they apprecite 
you spending it?

-Chris

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Chris wrote:
> This piece of advice is gold, as it took me a long time to appreciate.
I don''t know if the following advice is good or bad, but here goes.

Each week, I review the project with my customer, then ask what to
work on the next week. Each thing he says I write on a card. Then I
write acceptance criteria for each item, and (alone without the
customer), I think of an "ideal hours" for each time.

Then I present to the customer a list of features, each with its
line-items and their ideal hour estimates. The customer censors any
line-items he doesn''t want.

Then I charge that many hours for that week.

This way, if I get stuck on a bug or an irritating piece of research,
I don''t need to worry about charging the customer for my stupidity. I
can take my time, receive interruptions, clean up the garage for no
apparent reason, hang out at the mall with my family, noodle around on
a notebook while watching TV, etc. I don''t need to log each danged
minute that I''m making "progress".

Without this "ideal hours" system, we expect such research to average
out over time, but I don''t want to wait for that average. I want the
customer to own the feature requirements and their priorities, and I
want him to censor any item that would slow down a delivery.

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> On 1/1/07, Phlip <phlip2005-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> The iron triangle looks like this:
>
> - Time
> - Treasure
> - Talent
> - Technique
> - Target
I thought triangles had 3 sides...that looks more like an iron pentagon to
me.

--------------------
seth at subimage interactive
-----
http://www.subimage.com
http://sublog.subimage.com
-----
http://www.getcashboard.com
http://dev.subimage.com/projects/substruct

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

subimage interactive wrote:
>  > - Time
>  > - Treasure
>  > - Talent
>  > - Technique
>  > - Target
>
> I thought triangles had 3 sides...that looks more like an iron pentagon to
> me.
What do I look like? A Pragmatic Programmers author?? Who invents
catchy backronyms all day???

It''s the Iron Triangle, and they all start with T. Triangle, T, get
it??!!

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Jan 4, 2007, at 7:37 AM, Phlip wrote:
> I don''t know if the following advice is good or bad, but here
goes.
>
> Each week, I review the project with my customer, then ask what to
> work on the next week. Each thing he says I write on a card. Then I
> write acceptance criteria for each item, and (alone without the
> customer), I think of an "ideal hours" for each time.
>
> Then I present to the customer a list of features, each with its
> line-items and their ideal hour estimates. The customer censors any
> line-items he doesn''t want.
>
> Then I charge that many hours for that week.
>
> This way, if I get stuck on a bug or an irritating piece of research,
> I don''t need to worry about charging the customer for my
stupidity. I
> can take my time, receive interruptions, clean up the garage for no
> apparent reason, hang out at the mall with my family, noodle around on
> a notebook while watching TV, etc. I don''t need to log each danged
> minute that I''m making "progress".
>
> Without this "ideal hours" system, we expect such research to
average
> out over time, but I don''t want to wait for that average. I want
the
> customer to own the feature requirements and their priorities, and I
> want him to censor any item that would slow down a delivery.
I think this is a bad policy.

A lot of developers think they shouldn''t charge for
"learning" or
"debugging" time.

Everyone needs to learn or we''d all be writing FORTRAN, and everyone
needs to debug, or TDD wouldn''t be important!

It''s like a painter not charging you for masking and cleanup.

It''s *part* of the job.

-- 
-- Tom Mornini, CTO
-- Engine Yard, Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

But if I''m paying for their learning process I want some evidence that
these guys are super-learners (and not the usual crop of lazy,
indifferent,  narrow-minded slobs that I know number out there in the
millions)


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

R K wrote:
> But if I''m paying for their learning process I want some evidence
that
> these guys are super-learners (and not the usual crop of lazy,
> indifferent,  narrow-minded slobs that I know number out there in the
> millions)
Hence I split the difference.

"Why is the chat feature 15 points?"

"Because I gotta research how to send a tiny message over unstable
Ajax pipes in 1/3rd second"

"Just do it within 10 seconds"

"Okay. Three points."

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I agree with Tom. Charge for your learning.  If your project needs to do
some AJAX, and you know that RJS will help out but you''ve not used RJS,
you
need to learn it. You''ll learn it by implementing it on their project,
therefore they should be charged accordingly.

If you''re good (read: able to learn quickly and adapt) then you
won''t burn
too much time learning.  If it makes you feel better, do your learning at a
lower rate. If you don''t think you''re able to learn on the
fly, then do
something to boost your skills or confidence.

When I hire a developer, I know they don''t know everything. I hope they
know
how to find out what they don''t know.


On 1/4/07, R K <johnsyntax-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> But if I''m paying for their learning process I want some evidence
that
> these guys are super-learners (and not the usual crop of lazy,
> indifferent,  narrow-minded slobs that I know number out there in the
> millions)
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Brian Hogan wrote:
> When I hire a developer, I know they don''t know everything. I hope
they know
> how to find out what they don''t know.
Find Out What You Don''t Know

You forgot to hope that they are willing to :-)

-r


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Phlip wrote:
> R K wrote:
>
> > But if I''m paying for [...] the usual crop of lazy,
> > indifferent,  narrow-minded slobs
>
> Hence I split the difference.
>
> "Why is the chat feature 15 points?"
>
> "Because I gotta research how to send a tiny message over unstable
> Ajax pipes in 1/3rd second"
>
> "Just do it within 10 seconds"
>
> "Okay. Three points."
Where did this conversation happen?  School for the gifted programmers?
Please re-read my description.  :-)

-r


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I thought I''d mention a cost, quality, time formula I like to keep in 
mind when creating proposals. It sometimes comes in handy when needing 
to explain to clients why rush projects cost more or how they could have 
a high quality result at a lower cost. Mostly I base hours needed on the 
actuals tracked from past experiences with similar project to create 
flat-rate quotes though.

The three variables being:
Cost - the project to be done for a low cost.
Quality - the project to be high quality (full of features or content 
say).
Time - the project needs to be finished quickly.

Help the client define the two most important criteria.
If the client picks cost and quality, then time to complete the project 
will be longer.
If the client picks cost and time, then the quality will not be as high 
(less features).
If the client picks quality and time then the cost goes up.
And so on...

For someone working within a company with fixed salaries the only 
options would be quality and time. The more man hours spent on projects 
the higher the quality of final result typically.

Depends on what the most or least important factors are.

DAN

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Dan Poynor wrote:
> Cost - the project to be done for a low cost.
> Quality - the project to be high quality (full of features or content 
> say).
That''s scope, not quality. Quality is how clean, simple, robust, and
DRY
your code is, and how deep your tests go.
> Time - the project needs to be finished quickly.
>
> Help the client define the two most important criteria.
> If the client picks cost and quality, then time to complete the project 
> will be longer.
That means the client has requested more scope. To get there, do the 
high-business value things first, deploy continuously, review often, and 
seek every opportunity to exclude scope.
> If the client picks cost and time, then the quality will not be as high 
> (less features).
And that is indistinguishable from your first iteration with the above 
formula. So if the client wants early deployment, they get a lite website 
with a few high-value features, but it''s useful early. (And thanks to 
ActiveRecord migrations, Capistrano, gems, and plugins, you don''t need
to
bury yourself in rendundant details.)
> If the client picks quality and time then the cost goes up.
How? How do you get more features in less time?

You can''t lower quality, because that will make you go slower, and will
ruin
the "pay as you go" and "just-in-time requirements"
formulas.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!! 


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Phlip wrote:
> Dan Poynor wrote:
> 
>> Cost - the project to be done for a low cost.
>> Quality - the project to be high quality (full of features or content 
>> say).
> 
> That''s scope, not quality. Quality is how clean, simple, robust,
and DRY
> your code is, and how deep your tests go.
Think of it as the amount of work needed. A project with a large scope 
(many features, pretty code, lot''s of user testing, etc...) requires 
more work and could be considered a higher quality product than a 
project with a smaller scope (fewer features, sloppy code, no use 
testgin, etc...). It''s the same difference.
> 
>> Time - the project needs to be finished quickly.
>>
>> Help the client define the two most important criteria.
>> If the client picks cost and quality, then time to complete the project
>> will be longer.
> 
> That means the client has requested more scope. To get there, do the
> high-business value things first, deploy continuously, review often, and
> seek every opportunity to exclude scope.
That''s has more to do with project management work flow than pricing. A
larger scope (for example adding more features) usually means the 
project will cost more and/ or take longer to complete. The order of 
tasks and deployment strategies are consistent enough in my environment 
from project to project so I can use the formula and not itemize those 
out as a separate issue or price each time.
> 
>> If the client picks cost and time, then the quality will not be as high
>> (less features).
> 
> And that is indistinguishable from your first iteration with the above
> formula. So if the client wants early deployment, they get a lite 
> website
> with a few high-value features, but it''s useful early. (And thanks
to
> ActiveRecord migrations, Capistrano, gems, and plugins, you don''t
need
> to
> bury yourself in rendundant details.)
An early deployment is still a deployment with a date on it and all 
features should be useful and have some value. In general keep in mind 
that scaling down the number of features for your project should mean 
less time is needed and lower the cost. You might price each deployment 
by the amount of work needed to develop the necessary features at each 
stage if it helps.

A low cost project created in little time usually has less features than 
otherwise. If your client spends more, they get more, bottom line.  If 
your project has a large scope (no matter what technology or methodology 
is used) it will costs more or takes longer to compelete.

The first iteration refered to cost and quality instead of cost and 
time. Say the client wants bug proof, acccessible, validated, pretty 
printing, highly commented code - that takes a little extra time to do 
compared to just hacking something together. The quality vs. time needed 
is a fundamental difference that should not be overlooked in pricing.
> 
>> If the client picks quality and time then the cost goes up.
> 
> How? How do you get more features in less time?
Hire more people is the typical way. If you have more people working on 
a project then they can each be working on different features at the 
same time (or in more groups of two if you prefer). More eye''s looking 
for bugs can catch more of them quicker for example.

Another way would be to buy a prebuilt solution that can be modified 
rather than building from scratch. It always takes longer and costs more 
to create a custom solution compared to buying something that''s close 
and extending it.

It ultimately depends on your situation, constraints, and creativity.
> 
> You can''t lower quality, because that will make you go slower, and
will
> ruin
> the "pay as you go" and "just-in-time requirements"
formulas.
> 
Higher quality does takes longer to achieve. Creating a lower quality 
product should not take longer. If you spend 100 hours on a project and 
it''s of lower quality, or has less features, than an project you spent
1
hour on, there''s something wrong. Lower quality should not be taking 
longer.

I''m not familiar enough with the pay-as-you-go and JIT requirements to 
understand how they effect the cost, quality, time formula.
> --
>   Phlip
>   http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

Hope that helps!

DAN

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

----- Original Message ----- 
From: "Dan Poynor"
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
> Think of it as the amount of work needed. A project with a large scope 
> (many features, pretty code, lot''s of user testing, etc...)
requires more
> work and could be considered a higher quality product than a project with 
> a smaller scope (fewer features, sloppy code, no use testgin, etc...). 
> It''s the same difference.
To make definitions useful, match them to roles in a project. The "onsite 
customer", or "project manager", or "goal donor" role
owns a project''s
scope. They decide what features to add, how detailed to make each feature, 
and what level to set their apparent quality.

The developers own the source code quality. It shall be as high as possible 
at all times. Where I''m coming from on this is experience with a young
Rails
project which had many of the signs of an old Classical project. Ambitious 
developers had thrown in a lot of features, and left the quality low in 
parts.

The difference between this and a Classical project, however, are those 
pesky unit tests. By increasing the testing, just a little, and by carefully 
matching the tests'' design to the codes'' design, we have
already turned this
code around. New features are now easier to add, because the internal 
quality is higher.

That''s why we need a name for scope, and a different name for "the
thing
inside the code that makes us faster".
> I''m not familiar enough with the pay-as-you-go and JIT
requirements to
> understand how they effect the cost, quality, time formula.
They are what I mean by frequent iterations with high business value in each 
one. You should develop as if the current iteration is expected to pay for 
the next one. You want your features to go online, to delight surfers, to 
cause more revenue, and pay for the next iteration. This is just a 
mind-game, but it forces you to think of scope in terms of business value.

And if you don''t specify your requirements until the iteration where
they
become features, then you can use the previous iterations to learn the exact 
details for these features. So your requirements are "just in time".
You
delayed an important decision until you have facts available to support it.

I have heard that''s how Toyota designs cars; I now realize there might
be a
lot in common between their techniques and ours!

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!! 


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Hey Phlip,

Keep in mind the cost, quality, time formula is general business 
practice to estimate price. It''s not RoR specific. Salt to taste.

Good points about using proper management techniques and talented 
contractors to help keep the client happy.

Cheers,
DAN

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---