estimating a programming job

estimating a programming job

The hardest task in the computer business is estimating the time it takes to create a finished, working program. It always takes longer and sometimes seems to take forever.

An Unusually Optimistic Bunch
Programmers are often extremely optimistic. Unless they have written a very similar program before with the same programming tools, the new job inevitably takes longer. Application design is creative work. No matter how much a program is defined on paper, as soon as it starts to take shape, the design flaws become evident. It simply takes multiple iterations to get the design right.

Feature Creep Is Inevitable
Add feature creep, which is the continual adding of new functions to the end product before it has been completed (everybody does this), and you can see why estimating is difficult. Over the years, some estimates have been preposterous. What was thought would take a couple weeks takes a year. A one year job takes six.

Users Must Be Involved
In order to improve estimating accuracy, the functional requirements and user interfaces must be as carefully designed as possible before the programming begins. The programmers must be experienced, and the users must be involved in the project from the beginning and along the way.

The Mythical Man-Month
In 1975, IBM's Fred Brooks hit the nail on the head why programming projects take longer than expected in his book "The Mythical Man-Month." More than 30 years later, it still holds true. Adding more people to a programming job can slow the project rather than speed it up. Each additional programmer means more time communicating responsibilities, technical details and progress (see Brook's law). See to the recruiter.