How a Web Developer Estimates Completion Time

It’s common for software developers to underestimate the time it takes to create a new feature. It’s one of the realities of software development.

In this post, I’ll explain how a developer typically estimates a project, to help merchants understand the process.

Developing a Reorder Button

Let’s assume I’m going to develop a reorder button for an ecommerce store. This button will let customers reorder a product based on their previous orders. The goal is to encourage repeat orders by using the historical order data on hand.

Design new button. The first and most visible task is to create a new button on the product page. We could start with the existing add-to-cart button, but we’ll need to make a couple of changes to it.

• Move it outside of the add-to-cart HTML form and into its own form.
• Style it so it’s not as visually distinctive as the existing “Add to Cart” button.

Logged-in customers, only. Since this button only applies to returning customers, we need to add some logic that hides it from everyone else.

Most ecommerce systems have code to detect if someone is logged in. So we’ll need to find that code and use it with our reorder button.

Customers who have purchased the product. We also want to show the button only to customers that have purchased this product. We’ll need to access their orders and line items.

This will probably require a few queries to the database to get all of the data we need.

We’ll also need to check the performance of those queries because the load time of product pages is critical. That means we might need to add development time for performance optimization.

Connect the button to the server. Now that we know who will see the button, we need to connect it to the server so it actually does something when clicked.

First, we’ll need to wrap the button in a HTML form. We’ll also need to embed the product ID in a hidden field so the server knows which product the customer is looking at.

We’ll also need a URL created on the server for this form — an endpoint. Depending on the ecommerce system, that could be easy or difficult. In Ruby on Rails for example, we’d need to add a route for the URL and a controller to hold the server logic.

With the form, hidden data, URL, and an area to hold the server logic, we have connected the button to the server. But it still doesn’t do anything.

Find product in previous orders. With the front-end development complete, now we can focus on the backend and the actual goal of the button.

First, we’ll use the product ID that was sent with the form and look for that product in the customer’s orders. To do that, we’ll access the database and find the product we need. Since we did a similar version of this already —embedding the product ID so the server knows which product the customer is viewing — we should be able to use those same queries but with a few minor tweaks to find the product line item in an order.

Once we have the line item, we can copy it to the cart along with any options or sizes the customer ordered.

Redirect user to the cart. Finally, now that the product has been added to the cart we’ll want to redirect the customer to her cart page, to checkout.

Test everything. During the entire development, we’ll also need to test functionality as we go — at the very least some basic testing for each step.

Getting the code live. As the final step, all of this code needs to get onto the web server. Sometimes this is easy and just takes a few minutes. Other times, for large projects, there are weeks of scheduling, delays, and unforeseen additional tasks.

Many developers miss this part in their estimates. They call a feature “done” even when it’s not on the actual site.

More Complex Than It Appears

What might be surprising to non-developers is the complexity of implementing a reorder button, a small feature.

It is seemingly simple, but it required graphic design, front-end logic, HTML forms, database queries, and backend changes.

This is why a lot of software features feel like they take longer than they should. They’re like icebergs. The visible part is small but there’s a huge amount of work needed underneath the surface.

A good developer will go through this process and provide estimates that include everything. A mediocre developer will overlook tasks and might only estimate the time to simply place the button on the page. The actual functionality work could take four times as long.

And the steps that I’ve described above don’t cover it all. Having quickly thought about it, I realize there are additional questions that will need to be answered before development can start, which could increase the estimate.

• What if there are multiple orders with that product? Should we use the most recent? Or should we have a pop-up asking the customer to choose one?

• What if the customer wants to reorder but with a different option or variant? Can he change it in the cart or will he have to remove the one we added and then add the new one? Does that even save time over the regular add-to-cart button?

• Would it make more sense to simply tell customers what they ordered last time and let them pick the option this time — reorder or new purchase? (That’s what Amazon does.)

• What if first version of the button design and layout doesn’t look right? Should the developer changed it?

Each of these questions reveals an assumption, an area that might be a potential miscommunication, or something that might need to be discussed. Each can affect the estimate.

A Difficult Process

In short, estimating development time is difficult. Many projects appear simple but are, in fact, complicated.

Merchants should ask many questions before they launch a new development project. Ask the developer for details or clarification on anything that sounds vague. It could extend the time to assemble an estimate, but the estimate would be more accurate, and realistic

Which would you rather have: An project estimate of 40 hours that actually takes 40 hours, or an estimate of 10 hours that takes 40? The first you can plan for. The second screws everything up.