I get the point, and with irresponsible parties (as is fairly widespread in most companies) there's a real risk here. However the analogy of a meteorologist seems poor as that job is focused on predicting the weather - the typical dev is focused on operating in that weather and comparatively inexperienced in predicting with great accuracy. What's frustrating as a stakeholder is ludicrous estimates, which don't even s…
"No, it's less effort than that"
251–260 of 388 posts
Re: "No, it's less effort than that"
#252Whenever this estimation question comes up, developers rarely put themselves in the shoes of the business side, and try to understand why there needs to be an estimate, and why shorter is always better than longer. What they do instead, is try to protect their holy land of software development, and exacerbate the differences between engineers and "the others" - sarcasm and cynisism usually shine through at this time,…
I've always hated this sort of talk. The myth that some people are inherently creative, or inherently logic brained, or inherently buisness brained, or whatever, and never the twain shall meet.
I've seen a spectrum in most dev teams I've worked in. Those with good communication, those without. However, I've also spoken to sales, HR, etc people who paint the whole team with one brush and are afraid to come and speak to the scary code people. This, I'm afraid to say, is often because those people were also bad communicators.
I agree there needs to be more awareness of the buisness realities among developers (personally I think it leads to more fulfilled and happy developers, among other things), but I think that can't be placed entirely on developer's heads. They can't know how the sales team's meeting in morocco next week's call might affect things if they have no idea that the meeting is happening, who the client is, what that client means in terms of the industry, the likely things that client might value. They are adults. A couple of onboarding meetings, occasional cross-training does wonders.
And if they did know that? They might be able to quickly throw something together that has a good chance of really impressing that client. Or provide certain insight into what the company's solution actually does for the client.
Re: "No, it's less effort than that"
#253Earlier quoted context omitted.
Isn’t sales a numbers game for the most part? Like you can convert 10% of leads, so if I need 5 conversions instead of 4, I need to call ~10 more people? A better comparison to software I think would be construction of a novel building. Try constructing a geodesic dome house with no experience, and little knowledge of the issues you might run into, but then you’re asked for accurate estimates and then pressured to sh…
> I need to call ~10 more people? I need to write 10 more lines, code for 10 for minutes, etc.
Re: "No, it's less effort than that"
#254Earlier quoted context omitted.
> I need to call ~10 more people? I need to write 10 more lines, code for 10 for minutes, etc.
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.
Re: "No, it's less effort than that"
#255Earlier quoted context omitted.
You're reading too much into the morallity. Furthermore how is it a fallacy?
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)
Re: "No, it's less effort than that"
#256Earlier quoted context omitted.
> I need to call ~10 more people? I need to write 10 more lines, code for 10 for minutes, etc.
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.
Re: "No, it's less effort than that"
#257Earlier quoted context omitted.
> I need to call ~10 more people? I need to write 10 more lines, code for 10 for minutes, etc.
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.
And a phone call doesn't mean a sale closes.
See conversation upthread.
Re: "No, it's less effort than that"
#258Earlier quoted context omitted.
It's totally valid to push devs to get a ticket done faster when there's real pressure. It's much better to finish a ticket under estimate than turn estimates into aspirations. The best case is to: - line up the work in order of priority, taking into account prerequisites - have sufficient stories in a ready for dev state - during crunch time, be strategic about ticket assignment (you pay for this in the long term wi…
>be very careful that you don't make this approach the standard way of working Legacy management steeped in manufacturing has entered the chat!
The truth is it really doesn’t matter how many features you deliver, or how many cars you produce.
The real impact is from managerial decisions on customers and products. A car company that does not produce as fast as it could, but produces high-quality, is still going to sell everything that they can make. Same in software. I would argue this is Microsoft and Apple’s model.
If people want it, they can even raise the prices and it won’t make any difference if they make more of them. The same truth exists in software, but everyone wants to talk about productivity because management wants to feel like they’re getting a good deal for the money.
But they’re focused on the wrong aspect of their business. It’s the same as the car business. In software, we say that sometimes you have to slow down to go faster. That’s kind of what Toyota did. Focused on quality, and now they’re making more money than anyone else.
Re: "No, it's less effort than that"
#259“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…
Asking meteorologists for sunshine is unequivocally unreasonable, so what you are saying here, I believe, is that the analogy does not apply to sales people, and arguably not in the case of devs either - which I agree with, up to an ill-defined point where wishes lose any contact with reality in any circumstance.
Re: "No, it's less effort than that"
#260Typical action movie hacking scene: Leader: How long until you can hack the mainframe? Techie: The other hacker is really good; at least 2 hours. Leader: You have 1. Get it done! [commence flying around the 3d filesystem] Whenever I watch a scene like this, I mentally add a voiceover for the techie: [Techie thinks]: My actual estimate was 20 minutes. I can probably get it done in about 50, then I need to fly in the 3…