Pedro Arantesrose
ArticlesContactNow

Last Mile in a Software Project

These final adjustments can have fewer tasks compared with the core, but it is the laborious part, then the time to finish it is almost as the core time implementation.
#90-90-rule
Articles, March 22, 2021 (changes)
Reading time: 5 minutes
Photo by Vidar Nordli-Mathisen on Unsplash

Photo by Vidar Nordli-Mathisen on Unsplash

We built an App recently for a researchers team about helping other researchers to keep their projects up to date. Let's call this project ProRes. There was a problem with this project: we took so much time to finish it, and the quality wasn't the best as we were used to. We were wondering about this project and others we've built at Triângulos Tecnologia and we had some insights about the issues.

The other projects aren't necessarily easier, they were as difficult as ProRes, but they took 4x less time than ProRes to be finished. The biggest difference was the order in which we executed the implementation.

In this article, we're going to try to understand better why this big difference happened. We think this problem is correlated to the last mile problem. So let's discuss a little about it.

Last Mile Problem

Telecommunications is a common field in which the last mile problem appears. It occurs when it has a whole telecommunication infrastructure available except the one that links the final client, the final leg. For instance, suppose we have an optical fiber ring in a city that provides Internet to some buildings, but neighbor buildings don't have access to the ring. This is the last mile problem because the ring is working but some clients can't access it.

We can see this problem in logistics too. A product may arrive in a capital of a country but might not arrive in neighboring cities because there isn't an easy path to there, for instance, need to cross a river.

In summary, the last mile problem is the last thing that needs to be done to something works/arrives/finishes.

Last Mile in a Software Development Context

Almost every App we build, we can see the last mile part in every implemented feature. The first part of a feature is the core. We can call core the most important and the essential functionalities that such a feature must-have. After the core is implemented, we have the final adjustments (FA) or the last mile. These adjustments don't change the functionalities, rather improve the user experience of the application. For instance, if we're building a form, the core features are the fields and the submit logic; the FA are some input masks and designs.

These final adjustments can have fewer tasks compared with the core, but it is the laborious part, then the time to finish it is almost as the core time implementation. We may explain this using the flow state. Core tasks commonly are more challenging and interesting to be done, a condition to enter the state, whilst the last mile tasks, don't. Then the FA may be the least efficient part of feature implementation.

Core and last mile development time vs the number of tasks.

Core and last mile development time vs the number of tasks.

ProRes Execution

The ProRes App had some features. The objective of the project was to validate these features. Then, since the beginning, we started implementing all the core features together. Once we've finished the core features and validate their core functionalities with the stakeholders, we've started building the final adjustments.

Core features finished. Final adjustments are unfinished.

Core features finished. Final adjustments are unfinished.

As we can see in the figure above, we have 4 core features working and the final adjustments to be done. But another big problem arose: they're dependent on each other, therefore the energy needed (ENE_N) to finish them wasn't evaluated as a linear sum of the energy of each final refining, rather we have to consider the dependency of all unfinished parts. The definition of energy in a software context might be the time or the cost of the implementation.

EN=E1+E2+E3+E4+linear+E12+E13+E124+E1234+dependencyE_N = \underbrace{E_1 + E_2 + E_3 + E_4 + \dots}_{\text{linear}} + \underbrace{E_{12} + E_{13} + E_{124} + E_{1234\dots} + \dots}_{\text{dependency}}

The number of factors of ENE_N is given by the sum of all dependencies subgroups that can be made considering nn features, that is, 2n12^n -1.

One of the reasons the dependency existence is because you need to switch between features when implementing them. Suppose you're doing feature 1's FA. At some time, you need a feature 2's FA to continue working on feature 1, so you switch your work to implement it. Working on feature 2, you also need some feature 3's FA... and so on.

90-90 Rule

This scenario is correlated to the 90-90 Rule, which states that

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." Tom Cargill, Bell Labs.

It was our case. 90% of the time was used to implement 90% of the main functionalities, while the last mile, which represents 10% of the value aggregated to the App, took another 90% of the stipulated time to be done.

Other Apps Execution

While we've implemented all core features first on ProRes, on the other Apps we finish a feature (core and final adjustments) before starting another one. In this case, we didn't need to switch between required features because they've already had been implemented.

In these cases, we didn't have to worry about the dependency energy because it didn't exist.

Features 1 and 2 finished. Working on feature 3.

Features 1 and 2 finished. Working on feature 3.

How to Overcome the Last Mile Problem?

  1. Break the project into small tasks. This is the most important action to be made to overcome the last mile problem. Once the tasks are small enough, big dependency energy among features doesn't exist - we don't have to switch between features while implementing one of them.

  2. Set aggressive deadlines. Don't worry about setting aggressive deadlines because you know that the real one is still ahead. Even if you know that you won't make the deadline, you'll make better plans and prioritizations because you don't have much time left.

Conclusion

We and the stakeholders weren't very happy with the ProRes execution. However, it was a very insightful experience that teaches us more about the importance of having an efficient development path.

As developers, maybe we'll always want to develop the coolest parts of an application and because of this, the role of a product manager (PM) is very important. Also, to manage the development time, it's far-reaching that he/she, together with the whole team and the stakeholders, plans the most effective features' sequence implementation to avoid the dependencies among all software's unfinished parts. It's also substantial the PM guarantee that one feature is being implemented at a time.

RecommendationsDo you want to see all posts instead?
The 90-90 Rule
When you finished 90% of any project, the remaining 10% will take the same amount of time of the fist 90%.
Zettelkasten, February 07, 2021
Last Mile Problem
The last thing to be done to something works/arrives/finishes.
Zettelkasten, February 06, 2021
Flow State (Psychology)
It's the most efficient state when doing a task.
Zettelkasten, January 28, 2021
Pareto Paradox
Pareto Paradox states that there are usually more opportunities in the undermanaged 80% than the overmanaged 20%.
Zettelkasten, July 02, 2021
Radical Delegation Framework
This framework helps you assign and do work that must be done.
Zettelkasten, June 09, 2021
Reading time: 2 minutes
VP of Engineering
VP of Engineering role faces inward. They're responsible for building the engineering team and establishing the engineering culture and operations.
Zettelkasten, July 23, 2021
From Reactive Planning Model to Natural Planning Model
Until some point, the project was manageable, but after some feature requests and bug reports, it became unfeasible. In addition, almost every bug fix or feature implementation broke other "uncorrelated" parts of the application. That slowed us down a lot because our client and his customers were using the software, and we had to rush to fix the new bugs (yes, we didn't have testing at that time).
Articles, June 16, 2021
Reading time: 5 minutes