How do you figure out how long a project in a new area "should" take?
Posted by splash_hazard@reddit | ExperiencedDevs | View on Reddit | 24 comments
By new area I mean a problem domain I (and everybody I work with) have no experience in. I have no idea how to reasonably evaluate myself. I ended up spending over two weeks to iterate on solutions, test and figure out what was even technically possible, develop a vocabulary for concepts, find the ideal human facing output format etc and the end result is ~300 lines of code. Now that I know the approach that works I could easily reproduce it in a day. So why did it take me so long to get here?
What are your strategies for evaluating your effectiveness in the initial research and exploratory phase? I desperately need this to go faster but I have no learnings for myself other than "be smarter".
HosseinKakavand@reddit
Exploration expands time. Separate discovery from delivery. Timebox spikes, capture options and risks, build a walking skeleton, then estimate the remaining work after the spike. Track learning debt and artifacts produced, not lines of code. Next time reuse your checklist to compress ramp.
We’re experimenting with a backend infra builder, think Loveable for infra. In the prototype, you can: describe your app → get a recommended stack + Terraform, and managed infra. Would appreciate feedback (even the harsh stuff) https://reliable.luthersystemsapp.com
TheDevDex@reddit
Congrats. You payed the discovery tax.
Over time you’ll build instincts for how messy a domain “feels” at the start and budget accordingly.
splash_hazard@reddit (OP)
It was budgeted for me. Once I identified the solution it was easy, so now the feedback I get is that I should have been able to identify the solution 10x faster. I don't know how to go faster or how to justify how long it took since clearly it's theoretically possible to come up with it on the first try?
Key-Life1874@reddit
You don't know what you don't know. In theory Einstein could have discovered the theory of relativity in 5 minutes.
The speed at which someone can find a solution to a problem is a direct function of the experience that someone has with that problem. You said yourself no one has experience or knowledge of the domain you were exploring.
The only thing you could have done is give yourself a fixed amount of time to learn and provide an update on your capacity to deliver on time before working on a solution.
That way management can make an informed decision on giving you more time or throw money at the problem and hire someone more experienced with the domain.
Managing expectations on delivery is as if not more important than actually delivering.
Drugbird@reddit
There's no substitute for learning the domain, and figuring out what the correct approach is.
Your productivity is not the amount of lines of code you write. Measuring productivity is in general a very difficult process. On my most productive days I write +2 and -600 lines of code.
For a new domain you'll always have difficulties starting up. Estimating how long tasks should take is already a very difficult art, but I wouldn't even attempt it for a domain I'm not familiar with.
splash_hazard@reddit (OP)
Well, having difficulty is not an option. I got this challenge with basically "we need this to be clear, we don't know what that looks like, and we have three days." Now the whole project is two weeks behind and it's my fault.
I'm honestly not sure anyone else here could have done it, but I don't know how to defend against the assertion that I could have gotten it done on time if I'd been better at my job. My next "unknown domain" has to be as fast as if I am already an expert in it.
Drugbird@reddit
I recommend pushing back at the unreasonable deadlines. In general, effort estimations should be made by the developers (aka you). If they're not made by the developers, then any delays with respect to some deadline is much more the fault of whoever set the deadline.
Try and figure out where the deadline is coming from, and see if you can push it upwards. Also, find the one responsible for the deadline and make him/her consult with the developers before committing to any deadlines in the future.
splash_hazard@reddit (OP)
The deadline came from someone asking AI how hard it was. I think it's very silly but that doesn't stop me from catching all the blame for it.
dlm2137@reddit
YOU need to stop them from blaming you.
When they tell you it needs to happen in 3 days, you need to tell them that is not a reasonable deadline, and that you need time for discovery work before we can even come up with an estimate for implementation.
When they tell you the estimate came from AI, you need to tell them, that is a stupid way to come up with estimates.
You need to call them out on their bullshit or else you will just be a doormat.
shootersf@reddit
Ask what kinda of AI algorithm they chose to determine it and what weights and values they used. Maybe it needs to be reconfigured.
Drugbird@reddit
So there's no commitment made to e.g. a customer? Then push back against that hard.
flavius-as@reddit
Break it down in small steps and fail fast at bogus steps.
Optimize for failing fast so that you almost skip steps which would be a waste of time.
opideron@reddit
Failing fast is everything.
The reason why the OP even has a question is that most worthwhile projects have a lot of unknowns. As my Dad taught me, "If it were easy, it would already be done." Therefore you need to work on Proof-of-Concept on every unknown. I've been doing this for years, and every once in a while, it results in a project being scrapped because it's not doable. In one notable case, the company had entered into a contract with a API provider for a specific kind of data. I got the Jira, did a half a day of investigation, and proved that the API didn't have the data we needed. Project was immediately canceled.
Main-Drag-4975@reddit
Good work. A lesser dev might’ve dragged that one out for months!
splash_hazard@reddit (OP)
Do you have suggestions for how to do this when (effectively) designing a UI? I spent a couple days with a notebook trying to figure out representations that were clear and unambiguous and this whole project, with all the unknowns, had three days initially budgeted for it. I need to learn how to have found my final solution in a couple hours instead.
greensodacan@reddit
Reach for a component library, that will help minimize the "UI" part, and leave the UX, which is an iterative process by nature.
splash_hazard@reddit (OP)
To be clear, it's not actually UI. It's a complex system that I needed to simplify to a graph of nodes that is accurate while being as succinct as possible. On the order of 200+ nodes that I needed to develop a graph algorithm to simplify down to 20 without losing any information. That's what I meant by UI, finding the right simplification approach so we have something we can then realistically figure out how to render.
aviboy2006@reddit
One thing you accept no matter how much research you do you will always have iteration and changes as you move forward. You only realize certain things in the journey, and that’s absolutely fine. Understand the big picture first, then break it into tiny steps. Example: how many APIs do we need? How many screens? Any background jobs or async stuff? Even if these are rough guesses, they give you a shape of the work. Second, timebox your research. Don’t try to explore the entire unknown space at once. Give yourself 1–2 days to spike an idea, test it, and then decide if it’s worth continuing or throwing away. Those throwaway spikes feel like wasted time but they are actually the cost of learning. Third, track outcomes, not just hours. Ask? “What did I learn that I didn’t know yesterday?” If the answer is something concrete like a working API call, or confirming an approach won’t work that’s progress.
Last, accept that projects in new domains always feel slow at the start. Once you have climbed the hill, it’s easy to look back and say “oh that was just 300 lines of code.” But the time wasn’t for writing code. it was for building the map so you could write the right code. Enjoy journey.
nicocope@reddit
It really depends on the organisation you are working for and the context.
For example, If the organisation is not malevolent in feedback, you could plan a small PoC with the fundamental parts of the project.
If the organization is malevolent in feedback, you have to spend lots of time in planning ahead and probably you'll not be so fast.
Context is a completely different topic also.
drnullpointer@reddit
Hi. Figuring out how long a novel project should take is difficult at best.
Here is what I do:
* I break the project into parts that I know and parts I do not,
* I estimate each part separately,
* for parts that I do not know, I try to estimate how much it would take for me to learn and then do it,
* I try to use similar projects in the past as a guide (compare it to similarly new and similarly complex things I did)
* for parts with most unknowns, I will try to reduce risks by first completing some PoCs so that I have at least some knowledge before actually starting the project. Usually, I will try to delay creating estimates until I have PoCs for the most risky parts already completed.
Hundredth1diot@reddit
All good solutions look obvious in hindsight.
I have an experienced engineer working on a project like this, with a bunch of candidate tech he has no experience in (this is normal, everything changes). He's two weeks in, and doesn't have it working yet.
We've had a few chats over this period where he updates me on progress, I throw things at his strawmen, he expresses frustration with all the time he feels he's wasted, I provide reassurance and hope.
This is what a supportive, collaborative, trust-based discovery process looks like to me. It's my favourite part of the job, talented people wrestling with tricky problems.
Is it possible you work for arseholes?
dash_bro@reddit
What my EM and I generally lead with is a discovery phase. We try to structure a project around this with stakeholders, such that at the end of the discovery phase is when we have a better strategic idea of time it needs to be built out.
Then the problem only becomes scoping out how much time discovery is going to take - we generally spend a day to a work week brainstorming and getting the product expectation details right, and pick two or three most reasonable ways to get the functionality out. Add a 30% tax on top of this and you have a discovery timeline.
The whole idea during discovery is to fail fast with as little resources and dependability as possible.
The whole thing is designed for quick brainstorming and rapid iterations. This is where we heavily spend time iterating and building out MVPs with extremely loose constraints to see what works. This is also where most of the AI generated slop is put to use, while we develop and iterate on building/structuring just PRDs.
eg.:
Ofcourse, all this is predicated heavily on gut feeling.
roynoise@reddit
When you find out let me know. Had a conversation today and wish I could have said something like "bro, I don't think either of us know what you're even talking about"
LogicalPerformer7637@reddit
I experienced this about a year ago. Integration to new system, lacking documentation (poor quality, need to ask someone to send me a copy as I had no access), unstable integration environment, unknown processes.
Normally work for few weeks including testing. Given issues above, I have estimated three months.
Simply go by gut feeling and inflate the estimate a lot.