3 ms·
There's another strategy that works better than searching for a keyword, which is to read the article. It's about the difficulty/expense of systematically and
by routerl 5y ago
There's another strategy that works better than searching for a keyword, which is to read the article.
It's about the difficulty/expense of systematically and scientifically studying the software development process (e.g. finding out what data actually exists to support the claim that "a bug is cheaper to squash when it is caught during the specification process").
The title expresses frustration not at science itself, but at how needlessly difficult this process is, since both the secondary and primary academic literature surrounding it are of extremely low quality.
- AnimalMuppet 5y agoBut specifically with respect to software engineering, it's really hard to do solid, repeatable experiments. It's not like physics, it's like sociology or psychology - which also have trouble doing precise, repeatable science. Why is it like sociology or psychology? Because it's about people, not about things. Software engineering is not just about languages and programming techniques; it's about how people interact with those languages and techniques. The people have far more variability than the languages and techniques do. Cutting through that to be able to accurately say something about any language or technique is... really hard.
- deregulateMed 5y agoI think at the present time, software can be more like science than sociology. Both suffer from abstraction. I think psychology when closer to biology is similar to programming like running the programming language C experiments.
- deregulateMed 5y agoDespite insistence of programmers wanting to be scientists and engineers, it's not true to the definition. Maybe safety critical C or assembly is engineering. Maybe testing code for speed can be considered science. By the time any useful program is finished, there's significantly more tradition and art than Science and engineering.
- routerl 5y agoSure, but I think the underlying instinct behind "evidence based software engineering" is precisely about turning those "maybes" into measurements. In principle, I'm in favor of this endeavor, and the article at hand expresses frustration about apparently arbitrary barriers towards accomplishing these measurements. I don't know about you, but I'm generally always in favor of "let's measure more things and build more models from that data, to make sure we're actually improving"