Same way that throughput and latency is different. You can use it to predict what the team can deliver in a quarter for example. But difficult to give ETAs to individual stakeholders.
if you are at a point where you employ such a factory throughput thinking for information workers then you're misusing information workers in my opinion. Focusing on a throughput metric is just as nonsensical as focusing on how many lines of code somebody creates, in fact, it's really astonishingly similar in how nonsensical it is. Bug reports, issues and features are not just lumps of coal that you need somebody with a pickaxe to beat it with. If you are treating employees like cogs then they will mold themselves to be empty, unthinking cogs. They will not think of outside solutions anymore, they will not care anymore, they will just take the next issue and beat it as ordered.
In my opinion it could even be seen as the biggest red flag of a team when they start using story points. It fundamentally means that this team started to measure their work in terms of raw issue throughput instead of real value. It may work for a while. Maybe your managers are just so awesome that all the issues they create are perfect and great for the business and you never have to think for yourself at all. But inevitably there will come a point where the company would be better off if everyone was using their full potential but by that point you are stuck with a bunch of cogs that you have molded into cogs over years.
ah, we are not using it as a measure of teams performance, like throughput though. Its just used to predict what the team can deliver in a sprint or a quarter etc and make business decisions based on that.
That is kinda the same thing. With story, it’s either we roughly know how to do it or we need to do some research. In te first case, estimates will be wrong because of edge cases and contextual differences.
Businesses decisions should be based on things like feature requests from customers, not the amount of “points“ a team can get done.
It’s extremely useful for a business to have a rough idea of when they’ll be able to deliver something. Budgets, contracts, client relationships, marketing, etc are affected by it.
So should Engineering give a best effort to estimate that, or just throw up their hands and say “it’s done when it’s done”?
Counterpoint: it's extremely useful for the Trisolarans to know when their next stable period will be, but that doesn't make it reasonable to demand an estimate and factor it into a contract unless you're really really clear about the uncertainty in the estimate.
Yes, we should all live in reality and use our best judgement. If estimating based on story point velocity is literally useless, then no one should be doing it. However if it does help make planning more accurate, even by a little, then it might be worth the cost of doing so. It’s a conversation to be had between different functions, hopefully based on empirical evidence.
I feel like a lot of engineers overlook that there’s more to a viable business than just producing high-quality software. People don’t ask for estimates just to annoy developers.
> People don’t ask for estimates just to annoy developers.
No, I know, there's just a systemic difficulty with scheduling dev items that are difficult to estimate.
My team is currently working on performance improvements for a certain service in order to get it to a level that our biggest client is happy with. Based on some profiling and some intuition, I built some Jira cards with rough ideas of what changes might make some improvements and added some rough estimates of how long it would take to trial each idea. Of course, what's actually happening is that we try one idea, it counter-intuitively makes performance worse, we dig into why that's the case and refine the idea, then try a different version of it. It's fundamentally impossible to give an estimate for when we will have run through all the ideas (plus new ones we think up along the way) and how much of an improvement it will make.
I just came out of a slightly painful standup where the dev manager repeatedly asked "Is this doable by mid-August?", and I repeatedly answered that it's not possible to give such an accurate estimate, that we would do what we can in that time and hope to give a better idea of what's possible by the end of this month. Of course it's not great for the dev manager to hear, because they have a client who needs to know how quickly they can scale up their use of the service. There's a conflict between what we can possibly know and what the client "needs" to know. I wish that I knew how to resolve it. It feels wrong to agree to deliver something with such a level of uncertainty, since it just leads to a ridiculous amount of pressure like this.
That’s all fair. It’s an inherently difficult problem. In a healthy organization, leadership is aware of this, has reasonable expectations and factors in the risk. Unfortunately not all organizations are mature in this way.
They need to use an input device like a mouse to disable bluetooth. Which they are about to not be able to use. But when they are seeing the message they are still using it.
Why the set of developers is considered centralised? I can write an implementation according to the specification and have no relationship with developers of another implementation.
My understanding is that the specification changes over time, and if your implementation doesn't match the central one, then the rest of the network stops interacting with you. That is: there is a massive network effect of people using github.com/bitcoin/bitcoin as canon, and there is a central group of devs with write-access there. While you can fork it, unless the rest of the network gets in on it, you've just created some altcoin that nobody cares about.
Maybe you can, but have you? Has anyone? Are there any nodes on the bitcoin network not running the same code written by the same handful of people?
Also, saying that "all you have to do to participate in this new trustless economy is to read the spec and implement your own validation node and client, and maintain it as the protocol changes" is a pretty different promise than "just download this app".
What exactly is multitasking? I am a software developer. I listen to music while I work. Is that multitasking? If I pick up a different issue to work on while I wait for code review on another, is that multitasking?
