Hottie hangout pics with nude babes - https://adultlove.life
Software effort estimation is mostly fake research
41–50 of 318 posts
Re: Software effort estimation is mostly fake research
#42If someone can conclusively teach inexperienced programmers good approach to estimates (methodology) + help embed this into sales process of a software house-type company, I know some folks who'd love to have this :) My own experience has been this: people make estimates, client has expectations based on some variant of those, and something later happens but so much change is introduced during the actual software dev…
I think it's because inexperienced programmers don't think about the "soft" costs of programming. Requirements gathering, general communication, testing, production rollout, coordination, research, final approval - it all adds up. For a 2 week project you might only actually spend a day of ass-in-seat coding. And that ass-in-seat coding is what they tend to estimate.
Programmers can also try to come up with reasonable estimates, only for management (product, middle or upper - or often all of them) to come back and assert that the estimates are off base and to "reconsider." Not much to do at that point but to give a lower estimate and hope it works out. If you make that your hill to die on as a programmer you will find yourself out of a job with only your integrity to keep you warm at night.
Re: Software effort estimation is mostly fake research
#43If someone can conclusively teach inexperienced programmers good approach to estimates (methodology) + help embed this into sales process of a software house-type company, I know some folks who'd love to have this :) My own experience has been this: people make estimates, client has expectations based on some variant of those, and something later happens but so much change is introduced during the actual software dev…
Apple executes massive feature releases on a yearly waterfall-like schedule across hundreds of teams. It requires honesty, transparency, strong leadership (ruthless prioritization), strong cross-team goodwill, strong cross-team collaboration as well as a solid body of experienced top-tier engineers. Other than that there's no magic. While there are teams within apple that does scrum/agile, none of the core OS/framewo…
How do you know they are thoroughly waterfall? How do you know they don’t use agile, time-boxing, etc.? Apple is so secretive, it feels like we know of little other than what they are confident about releasing. The things that weren’t done on a schedule compatible with a hardware release, how often are they simply postponed? And for those postponements that they do admit, how many are waved away with a creative explanation? I think you need a good deal more information to back up your point about Apple’s work management.
Re: Software effort estimation is mostly fake research
#44I am 20 years in development business now. This simple rule of thumb works for me and the team: (Your honest and concise estimation) * 3 There are just to many unknowns you cannot foresee. Software development is complex.
I've been hearing this rule for years now, and I think the coefficient is increasing. It started at 1.5x, now it's at 3x... Is this just me?
Maybe the coefficient is related to your age. You got older, so there is more wisdom around. ;)
Re: Software effort estimation is mostly fake research
#45I am 20 years in development business now. This simple rule of thumb works for me and the team: (Your honest and concise estimation) * 3 There are just to many unknowns you cannot foresee. Software development is complex.
I'm such an optimist! I multiply by 2.2.
Re: Software effort estimation is mostly fake research
#46If someone can conclusively teach inexperienced programmers good approach to estimates (methodology) + help embed this into sales process of a software house-type company, I know some folks who'd love to have this :) My own experience has been this: people make estimates, client has expectations based on some variant of those, and something later happens but so much change is introduced during the actual software dev…
Apple executes massive feature releases on a yearly waterfall-like schedule across hundreds of teams. It requires honesty, transparency, strong leadership (ruthless prioritization), strong cross-team goodwill, strong cross-team collaboration as well as a solid body of experienced top-tier engineers. Other than that there's no magic. While there are teams within apple that does scrum/agile, none of the core OS/framewo…
> Apple executes massive feature releases on a yearly waterfall-like schedule across hundreds of teams. It requires [...]
And no doubt a great deal of crunch time, their fair share of delays, some major messes and the occasional outright cancellation. And if I'm not wrong their roadmap is not public information.
I personally find it hard to believe that a large company can exhibit all those adjectives you list. Everyone finds this hard.
Re: Software effort estimation is mostly fake research
#47Scrum dogma is that estimates are for complexity, not effort or timing. The points you track in JIRA are meant to reflect how much of the current backlog is complete and how much is remaining. That can be extrapolated into timing but can't be done up front.
If it can't be done upfront it's largely useless for business folks ("so you have an estimate but can't translate it into time? so why do it? go away" :). If it assumes remaining work is equivalent in time to done work (notion of velocity), it's (in my view) very optimistic. People learn the nature of the beast as time progresses. Collective learning happens slowly. A lot of important work is usually only discovered…
I'm gonna play the devil's advocate here.
> Sadly, few business folks want that of course :)
Business folks want this usually because it's their money you're playing with.
> Ignore long term planning. It's not helpful.
So, no don't tell people to ignore long term planning otherwise people who give you money are going to stop giving you money to "build, demo and decide". Unless you're on your own dime (e.g. you pay yourself or are self funded), then I wouldn't take this advice.
Re: Software effort estimation is mostly fake research
#48I find this amusing. Know how much a Honda Accord costs? About 25 Grand. Know how much a Mercedes S450 costs? About three times as much. They are both great cars, that will be rewarding to own. The Mercedes doesn't have 3 times more parts, but it probably took four times longer to make, and they paid the folks that make it, a lot more than the Honda. It's actually, probably better "bang for the buck," although it won…
Your base assumption seems to include that quality is valuable for its own sake. I don't totally disagree, but I'm wary of assigning value based on effort rather than output.
Depending on why you are buying a car, the Accord is very likely much better bang for the buck than the S-class Mercedes. And depending on the situation, the prototype is often better value than the shippable product.
Re: Software effort estimation is mostly fake research
#49Re: Software effort estimation is mostly fake research
#50If someone can conclusively teach inexperienced programmers good approach to estimates (methodology) + help embed this into sales process of a software house-type company, I know some folks who'd love to have this :) My own experience has been this: people make estimates, client has expectations based on some variant of those, and something later happens but so much change is introduced during the actual software dev…
Apple executes massive feature releases on a yearly waterfall-like schedule across hundreds of teams. It requires honesty, transparency, strong leadership (ruthless prioritization), strong cross-team goodwill, strong cross-team collaboration as well as a solid body of experienced top-tier engineers. Other than that there's no magic. While there are teams within apple that does scrum/agile, none of the core OS/framewo…
When you have hundreds of teams you can cut a bunch of features and it still looks like you are massively productive each release :) Not everyone has that luxury unfortunately. Some of us are a single team of a handful of developers.