Also, unrelatedly: I can't get this talk about of my mind. It's about how little we know about what works in software development. Is global state really bad? I sure think so but where's the empirical evidence?! If it were so clearly bad, then that badness we detect must somehow show up in reality and can be measured empirically. Is the issue that it's too costly to perform the test? Or that it's actually not as bad as we thing... (Reminds me of the debate I have with my mom about alternative medicine.) https://hillelwayne.com/talks/what-we-know-we-dont-know/

epistemology!

I put this in a recent proposal:

Programmers develop a set of heuristics about what code patterns have or have not worked before. They internalize information about these patterns into abstractions, which they then use to reason about programs. These abstractions can differ from programmer to programmer and are often not explicitly known, named, or discussed. When writing code, a programmer isn’t often thinking in terms of code, but usually in terms of these abstractions. This isn’t always reliable: combining two abstractions often results in a bigger abstraction with different properties than either of the two abstractions. So in turn, programmers must develop more heuristics about the properties of composed abstractions. Any failure to identify a novel composition, create sound abstractions, or correctly use an abstraction can result in bugs or poor performance. In addition to this complexity of writing code, reading and changing code is usually harder: code doesn’t show what abstractions the writer was working with when they wrote it or what the impact of a “small” change might be.

Reminds me a little of Peter Naur’s article “Programming as Theory Building” which is near annual read for me now http://pages.cs.wisc.edu/~remzi/Naur.pdf

In the Computing education research field (CER) they've been doing research into what abstractions people build (usually conception/misconceptions pairs). Diana Franklin from University of Chicago won best paper at ICER 2017 for one of the first mappings of these: https://dl.acm.org/citation.cfm?id=3106166

Surely, surely we could mine Github for honest answers to these questions!

I am a big fan of empirical evidence. When coupled with solid math underneath you get an unbeatable combination. I can prove in a series of examples, if one has the time to devote to it, that global mutable state is not only unavoidable (can only be concealed), but that done properly it creates near the minimum word count to express the program. I know them's fighting words, but nobody has been able to disprove it. The lack of a counter-example doesn't prove something is true, but in mathematics they occasionally know something is true long before the proof arrives such as in the 4 color map theorem. When you have had a 100,000 hours of river water flow against your body, you get rounded. I think all of the old practices of careful construction were built in response to painful learning experiences. As my friend Joon says, wisdom comes from experience. Experience comes from making mistakes, which comes from bad judgement. Testing has limited use, too many people are obsessed with tests, when in reality more time should have been spent making it unbreakable rather than trying to iterate possibilities. Better to spend the time reducing the number of states, than verifying 2^30 possible path combinations.

Am sure Hillel Wayne will learn the answer to this, as he does a lot of reading. IBM have done a lot of work on this topic and already have very good solutions that not only solve the problem, but also reduce development time. ... software inspection by Tom Gilb is a good starting point. The exercises in a discipline for software engineering are like gold, but the book wants an editor.

I think in the area of software engineering, it isn't that we don't know what works; frankly we know a ton about what works. It is just that the senior developers are not honored and imitated. Few seek out masters to study from, they consider the older programmers obsolete. Looking at the industry from a bird's-eye view, the average experience level is dropping due to the larger number of new programmers. Programming is a great deal more like basket weaving than most would like to admit. Lots of repetitive actions, and the skill lies in knowing the exact optimum sequence in which to construct a large product. The most important factor in productivity is knowing the proper sequence in which to build, so that you minimize the number of things changing at once. Biological systems are built this way; a layer added at the boundary, so that it can be verified easily; never 10 things at once which in the case of programming creates uncertainty as to where the problem lies. This is why the fanatic testers do have some advantages over the non-testers; the practice of making the test means they are building sturdiness as they proceed. When you see big team projects fail over and over, it is almost always because they are changing 100 things at once, which creates total chaos. This is why we have so few large projects attempted and instead many projects on GitHub are actually mashups, and many of these mashups have a frightening number of dependencies. In every company i worked for we fought hard against dependencies, because robustness is impossible above a certain complexity. Just look at the endless bugs in MS Windows and OSX to see examples of good teams being incapable of creating robust software.