Effective method of estimation when dealing with large code bases

Question

Got a largish legacy Java code base at my hands:

• ~100k LoC
• ~1100 classes
• monolithic and cohesive (no "modules" or so)
• many OOP abstraction layers
• almost no comments, etc.

The task is to produce time estimations (in the end the viability) of numerous new requested features. Some of these apparently go really deep into.

My approach was to get familiar with the code base a bit and then try to break down the obvious required changes to tasks. However, there are still huge parts left to estimate somehow.

It starts feeling like I've spent too much time on this already and still, I can't estimate more without going so deep that it feels like almost coding the thing.

---

Is there an effective method for this kind of estimations? Spending many days on analyzing just to produce really rough estimations seems odd.

Answer 1

Assuming you're talking about story point estimation, it would be preferable to simply over-point the stories if there are a large number of unknowns. It's impossible for you to fully understand a code base in just a few days. Some of these features might require heavy refactoring and that might not even be obvious until you've started working the ticket.

I wouldn't spend too much more time looking at the code base since as you've suggested you'd just be wasting time analyzing. If you start with the smaller tickets first your margin of error for your estimations isn't going to be as large, and it will also give you an opportunity to start to understand the code more, which in theory should make your future estimations more accurate.

The most effective method for estimations is having multiple people provide input (e.g. planning poker). This helps make up for areas you may have either misunderstood or hadn't taken into consideration. If you're the only person responsible for the estimating then don't take it too seriously -- the estimation should be an approximate timebox and nothing more.

If your estimate takes into account the rough scope, unknowns, complexities, etc. then it is a valid estimate. It may not be accurate, but again, it's just an estimate. My advice would be to under promise and over deliver. Setting the bar too high will cause unnecessary stress down the road when you inevitably run into some difficult roadblocks in the code.

EDIT: There are a couple things I neglected to mention with regards to how the estimations are presented. I don't know what your situation is so these may not apply.

If you know there is going to be a large margin of error in your estimations then don't try and hide that fact, being transparent up front keeps everyone on the same page and helps prevent surprises later on. Likewise, if you say a feature will take 1-3 weeks but the response suggests the other party only heard "1 week", be sure to make it clear that it is an approximation and that there should be no expectations regarding a specific amount of time.

Finally, if you are able to, re-evaluate your estimations as the project goes on if you feel your original estimations turned out to be inaccurate. Be careful not to be too eager to cut down your estimations, it's very tempting to be overconfident once you get started ("you don't know what you don't know"). It's more important to know if the time needed for the project is going to be extended rather than shortened.

Answer 2

I strongly disagree with the selected answer.

Your question is equivalent to asking what kind of surgery to do just by visually looking at the belly. By providing an answer in such conditions you are saying that by visually looking at the belly you know what's the illness and what surgery to do. It doesn't work that way.

The previous answer just suggests asking more doctors to look at the belly.

From another point of view, the client has a BIG problem in its hands. A horrible code that does something, but that's very difficult to maintain. That's their problem, not yours. That's the normal consequence of saving pennies the moment they were required.

First, there are two approaches when engaging software professionals: either the client pays for time (and accepts the results even if they are not finished after the time has finished) or the client pays for a product (regardless of the time). Of course, a good developer would deliver a good product in an optimal amount of time.

In this case, the client wants the product. But the constraints to develop such product are unknown, and will only be known after the proper examination. Therefore, there are two things to charge for: the proper examination (going further than just looking at the belly, take some x-rays, blood/urine analysis, whatever), and the actual surgery.

So, you are doing for free, within improper conditions, what you should do as part of a comprehensive and proper work. You are denying the BIG problem that the client has within its hands, and if you "don't take it too seriously", you will assume the final responsibilities.

What I would do is to budget a first period of work, where you would test the actual codebase and prepare a proof of concept of implementation of the requirements (after the first phase).

Then, with the best confidence (of course, will never be of 100%), you can then present a plan and budget for the actual functional implementation. The second phase is easy: just coding what you need.

Regarding how to approach the actual technical task, I've experienced this kind of situations. In this case, for small-medium -sized apps, the first phase, my approach was always to recognize (sometimes delete) the code unrelated to the functionality and keep the codebase working. Then, find all the necessary endpoints which the new functionality must interact with. The second phase implies just working.

To the person who wrote the selected answer: I would never engage you, if your philosophy regarding my code is "don't take it too seriously". That's a horrible approach of this beautiful discipline and a lack of respect to all clients. I don't know you, this is not personal. Please think on that.