The site is down for me, so :
https://web.archive.org/web/20210118200327/http://shape-of-c...
Software effort estimation is mostly fake research
51–60 of 318 posts
Re: Software effort estimation is mostly fake research
#52I 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 use a similar methodology.
The part you didn't mention is that for most businesses it's better to be over than under in the estimation. I also explain this thought process to the various stake holders. We can certainly try to tighten up an estimate, but that runs a higher risk of being under which is usually a worse outcome (promised launch dates are missed, marketing is missed/happening, customers are told, etc...).
Re: Software effort estimation is mostly fake research
#53Broken Link....
Re: Software effort estimation is mostly fake research
#54If 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…
Estimates don't give you the time when something will be done. You can just be almost sure that the thing will not be ready before this time. And that's still something.
Re: Software effort estimation is mostly fake research
#55"Estimates" are for things you've done before - like you can estimate building a house, because people have built houses before. The more like an existing house, the better you can estimate it. Software is invention and construction. The construction part is pretty easy to estimate. The invention part is ... very very hard. I'd like to say it's impossible. I'd like to see the software industry use a different word th…
Very true, I think those estimates are actually two ideas/types crammed into one value.
1. The construction part, as you said, can be estimated.
2. I'd just call the other thing "allocated time" instead of "estimated time".
Any time someone asks me how long it will take me to fix a bug that I haven't really looked at yet, or to plan some new feature or something like that, and they badly need a number, I ask them how much time I should allocate to that. I can't promise to have something like that done by that time, but it gives us both an idea about how to treat that problem.
For example, we could allocate two hours to fix a bug, with the understanding that if that turns out to not be enough then we'll need to talk about workarounds. Or we can allocate two days to plan a new feature, and the best solution we can think of in that time shall be the one we use.
Re: Software effort estimation is mostly fake research
#56Earlier quoted context omitted.
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…
Adobe executes (executed) massive releases on a well-defined cadence (1.5 yr per "creative suite"). Sure, I won't say they don't have collaboration, or top-tier engineers etc. But in the end, the success of this well defined cadence boiled down to the simple strategy of "we release what is ready". Everybody knew the deadlines well in advance, and everybody strives to 'make it' - but, (not so) occasionally, some teams…
That's pretty much how Linux kernel releases work. Just having a regularly scheduled release train that always runs on time – that you can catch (or not) is great.
Re: Software effort estimation is mostly fake research
#57If 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…
Make a complete list of things to develop in a spreadsheet, "complete" means every single item the customer wants to see in the product, not only every single button but also every single label, that should be definable by reading the project specs or mockups. I think "forgetting things" is the first big mistake leading to under estimations. Add an estimate that you multiply by three in front of each, ie. if the dev…
Back when I was a product manager, there was an engineering manager who would drive me crazy. He had this idea of a 90% schedule, by which he meant a 90% chance of hitting if everything went as planned. Everything never went as planned.
Re: Software effort estimation is mostly fake research
#58"Estimates" are for things you've done before - like you can estimate building a house, because people have built houses before. The more like an existing house, the better you can estimate it. Software is invention and construction. The construction part is pretty easy to estimate. The invention part is ... very very hard. I'd like to say it's impossible. I'd like to see the software industry use a different word th…
You've perfectly nailed the fundamental issue here.
For many software projects, you simply cannot make meaningful granular estimations for parts of them. It doesn't matter how many story-point poker sessions you hold. Some software work cannot be reduced to a positive integer. In our business scopes creep, bugs plague us, and myriad issues make precise estimations pointless. It's engineering Numberwang.
I get that folks want to tame a chaotic world. But sometimes you can't. And the software engineering field in particular feels wildly neurotic about pretending otherwise. Sometimes I imagine applying our project management tools to other technical fields and laugh at how insane we must look.
Re: Software effort estimation is mostly fake research
#59Scrum 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.
> Scrum dogma is that estimates are for complexity, not effort or timing The theory of story points (which originate outside of Scrum and are not part of Scrum proper) is that task-specific time estimates in creative intellectual work are extraordinarily unreliable and expending more effort on them doesn't improve them, but broad-banded complexity class evaluation mixed with empirical observation of the teams velocit…
Right, the estimates are not even in the guide: https://www.scrumguides.org/scrum-guide.html#sprint-planning
Planning poker and such are useful as they encourage the team to discuss differences and help identifying stories which are too large.
Re: Software effort estimation is mostly fake research
#60In his book “Code Complete”, Steven McConnel speaks about metaphors. He reasons that metaphors are necessary to be a good developer as it helps visualize the act of coding. The metaphor he prefers is the “construction” metaphor. This metaphor he argues best explain the act (some would say art) of programming and gives developers a language to speak in that brings clarity to the development process.
When in construction you prepare the building site, lay a foundation, frame the house, put siding and a roof on it, and plumb and wire it. This is equivalent to programming. In other words through the lens of the construction metaphor, the developer is someone who ultimately build someones house by working together with different disciplines (Architects, designers, contractors etc)
The problem with that metaphor IMO is that it's not actually what software development is.
The proper metaphor for software development is more "engineering and development of construction site equipment and material" i.e. a developer is not building buildings they are building the things necessary for building the building.
And so the developer will often find themselves in a situation where the material doesn't exist and they have to invent it it or the material exist but we dont know how it's going to work with some other material needed or the equipment used for that material isn't made yet or doesn't work with that material even though it normally does.
I.e. a developer is inventing, engineering and building all at the same time and that is what makes it impossible to estimate development regardless of process or metaphor.