[quickthrower2]

Let’s say the code base is 1M Loc written by 230 engineers over 20 years. No docs. The epic is to make the whole thing support internationalization. That’s hard to estimate.

That’s a more typical requirement. A system that is built in nice incremental steps eg add an api and can be for its life sounds like a dream.

[dpenguin]

Looks like tech debt to me.

It’s understandably a big project. But you can still start breaking it down, correct?

Break it down by services first. Then do estimates for say 2 services to get an idea of what it takes to estimate the whole thing. Part of the process is also to communicate the cost to business so that they can see if the feature is worth it or not. (Read “Shape Up” by 37signals on this. Free ebook but you get way more than what you pay).

Can’t comment too much without knowing your codebase but it is engineering. Most tasks are not supposed to be this hard. If they are, then it’s time to start paying back tech debt so you have things under control again.

[Olreich]

Tech debt is something that the engineers left undone because of pressure to finish quicker. The example above is not that. It's the fundamental assumptions getting changed mid-project.

The big system was designed with the assumption of single-locale users. This let them move faster, and make the system faster. It could mean schema changes, business process changes, and making hot paths in the code slow in a way that users will not tolerate.

Each service might have it's own level of integration with the single-locale, accounting might be 10 weeks of work, UI 5 weeks, and data processing 1 week. If you pick the wrong system to estimate against, you can easily be off by a factor of 10.

Estimates are definitely doable, but take a lot of time and expertise to do well, not just programming skill, but deep knowledge of the affected systems. An engineer can only estimate accurately for the pieces that they fully understand, and they can only estimate how long it would take them to do it, as the things they have context for aren't very likely to overlap well with other team members.

A dev that's been around for 3 years is likely to estimate lower than someone who's in their first year for many systems. But that thing the new guy implemented from scratch and the 3 year dev hasn't ever touched? Changing that will take much less time for the new guy. (all of this is on average, some people are better at holding context than others)

[bdefore]

The book you refer advocates a concept of 'apetite' rather than estimation: "Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend?"

[dpenguin]

Yeah. The reason I mentioned it is to highlight that the business often needs to know what something will roughly cost and cannot just headfirst five into it. Estimation is a form of communication that addresses this.