71–80 of 388 posts
Earlier quoted context omitted.
Your workplace may be toxic. My manager celebrates simplification and cost reduction when it solves business problems.
Completely different topic. I'm not even referencing "my workplace", I'm talking our entire industry.
The only magic wand in software development is to simplify requirements. The requirements are always wrong: too broad, too vague, based on invalid assumptions The real genius is to propose a simplified solution, by discarding some assumptions. This is the best and only way to shrink the schedule
I think it's less simplification and more precision and completeness. Obviously if you have simpler requirements they more complete and precise, but the requirement might not actually be simplifiable. In which case what you want is better specification.
"They write the right stuff" about the shuttle software group is basically a story about doing that: https://www.fastcompany.com/28121/they-write-right-stuff
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…
Dev teams have choices though. They can choose to use existing 3rd party code, services, etc, to accelerate development or not. They can choose some amount of non-functional requirements. They can choose the amount of "future proofing", abstraction, etc. And on and on...many choices that would drive timelines, trade speed for quality, longevity, maintainability, or cost, and so on.
And if it's built in-house, that means that in addition to being much more tailored to the organization's needs, it can be much more easily changed as those needs evolve.
This doesn't mean that I think it's always better to roll your own, of course; there are lots of instances where that counts as "reinventing the wheel." But it's absolutely not as simple as "just use something that's already out there and it will be faster and work just as well."
Earlier quoted context omitted.
That still doesn't solve the prerequisites being exceedingly rare in most teams. A system solving an issue under rare circumstances is barely worth considering, doubly so if it doesn't solve the issue in your specific circumstance. That's, again, disregarding that the modus operandi of most management teams directly interferes with planning poker itself (high turnover, high focus on increasing scope and scope per per…
I honestly do not understand what you're describing as the prerequisites. You ask people how hard something is to do, make everyone actually answer before hearing others opinions and if people disagree you talk about it to understand why. These are all short term features. The two things it deals with are: * get everyone to say how big of a thing it is, find out if there's misunderstandings about what the task involv…
Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. The only situation where this isn't a problem is with eager junior devs, and devs that have direct skin in the game, such as at startups or a department about to be cut for being unprofitable.
You punish us for being ambitious and failing and give us nothing for being ambitious and succeeding. As a developer, I endorse doing as little as possible as a result.
Whenever 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,…
why shorter is always better than longer?
Sure, if you’re a contract dev shop who is marking up hours, then longer is better.
Whenever 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,…
No amount of effort on either your or my part is going to make the baby appear faster.
Whenever 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 put plenty of effort into trying to understand. 95% of the time there's no business reason. Most of the time someone just wants to put a number on their powerpoint for some organisational politics nonsense. Sometimes the business wants to decide whether to do thing A or thing B (in which case they have a legitimate need for a relative estimate, but not an absolute one). Occasionally there's a real deadline, in which case again they don't actually need an estimate, they need a "can we hit this date y/n" (or, more usefully, "what do we need to do to make this date").
I'm very happy to work as closely as possible with the business. The reason I'm writing software at all is usually to solve business needs, after all. But when it comes to estimation it really is a case of them being wrong and us being right. (The best businesspeople don't work in terms of estimates in the first place; I don't know if estimates used to work at some point in the past and have been cargo culted since, or what)
> why shorter is always better than longer
If shorter is always better than longer then all my estimates are now 1 day. Does that makes things better?