Hacker News Reader

Comment by muzani | Hacker News Reader

I think schedules are either Parkinson's Law (work expanding to fill time) or things too tightly scheduled and about to fall apart. The only optimum is getting the schedule accurate, which causes anxiety.

The other problem is that programming is not simply "development", it's research too. Research can be a bottomless hole, and it's also really hard to estimate how much research is needed.

For example, maybe I just want to add an icon to my social media site that says this was fact checked. That doesn't seem too hard, but it also is, and it's complex enough that it's patented by LinkedIn.

View on HN

> The other problem is that programming is not simply "development", it's research too. Research can be a bottomless hole, and it's also really hard to estimate how much research is needed.

This. As a programmer, I've never been able to successfully explain to my managers about this. It always ends up being a blame on me instead for "not properly assessing and estimating the effort".

This will continue to be a challenge because humans are simply not great at estimating. I have had success by explaining to managers that a big part of my job is to help them manage risk. In order for me to do that properly I typically need more information than is initially present so that I can give a high confidence estimate. I might say something like, "I can give you a low confidence ball park estimate right now but if you give me a few hours to research then I can greatly increase the confidence level."

After all, you know the least about a project at the beginning therefore no one should have a high degree of confidence in estimates given then.

Yeah, this was how I was trained to do it. A ballpark estimate on the spot at best is around 30% accuracy. I normally wouldn't give an estimate unless I can break it down the work into less than 4 hour chunks. Proper estimates also contribute to work done as it involves the design, but it's normal to spend a few hours doing estimation.

Trained managers are familiar with the cone of uncertainty, though.

But what I really mean is stuff on the level of powering a toaster with a car battery. It's certainly possible, but nobody has documented on what they did, and there's a very high number of uncertainties as neither were designed to perform this way.

I think you nailed it by pointing out how overlooked the research part of development is. Technical folks often understand this but it can be a challenging concept for people who have not worked as a developer. They can have a distorted view of the research to coding ratio. I imagine they often believe that writing code takes up 90% of a developer's time when in reality time spent researching and thinking is the dominant activity.

Reply on news.ycombinator.com