Better time estimation in software engineering

During time of software development, there should be some points this thought hovering around our mind: “If I’ve got one more week (or month), this project would be in much better shape”. It probably is a more friendly and easier-to-use UI, a cleaner set of APIs, or more readable and maintainable codebase. In general, we usually fall into the lack-of-time situation. Sometimes, we estimated too little time for the work, but on other occasions, we gave more room than it needed for a project and still missed the deadline.

The reason varies. It might be a wrong prediction on the scale and technical complexity, or the productivity of individuals derives from the expectation. Sometimes it’s just Parkinson’s Law: “Work expands so as to fill the time available for its completion”. No matter the reason, it happening means there’s some issue with planning activities in the development process. This writing discusses the planning phase in software engineering: Why time estimation is important and how to get better at it.

Why time estimation is important in software engineering

The answer is simple: Software estimate and planning is the map for the development process. Good estimation results in reasonable deadlines, which make everyone life easier. A casual and unrealistic estimation is normally wrong as work progresses, resulting in breaking both schedule and budget.

Why it’s so easy to get it wrong

There are dozens of reasons why time estimation can go wrong. Most of the time, it’s the result of inexperience or lack of knowledge on some certain domains.

1. We not carefully spend time for estimating instead of putting it into real work. Time estimation is also a development activity, and it can take up to 5–10% of the total time. If not careful, we might use those time into pointless planning and get nothing back.
2. Estimation is temporary and subject to change, especially in the early stage of development. There’re always many unknown factors that are only visible once we’re deep into the work.
3. Planning and deadlines are also error-prone due to unforeseeable situations like change of requirement, incidents, or human resource adjustment. It’s really difficult to put these things into account during the planning phase.

Planning and time estimation on project level

We should make sure that everyone understands what’s expected from the project. Knowing what to do and what the project should look like at the end will help greatly on estimating time to deliver “enough” results: We don’t want to return a malfunction, not-meeting requirement result, but we don’t want to overkill by putting in too much effort than it should be either.

1. Break down the estimation into smaller pieces.
   - The more details the planning is, the easier to label a time span to each item. For example, “Having a social media feature on the platform” would be ambiguous and thus, difficult to estimate. More detailed like “A user sign in/out system”, “a newsfeed displayer”, “follow/unfollow functionalities” would give everyone better ideas on what’s the specific job to do, hence better estimation on how much time necessary for them.
   - Another benefit is that it helps assign the estimation to the correct person with proper expertises. Let’s say we’re working the item: “Analyse 3 solutions and implement one for our system”. Apparently, it’s easier to split it and let the benchmark-oriented engineer gives estimation for the “analyse” part, while development-oriented engineer suggests the time for implementation.
   - The breaking down process should be realistic. In fact, make a complete diagram of required components alongside with their estimation. The diagram should be expandable if new requirements or new components are discovered.
2. Knowing who and how they should be involved into planning process would help. As mentioned above, each party will give better ideas on the time they need to do their work, as well as the potential risks to the development process. In general, having all parties (not necessarily everyone) is useful in creating overview estimation, or a roadmap in bigger scale.
3. It’s important to keep the planning up to some certain level of flexibility. In fact, make it with the assumption that the plan/estimation will change. There’re some ways doing it such as adding buffer time, building a parametric model before estimation, employing agile methodology, etc. No matter how we make the estimation, we should revise it regularly to keep it in the most up-to-date shape.

How to do better at time estimation as a software engineer

Here’s the paradox of estimation: Persons who are most capable to make predictions are the least interested in doing so. There’s a quite number of software engineers who are only interested in coding and building stuff, and would avoid doing the planning and other administrative works if possible. Time estimation might not appear as an important engineer-engineering skill, but in fact it’s crucial if one wants to grow into a better engineer. Good practice of doing so would help to embrace the ability of collaboration, understanding system, sense of ownership, and many other benefits.

Here are some things to keep in mind to keep a good practices on time estimation

• Think about non-coding time. Development is not only about programming, since there are many other activities that we should take into account when estimating time. Analysis, experiment, design, testing also matter!
• Always overestimate and give a bit of buffer time for your estimation. Having nothing to do is better than missing deadlines and blocking other people’s work.
• It’ll take time for you to ramp up to 100% productivity. Your ability to work is not constant, and it always takes some more time switching between tasks.
• Reconcile when the estimation doesn’t match the reality. It’s a good practice to check if we’re up to speed once in a while during development time. The adjustment, if there is, is better made sooner than later. However, sometimes we can’t do much about the wrong estimation, so the best way is making better estimation next time.

After all, there’s no exact science on how to estimate time for your project better. The sense of estimation normally develops alongside with your experience and your knowledge about certain domains.

Thank you for reading!