"No, it's less effort than that"
301–310 of 388 posts
Re: "No, it's less effort than that"
#302It's more Machiavellian than that. What the middleman wants is a heads I win, tails you lose deal. He wants to present a low number, to encourage whoever he's dealing with on his end to do what he wants, gaining the benefit from that. So he'll use every technique under the sun to encourage devs to give him a number he likes more, while never making it look like an order or coercion (which would make it his number - s…
Sometimes, but not always. I've been on both sides of this situation. As an engineer I'm always adamant - yep, no way this could be done any faster and please stop pressuring me to just get the number you want to hear. It'll be done when it's done, and it'll be robust and good. Now please go away and let me cook. But when I've been the manager pushing for smaller estimates, it's been because the business realities we…
What's unreasonable is saying "we need X in Y weeks, and it needs to be done properly". It will take a certain amount of time to do anything properly, and that doesn't change with pressure.
Re: "No, it's less effort than that"
#303Earlier quoted context omitted.
Yeah, the 30 minute tasks would more frequently be quick if there was room for them . You can have agile flexibility or you can have lists of tasks that you have attempted to minmax that people are tracked to finish. Not both. Flexibility costs significant down time, if you're not being given it then you're not being allowed to be flexible.
Correct. If management told our team that our performance was based on getting 2-3 planned features out this quarter, and we've been minmaxed to fill our schedules, and there's a hiring freeze and one team member just left - then we have no room for some "30 minute" (which is much more than 30 minutes for us) request. Also, management has told us that our performance reviews are based on whether we got these 2-3 plan…
Re: "No, it's less effort than that"
#304“Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”. Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly. It’s like asking sales people what their quota should be. They pick a number that is no-brainer hittable, because there is a lot of complexity and many unkn…
This isn't to argue that we should just believe developer estimates unconditionally. That's a bigger rabbit hole that I'm too tired to go down right now.
Re: "No, it's less effort than that"
#305Earlier quoted context omitted.
Except a sale is a sale; did they buy it or did they not? There's additional nuance for whether they'll buy again or what support they need going forward, but a sale is still a sale. A program is not just a program. A bug fix is not just a bug fix. They are not fungible, while sales, definitionally due to the exchange of money, are fungible.
Taking a narrow view, maybe. But a sale in a jurisdiction you don’t currently have other customers in could impose significant regulatory burden for relatively little gain. A single 100x sale is very different than 100 1x sales both in overhead you’ll have and in how much leverage the customer will have in the future, etc
I'd claim that businesses are biased toward chasing a highly fungible sales model, to the point of eliminating the need for a salesperson altogether, and so naturally sales tends to the right.
Re: "No, it's less effort than that"
#306Earlier quoted context omitted.
This is ridiculous. The number of LOC doesn’t define whether something is well implemented. You can’t crank out a better design or proper feature implementation by asking developers to write code faster or write more code in a given day.
You’re restating their point, just with more words.
Whereas with code, deleting code and writing less code is very much preferred because each line of code written increases the complexity and risk in the system.
This is why business teams who are shirking discovery and instead focusing on the anti-pattern of trying to increase engineering productivity is such a massive mistake. Not only is the team pooping out code that doesn't fill a need (and hence won't be monetized), but they are also rapidly increasing complexity and opening the business to future liability when the code causes customers to seek remediation.
The quarter driven nature of most companies amplifies this bad behavior. This is why we see this revolving door of executives who come in, drive some bad initiative to incompletion, declare success and move on before their chickens come home to roost.
Re: "No, it's less effort than that"
#307Earlier quoted context omitted.
it's a fallacy in that it implies that one side is right and the other is wrong. (or one side is fair and the other is greedy)
My argument is not assigning blame, but explaining why the article will not convince many managers. It works assuming either side can be greedy or fair.
Management has to push for lower estimates because developers have an incentive to overestimate to make life easier.
this statement as written clearly supports management and puts blame on developers. if that wasn't your intention then it could be expressed more neutrally:
management pushes for lower estimates, because they believe that developers intentionally overestimate, therefore this article will not convince them
my response to that would still be the same though. statistics don't support that developers overestimate. on the contrary, one might even be motivated to claim that projects failing their estimates is caused by these managers.
Re: "No, it's less effort than that"
#308“Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”. Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly. It’s like asking sales people what their quota should be. They pick a number that is no-brainer hittable, because there is a lot of complexity and many unkn…
> “Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”. Not really, because those are not estimates. Also, consequences are different. With programmers, consequence is typically very buggy and hard to maintain software. With sales, the consequence is a lot of fraud, followed by firing of every who is not comiting fraud and then even more fraud.
P.S. Not really, you covered it nicely under fraud
Re: "No, it's less effort than that"
#309Earlier quoted context omitted.
> “Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”. Depending on the economic climate and the situation of the company in the marketplace this may be accurate. If you've got good sales people that are already selling as hard as they can't you won't be able to squeeze much more out of them if the economy tanks and nobody wants your product. I'm sure there are sa…
Heh, have we already forgot what happened with Wells Fargo? We need to upsale 10 accounts a day? Random accounts it is! https://www.justice.gov/opa/pr/wells-fargo-agrees-pay-3-bill...
Re: "No, it's less effort than that"
#310Earlier quoted context omitted.
This is a very childish way of viewing the situation. Of cousd you should look out for yourself, but your reward is not fixed, so you should not look to minimize your work at all costs
My reward is fixed as my salary is fixed.