Mind the tosta mista effect
Why does the “simple” feature always take longer than expected? Let me tell you about the grilled cheese sandwich effect…
In Portugal, tosta mista (grilled cheese and ham sandwich) is a popular item on any café menu. Yet, it’s often the last thing to be delivered to the table, even when considering other complex items such as lattes, waffles, or pastries.
But Why? Why is it so slow, to the point of getting frustrating or even intimidating to ask for one? I have a theory: “Simple” doesn’t necessarily mean “fast.”
The croissants are already made. An espresso is almost instant. But the sandwich requires a workflow: assemble, grill, wait, retrieve. It might also be forgotten once it’s done. In sum, it has hidden dependencies.
Software engineering works the same way. That simple query parameter filter? It touches 3 distinct microservices, requires frontend changes, and probably 4 merge requests.
Having this in mind is very important. Engineers might overlook the complexity. Non-tech people tend (in my experience) to have difficulty grasping the inherent complexity (the gearshift in a car is simple, but the whole gearbox mechanism is not). Simply put:
- The “easy” API change might require coordinating three teams.
- The “quick” bug fix might expose architectural debt and require a fix before effectively doing it.
- The “simple” feature might have 5+ hidden dependencies.
But how can we avoid the “tosta mista effect”? The answer might be in timely and wise planning.
Tackling hidden dependencies
My first tip is for developers: navigate the system, the code, infrastructure, and dependencies. When you find hidden complexity, don’t be shy: double or triple your estimate.
On the other hand, if you are a product/delivery manager, you might not see the hidden complexity. You might be non-tech, but you understand the business domain and serve as “bridge” between technical and non-technical teams. Therefore, your position can be a solid solution for this problem, as a mediator, helping your team to build shared context:
- Sit everyone involved down and ask: “What actually needs to happen?”
- Sketch a crude high-level diagram together until everyone, including you, understands the involved pieces
- Have engineers walk through the affected code and assess the difficulty together. This surfaces assumptions and catches hidden dependencies early.
- When doubts arise, take notes and reconvene with the relevant team or lead
- Ask “dumb” questions (there are no dumb questions)
- Break it down into concrete tasks, with your team, together. If you do this alone, with a lead, or with a single team member, you risk not having the angle of someone who knows or works closer to the system you are aiming to modify.
- If it takes more than 45 minutes, you need a second session: pause, share notes, reconvene fresh. In my experience, after 30 minutes of meeting, teams lose their focus completely.
Don’t forget QA professionals, too. They often grasp workflows and business dynamics faster than anyone. Developers and managers should involve them early when mapping dependencies.
Ending notes
The main message of this post is that the most important thing for engineering teams is to aim for clarity. It solves not only the problem with estimations, but better yet, provides a better understanding of the systems and their dependencies. But even then, as we say in Portugal, “always respect the sea”[1]: next time someone says “this should be quick”, pause. Ask about the workflow. Mind the tosta mista effect: because good engineering teams know that simple features are never just “simple”.
[1] “Respeita sempre o mar” means both literally and figuratively that we should never underestimate something that looks calm/manageable on the surface