Free Republic
Browse · Search
General/Chat
Topics · Post Article

Skip to comments.

Software Estimation: How Misperceptions Mean We Almost Always Get It Wrong
Dr. Dobbs Journal ^ | April 08, 2014 | Carol Dekkers

Posted on 04/09/2014 5:11:04 PM PDT by ImJustAnotherOkie

Software developers are among the smartest people on the planet and often boast advanced degrees in mathematics, engineering, or computer science. In some ways, they are like superheroes — capable of programming complex functions, juggling myriad technologies, morphing customer ideas into working software, all the while not breaking a sweat. So how is it that despite such technical savvy and programming prowess, they are so woefully poor at project estimation? Study upon study cites that less than one-third of projects are delivered on time or on budget. Couple this with the fact that close to half of the effort spent doing software projects ends up being "rework" and the whole situation seems to defy logic. How can smart people produce dumb estimates?

(Excerpt) Read more at drdobbs.com ...


TOPICS:
KEYWORDS:
Navigation: use the links below to view more comments.
first 1-5051-66 next last
This article is so wrong on so many levels. Software developers don't make estimates, in the best case ex-software developers (ones who got bored with it or promoted using the Peter-Priniciple) did. The vast majority barely know what a Crosstab is let alone a Hash key or an OO Instance.

I've been to project meetings and they drive me nuts. People repeating what other people say,

The dead give away was in the title.

How Misperceptions Mean We Almost Always Get It Wrong

.

What is this 'We' kemosabi. Can the author explain the basic principles I stated above?

1 posted on 04/09/2014 5:11:04 PM PDT by ImJustAnotherOkie
[ Post Reply | Private Reply | View Replies]

To: ImJustAnotherOkie
There are a few individuals who are easily 10x more efficient in programming than the average.

Then there are some who have negative efficiencies.

Putting together a competent staff larger than two or three quickly becomes problematic.

2 posted on 04/09/2014 5:13:40 PM PDT by Paladin2
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie

Plus mission creep.


3 posted on 04/09/2014 5:14:48 PM PDT by Cboldt
[ Post Reply | Private Reply | To 1 | View Replies]

To: Cboldt

yep, mission creep, plus on long term projects, technological advances and in some cases, obsoletion…..(is that a word)


4 posted on 04/09/2014 5:18:29 PM PDT by C. Edmund Wright (Tokyo Rove is more than a name, it's a GREAT WEBSITE)
[ Post Reply | Private Reply | To 3 | View Replies]

To: ImJustAnotherOkie
Software developers are among the smartest people on the planet

Oh, I could tell you stories ...

5 posted on 04/09/2014 5:19:19 PM PDT by ClearCase_guy
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie

IT people [I call them Programming Weenies] have absolutely no clue as to what users want or need. They don’t live in the real world.

They take an established piece of software or a program, then put in all these unnecessary bells and whistles because they think it is neato-keen.

At the same time, they remove existing features that the users absolutely want and need - declaring them to be irrelevant. They also take existing features that they are going to keep and then put them in new places, so the users have to hunt-and-find them.

Then, they declare Victory ...


6 posted on 04/09/2014 5:21:46 PM PDT by Lmo56 (If ya wanna run with the big dawgs - ya gotta learn to piss in the tall grass ...)
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie

If you’re doing something that’s already been done by the same group it isn’t that hard to estimate time. When it is all a big unknown - that’s what you get for a time estimate... Bugs and/or poor documentation on interfaces to third party modules/sub systems can blow the whole thing up real fast time wise...


7 posted on 04/09/2014 5:23:31 PM PDT by DB
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie

When they solve the problem of 90% of “software developers” being either barely able to string code together, or incapable of just “getting the job done”, then I’ll start listening.

Until then, 90% of estimates are crap, 90% of project deadlines are unrealistic, 90% of buzzwordy BS is exactly that, and 90% of “software developers” can keep finding another line of work.

And yes, ultimately we have fired or otherwise ensured the discontinuance of employment for 90% of the developers we’ve hired.


8 posted on 04/09/2014 5:24:47 PM PDT by TheZMan (Buy more ammo.)
[ Post Reply | Private Reply | To 1 | View Replies]

To: Paladin2
Putting together a competent staff larger than two or three quickly becomes problematic.

Hence pair programming is as fair as teamwork can really go, heheh.

In all seriousness it's more like 10000x. 10x is more like novice programmer over clueless newbie...

9 posted on 04/09/2014 5:25:14 PM PDT by no-s (when democracy is displaced by tyranny, the armed citizen still gets to vote)
[ Post Reply | Private Reply | To 2 | View Replies]

To: Lmo56

I’m currently working with a full team that believes in this methodology. Aint life grand.


10 posted on 04/09/2014 5:25:49 PM PDT by TheZMan (Buy more ammo.)
[ Post Reply | Private Reply | To 6 | View Replies]

To: ImJustAnotherOkie
So how is it that despite such technical savvy and programming prowess, they are so woefully poor at project estimation?

Management.

11 posted on 04/09/2014 5:32:30 PM PDT by grobdriver (Where is Wilson Blair when you need him?)
[ Post Reply | Private Reply | To 1 | View Replies]

To: TheZMan
I’m currently working with a full team that believes in this methodology. Aint life grand.

And, when you point out a bug or flaw in the "New And Improved" software, they smile at you and call it a "Feature" - and then proceed to give you a 23-Step Rube Goldberg type "Workaround" instead of fixing the damn thing ...

12 posted on 04/09/2014 5:38:35 PM PDT by Lmo56 (If ya wanna run with the big dawgs - ya gotta learn to piss in the tall grass ...)
[ Post Reply | Private Reply | To 10 | View Replies]

To: ImJustAnotherOkie

I think the biggest factor in under-estimating software projects comes down to people: client expectations, software analyst’ skills in requirements-gathering, availability of business SMEs to help design and test, readability of the program, understanding of business rules and processes, etc. A good project manager has to properly manage the ENTIRE team, including the software development folks, as well as the customer.


13 posted on 04/09/2014 5:44:02 PM PDT by Lou L (Health "insurance" is NOT the same as health "care")
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie

Mission/scope creep, constantly changing requirements from the client/business, levels of beauracracy that rival anything the government can throw in your way, and finally, multitudes of clueless, useless, counterproductive management.


14 posted on 04/09/2014 5:44:58 PM PDT by Sicon ("All animals are equal, but some animals are more equal than others." - G. Orwell)
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie
My experience with cost/time overruns is that there is no really good way to gather requirements. And if you don't have good requirements you have no idea how long the project is going to take.

I've been on projects where we did detailed interviews and created massive, well-organized and detailed requirements. In most cases when we delivered the software we got a collective: "Huh? This is not what we asked for."

So then we tried the UI sample screens approach where we worked with them to identify what all of the user interface screens would look like, and collected the requirements through interaction with the clients. But then when we delivered the actual software, again we got the "Huh? This isn't what we wanted."

Until the users could actually interact with the application they really didn't grasp what they wanted it to do or how they wanted it to work. I really think it comes down to the fact that very few people are capable of thinking abstractly.

You almost have to build the application from scratch with continuous input from the user community to avoid rework. But of course the user community is already overworked and doesn't have time to spend helping you create the application that may eliminate their jobs.

So you gather enough requirements to get started knowing that whatever you build the first time will look nothing like the final version and you pray that the users will give your application enough time to identify all the missing requirements.

15 posted on 04/09/2014 5:46:12 PM PDT by who_would_fardels_bear
[ Post Reply | Private Reply | To 1 | View Replies]

To: Lmo56

You’ve played this game before, I see.


16 posted on 04/09/2014 5:52:01 PM PDT by TheZMan (Buy more ammo.)
[ Post Reply | Private Reply | To 12 | View Replies]

To: All

In my career in IT, the major issues leading to not bringing in a project on time and on budget are:

1. Broad finish dates driven by upper management, often management that is not in IT or does not have an IT background.

2. Failure of management to take the council of experienced IT professionals who do have experience in providing estimates. Often I have seen that given a set of broad requirements and a rough estimate that states “We estimate we can complete this project in x months”, management will state “That’s great. You will need to get this project done in 1/2 that time or 2/3 that time.

3. Poor requirements.

4. Scope creep, which quite often is driven from point 2.

5. Once it becomes obvious a project is in the ditch and will not come in on time, adding inexperienced resources in an attempt to cut the time to deliver. Adding these resources results in time wasted due to training new resources and rework.

I do find that developers often do underestimate the time needed to complete a task, but by the time a project is at the point of individual estimates for specific sets of work, the failure of a project has already been set in motion by factors far above estimates from a developer.

The article is interesting, but seems rather academic and not based upon the realities in business.


17 posted on 04/09/2014 5:52:40 PM PDT by WillVoteForFood
[ Post Reply | Private Reply | To 11 | View Replies]

To: All

In my career in IT, the major issues leading to not bringing in a project on time and on budget are:

1. Broad finish dates driven by upper management, often management that is not in IT or does not have an IT background.

2. Failure of management to take the council of experienced IT professionals who do have experience in providing estimates. Often I have seen that given a set of broad requirements and a rough estimate that states “We estimate we can complete this project in x months”, management will state “That’s great. You will need to get this project done in 1/2 that time or 2/3 that time.

3. Poor requirements.

4. Scope creep, which quite often is driven from point 2.

5. Once it becomes obvious a project is in the ditch and will not come in on time, adding inexperienced resources in an attempt to cut the time to deliver. Adding these resources results in time wasted due to training new resources and rework.

I do find that developers often do underestimate the time needed to complete a task, but by the time a project is at the point of individual estimates for specific sets of work, the failure of a project has already been set in motion by factors far above estimates from a developer.

The article is interesting, but seems rather academic and not based upon the realities in business.


18 posted on 04/09/2014 5:52:40 PM PDT by WillVoteForFood
[ Post Reply | Private Reply | To 11 | View Replies]

To: ImJustAnotherOkie
When a team does come up with a realistic estimate based on actual history, management can become incredulous and will reduce the estimate to a level they can live with.

MANAGEMENT will REDUCE the estimate! Winner! Winner! Chicken dinner!

19 posted on 04/09/2014 5:54:41 PM PDT by missnry (The truth will set you free ... and drive liberals crazy!)
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie

you gotta hire someone good just to spec it out BEFORE you can estimate how long to get it done (and how much)


20 posted on 04/09/2014 5:55:03 PM PDT by Mr. K (If you like your constitution, you can keep it...Period. PALIN/CRUZ 2016)
[ Post Reply | Private Reply | To 1 | View Replies]

To: TheZMan

you should call me


21 posted on 04/09/2014 5:56:36 PM PDT by Mr. K (If you like your constitution, you can keep it...Period. PALIN/CRUZ 2016)
[ Post Reply | Private Reply | To 8 | View Replies]

To: ImJustAnotherOkie

REM The standard response that we always got from the boys and girls at Lawrence Livermore Labs - six months, a million bucks. Someone usually wrote them a check.


22 posted on 04/09/2014 5:58:24 PM PDT by centurion316
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie
I have developed software for 30 years. First what some people love others hate. It is simply the reality of applications.
The modern problem is the over division of labor. On a project we have business analysts, project managers, QA, project sponsors, and a computer geek who is fundamentally incapable of uttering a single word of English.
Gone are the days of us oldsters who know business, accounting
g, computers, AND how to talk to other human beings.
23 posted on 04/09/2014 6:06:34 PM PDT by CyberSpartacus
[ Post Reply | Private Reply | To 1 | View Replies]

To: who_would_fardels_bear

That’s where Agile Projects come into play.

Build your package incrementally. Management loathes rewriting existing functionality but it needs to be done. After several iterations you’ll get it right.

Real programmers are not Fungable...Lesson 1.


24 posted on 04/09/2014 6:06:55 PM PDT by ImJustAnotherOkie (zerogottago)
[ Post Reply | Private Reply | To 15 | View Replies]

To: Lmo56

Message from planet X.

IT these days is 80% technical generalist’s and 15% programmers of medium ability, 4% good abilities and about 1% outstanding abilities.

The majority of developers who have been at it for 5 years have 1 year’s experience 5 times.


25 posted on 04/09/2014 6:10:19 PM PDT by ImJustAnotherOkie (zerogottago)
[ Post Reply | Private Reply | To 6 | View Replies]

To: CyberSpartacus

Your’re singing to the crowd brother.


26 posted on 04/09/2014 6:11:09 PM PDT by ImJustAnotherOkie (zerogottago)
[ Post Reply | Private Reply | To 23 | View Replies]

To: ImJustAnotherOkie

Since software is easy to change, management will change the target often at the slightest whim of the customer. Mechanical or electical managers are much better at telling upper level management “we’ve already had the dies made. Your ‘little tweak’ will cost $30,000 and set us back six weeks. Are you sure you really want this?” Software’s flexibility is used as an excuse to skip the design phase or to throw aside the design when the code is being written.


27 posted on 04/09/2014 6:12:57 PM PDT by KarlInOhio (Republican amnesty supporters don't care whether their own homes are called mansions or haciendas.)
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie
Software developers are their own worst enemies. Every year there is a new "must have" programming language. This is great for the newbies trying to break into the computer programming racket.

But then when they've been on the job for a couple years and finally know how to program in that language they are considered dinosaurs and are now unemployable because the new latest-greatest language has just come out.

Philosophy is supposed to just be footnotes to Plato.

Why can't software just be add-ons to C?

28 posted on 04/09/2014 6:15:48 PM PDT by who_would_fardels_bear
[ Post Reply | Private Reply | To 25 | View Replies]

To: Sicon

Who’s job is to update the spreadsheet? Ok, we’ll download ms project and import it into the spreadsheet to massage it? Who’s job is that? Ok, we’ve lost the conference room, time for the next meeting.

I see these project management types Outlook calendars. It looks like modern art. Where is the time to think, run analysis models?


29 posted on 04/09/2014 6:16:19 PM PDT by ImJustAnotherOkie (zerogottago)
[ Post Reply | Private Reply | To 14 | View Replies]

To: Lou L

What is a software analyst?


30 posted on 04/09/2014 6:17:21 PM PDT by ImJustAnotherOkie (zerogottago)
[ Post Reply | Private Reply | To 13 | View Replies]

To: grobdriver

The programmers are not giving the estimates.


31 posted on 04/09/2014 6:18:24 PM PDT by ImJustAnotherOkie (zerogottago)
[ Post Reply | Private Reply | To 11 | View Replies]

To: ImJustAnotherOkie
...they are so woefully poor at project estimation? Study upon study cites that less than one-third of projects are delivered on time or on budget.

My rule of thumb as a CFO was to double their estimates of time and cost. Worked every time.

5.56mm

32 posted on 04/09/2014 6:21:53 PM PDT by M Kehoe
[ Post Reply | Private Reply | To 1 | View Replies]

To: WillVoteForFood
I do find that developers often do underestimate the time needed to complete a task, but by the time a project is at the point of individual estimates for specific sets of work, the failure of a project has already been set in motion by factors far above estimates from a developer.

How well defined are the tasks? Are the tasks defined in user speak, or table names and fields. Someone other than the programmers needs to have a working knowledge of the tables, schema's and object models at a workable level.

33 posted on 04/09/2014 6:22:45 PM PDT by ImJustAnotherOkie (zerogottago)
[ Post Reply | Private Reply | To 17 | View Replies]

To: M Kehoe

We multiply by PI.


34 posted on 04/09/2014 6:24:15 PM PDT by who_would_fardels_bear
[ Post Reply | Private Reply | To 32 | View Replies]

To: M Kehoe

Hell, I’m developer and I double all mine for admin, status reports, team meetings, Quick questions, firefighting ...ect.


35 posted on 04/09/2014 6:25:08 PM PDT by ImJustAnotherOkie (zerogottago)
[ Post Reply | Private Reply | To 32 | View Replies]

To: ImJustAnotherOkie

Its actually the inverse Peter principle. Instead of getting promoted from competence to incompetence, they get promoted out of incompetence to a place where they can do less damage.


36 posted on 04/09/2014 6:27:15 PM PDT by Theophilus (.)
[ Post Reply | Private Reply | To 1 | View Replies]

To: Paladin2

It’s pretty much a solitary endeavor contrary to Popular Wisdom. Makes a rubics cuble look pretty simple sometimes.


37 posted on 04/09/2014 6:27:27 PM PDT by ImJustAnotherOkie (zerogottago)
[ Post Reply | Private Reply | To 2 | View Replies]

To: ImJustAnotherOkie

That’s an interesting question. The definition on tasks seems sometimes to have an odd relationship to how far behind a project has gotten. The more behind, the less well defined the tasks are. Whatever project discipline there might have been early on in the project tends to fly out the window as things get difficult and pressure rises.


38 posted on 04/09/2014 6:34:44 PM PDT by WillVoteForFood
[ Post Reply | Private Reply | To 33 | View Replies]

To: ImJustAnotherOkie

A couple of thoughts:

(BTW, I have been doing S/W development for 45 years and counting, and in my first 30 years I put in 15 years of un-compensated overtime; that’s 45 years of experience during that time plus the last 15 years of “normal” work. That’s 60 years equivalent experience by my count)

Why is it that the only people who know how to do S/W development better than those of us who actually do it is EVERYONE WHO HAS NEVER TRIED IT!?

And, they NEVER tire of telling us how easy it is. sigh.

The reason estimates are guaranteed to be off is because the software to satisfy a given set of requirements (usually a rough wild-assed-guess), composed of what the user thinks they want and never what they NEED, have NEVER been created by this development team, for this customer/user group, using these tools, on this platform, using this data, etc. EACH new project/requirement is UNIQUE! If it had been done before we would just go get that solution and be done. It’s not like an estimate to build 6 more houses like the last 50 that this crew built on the last project.

Why is it that the estimate (wild-assed-guess) is given more credibility than the work product that delivers the needed capability. It makes me think that the critics are all libs/progressives (live in a dream world) and the development team is conservative (forced to live with reality).

Sorry to rant.


39 posted on 04/09/2014 6:50:27 PM PDT by Thom Pain (If you like your country you can keep it. Period.)
[ Post Reply | Private Reply | To 1 | View Replies]

To: Thom Pain

The ones who talk the big game are the ones who tried it and failed because they are task oriented people who cannot focus on complex scenario’s. They need to be spoon fed. Can’t figure things out on their own. They think it is ok just to ask a question instead of mastering research skills. They can’t accept failure, if it doesn’t work the first time they give up.

I’ve seen so many it’s sickening.


40 posted on 04/09/2014 6:59:50 PM PDT by ImJustAnotherOkie (zerogottago)
[ Post Reply | Private Reply | To 39 | View Replies]

To: ImJustAnotherOkie

I think that our profession requires a fairly rare combination of the (sometimes) wildly creative part of the brain (the part that conceives of the solution(s)) and the disciplined part of the brain that ensures that the implemented solution is robust, efficient, resistent to errors, and maintainable. Quite rare, and quite valuable.


41 posted on 04/09/2014 7:04:57 PM PDT by Thom Pain (If you like your country you can keep it. Period.)
[ Post Reply | Private Reply | To 40 | View Replies]

To: ImJustAnotherOkie

Because at every step in the process - Requirements Development, Coding, Testing, there’s never time to do it right, but always time to do it over.


42 posted on 04/09/2014 7:07:46 PM PDT by DuncanWaring (The Lord uses the good ones; the bad ones use the Lord.)
[ Post Reply | Private Reply | To 1 | View Replies]

To: C. Edmund Wright
...and in some cases, obsoletion…..(is that a word?)

COBOL Rules!

(I would write "Hello World", but it would take 5 pages of code and my carpal tunnel is acting up again)

43 posted on 04/09/2014 7:47:59 PM PDT by BwanaNdege
[ Post Reply | Private Reply | To 4 | View Replies]

To: BwanaNdege

L,u. A0, $cas(’COBOL rules’)
LXI,u A0, 0103
ER aprint$

(No, it doesn’t)


44 posted on 04/09/2014 8:11:10 PM PDT by ImaGraftedBranch (...By reading this, you've collapsed my wave function. Thanks.)
[ Post Reply | Private Reply | To 43 | View Replies]

To: KarlInOhio

Ding ding ding. We have a winner.
Lots of non-programmers do this. In my experience, it’s been primarily managers and visual designers.
I had a manager who thought it would be a good idea to refactor my requirement satisfying enhancement after deadline (which I did meet by the way), because he thought it would easy and it would be cleaner that way. He disregarded my advice and turned a 2 day assignment turned into a 5 day one.
I also had a visual designer decide to not use Android’s UI element designed for what we wanted, because he didn’t like the way it looked. I explained to him that it is not in our best interests to create customized UI components for trivial reasons. Future versions of the OS could come out and easily break it (That happened to our iOS team A LOT)..
He just said do it and delayed the project for days.


45 posted on 04/09/2014 9:00:16 PM PDT by NullPointerException
[ Post Reply | Private Reply | To 27 | View Replies]

To: Thom Pain

In a more agile discipline, the number of features is subject to change, while the deadline and quality stay constant. So, there is always a quality product to deliver to a customer at the end of an release; it just may not have everything you want. However, I am not aware of any company that works this way and it’s because of the people who don’t program.
It usually goes like:
“I don’t know.”
“Why not?”
“Because I can’t see the future. If I could, I wouldn’t be working here.”
“Just guess.”
(A high number)
“Why do you think it is going to take a long time?”
“Things usually go wrong.”


46 posted on 04/09/2014 9:13:15 PM PDT by NullPointerException
[ Post Reply | Private Reply | To 39 | View Replies]

To: ImJustAnotherOkie

I appreciate the tremendous insight I am reading on this post. Apparently we have quite a few Freepers with firsthand knowledge of the programming business.

“So how is it that despite such technical savvy and programming prowess, they are so woefully poor at project estimation?”

I will add this to the other comments. It is possible to come in under budget and in less time than estimated. It is also possible to come in over budget and finish in more time than estimated. However, it is impossible to come in at less than zero cost or to be finished before you start. And it is possible to take infinite time and incur infinite costs. Thus, on average, estimates tend to be less than the actual results. The more specific we can be when planning and closer to existing, real-world projects in scope, the closer the estimates will be also.


47 posted on 04/09/2014 9:34:50 PM PDT by unlearner (You will never come to know that which you do not know until you first know that you do not know it.)
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie

show me one major software project that managers didn’t pull resources away from, one project that didn’t have fundamental requirements change along the way, demands to add in or do something major that wasn’t in the original scope (scope creep), show me one major project that doesn’t have enough resources allocated to do proper testing and integration, between teams, and between user testing.

it aint b/c of software engineers not estimating properly.


48 posted on 04/09/2014 10:49:05 PM PDT by Secret Agent Man (Gone Galt; Not averse to Going Bronson.)
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie
What is a software analyst?

I think this title may vary from company to company; in my experience, this role may also be called a business analyst, a business integrator, an information analyst, and so forth. This role is the person who sits with the client to elicit and capture requirements which will be used to develop the software.

49 posted on 04/10/2014 5:28:16 AM PDT by Lou L (Health "insurance" is NOT the same as health "care")
[ Post Reply | Private Reply | To 30 | View Replies]

To: unlearner
The more specific we can be when planning and closer to existing, real-world projects in scope, the closer the estimates will be also.

Just remember, there's a cost associated with being specific. Software development--much like carpentry--is a field where "measuring twice and cutting once" often applies. In software development however, the "measuring" is the requirements-gathering, design, and probably testing. These aren't the "sexy" parts of software development, but accuracy pays off here.

Unfortunately, these up-front activities are often areas where timelines and budgets get cut the most. Customers don't want to hear that it'll take six months of planning and user meetings before any code is written. Obviously, that depends on your development methodology, but I hope you get my point.

50 posted on 04/10/2014 5:39:33 AM PDT by Lou L (Health "insurance" is NOT the same as health "care")
[ Post Reply | Private Reply | To 47 | View Replies]


Navigation: use the links below to view more comments.
first 1-5051-66 next last

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.

Free Republic
Browse · Search
General/Chat
Topics · Post Article

FreeRepublic, LLC, PO BOX 9771, FRESNO, CA 93794
FreeRepublic.com is powered by software copyright 2000-2008 John Robinson