How much time for this feature? This may be the wrong question.

Or how do you measure a piece of string.

Hey there! I’m looking for a new gig as a fractional senior frontend or fullstack developer (15h-20h a week). I have experience building software for public transportation, employee management, cybersecurity, and a bit of IoT. Please reach out if you need some help!

It’s not easier to evaluate how long a project or a new feature will take without context. When I have a look at how much time a project will take, one of the most important thing to know is where the project is at.

You don’t need the same level of quality and robustness all the time, and it’s important to know where you are before you start coding, or if you’re the one purchasing software!

Here are some of the most common stages that will have an impact on the time it takes to complete a feature.

The prototype

When you’re building some throw-away project trying to figure out if something is possible, or need to demo a quick something to win a contract or some financing.

This doesn’t need all the fancy bells and whistle like automated testing and continuous integration since it’s going to be short-lived, and it may behave a bit weirdly in some spots. The main goal is to prove a point or get that money before moving on to the real thing.

It’s not the first step of every project, but if you’re doing something technically complex you’ll want to figure out if something is possible before it blows up in your face. No need to get all fancy before that.

You may also want to do a prototype of something in an existing project to check if a new feature idea is possible.

The MVP (minimum viable product)

A MVP is generally a real product, but at the smallest size possible to be able to release it to the market and see the reaction, show some progress to your stakeholders, or get the benefits of that application right away even if it’s not yet “done”.

It doesn’t need to be perfect yet, but since you’re planning to have real users you’ll need more plumbing code for features such as authentication, validations and security.

You’ll release that one into the world to morph into a real product at some point, but you’ll still be cutting some corners since money or time is generally tight there. A mistake is not very costly yet, and you can afford to work without a safety net in most cases.

The product

A product is something that has users and starting to have a product-market fit, so you know you’re going to keep working on it. You’re having real impact on users (or starting to), so you have to be a lot more careful about breaking things in production and migrating existing data and users.

Now that you know your app is sticking around, you’ll also need to start thinking about reusing existing code and component if your MVP was weak in this area.

Technical debt can compound quickly at that stage and you don’t want to slow down your development speed too much. Copy-pasting bits of code is cheap at first, but it can turn into a nightmare when you must start modifying all those copies.

You’ll also need to grow all the parts of a real product that you may be missing, such as testing, logging, monitoring and the like.

It’s possible to jump straight into the product, especially if you’re working for internal stakeholders: for example if you’re rewriting an old codebase or writing an application for a known business process that you’re automating, you may not need to jump throught all the previous hoops.

The legacy product

Some project are just at the end of their lifetime. It’s going to be rewriten, is not just a priority, or is pretty much mission-complete and everybody moved on to somewhere else.

This will look a lot like an MVP: since in many case the original developers are no longer there, or it’s pretty far back in their memory, it will get touched as little as possible, and a few corners are likely to be cut if a new feature is needed.

Even if it pretty much slowed down, it’s a good idea to keep allocating a bit of time to upgrading its dependancies from time to time so you don’t have a surprise security hole or have trouble deploying it someday because everything is just too old.