Paul M. Jones

(This is an older draft I’ve had around for more than a year; rather than let it sit around while I ponder how to improve and expand it, I’m publishing it now so it can be useful in the mean time.)

Prerequisites

These are my prerequisites for building a reasonable estimate for client work. Note that this is primarily for team development of client work, not single-developer work (whether for clients or otherwise), but may be applicable in those situation as well.

1. Business and functional requirements have been discussed back-and-forth until both the client and the work team are roughly satisfied they understand the system requirements as a whole and how it helps the business. This is not a waterfall condition, where one needs to know absolutely everything in advance; it is more like meeting-of-the-minds to make sure both the client and the work team believe they understand the business needs, how well the parties feel they can work together, and a moderately-detailed idea of how the resulting system will fulfill the business needs.

2. For each sub-portion of the project to be estimated, the design team has put together a reasonable facsimile of the site as bare-bones wireframes. It is much better if the entire project is wireframed first, even though we know the requirements will change. As Eisenhower said, “Plans are nothing, but planning is everything.” This will give the client an idea of the scope of what he is asking for, and make it more concrete in everyone’s mind what the end-goal will look like.

   In addition, the wireframes help to ascertain that both the client and the work team have an agreed-upon picture of what the final product ought to look like; without this, it’s too easy for the client and the work team to think they understand each other when in fact they do not. Seeing the wireframes and how they fit together will illuminate inconsistencies, imperfections, and misunderstandings; these can be resolved well before development begins.

3. Schemas (whether SQL or no-SQL) for the data models, as derived from the requirements and wireframes, are complete to a first approximation.

As you can see, I do not do estimates based on general narrative descriptions. I do them based on the wireframed feature sets. No wireframes, no estimations. This generally means the “discovery” period needs to be billed separately from the “development” period.

Two Workers, One Day Per Controller Method

Once the prerequisites are in place, I can build an estimate. For each page of the wireframes, or each substantial portion thereof, I estimate the project as a whole will take an average of one work day for two workers to complete. (Some pages will take less than a day, but some will take more.) Phrased another way, I usually estimate a project to take two workers one day for each page-controller method.

I arrived at this rule-of-thumb by looking at several past projects and dividing the actual calendar time by the number of controller methods in each project. It has proved a reliable guide ever since I started using it. One nice thing is that it takes into account all the real things that happen to cause delays; the natural optimism of developers and and their tendency to ignore the possibility of unexpected negative events is thereby removed.

To illustrate this, let’s say one component of the project ends up needing to browse, read, edit, add, and delete (BREAD) elements of a particular data model. Those would normally translate into five separate pages, or five separate methods in a page controller. (Even if they are AJAX-enabled portions of the same page, they would still be very likely to be separate method in a page controller.) My default position is that it will take two workers five days to complete that component for a client.

Two Workers?

The pair of workers are a mixed set composed of a primary PHP developer, and a secondary or support worker. The mix might change on a daily basis, and is certain to change at different times in the project for long projects. The mix could be be two PHP developers; or a PHP developer and a UI/UX developer; or a PHP developer and a system architect; or a PHP developer and a DBA.

As such, note that a worker-pair is not the same thing as Agile paired-programming. The worker-pair terminology is for determining the cost of development; the per-day terminology is for determining the calendar schedule for development.

I think the idea of the worker-pair accurately reflects the day-to-day reality of team development. Graphic design can proceed concurrently; as such, it may not affect the calendar schedule, but it certainly can affect the budget.

One Day Per Controller Method?

A whole day per controller method? Even though it includes all the pieces needed for that method, such as the views, model methods, and other support methods, it sounds really unrealistic. Any developer worth his salt can knock out an entire BREAD controller in half a day easy, right?

Perhaps if he’s working on his own project, to his fulfill his own needs. But when he’s working on a project for someone else, and has to coordinate his activities with a team, production velocity decreases predictably. This is because of the volume and frequency of communication that needs to occur to impart understanding.

Here are some scenarios for consideration:

1. An individual developer working on his own project for his own reasons. He understands his own project, he doesn’t need to communicate with anyone else about the need for changes, or explain those modifications, or anything else. All those conversations happen inside his own skull, so latency is very low, even for unskilled developers.

2. A developer working on a team, for that team’s own shared reasons. Communication latency is necessarily higher, since there is more than one developer, but all the team members are (in theory) very familiar with what they want to build, and are in constant short feedback loops.

3. An individual developer working on a project, for a client he communicates with directly. This is the first point at which we see productivity drop off. The developer now needs to coordinate his development with the wishes, desires, and requirements of an external client whose business he probably does not participate in. The time needed to perform this communication is too often neglected when scheduling; developers often think this time “doesn’t count” when building a calendar estimate. The amount of time doing only the development on a controller method may be only an hour, but when communications are factored in, it takes longer.

4. A developer working on a team, for a client he will rarely communicate with directly. This is the second point at which productivity drops off. Now the developer must communicate with an intermediary about the system requirements. That other person may be a developer senior to him, a system architect, or a project manager. In addition, the developer is likely to be working with at least one other developer to perform his tasks. The added communication delays factor in here as well.

Conclusion

Once I have the core estimate in place, it becomes possible to determine other portions of the project, especially things like setup overhead and deployment risks.