algorithm - how to estimate time to complete

Discussion in 'Java' started by worzel, Feb 7, 2005.

  1. worzel

    worzel Guest

    Not a problem as such, just a question about estimating time for producing
    algorithms.

    I recently had to write a class with a method that was to convert digits
    (int) into their 'word' representation.
    To begin with, converting say, 234, into "two three four", was easy enough.
    But the method was also to 'sound english'

    So, 234 now had to be converted to:

    "two hundred and thirty four"

    Some other examples:

    "six million, three thousand and fifty six"
    "six billion and one"
    "eight billion,six million, three thousand, fourhundred and fifty six"

    (like the way a person may write on a cheque underneath the digit amount.)

    I wrote such a method. (which was actually a little more invoved than this
    as it supports currencies, floating point number etc;) But, only after badly
    underestimating the time involved for me to do so. There were were a few
    elemenst about it that were not so obvious until I sat down to write it. I
    ended up scratching a lot of stuff down on paper, and wrote it 3 times till
    I was happy with it.


    I have two questions here:

    What is the best way to estimate time for rather small tasks like this? How
    to you determine if a job will take an hour, a day, or a week? I know it
    seems like a silly question - but I am just keen to see what sort of
    responses come back from it.

    Secondly, how long do you think it would take you to write a method such as
    this? Personally, I allowed an hour and a half, and, like I said, was badly
    mistaken. I know I took longer because I trivialised the problems till I ran
    into them in live code, but still, it took way longer than I expected. (It
    took me a whole day and a bit of the next day)


    TIA
     
    worzel, Feb 7, 2005
    #1
    1. Advertising

  2. worzel wrote:
    > Not a problem as such, just a question about estimating time for producing
    > algorithms.
    >
    > I recently had to write a class with a method that was to convert digits
    > (int) into their 'word' representation.
    > To begin with, converting say, 234, into "two three four", was easy enough.
    > But the method was also to 'sound english'
    >
    > So, 234 now had to be converted to:
    >
    > "two hundred and thirty four"
    >
    > Some other examples:
    >
    > "six million, three thousand and fifty six"
    > "six billion and one"
    > "eight billion,six million, three thousand, fourhundred and fifty six"
    >
    > (like the way a person may write on a cheque underneath the digit amount.)
    >
    > I wrote such a method. (which was actually a little more invoved than this
    > as it supports currencies, floating point number etc;) But, only after badly
    > underestimating the time involved for me to do so. There were were a few
    > elemenst about it that were not so obvious until I sat down to write it. I
    > ended up scratching a lot of stuff down on paper, and wrote it 3 times till
    > I was happy with it.
    >
    >
    > I have two questions here:
    >
    > What is the best way to estimate time for rather small tasks like this? How
    > to you determine if a job will take an hour, a day, or a week? I know it
    > seems like a silly question - but I am just keen to see what sort of
    > responses come back from it.


    There are a number of cost-models to estimate the required time (and
    costs) to develop an application. One of those is called Constructive
    Cost Model (COCOMO). The effort of development is measured in person
    months and is mainly based on the KSLOC of your project (thousand source
    lines of code). Though I doubt it would yield any useful output for a
    more or less simple algorithm that stays well below the 1 KSLOC boundary.

    More info: http://www.softstarsystems.com/overview.htm

    Basically the best answer to your question would probably be:
    Experience. All cost models I know of are based on empiric knowledge
    about software development, in other words: they are based on
    experience. :)

    > Secondly, how long do you think it would take you to write a method such as
    > this? Personally, I allowed an hour and a half, and, like I said, was badly
    > mistaken. I know I took longer because I trivialised the problems till I ran
    > into them in live code, but still, it took way longer than I expected. (It
    > took me a whole day and a bit of the next day)


    As far as I can see the algorithm should be more or less simple. But as
    you had to learn yourself the hard way, looking at it and looking into
    it are two different things. :)

    --
    Regards,

    Karsten
     
    Karsten Baumgarten, Feb 8, 2005
    #2
    1. Advertising

  3. worzel

    worzel Guest

    Thanks for the resposes guys. Much appreciated.

    I have to say that the other side of my problem was that I went ahead with
    the task believing it to be very very simple. As it turned out, it was
    simple, but not quite as simple as I thought. There was a fair bit of logic
    in figuring if 'and' and ',' were required in the plain english version of
    the digits, and a bit in figuring out if we needed the likes of a 'one' or
    in the case of a 'one' in the preceding column, an 'eleven'. Just silly
    stuff like that - while none of it on it's own particulalry difficult, it
    certainly added time on top of my estimate.

    So basically, without formally undersatnding the problem until closer
    inspection, it makes it hard to provide a manager, who wants an estimate
    almost immediately, with an answer to how long a task will take. There is
    obviously many approaches for managing the project as a whole, but seemingly
    not to estimating times for very small tasks (1 hour to 3 days, say)

    I guess this is just the nature of the business - managers want it all ASAP,
    developers always need more time! And I guess the ultimate answer to my post
    is "go tell your manager to allow you time to look into how how much time is
    required" if he absolutely needs that info. Otherwise, just leave you to get
    on with it, it'll be done when its done!

    Anyway, thanks again.



    "worzel" <> wrote in message
    news:42085ef1$0$18909$...
    > Not a problem as such, just a question about estimating time for producing
    > algorithms.
    >
    > I recently had to write a class with a method that was to convert digits
    > (int) into their 'word' representation.
    > To begin with, converting say, 234, into "two three four", was easy
    > enough. But the method was also to 'sound english'
    >
    > So, 234 now had to be converted to:
    >
    > "two hundred and thirty four"
    >
    > Some other examples:
    >
    > "six million, three thousand and fifty six"
    > "six billion and one"
    > "eight billion,six million, three thousand, fourhundred and fifty six"
    >
    > (like the way a person may write on a cheque underneath the digit amount.)
    >
    > I wrote such a method. (which was actually a little more invoved than this
    > as it supports currencies, floating point number etc;) But, only after
    > badly underestimating the time involved for me to do so. There were were a
    > few elemenst about it that were not so obvious until I sat down to write
    > it. I ended up scratching a lot of stuff down on paper, and wrote it 3
    > times till I was happy with it.
    >
    >
    > I have two questions here:
    >
    > What is the best way to estimate time for rather small tasks like this?
    > How to you determine if a job will take an hour, a day, or a week? I know
    > it seems like a silly question - but I am just keen to see what sort of
    > responses come back from it.
    >
    > Secondly, how long do you think it would take you to write a method such
    > as this? Personally, I allowed an hour and a half, and, like I said, was
    > badly mistaken. I know I took longer because I trivialised the problems
    > till I ran into them in live code, but still, it took way longer than I
    > expected. (It took me a whole day and a bit of the next day)
    >
    >
    > TIA
    >
    >
    >
    >
     
    worzel, Feb 8, 2005
    #3
  4. worzel

    Dag Sunde Guest

    "worzel" <> wrote in message
    news:42085ef1$0$18909$...
    > Not a problem as such, just a question about estimating time for producing
    > algorithms.
    >

    <snipped/>

    > What is the best way to estimate time for rather small tasks like this?

    How
    > to you determine if a job will take an hour, a day, or a week? I know it
    > seems like a silly question - but I am just keen to see what sort of
    > responses come back from it.
    >


    I usually tell my manager (only half joking) that:

    * Make your best esimate.
    * Multiply by two
    * and then convert to the next higher unit.

    So in your case, 1.5 x 2 = 3 hours, converted one unit
    up = 3 days!

    Mind you, this time includes design, comments, documentation & testing.
    Ready for production.

    ;-)

    --
    Dag.
     
    Dag Sunde, Feb 8, 2005
    #4
  5. In article <cu9pvh$r9r$00$-online.com>,
    Karsten Baumgarten <> wrote:

    > Basically the best answer to your question would probably be:
    > Experience. All cost models I know of are based on empiric knowledge
    > about software development, in other words: they are based on
    > experience. :)


    Experience is not enough - records also matter.

    Many trying to figure out modelling and time estimation do not track the
    actual and the estimated time, which makes it really hard to figure out
    not just how far off your original estimate is, but in what way you
    screwed it up.

    If you are really, really into paperwork, Watts Humphries' Personal
    Software Process has a pretty good set of machinery to track both the
    kinds and the impacts of errors. (Estimation errors, bugs, defect
    tracking, overhead, etc.)

    It is a grind to do, but if you stick to it for a month or so, you will
    have a really good idea of what you need to track, and what you need to
    look out for. Even if you then drop it for an agile methodology, you
    still will know your own personal strengths, and your own personal time
    sinks.

    Scott
     
    Scott Ellsworth, Feb 8, 2005
    #5
  6. worzel

    worzel Guest

    Thanks Lee - thats helps a lot.


    "Lee Fesperman" <> wrote in message
    news:...
    > worzel wrote:
    >>
    >> Not a problem as such, just a question about estimating time for
    >> producing
    >> algorithms.
    >>
    >> ...
    >>
    >> I have two questions here:
    >>
    >> What is the best way to estimate time for rather small tasks like this?
    >> How
    >> to you determine if a job will take an hour, a day, or a week? I know it
    >> seems like a silly question - but I am just keen to see what sort of
    >> responses come back from it.
    >>
    >> Secondly, how long do you think it would take you to write a method such
    >> as
    >> this? Personally, I allowed an hour and a half, and, like I said, was
    >> badly
    >> mistaken. I know I took longer because I trivialised the problems till I
    >> ran
    >> into them in live code, but still, it took way longer than I expected.
    >> (It
    >> took me a whole day and a bit of the next day)

    >
    > I would tend to agree with the other posters that experience is the
    > primary factor in
    > being able to estimate well, though I also go along with the poster who
    > recommended
    > recording the information and tracking estimates against performance.
    >
    > Experience is no guarantee though. Nor is resources. Note that Microsoft
    > with all its
    > resources is very bad at estimates. In fact, I would say that the vast
    > majority are very
    > bad at estimating no matter the experience. OTOH, I find that few managers
    > will accept a
    > proper estimate and generally will force the estimator to cave in. I have
    > lost contracts
    > for refusing to give.
    >
    > I consider myself a very good estimator and have a long track record to
    > prove it. At
    > first, I used to go over each task in my mind to estimate the time and
    > then add
    > integration, testing, trips to the water cooler, etc. and finally some
    > fudge for the
    > unexpected (usually, external factors). After a decade or so, I find my
    > intuition is
    > pretty accurate, which is useful when the manager demands quick answer.
    > Given the time,
    > I would always prefer to study the problem properly. This also ends up
    > benefiting the
    > actual project.
    >
    > --
    > Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
    > ==============================================================
    > * The Ultimate DBMS is here!
    > * FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
     
    worzel, Feb 9, 2005
    #6
  7. worzel wrote:
    >
    > Not a problem as such, just a question about estimating time for producing
    > algorithms.
    >
    > ...
    >
    > I have two questions here:
    >
    > What is the best way to estimate time for rather small tasks like this? How
    > to you determine if a job will take an hour, a day, or a week? I know it
    > seems like a silly question - but I am just keen to see what sort of
    > responses come back from it.
    >
    > Secondly, how long do you think it would take you to write a method such as
    > this? Personally, I allowed an hour and a half, and, like I said, was badly
    > mistaken. I know I took longer because I trivialised the problems till I ran
    > into them in live code, but still, it took way longer than I expected. (It
    > took me a whole day and a bit of the next day)


    I would tend to agree with the other posters that experience is the primary factor in
    being able to estimate well, though I also go along with the poster who recommended
    recording the information and tracking estimates against performance.

    Experience is no guarantee though. Nor is resources. Note that Microsoft with all its
    resources is very bad at estimates. In fact, I would say that the vast majority are very
    bad at estimating no matter the experience. OTOH, I find that few managers will accept a
    proper estimate and generally will force the estimator to cave in. I have lost contracts
    for refusing to give.

    I consider myself a very good estimator and have a long track record to prove it. At
    first, I used to go over each task in my mind to estimate the time and then add
    integration, testing, trips to the water cooler, etc. and finally some fudge for the
    unexpected (usually, external factors). After a decade or so, I find my intuition is
    pretty accurate, which is useful when the manager demands quick answer. Given the time,
    I would always prefer to study the problem properly. This also ends up benefiting the
    actual project.

    --
    Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
    ==============================================================
    * The Ultimate DBMS is here!
    * FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
     
    Lee Fesperman, Feb 10, 2005
    #7
  8. worzel

    Tony Dahlman Guest

    worzel wrote:

    > Not a problem as such, just a question about estimating time for producing
    > algorithms.
    >
    > I recently had to write a class with a method that was to convert digits
    > (int) into their 'word' representation.
    > To begin with, converting say, 234, into "two three four", was easy enough.
    > But the method was also to 'sound english'
    >
    > So, 234 now had to be converted to:
    >
    > "two hundred and thirty four"
    >
    > Some other examples:
    >
    > "six million, three thousand and fifty six"
    > "six billion and one"
    > "eight billion,six million, three thousand, fourhundred and fifty six"
    >
    > (like the way a person may write on a cheque underneath the digit amount.)
    >
    > I wrote such a method. (which was actually a little more invoved than this
    > as it supports currencies, floating point number etc;) But, only after badly
    > underestimating the time involved for me to do so. There were were a few
    > elemenst about it that were not so obvious until I sat down to write it. I
    > ended up scratching a lot of stuff down on paper, and wrote it 3 times till
    > I was happy with it.
    >
    >
    > I have two questions here:
    >
    > What is the best way to estimate time for rather small tasks like this? How
    > to you determine if a job will take an hour, a day, or a week? I know it
    > seems like a silly question - but I am just keen to see what sort of
    > responses come back from it.
    >
    > Secondly, how long do you think it would take you to write a method such as
    > this? Personally, I allowed an hour and a half, and, like I said, was badly
    > mistaken. I know I took longer because I trivialised the problems till I ran
    > into them in live code, but still, it took way longer than I expected. (It
    > took me a whole day and a bit of the next day)
    >
    >
    > TIA
    >

    Whoa! I think you made three or four mistakes, here....

    First, it took me ten minutes to find out that this code has previously been written,
    far more completely and scalably than you even imagined. (See link below.) And it
    is free under a GPL-like license.

    Second, if you think that the correct text to put on your checks for $234 is
    "two hundred and thirty-four," then you missed something in your sixth- or
    seventh-grade grammar book. (I know that many Americans talk that way, but
    that is colloquial and therefore, arguably, acceptable.) Is it standard in
    Australia, or should $234.39 be written:

    Two hundred thirty-four and thirty-nine / 100 ______dollars ?

    At least, other English-speaking countries will be using this, not your,
    convention for writing numbers as text.

    Third, you apparently did not even think about internationalizing these strings.

    Fourth and perhaps most important, your boss's question about how long it would
    take you to do this may have been intended to get you to think about the problem
    rather than just doing calculations. Not speaking for the boss, of course, and
    he/she may know nothing about software development and programming, in which case
    the above doesn't apply.

    It pains me (I'm a shareholder but never an employee) to think that IBM puts
    this code out there, yet people don't notice. WORA means "run anywhere", so why
    don't more people learn how to do that? (Not flaming you personally with that. :))

    http://icu.sourceforge.net/apiref/icu4j/com/ibm/icu/text/RuleBasedNumberFormat.html

    Regards,
    Tony Dahlman

    ----------------------------------------
    Please do not send follow-ups to my posted email address. I will never see them,
    thanks to spammers who will surely send lots of crap there.
     
    Tony Dahlman, Feb 28, 2005
    #8
  9. worzel

    worzel Guest

    re:
    First, it took me ten minutes to find out that this code has previously been
    written,
    far more completely and scalably than you even imagined.

    No good - not allowed to use any external code.

    re:
    > Second, if you think that the correct text to put on your checks for $234
    > is
    > "two hundred and thirty-four," then you missed something in your sixth- or
    > seventh-grade grammar book.


    Sure, this is just an error in my post, not the actual code. The code works
    as expected. It,s not actually got anything to do with check or money, that
    was just my way providing some insight into the problem.

    re:
    > Third, you apparently did not even think about internationalizing these
    > strings.


    Thought of, and dismissed. Not a requirement.

    Thanks for your feedback. However, I was more interested in the estimation /
    time management issue, not how to write the code as such.



    "Tony Dahlman" <> wrote in message
    news:...
    > worzel wrote:
    >
    >> Not a problem as such, just a question about estimating time for
    >> producing algorithms.
    >>
    >> I recently had to write a class with a method that was to convert digits
    >> (int) into their 'word' representation.
    >> To begin with, converting say, 234, into "two three four", was easy
    >> enough. But the method was also to 'sound english'
    >>
    >> So, 234 now had to be converted to:
    >>
    >> "two hundred and thirty four"
    >>
    >> Some other examples:
    >>
    >> "six million, three thousand and fifty six"
    >> "six billion and one"
    >> "eight billion,six million, three thousand, fourhundred and fifty six"
    >>
    >> (like the way a person may write on a cheque underneath the digit
    >> amount.)
    >>
    >> I wrote such a method. (which was actually a little more invoved than
    >> this as it supports currencies, floating point number etc;) But, only
    >> after badly underestimating the time involved for me to do so. There were
    >> were a few elemenst about it that were not so obvious until I sat down to
    >> write it. I ended up scratching a lot of stuff down on paper, and wrote
    >> it 3 times till I was happy with it.
    >>
    >>
    >> I have two questions here:
    >>
    >> What is the best way to estimate time for rather small tasks like this?
    >> How to you determine if a job will take an hour, a day, or a week? I know
    >> it seems like a silly question - but I am just keen to see what sort of
    >> responses come back from it.
    >>
    >> Secondly, how long do you think it would take you to write a method such
    >> as this? Personally, I allowed an hour and a half, and, like I said, was
    >> badly mistaken. I know I took longer because I trivialised the problems
    >> till I ran into them in live code, but still, it took way longer than I
    >> expected. (It took me a whole day and a bit of the next day)
    >>
    >>
    >> TIA
    >>

    > Whoa! I think you made three or four mistakes, here....
    >
    > First, it took me ten minutes to find out that this code has previously
    > been written,
    > far more completely and scalably than you even imagined. (See link
    > below.) And it
    > is free under a GPL-like license.
    >
    > Second, if you think that the correct text to put on your checks for $234
    > is
    > "two hundred and thirty-four," then you missed something in your sixth- or
    > seventh-grade grammar book. (I know that many Americans talk that way,
    > but
    > that is colloquial and therefore, arguably, acceptable.) Is it standard
    > in
    > Australia, or should $234.39 be written:
    >
    > Two hundred thirty-four and thirty-nine / 100 ______dollars ?
    >
    > At least, other English-speaking countries will be using this, not your,
    > convention for writing numbers as text.
    >
    > Third, you apparently did not even think about internationalizing these
    > strings.
    >
    > Fourth and perhaps most important, your boss's question about how long it
    > would
    > take you to do this may have been intended to get you to think about the
    > problem
    > rather than just doing calculations. Not speaking for the boss, of
    > course, and
    > he/she may know nothing about software development and programming, in
    > which case
    > the above doesn't apply.
    >
    > It pains me (I'm a shareholder but never an employee) to think that IBM
    > puts
    > this code out there, yet people don't notice. WORA means "run anywhere",
    > so why
    > don't more people learn how to do that? (Not flaming you personally with
    > that. :))
    >
    > http://icu.sourceforge.net/apiref/icu4j/com/ibm/icu/text/RuleBasedNumberFormat.html
    >
    > Regards,
    > Tony Dahlman
    >
    > ----------------------------------------
    > Please do not send follow-ups to my posted email address. I will never
    > see them,
    > thanks to spammers who will surely send lots of crap there.
     
    worzel, Mar 3, 2005
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bob
    Replies:
    31
    Views:
    1,061
    Nick Malik
    Jul 16, 2004
  2. =?Utf-8?B?dmlrdG9yOTk5MA==?=

    cost estimate for a database-driven web site

    =?Utf-8?B?dmlrdG9yOTk5MA==?=, Jun 5, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    362
    =?Utf-8?B?dmlrdG9yOTk5MA==?=
    Jun 5, 2005
  3. =?Utf-8?B?dmlrdG9yOTk5MA==?=

    cost estimate for a database-driven web site

    =?Utf-8?B?dmlrdG9yOTk5MA==?=, Jun 5, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    379
    =?Utf-8?B?dmlrdG9yOTk5MA==?=
    Jun 5, 2005
  4. shuisheng
    Replies:
    9
    Views:
    378
    Jerry Coffin
    Mar 3, 2007
  5. Paul
    Replies:
    8
    Views:
    117
    Paul Carvalho
    Aug 20, 2009
Loading...

Share This Page