dpenguin

There are a lot of arguments about how DoH with TLS 1.3 will give us privacy etc by the proponents of DoH(not this article).. but it’s basically moving the trust from ISPs to CDNs. There are fewer major browsers and fewer major CDNs than ISPs, I suppose.. so not sure if it’s a good move.

It was not a counter argument to anything per se. Just pointing out that even with episodes of failed estimates, there is reason to continue estimating.

Just woke up. Totally agree with this article, even though it was published 4 hours ago in the early hours of the morning!

Got it. Better to stick to tried and tested “boring” stuff and actually code small functionality yourself than chasing a thousand line library for trivial stuff.

At work, someone used a 3rd party library to send stats to a server in json format and “standardized” on it. 100s of developers had to now learn this new library and it’s APIs and one bug caused everyone a bit of hassle. It probably made the original dev’s job just a little easy but made it a bit hard for everyone else. These things do happen. The point is to learn from this and make better decisions over time, not give up and say we can’t get better. Trying to provide an estimate forces you to think more carefully and become better over time.

Would you say SpaceX launch is novel? Did they do it on schedule?

Software is not rocket science. Rocket science is not rocket science.

That’s cheating. No, that’s not what happened in that org though.

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.

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.

Ah! xml.js

Code organization (part of Architecture) matters a lot here. Especially in large code bases. Software is meant to be “soft” or pliable easily. To do that, one should be able to alter a module without having to understand the whole system. If a small task takes too long, there’s a problem with the software architecture or code organization.

Let me clarify: when I said “they are not qualified for the job” I meant they are not qualified to produce the estimate yet. They can always go back and learn what’s needed and come back with a more educated estimate (still an estimate) or they call it out as a risk item and address it ASAP. More often than not, this is because they are not ramped up (manager’s or team lead’s fault) - why else would you ask a complete newbie, regardless of seniority, to estimate?

It could be because you are working on a brand new area every single “Sprint “(or equivalent). That’s not prudent assignment of resources(the manager should know this).

I have worked in companies where ownership is somewhat static(same few folks work on a given area of the product) and things get done within 10% of estimates (a lot of innovation too).

I have also worked in terms where ownership is fluid and “resources” get assigned to tasks. Nothing is now “estimatable”. Your experience is probably in line with the latter.

It only means you didn’t do your homework(no offense, everyone falls into this trap too and conclude the issue is that estimation itself is not possible ). You can’t give an estimate based on what the task would take at your previous job.

You need to call out what you don’t know(Now, don’t give me Rumsfeld wisdom.. Most software is not that complicated)