321–324 of 324 posts
I once had a really convoluted metaphor for estimation which involved opening boxes that sometimes contained other boxes which sometimes contained other boxes... I wonder how that models mathematically.
The problem with this analogy is that the boxes do not obey the laws of physics and fit inside eachother...
Earlier quoted context omitted.
Price negotiation is not zero sum. Zero sum means one party’s gain is exactly equal to the other party’s loss. Most deals are positive sum - both parties get benefits. Price negotiation is about the seller getting some the upside of the buyer’s benefits but not so much that it sucks for the buyer and not so low a price that the seller will walk. Some deals are inherently negative sum - if you bought a lemon.
If I pay a dollar more for the same thing, I, the buyer, lose a dollar, and the seller gains a dollar. Can you explain how that's not zero-sum?
First, Not everything is a commodity with perfect substitutes, arguably most things aren’t. Substitutability goes beyond price.
Secondly, benefits are not necessarily equal or a linear function of cost.
Third, whether a game is zero, positive, or negative sum requires a look at the costs/benefits of the whole transaction. Saying that a buyer gains $1 more if the price goes up is obvious, it that doesn’t necessarily make it zero sum when you look at the overall transaction of a $1 price raise. .
Zero sum implies that price, costs and benefits are equal. I spend $20 on a product that cost you $20 to make, and I get $20 of benefits out of it.
Whereas I buy something for $20 , it cost you $5 to make, and I got benefits of $100 out of it, that’s positive sum, as both the buyer and seller got positive gain. If you raise the price, the deal isn’t as great, but it’s not zero sum.
Earlier quoted context omitted.
> They probably don’t want you to lie, but there is a small chance that they pruessure you to. In my experience, most of the time there was pressure. I remember a funny conversation between my project manager and a colleague: PM: "We need to have X as soon as possible, how long will it take you?" Dev: "Oh that's, easy, I can finish it tomorrow." PM: "Tomorrow??? That's impossible, because it needs a and b, no?" Dev:…
Remember - the pressure is to get you to work unpaid overtime under the (mistaken) belief that more hours = more software.
Earlier quoted context omitted.
I highly recommend the book "Software Estimation: Demystifying the Black Art". I work for an outsourcing company and part of my job is to come up with estimates and it helped me deal with clients and managers. The book contains a quiz that we used as part of a training exercise with management and the results were hilarious. Here is an online copy: https://scrumandkanban.co.uk/how-accurate-are-your-estimates... pleas…
Thank you for posting this - I took this quiz a few years ago in a team exercise and all of my answers were off. Since then I wanted to find a copy of this test, but didn't know where to look. I think out of 15 people nobody got more than 1 or 2 right, except for my manager, who somehow got about 8 right. I'm curious how the HN crowd does on this - care to post your scores?