Rails - Jun 2005 - [OT] how to estimate RoR projects that follow the agile way

hi, I''m a total newbie to RoR, Ruby and this list, I hope it''s
not
too off-topic to ask this here. I''ve also signed up to the prag prog  
mailing and am asking it there... but I thought it''d be good to ask  
this regarding specific RoR dev.

I''m reading Dave Thomas''s Rails book (loving it), and the way
he''s
proposing to design functionality while prototyping makes a lot of  
sense to me. I''ve essentially only scripted small php apps in a  
chaotic fashion so far, and haven''t done anything that could be  
called real software dev. I want to make the big move towards a sane  
methodology, and the agile way seems very appealing. and I want to  
use Rails, of course ;)

so I talked to the designer with whom I''m about to work on a small  
project, and she got all psyched to try both of them. but then she  
asked me, "how do we charge for this?", and I didn''t know
what to
answer.
without a more detailed spec, and given the functionality the client  
settles for in the end may vary greatly, and thus the time of  
development, I really have no idea how to charge for this. Anything  
charged hourly just scares the s*** out of clients... I thought of  
using a taxi meter analogy, whereby there''d be a starting base price  
for a basic funcionality, and then as the client asks for new  
funcionality, she''d pay for the extra time it takes. does this make  
sense? or would the client just be confused with the mix?

I''m very interested in hearing other people''s take on this,
and their
experience in using RoR and the agile method in their projects, how  
to budget, how they introduced the use of RoR for the first time, how  
their clients reacted... perhaps it''d be of interest to other newbies  
too.

- Oliver

oliver wrote:
> 
> so I talked to the designer with whom I''m about to work on a small
> project, and she got all psyched to try both of them. but then she  
> asked me, "how do we charge for this?", and I didn''t
know what to  answer.
I listened to a podcast recently that included some discussion of this.

http://www.itconversations.com/shows/detail355.html


James Britt

On 6/28/05, oliver <trabalho-5Rm33T4iiGWrKE0HZC4y0w@public.gmane.org>
wrote:
> hi, I''m a total newbie to RoR, Ruby and this list, I hope
it''s not
> too off-topic to ask this here. I''ve also signed up to the prag
prog
> mailing and am asking it there... but I thought it''d be good to
ask
> this regarding specific RoR dev.
> 
> I''m reading Dave Thomas''s Rails book (loving it), and the
way he''s
> proposing to design functionality while prototyping makes a lot of
> sense to me. I''ve essentially only scripted small php apps in a
> chaotic fashion so far, and haven''t done anything that could be
> called real software dev. I want to make the big move towards a sane
> methodology, and the agile way seems very appealing. and I want to
> use Rails, of course ;)
> 
> so I talked to the designer with whom I''m about to work on a small
> project, and she got all psyched to try both of them. but then she
> asked me, "how do we charge for this?", and I didn''t
know what to
> answer.
> without a more detailed spec, and given the functionality the client
> settles for in the end may vary greatly, and thus the time of
> development, I really have no idea how to charge for this. Anything
> charged hourly just scares the s*** out of clients... I thought of
> using a taxi meter analogy, whereby there''d be a starting base
price
> for a basic funcionality, and then as the client asks for new
> funcionality, she''d pay for the extra time it takes. does this
make
> sense? or would the client just be confused with the mix?
> 
> I''m very interested in hearing other people''s take on
this, and their
> experience in using RoR and the agile method in their projects, how
> to budget, how they introduced the use of RoR for the first time, how
> their clients reacted... perhaps it''d be of interest to other
newbies
> too.
> 
> - Oliver
Selling customers on a time and materials basis takes a lot of trust,
and you may find yourself having to agree at least at first to doing
it on a fixed-contract basis. In principal, with agile you define
stories with the customer (with as far as possible each story giving
the customer some visible business value). You give an estimate for
each story, the customer defines the importance, then together based
on priority and the length of each iteration (and an agile development
process without defined iterations is going to decend into
waterfall-style development quite quickly) you decide what you''ll do
and when - typically only one iteration in advance.

You may find it much easier to sell your customer on a pseudo-scrum
style approach than a full-on XP. As before, you define the stories
with the customer ("As a customer of company X I want to be able to
change my password so I can feel secure in using the site"), you
define the estimate, and the customer defines the priority. You then
plan out a (long com pared to XP) 4 week iteration, where you commit
to deliver that amount of work (and by deliver I''d suggest a a
deployable app - then the cusotmer feels confident that they''ll have
something runable early on). The iteration should be planned such that
all the highest priorities get done first - all the stories that won''t
fit in a four week window go into the backlog. If you get more done
than you though, take a story from the backlog and work on that.
Towards the end of the iteration you sit down with the customer and
decide what stories in the backlog need to be done next.

In this way the customer gets to see clear progress over a period of
time and learns to understand that each bit of functionality comes
with a cost to you.

Hope this helps,

-- 
sam
http://www.magpiebrain.com/

When setting up a quote I am always reminded of Hofstaders Law:

"It always takes longer than you expect, even if you take into 
considderation Hofstaders Law"

-not something clients would like to hear when time runs out and you are 
still struggling to make something work.

I rather quote way more time than I think is needed. This way if I 
"finish" before schedule the client gets all excited, otherwise when I
finish on project schedule time (longer than I expected) the client 
still sees me as punctual.


*:*Francois

Sam Newman wrote:
>On 6/28/05, oliver <trabalho-5Rm33T4iiGWrKE0HZC4y0w@public.gmane.org>
wrote:
>  
>
>>hi, I''m a total newbie to RoR, Ruby and this list, I hope
it''s not
>>too off-topic to ask this here. I''ve also signed up to the prag
prog
>>mailing and am asking it there... but I thought it''d be good to
ask
>>this regarding specific RoR dev.
>>
>>I''m reading Dave Thomas''s Rails book (loving it), and
the way he''s
>>proposing to design functionality while prototyping makes a lot of
>>sense to me. I''ve essentially only scripted small php apps in a
>>chaotic fashion so far, and haven''t done anything that could be
>>called real software dev. I want to make the big move towards a sane
>>methodology, and the agile way seems very appealing. and I want to
>>use Rails, of course ;)
>>
>>so I talked to the designer with whom I''m about to work on a
small
>>project, and she got all psyched to try both of them. but then she
>>asked me, "how do we charge for this?", and I didn''t
know what to
>>answer.
>>without a more detailed spec, and given the functionality the client
>>settles for in the end may vary greatly, and thus the time of
>>development, I really have no idea how to charge for this. Anything
>>charged hourly just scares the s*** out of clients... I thought of
>>using a taxi meter analogy, whereby there''d be a starting base
price
>>for a basic funcionality, and then as the client asks for new
>>funcionality, she''d pay for the extra time it takes. does this
make
>>sense? or would the client just be confused with the mix?
>>
>>I''m very interested in hearing other people''s take on
this, and their
>>experience in using RoR and the agile method in their projects, how
>>to budget, how they introduced the use of RoR for the first time, how
>>their clients reacted... perhaps it''d be of interest to other
newbies
>>too.
>>
>>- Oliver
>>    
>>
>
>Selling customers on a time and materials basis takes a lot of trust,
>and you may find yourself having to agree at least at first to doing
>it on a fixed-contract basis. In principal, with agile you define
>stories with the customer (with as far as possible each story giving
>the customer some visible business value). You give an estimate for
>each story, the customer defines the importance, then together based
>on priority and the length of each iteration (and an agile development
>process without defined iterations is going to decend into
>waterfall-style development quite quickly) you decide what you''ll
do
>and when - typically only one iteration in advance.
>
>You may find it much easier to sell your customer on a pseudo-scrum
>style approach than a full-on XP. As before, you define the stories
>with the customer ("As a customer of company X I want to be able to
>change my password so I can feel secure in using the site"), you
>define the estimate, and the customer defines the priority. You then
>plan out a (long com pared to XP) 4 week iteration, where you commit
>to deliver that amount of work (and by deliver I''d suggest a a
>deployable app - then the cusotmer feels confident that they''ll
have
>something runable early on). The iteration should be planned such that
>all the highest priorities get done first - all the stories that
won''t
>fit in a four week window go into the backlog. If you get more done
>than you though, take a story from the backlog and work on that.
>Towards the end of the iteration you sit down with the customer and
>decide what stories in the backlog need to be done next.
>
>In this way the customer gets to see clear progress over a period of
>time and learns to understand that each bit of functionality comes
>with a cost to you.
>
>Hope this helps,
>
>  
>

http://www.joelonsoftware.com/articles/fog0000000245.html

A good start.

On Jun 28, 2005, at 7:03 AM, Francois Paul wrote:
> When setting up a quote I am always reminded of Hofstaders Law:
>
> "It always takes longer than you expect, even if you take into 
> considderation Hofstaders Law"
>
> -not something clients would like to hear when time runs out and you 
> are still struggling to make something work.
>
> I rather quote way more time than I think is needed. This way if I 
> "finish" before schedule the client gets all excited, otherwise
when I
> finish on project schedule time (longer than I expected) the client 
> still sees me as punctual.
>
>
> *:*Francois
>
> Sam Newman wrote:
>
>> On 6/28/05, oliver
<trabalho-5Rm33T4iiGWrKE0HZC4y0w@public.gmane.org> wrote:
>>
>>> hi, I''m a total newbie to RoR, Ruby and this list, I hope
it''s not
>>> too off-topic to ask this here. I''ve also signed up to the
prag prog
>>> mailing and am asking it there... but I thought it''d be
good to ask
>>> this regarding specific RoR dev.
>>>
>>> I''m reading Dave Thomas''s Rails book (loving it),
and the way he''s
>>> proposing to design functionality while prototyping makes a lot of
>>> sense to me. I''ve essentially only scripted small php apps
in a
>>> chaotic fashion so far, and haven''t done anything that
could be
>>> called real software dev. I want to make the big move towards a
sane
>>> methodology, and the agile way seems very appealing. and I want to
>>> use Rails, of course ;)
>>>
>>> so I talked to the designer with whom I''m about to work on
a small
>>> project, and she got all psyched to try both of them. but then she
>>> asked me, "how do we charge for this?", and I
didn''t know what to
>>> answer.
>>> without a more detailed spec, and given the functionality the
client
>>> settles for in the end may vary greatly, and thus the time of
>>> development, I really have no idea how to charge for this. Anything
>>> charged hourly just scares the s*** out of clients... I thought of
>>> using a taxi meter analogy, whereby there''d be a starting
base price
>>> for a basic funcionality, and then as the client asks for new
>>> funcionality, she''d pay for the extra time it takes. does
this make
>>> sense? or would the client just be confused with the mix?
>>>
>>> I''m very interested in hearing other people''s
take on this, and their
>>> experience in using RoR and the agile method in their projects, how
>>> to budget, how they introduced the use of RoR for the first time,
how
>>> their clients reacted... perhaps it''d be of interest to
other newbies
>>> too.
>>>
>>> - Oliver
>>>
>>
>> Selling customers on a time and materials basis takes a lot of trust,
>> and you may find yourself having to agree at least at first to doing
>> it on a fixed-contract basis. In principal, with agile you define
>> stories with the customer (with as far as possible each story giving
>> the customer some visible business value). You give an estimate for
>> each story, the customer defines the importance, then together based
>> on priority and the length of each iteration (and an agile development
>> process without defined iterations is going to decend into
>> waterfall-style development quite quickly) you decide what
you''ll do
>> and when - typically only one iteration in advance.
>>
>> You may find it much easier to sell your customer on a pseudo-scrum
>> style approach than a full-on XP. As before, you define the stories
>> with the customer ("As a customer of company X I want to be able
to
>> change my password so I can feel secure in using the site"), you
>> define the estimate, and the customer defines the priority. You then
>> plan out a (long com pared to XP) 4 week iteration, where you commit
>> to deliver that amount of work (and by deliver I''d suggest a a
>> deployable app - then the cusotmer feels confident that
they''ll have
>> something runable early on). The iteration should be planned such that
>> all the highest priorities get done first - all the stories that
won''t
>> fit in a four week window go into the backlog. If you get more done
>> than you though, take a story from the backlog and work on that.
>> Towards the end of the iteration you sit down with the customer and
>> decide what stories in the backlog need to be done next.
>>
>> In this way the customer gets to see clear progress over a period of
>> time and learns to understand that each bit of functionality comes
>> with a cost to you.
>>
>> Hope this helps,
>>
>>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On 6/28/05, Ben Jackson
<ben-p14LI7ZcAE/pVLaUnt/cCQC/G2K4zDHf@public.gmane.org>
wrote:
> http://www.joelonsoftware.com/articles/fog0000000245.html
>From that article (dated mid 2000):
"As I write this, Netscape''s 5.0 web browser is almost two years
late.
Partially, this is because they made the suicidal mistake of throwing
out all their code and starting over: the same mistake that doomed
Ashton-Tate, Lotus, and Apple''s MacOS to the recycle-bins of software
history."

My, how times change. :p

Tyler

> On 6/28/05, Ben Jackson
<ben-p14LI7ZcAE/pVLaUnt/cCQC/G2K4zDHf@public.gmane.org> wrote:
>> http://www.joelonsoftware.com/articles/fog0000000245.html
>
>>From that article (dated mid 2000):
>
> "As I write this, Netscape''s 5.0 web browser is almost two
years late.
> Partially, this is because they made the suicidal mistake of throwing
> out all their code and starting over: the same mistake that doomed
> Ashton-Tate, Lotus, and Apple''s MacOS to the recycle-bins of
software
> history."
>
> My, how times change. :p
Ha! I thought the same thing considering it seems like Joel has
officially endorsed Firefox.

http://www.joelonsoftware.com/items/2004/06/15.html

"Oh, goody, FireFox 0.9 is here.... I have long since switched to
FireFox for web browsing..."

I''d love for Joel to go back through some of his trash talk and see
what he has to say about it now.  I have no doubt he''s still disparage
throwing code away and re-writing it; but obviously his comments about
Apple and Mozilla were/are wrong.  Of course, I''m allowing for the
switch from Netscape to Mozilla to Firefox.  Also, no matter how
much we like FireFox, it was _very_ long in coming...
-- 
doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org

indeed a great read, thanks! and thanks to the others for the  
insights and the podcast (which I''m still working through),
they''ve
been very helpful. I have a better sense of how to go about  
estimating and communicating with the client now.

... and I feel much better after hearing that major league  
programmers also take 3 times the original estimate to finish their  
job ;)
the 65% failure rate is very scary though.

On Jun 28, 2005, at 10:27 AM, Ben Jackson wrote:
> http://www.joelonsoftware.com/articles/fog0000000245.html
>
> A good start.
>
> On Jun 28, 2005, at 7:03 AM, Francois Paul wrote:
>
>
>> When setting up a quote I am always reminded of Hofstaders Law:
>>
>> "It always takes longer than you expect, even if you take into  
>> considderation Hofstaders Law"
>>
>> -not something clients would like to hear when time runs out and  
>> you are still struggling to make something work.
>>
>> I rather quote way more time than I think is needed. This way if I  
>> "finish" before schedule the client gets all excited,
otherwise
>> when I finish on project schedule time (longer than I expected)  
>> the client still sees me as punctual.
>>
>>
>> *:*Francois
>>
>> Sam Newman wrote:
>>
>>
>>> On 6/28/05, oliver
<trabalho-5Rm33T4iiGWrKE0HZC4y0w@public.gmane.org> wrote:
>>>
>>>
>>>> hi, I''m a total newbie to RoR, Ruby and this list, I
hope it''s not
>>>> too off-topic to ask this here. I''ve also signed up to
the prag
>>>> prog
>>>> mailing and am asking it there... but I thought it''d
be good to ask
>>>> this regarding specific RoR dev.
>>>>
>>>> I''m reading Dave Thomas''s Rails book (loving
it), and the way he''s
>>>> proposing to design functionality while prototyping makes a lot
of
>>>> sense to me. I''ve essentially only scripted small php
apps in a
>>>> chaotic fashion so far, and haven''t done anything that
could be
>>>> called real software dev. I want to make the big move towards a
>>>> sane
>>>> methodology, and the agile way seems very appealing. and I want
to
>>>> use Rails, of course ;)
>>>>
>>>> so I talked to the designer with whom I''m about to
work on a small
>>>> project, and she got all psyched to try both of them. but then
she
>>>> asked me, "how do we charge for this?", and I
didn''t know what to
>>>> answer.
>>>> without a more detailed spec, and given the functionality the  
>>>> client
>>>> settles for in the end may vary greatly, and thus the time of
>>>> development, I really have no idea how to charge for this.
Anything
>>>> charged hourly just scares the s*** out of clients... I thought
of
>>>> using a taxi meter analogy, whereby there''d be a
starting base
>>>> price
>>>> for a basic funcionality, and then as the client asks for new
>>>> funcionality, she''d pay for the extra time it takes.
does this make
>>>> sense? or would the client just be confused with the mix?
>>>>
>>>> I''m very interested in hearing other people''s
take on this, and
>>>> their
>>>> experience in using RoR and the agile method in their projects,
how
>>>> to budget, how they introduced the use of RoR for the first  
>>>> time, how
>>>> their clients reacted... perhaps it''d be of interest
to other
>>>> newbies
>>>> too.
>>>>
>>>> - Oliver
>>>>
>>>>
>>>
>>> Selling customers on a time and materials basis takes a lot of  
>>> trust,
>>> and you may find yourself having to agree at least at first to
doing
>>> it on a fixed-contract basis. In principal, with agile you define
>>> stories with the customer (with as far as possible each story
giving
>>> the customer some visible business value). You give an estimate for
>>> each story, the customer defines the importance, then together
based
>>> on priority and the length of each iteration (and an agile  
>>> development
>>> process without defined iterations is going to decend into
>>> waterfall-style development quite quickly) you decide what
you''ll do
>>> and when - typically only one iteration in advance.
>>>
>>> You may find it much easier to sell your customer on a pseudo-scrum
>>> style approach than a full-on XP. As before, you define the stories
>>> with the customer ("As a customer of company X I want to be
able to
>>> change my password so I can feel secure in using the site"),
you
>>> define the estimate, and the customer defines the priority. You
then
>>> plan out a (long com pared to XP) 4 week iteration, where you
commit
>>> to deliver that amount of work (and by deliver I''d suggest
a a
>>> deployable app - then the cusotmer feels confident that
they''ll have
>>> something runable early on). The iteration should be planned such  
>>> that
>>> all the highest priorities get done first - all the stories that  
>>> won''t
>>> fit in a four week window go into the backlog. If you get more done
>>> than you though, take a story from the backlog and work on that.
>>> Towards the end of the iteration you sit down with the customer and
>>> decide what stories in the backlog need to be done next.
>>>
>>> In this way the customer gets to see clear progress over a period
of
>>> time and learns to understand that each bit of functionality comes
>>> with a cost to you.
>>>
>>> Hope this helps,
>>>
>>>
>>>
>> _______________________________________________
>> Rails mailing list
>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On Tue, 28 Jun 2005, Francois Paul wrote:
> When setting up a quote I am always reminded of Hofstaders Law:
>
> "It always takes longer than you expect, even if you take into
> considderation Hofstaders Law"
The variant I use:

"Everything takes twice as long as you think, including thinking."

Multiplying my gut estimate by four is usually really close. Of course, I
have a lot of experience estimating....

-- 
_Deirdre  web / blog: http://deirdre.net/
yarn: http://fuzzyorange.com    cat''s blog: http://fuzzyorange.com/vsd/
"Memes are a hoax! Pass it on!"

I don''t personally know any programmers that consistently deliver 
reasonably accurate (meaning that the actual time ends up being no more 
than 100-150%) estimates.

http://del.icio.us/search/?search=estimating+scope has most of my good 
links on the subject.

The trick is to plan for not being able to fully plan. Mind like water, 
bro.

- Ben

On Jun 28, 2005, at 11:05 PM, oliver barnes wrote:
> indeed a great read, thanks! and thanks to the others for the insights 
> and the podcast (which I''m still working through),
they''ve been very
> helpful. I have a better sense of how to go about estimating and 
> communicating with the client now.
>
> ... and I feel much better after hearing that major league programmers 
> also take 3 times the original estimate to finish their job ;)
> the 65% failure rate is very scary though.
>
> On Jun 28, 2005, at 10:27 AM, Ben Jackson wrote:

I''ve heard vague stories about accurate estimates actually
happening....
Never been a witness myself, though. I don''t even want to _talk_ about
the projects I managed myself ;-)

 - Rowan

On 6/29/05, Ben Jackson
<ben-p14LI7ZcAE/pVLaUnt/cCQC/G2K4zDHf@public.gmane.org>
wrote:
> I don''t personally know any programmers that consistently deliver
> reasonably accurate (meaning that the actual time ends up being no more
> than 100-150%) estimates.
> 
> http://del.icio.us/search/?search=estimating+scope has most of my good
> links on the subject.
> 
> The trick is to plan for not being able to fully plan. Mind like water,
> bro.
> 
> - Ben
> 
> On Jun 28, 2005, at 11:05 PM, oliver barnes wrote:
> 
> > indeed a great read, thanks! and thanks to the others for the insights
> > and the podcast (which I''m still working through),
they''ve been very
> > helpful. I have a better sense of how to go about estimating and
> > communicating with the client now.
> >
> > ... and I feel much better after hearing that major league programmers
> > also take 3 times the original estimate to finish their job ;)
> > the 65% failure rate is very scary though.
> >
> > On Jun 28, 2005, at 10:27 AM, Ben Jackson wrote:
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 
Morality is usually taught by the immoral.

BigSmoke wrote:
> I''ve heard vague stories about accurate estimates actually
happening....
> Never been a witness myself, though. I don''t even want to _talk_
about
> the projects I managed myself ;-)
In normal projects, an "accurate estimate" is one that puts the target
in a position that allows the team to hit it.

To be scientific, you would have to keep the target secret from the 
team, before finding out whether it was achieved or not. I''m not 
recommending this - just pointing out that any association of
"accuracy"
with estimates is illusory. To talk about an "achievable" estimate
would
be better.

   Justin

Hi Oliver,

Well, here''s my (long winded) advice to you which is probably going to
be very controversial.  

First off, you need three things before you can even come close to
measuring just about anything:

1.  A sizing aspect that gives you some consistent metric of what you
want to analyze.
2.  A comparison aspect that takes your sizing and turns it into a
relative comparison with something else, usually time.
3.  A sampling method that dictates how you plan to sample or measure
what you want to observe.

Alright, so here''s what I do that works reasonably well:

1.  Develop enough of the application''s screens so that you know what
the customer is expecting to work with.  This can be done with paper
prototypes, mocked-up HTML, mocked-up ASCII art, or even just bang out
some ugly Rails.  I personally like mocked-up ASCII art as it prevents
the customer from complaining about how it looks, and it''s fast as
hell.
2.  Write down the things they keep talking about.  Customer, Purchase,
Credit Card, Transaction, Security Guard, etc.  Use their language.
3.  Once you''ve worked out the proposed screens with the customer and
things they expect to work with, you can start to count the following
abstract elements:
	a.  User Inputs -- Screens where they enter a bunch of stuff and get a
"done" or some small amount of response.
	b.  User Outputs -- Screens where they enter a little bit of stuff and
get lots of stuff back.  Google search is a User Output.
	c.  User Queries -- Screens where the user interacts heavily or the
ratio of input/output elements is about the same.
	d.  Database Tables/Internal Files -- Remember those "things" you
wrote
down? Count them up as the potential tables.  Be reasonable, but usually
you''ll have more than you expected.
	e.  External Interfaces -- Figure out what other systems your proposed
system will have to interface with.  SMTP? SOAP? A weird ass database?
4.  Go to
http://www.engin.umd.umich.edu/CIS/course.des/cis525/js/f00/harvey/FP_Calc.html
and enter these counts into the form.  Pick a suitable weighting factor for each
one.  I tend to use my lack of experience as a weighting factor where, if I have
lots of experience then it''s average, otherwise complex since I
don''t know it.  I reserve a "simple" rating only if I have
already written the component and plan to reuse it.
5.  Update the part at the bottom based on what you think you''ll need
in
the project.  I like to do a calculation at the bottom, expected, and
maximum levels as a sanity check.
6.  Click calculate and that''s the Function Points for your project.
Yeah, you''ve done an FP calculation.

Now comes the part you aren''t going to like:  FP is useless by itself.
Why use it then?  Because you can combine it with time and history to
develop a sense of how quickly you complete FP measured projects.  Also,
the questions on the bottom of that FP page are just really good
questions to ask when you start a project.  They''re the unexpected
things that always screw up projects.

Once you get your FP on a proposed project, you need to ask around and
see what other people have done on similar sized projects and how
quickly they did it.  Here''s how I do this:

1.  Do one small project after you know the FP and see how long it
takes.  You can also do a portion of the project (say a month) and
calculate the FP for that project.  It''s important to calculate this
before hand, otherwise you will cheat to make your estimates look
better/worse.  Consider FP as your scientific hypothesis, and your time
to complete as your experiment.
2.  Make sure that you don''t use 8 hours/day as your daily work
estimate.  Nobody I know works 8 hours straight coding in an 8 hour day.
I usually do 6 hours in a 8 hour day, less if I''m managing a team.
(Even less if I''m in meeting hell).
3.  Use this time measurement to figure out your FP/hour rate.  This
will be kind of fuzzy if you have a team, but if the team is consistent
then doing the average for the whole team is a good start.  You may get
really pissed off developers if you start trying to compare their
FP/hour rates (and also lots of really bad code cranked out quickly).
4.  Finally, spend some time to figure out what your defects are at the
end.  This is your FP/defect ratio and works to counter high FP/hour
rates producing bad code.

The end result of this is your first measurement of how long it takes
you to implement a certain chunk of FP, and the defects injected per FP.
As you do more of these measurements over time you''ll start to develop
better and more accurate FP/hour measurements, and know about how many
FP/defect to expect.  You can then use the FP/defect to add that much
time to your estimate for expected fixes.

Additionally, you can then work on improving these to measurements.  You
should read about statistical process control if you want to do this,
but if you can get the FP/hour and FP/defect up then that means you make
more money.  Also, when you go to your customers and show them your
historical implementation rates, you''ll be one step ahead of your
competition.  They''ll say, "We use XP so it''s done when
it''s done
biatch."  You''ll say, "Here''s a measurement of our
efficiency and defect
injection rates..."

To get you started here''s my rates on different types of projects:

Java,Tapestry,Hibernate -- 0.5 FP/hour
Python/Twisted -- 3 FP/hour
Ruby/Rails -- 4-5 FP/hour (this is still rough), a team does 2 FP/hour.
C++/POSIX/FLTK/FOX -- 1.5 FP/hour

I don''t have any FP/defect measurements yet since I recently decided to
start tracking that.

Also keep in mind that it''s kind of dangerous to use FP to compare team
or developer efficiency.  It could be use to spot teams/people who are
wildly better or worse, but even that''s controversial.  This is
frequently done in CMM and most CMM programmers hate it with a passion.

Anyway, hope that helps some.  Take the time to go out and read up on
things like Function Point Analysis, COCOMO and statistical process
control or operations research.

Zed A. Shaw
http://www.zedshaw.com/


On Mon, 2005-06-27 at 23:52 -0300, oliver wrote:
> hi, I''m a total newbie to RoR, Ruby and this list, I hope
it''s not
> too off-topic to ask this here. I''ve also signed up to the prag
prog
> mailing and am asking it there... but I thought it''d be good to
ask
> this regarding specific RoR dev.

Hi Zed.

Well you said it was going to be controversial, right? I know developers who 
will simply throw their hands up in the air and say "it''s
impossible to give
time estimates".

I think your approach is better - a statistical analysis. Which will get better 
over time.

For yet another method that has worked fantastically well for me in the past 
read "Painless Software Schedules" (it''s just a couple of
pages :) )

http://www.joelonsoftware.com/articles/fog0000000245.html

This is a very simple approach, but subtle. It can be summed up as
- A spreadsheed
- A developer
- Hard thinking.

Drawing up GUI screens and taking down domain objects is definitely a good way 
to start. Then you define very fine grained task descriptions... anyway
it''s all
in the articleI have tried it, and it worked very well for me. And since no one 
is going to bother to go there, here''s an excerpt :)

 >>> (From Painless Software Schedules)
5) Pick very fine grained tasks. This is the most important part to making your 
schedule work. Your tasks should be measured in hours, not days. (When I see a 
schedule measured in days, or even weeks, I know it''s not real). You
might think
that a schedule with fine grained tasks is merely more precise. Wrong! Very 
wrong! When you start with a schedule with rough tasks and then break it down 
into smaller tasks, you will find that you get a different result, not just a 
more precise one. It is a completely different number. Why does this happen?

When you have to pick fine grained tasks, you are forcing yourself to actually 
figure out what steps you are going to have to take. Write subroutine foo. 
Create dialog such and such. Read the wawa file. These steps are easy to 
estimate, because you''ve written subroutines, created dialogs, and read
wawa
files before.

If you are sloppy, and pick big "chunky" tasks ("implement
grammar correction"),
then you haven''t really thought about what you are going to do. And
when you
haven''t thought about what you''re going to do, you just
can''t know how long it
will take.

As a rule of thumb, each task should be from 2 to 16 hours. If you have a 40 
hour (one week) task on your schedule, you''re not breaking it down
enough.

Here''s another reason to pick fine grained tasks: it forces you to
design the
damn feature. If you have a hand-wavy feature called "Internet
Integration" and
you schedule 3 weeks for it, you are doomed, buddy. If you have to figure out 
what subroutines you''re going to write, you are forced to pin down the
feature.
By being forced to plan ahead at this level, you eliminate a lot of the 
instability in a software project.

<<< (End Quote)

	Nik


Zed A. Shaw wrote:
> Hi Oliver,
> 
> Well, here''s my (long winded) advice to you which is probably
going to
> be very controversial.  
> 
> First off, you need three things before you can even come close to
> measuring just about anything:
> 
> 1.  A sizing aspect that gives you some consistent metric of what you
> want to analyze.
> 2.  A comparison aspect that takes your sizing and turns it into a
> relative comparison with something else, usually time.
> 3.  A sampling method that dictates how you plan to sample or measure
> what you want to observe.
> 
> Alright, so here''s what I do that works reasonably well:
> 
> 1.  Develop enough of the application''s screens so that you know
what
> the customer is expecting to work with.  This can be done with paper
> prototypes, mocked-up HTML, mocked-up ASCII art, or even just bang out
> some ugly Rails.  I personally like mocked-up ASCII art as it prevents
> the customer from complaining about how it looks, and it''s fast as
hell.
> 2.  Write down the things they keep talking about.  Customer, Purchase,
> Credit Card, Transaction, Security Guard, etc.  Use their language.
> 3.  Once you''ve worked out the proposed screens with the customer
and
> things they expect to work with, you can start to count the following
> abstract elements:
> 	a.  User Inputs -- Screens where they enter a bunch of stuff and get a
> "done" or some small amount of response.
> 	b.  User Outputs -- Screens where they enter a little bit of stuff and
> get lots of stuff back.  Google search is a User Output.
> 	c.  User Queries -- Screens where the user interacts heavily or the
> ratio of input/output elements is about the same.
> 	d.  Database Tables/Internal Files -- Remember those "things"
you wrote
> down? Count them up as the potential tables.  Be reasonable, but usually
> you''ll have more than you expected.
> 	e.  External Interfaces -- Figure out what other systems your proposed
> system will have to interface with.  SMTP? SOAP? A weird ass database?
> 4.  Go to
>
http://www.engin.umd.umich.edu/CIS/course.des/cis525/js/f00/harvey/FP_Calc.html
and enter these counts into the form.  Pick a suitable weighting factor for each
one.  I tend to use my lack of experience as a weighting factor where, if I have
lots of experience then it''s average, otherwise complex since I
don''t know it.  I reserve a "simple" rating only if I have
already written the component and plan to reuse it.
> 5.  Update the part at the bottom based on what you think you''ll
need in
> the project.  I like to do a calculation at the bottom, expected, and
> maximum levels as a sanity check.
> 6.  Click calculate and that''s the Function Points for your
project.
> Yeah, you''ve done an FP calculation.
> 
> Now comes the part you aren''t going to like:  FP is useless by
itself.
> Why use it then?  Because you can combine it with time and history to
> develop a sense of how quickly you complete FP measured projects.  Also,
> the questions on the bottom of that FP page are just really good
> questions to ask when you start a project.  They''re the unexpected
> things that always screw up projects.
> 
> Once you get your FP on a proposed project, you need to ask around and
> see what other people have done on similar sized projects and how
> quickly they did it.  Here''s how I do this:
> 
> 1.  Do one small project after you know the FP and see how long it
> takes.  You can also do a portion of the project (say a month) and
> calculate the FP for that project.  It''s important to calculate
this
> before hand, otherwise you will cheat to make your estimates look
> better/worse.  Consider FP as your scientific hypothesis, and your time
> to complete as your experiment.
> 2.  Make sure that you don''t use 8 hours/day as your daily work
> estimate.  Nobody I know works 8 hours straight coding in an 8 hour day.
> I usually do 6 hours in a 8 hour day, less if I''m managing a team.
> (Even less if I''m in meeting hell).
> 3.  Use this time measurement to figure out your FP/hour rate.  This
> will be kind of fuzzy if you have a team, but if the team is consistent
> then doing the average for the whole team is a good start.  You may get
> really pissed off developers if you start trying to compare their
> FP/hour rates (and also lots of really bad code cranked out quickly).
> 4.  Finally, spend some time to figure out what your defects are at the
> end.  This is your FP/defect ratio and works to counter high FP/hour
> rates producing bad code.
> 
> The end result of this is your first measurement of how long it takes
> you to implement a certain chunk of FP, and the defects injected per FP.
> As you do more of these measurements over time you''ll start to
develop
> better and more accurate FP/hour measurements, and know about how many
> FP/defect to expect.  You can then use the FP/defect to add that much
> time to your estimate for expected fixes.
> 
> Additionally, you can then work on improving these to measurements.  You
> should read about statistical process control if you want to do this,
> but if you can get the FP/hour and FP/defect up then that means you make
> more money.  Also, when you go to your customers and show them your
> historical implementation rates, you''ll be one step ahead of your
> competition.  They''ll say, "We use XP so it''s done
when it''s done
> biatch."  You''ll say, "Here''s a measurement of
our efficiency and defect
> injection rates..."
> 
> To get you started here''s my rates on different types of projects:
> 
> Java,Tapestry,Hibernate -- 0.5 FP/hour
> Python/Twisted -- 3 FP/hour
> Ruby/Rails -- 4-5 FP/hour (this is still rough), a team does 2 FP/hour.
> C++/POSIX/FLTK/FOX -- 1.5 FP/hour
> 
> I don''t have any FP/defect measurements yet since I recently
decided to
> start tracking that.
> 
> Also keep in mind that it''s kind of dangerous to use FP to compare
team
> or developer efficiency.  It could be use to spot teams/people who are
> wildly better or worse, but even that''s controversial.  This is
> frequently done in CMM and most CMM programmers hate it with a passion.
> 
> Anyway, hope that helps some.  Take the time to go out and read up on
> things like Function Point Analysis, COCOMO and statistical process
> control or operations research.
> 
> Zed A. Shaw
> http://www.zedshaw.com/
> 
> 
> On Mon, 2005-06-27 at 23:52 -0300, oliver wrote:
> 
>>hi, I''m a total newbie to RoR, Ruby and this list, I hope
it''s not
>>too off-topic to ask this here. I''ve also signed up to the prag
prog
>>mailing and am asking it there... but I thought it''d be good to
ask
>>this regarding specific RoR dev.
> 
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>