3 ms·
When you say things like "I consider these to be facts" and "you may not agree with these facts", it's a clue that we may not in fact be dealing with facts.
by serve_yay 11y ago
When you say things like "I consider these to be facts" and "you may not agree with these facts", it's a clue that we may not in fact be dealing with facts.
- hinkley 11y ago'phenomena' might have been a better choice. We have a bad habit of forgetting things that can actually be empirically measured.
- serve_yay 11y agoOne of the first things here is about the relationship between problem complexity and solution complexity. But how is this complexity measured empirically? We have the notion of cyclomatic complexity, an empirical measurement that can be used to assess the complexity of a piece of code, and presumably that code is the solution to a problem. So, OK, we have something like a measurement of solution complexity, but how is problem complexity measured, and what is its empirical relationship to the measure of complexity of the solution? Hell, what are the units we would measure such complexity, even? I think people who do what we do have a certain insecurity about how much of what we do is decidedly not science. And we have this tendency to talk in science-y ways about what we do, which sound good to our ears, but aren't quite rooted in anything concrete.
- StillBored 11y agoThe problem with cyclomatic complexity measurements, is that if you take two similar pieces of code, one with error handling for all potential failures, and one with absolutely no errors handling you get a large variation in the resulting complexity metric. Both pieces of code will probably pass simple correctness tests. But you can't really even make a statement about which is more robust, as the code with all the error handling paths may be full of latent bugs of worse severity than (another thing hard to quantify) simply not handling the errors. So, when people start talking about the cyclomatic complexity, it seems to me that we are better off understanding we are deep into a philosophical discussion rather than a scientific one.
- bediger4000 11y agoCyclomatic complexity may just be another way of saying "lines of code": (http://www.scirp.org/journal/PaperDownload.aspx?paperID=779 http://www.scirp.org/journal/PaperDownload.aspx?paperID=779) We found that due mostly to issues regarding population variance, that the linearity of the relationship between these two measurements has been severely un-derestimated. Using modern statistical tools we develop linear models that can account for the majority of CC by LOC alone. We conclude that CC has no explanatory power of its own and that LOC and CC measure the same property. We also conclude that if CC does have any validity as a measure of either complexity or test space size, then we must conclude these factors grow linearly with size regardless of software language, paradigm, or methodology. I was looking for another reference, and I found this one, which seems far better researched.
- deleted 11y ago[deleted]
- hinkley 11y agoYou can estimate complexity by the time to add or fix functionality in that part of the code. That's pretty much why you're measuring complexity in the first place. So you know if you're hemoraging or not.
- mathattack 11y agoIn his defense, the full quote is actually not so bad. I don’t expect you to agree with all these facts; some of them might even upset you. Great! Then we can begin a dialog about which facts really are facts and which are merely figments of my vivid loyal opposition imagination! It's interesting that he was (is?) a vocal dissenter on Open Source.
- MichaelGG 11y agoWikipedia says this: >in 2000, Glass criticized open-source software, predicting that it will not reach far, and "will be limited to one or a few cults emerging from a niche culture." Glass's basis for this bold prediction was that open-source software "goes against the grain of everything I know about the software field" Not to judge off something that small, but if "everything he knew" told him open source was not going to reach far, then perhaps his other facts are off.
- TheOtherHobbes 11y agoI don't see in what sense his "facts" are factual. There are no references. They look more like random opinions - some interesting, but with a fair sprinkling of platitudes - supported by some equally random numbers, of the "Did you know fifty percent of statistics are made up?" kind. I think it's interesting how dated the piece looks. Equivalent writing today on Quora, Medium, or HN - never mind an IEEE journal - would be more likely to discuss real research. It might not be certain to have facts, but I think standards of argument have improved significantly - possibly because it's so much easier to find and reference studies than it was when a lot of debate happened very slowly in print.
- mathattack 11y agoI think he puts the "Facts" out there with a grain of salt - and admits it in the preamble. They're very much a source of discussion rather than hard and true facts. (Software engineering is a social science where experiments are virtually impossible to replicate. As such, it's only slightly more rigorous than "Facts" in History or Political Science classes.)
- bhntr3 11y agoThe lack of citations is concerning. I could read his book but it worries me when numbers like these are thrown around without some way to verify the analysis. The "28x productivity" (or 10x or Xx ...) claim always triggers warning bells for me. http://morendil.github.io/folklore.html http://morendil.github.io/folklore.html does a pretty good job explaining how the research backing that widely accepted "fact" may be questionable. I also really like Dan Luu's review of the research behind static typing at http://danluu.com/empirical-pl/ http://danluu.com/empirical-pl/ as an example of how a "well studied" claim can still be questionable due to the massive difficulty in evaluating software engineering empirically. Software engineering is a very human activity and that makes it very hard to measure and quantify. A book that does a better job is Making Software (http://www.amazon.com/Making-Software-ebook/dp/B004D4YI6G/ref=la_B001H6PNGM_1_3?ie=UTF8&qid=1370219697&sr=1-3 http://www.amazon.com/Making-Software-ebook/dp/B004D4YI6G/re...) but as my first link points out, it still has some issues. At least its goal is to get more rigorous in our scientific analysis of software engineering.