Earlier quoted context omitted.
While I tend to agree, the research we environment demands this nonsense. Also, they have to start somewhere to set a record to get future funding. Should probably do more survey studies of what data exists and where the state of things are then suggest new studies and seek funding for it. Short of large and completely government funded development projects, I think it would be a struggle to get data. Few businesses…
Research at business schools manage to find all types of data that companies believe is way more integral to their success than information about their software estimation process. These researchers are choosing to waste their own time and governments money, because it's easier to play with new toy machine learning models than go to networking event and befriend software VPs in order to convince them to give you thei…
Software effort estimation is mostly fake research
311–318 of 318 posts
Re: Software effort estimation is mostly fake research
#312Earlier quoted context omitted.
Research at business schools manage to find all types of data that companies believe is way more integral to their success than information about their software estimation process. These researchers are choosing to waste their own time and governments money, because it's easier to play with new toy machine learning models than go to networking event and befriend software VPs in order to convince them to give you thei…
Nah. You just got a bone to pick. Christ.
I still think a lot of research in software engineering is useless because researchers spend too much time focusing on different methods and not enough going out into the world to collect better data. And researchers should be mildly ashamed for doing crappy research.
But also my tone should have been more constructive.
Re: Software effort estimation is mostly fake research
#313Earlier quoted context omitted.
What data would be useful here? There are so many confounding factors.
Well, isn’t that the kind of thing researchers ought to be researching?
I'd say Agile methodologies have done well in exposing the key factors for successful delivery, and they seem not very amenable to generalisation: - creative endeavours such as software creation are fraught with estimation difficulties (contrast, say, with migrating VMs from on-prem to cloud) - whoever prioritises / deprioritises features will have a large say in the accuracy - whatever technologies imposed/chosen will have a reasonable say in the accuracy - whatever architecture decided on will have a reasonable say in the accuracy - unforeseen requirements that may necessitate architecture / tech / people changes have a large say in the accuracy - individuals' skills in a team will have a very large say in the accuracy - how long a team has worked together / in an architecture / with a technology will have a very large say in the accuracy
We know all this. What can we learn? Genuine question.
Re: Software effort estimation is mostly fake research
#314Earlier quoted context omitted.
How do you know it's waterfall-like? If you ship working software every 2 weeks and every 26th one you release, hooray, you have yearly software that's super likely to work well.
Apple produces a new build of iOS or MacOS every 24 hours. For the many years that I had to suffer through that, about 40% of those builds were dogshit and unusable. The public gets the 360th release, and hopefully by then the PMs have driven enough burnout in the engineers that it is mostly acceptable to users.
Re: Software effort estimation is mostly fake research
#315Re: Software effort estimation is mostly fake research
#316Earlier quoted context omitted.
The reality is that software development is nothing like engineering or construction, it's totally different. You don't build a quick house, let people live in it and start building the walls whilst they live there. Humans like to think via metaphor because it's a least-effort mode of thought but sometimes there just isn't one and it's just tough luck and start thinking from first principles instead.
My point was more that the software developer have to not just build with existing material and equipment but have to invent and build those on the fly.
I think we humans find it hard to accept when something is completely new, when there's no analogy for it, because that's how our brains like to think. But software is just _different_ and it's better to give up on analogy than be misled by it.
Re: Software effort estimation is mostly fake research
#317Earlier quoted context omitted.
Well, isn’t that the kind of thing researchers ought to be researching?
Ought to? Not my call, as I don't employ any. I'd say Agile methodologies have done well in exposing the key factors for successful delivery, and they seem not very amenable to generalisation: - creative endeavours such as software creation are fraught with estimation difficulties (contrast, say, with migrating VMs from on-prem to cloud) - whoever prioritises / deprioritises features will have a large say in the accu…
Re: Software effort estimation is mostly fake research
#318Earlier quoted context omitted.
Well, the metric is #papers and #citations to get funding. So yes that's true, ideally, but...
Relevant blog post - It's not the incentives it's you. https://www.talyarkoni.org/blog/2018/10/02/no-its-not-the-in...
The reality is that the incentives are what society is asking for, with ethics etc acting as constraints only, rather than actively rewarded. In that formulation it is inevitable (and optimal) that some people will skate to the edge, and if the edge is poorly enforced they will increasingly go over.
Policies must address the overall actual effects, not just a chimerical ideal.
(It is even more ridiculous coming from someone in psychology.)