algorithm - how to estimate time to complete

[worzel]

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

 

[Karsten Baumgarten]

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.

 

[worzel]

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.

 

[Dag Sunde]

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

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.

;-)

 

[Scott Ellsworth]

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

 

[worzel]

Thanks Lee - thats helps a lot.

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]

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.

 

[Tony Dahlman]

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

 

[worzel]

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.