|
|
|
|
|
|
by dpenguin
2193 days ago
|
|
|
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. |
|
|
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)