iRihttp://www.jerf.org/iri/Tagline pending.en-usFri, 23 Jan 2015 20:18:18 -0000 It is impossible to deeply understand a solution before you have the problem. Let me ... http://www.jerf.org/iri/post/2943 <p>It is impossible to deeply understand a solution before you have the problem.</p> <p>Let me give you an example that probably all my readers can relate to: Mathematics education. Do you remember first seeing the quadratic equation and wondering why you should care? Or even if you were a math nerd like me, can you understand why someone would be asking themselves that at that point?</p> <p>The problem is that the students have not had the problem. For one thing, all the quadratic equations they've been solving were simple ones with integer solutions. For another, even the factoring problems themselves were artificial; they're not factoring because they've encountered a real life problem that requires a factoring solution, they're factoring because they were given homework. It's hard to care about the quadratic equation when it's a solution to a problem you don't have.</p> <p>Also, the problem is recursive in mathematical education... students don't care about the quadratic expression, because they have no quadratic equation problems, except in school. They don't care about the quadratic equations because they only needed to work them to learn about polynomials, which they have no reason to care about, except that it was homework. They have no reason to care about polynomials, except that they were assigned to teach algebraic manipulation, which they have no reason to care about except that it was assigned in school... and so on, recursively, until you arrive at simple arthimetic at which point most people would agree that it corresponds to real life.</p> <p>In some sense this is the complement to the classic <a href='https://www.maa.org/external_archive/devlin/LockhartsLament.pdf'>Lockhart's Lament</a> in which a mathematician observes current math education is nearly worthless from a pure mathematical point of view; I observe that it is also nearly worthless from a practical point of view. The ideal education would encompass both, an education that at least covered <i>one</i> would be better than what we have now, but we offer neither.</p> <p>As is my way, this theoretical-sounding observation can easily be converted into practice, informing both how I teach myself and others. For myself, when learning something I give the documentation a good skimming to sort of load in the "table of contents", then I just charge in. When I encounter a problem, I go back to the documentation. If what I'm using is solid and the documentation is well-written, I'll find the solution to my problem. It will be in some feature or command that previous did not fully make sense to me (proved by the fact that I had the problem in the first place), but now it will make complete sense, because I've actually had the problem it was trying to solve.</p> <p>At work the amount of time I spend training others is slowly-but-surely increasing, and this observation very strongly informs how I structure my training. The fact is, most "training" fails, because the average training session consists of trying to essentially read out a glossary and then reading out the solutions to some problems. This is a waste of time when the trainees have never had the problems you are giving them the solution to.</p> <p>Solution: If at all possible, give them the problems. Right now I'm training people on <a href='http://git-scm.com/'>git</a> at work, and despite the abundance of tutorials on the topic I still ended up writing my own training course. I find most tutorials consist of huge blocks of text explaining the basics of git, then they offer various solutions to source control problems, then that's the end. And I have found most people's idea of what being "trained on git" means is that we'll pile into a room, I'll stand in front of some slides gesturing wildly reading these things off, and then by presumably Magic they'll all know git by virtue of having heard some words.</p> <p>That is not how I run this training. Instead, I make sure everyone is in front of a computer. We all create a repo and follow along, issuing the same commands to the repo. And I do not cover the happy path of what happens when everything is working properly; in fact I probably spend more of the presentation in error conditions and confusing situations than I do things working correctly. People need to know why adding something before switching branches does what it does. People need to learn how to deal with the "detached head" state. People need to learn what to do when a branch is merged and there's a conflict. They can't understand the solutions until they've had the problem, so if you hope for people to walk away understanding the solution you have to have given them the real problem, too.</p> <p>If you're a programmer, hopefully that makes sense to you. Yeah, the problems themselves are still ultimately artifical, but hopefully it's still enough to trigger recognition when they occur for real. If you <i>aren't</i> a programmer and the last few sentences of the previous paragraph were so much gibberish, well, I ask you to imagine what use it would be to you if I were to describe the solutions here. You can't understand, partially due to glossary issues, sure, but also because you are <i>so far</i> from having those problems that you have nothing to hang a solution on to.</p> <p>It's early going yet on whether this training is sticking, but early results are positive. I'm seeing better uptake on these topics than I was expecting.</p> <p>I also have to admit it's a bit funny to hear how completely unused to being pushed into problem situations people are. I explain up front that I'm going to work us through some problems, but I've found people often still end up surprised when I tell them to type something and git yields an error. It's clearly a violation of deeply-held expectations.</p> <p>At some point I'm going to be delivering security training, which also has its own long, sordid history of failure. For that, I plan on pursuing an even more advanced variation based on this observation: The most important result that security training can have is for the developers to come away <i>aware that they have a problem at all</i>. The vast bulk of security failures can be traced back to that core issue, that the developers didn't even realize they had problems, because they aren't jumping up and down in front of them wearing a sign that clearly labels it as a problem. It is the thinking on that topic that led me to write <a href='http://www.jerf.org/iri/post/2942'>my previous post</a>. Security issues are about more than just not making the "top 10" errors, it's about realizing that frankly the deck is utterly and totally stacked against you in almost every conceivable way, that dealing with that problem one line at a time is virtually impossible, and that we must start with recognizing these problems before we can even start solving them.</p> <p>Providing solutions in training is a <i>distant</i> second-rate concern in this case; if developers realize they have problems, they'll seek out and create solutions. Solving problems is what they do, after all. It's that first clause of the "if" where the problem lies.</p> <p>I hope this can help you improve your own training, and any teaching you may do for others.</p> jerf@jerf.org (jerf)Fri, 23 Jan 2015 20:18:18 -0000http://www.jerf.org/iri/post/2943Bloviation It&#39;s 2015. Why do we still write insecure software? http://www.jerf.org/iri/post/2942 <p>I've read a lot of programming blogs, and if you're reading this, you probably have too. So let me tell you up-front this is not your usual security rant that boils down to "just try harder!" Let's talk about smart, experienced programmers who are trying to write secure code, even if they are not security "experts" per se. This is an important set of people, because there is more security-related software in the world to write than can be written by security experts.</p> <p>In a perfect world, setting that as the target audience would conclude this essay. As your browser's scrollbar shows in the full view, this essay continues on for quite a while. Alas, decades of experience and a trained reasonably high intelligence are not sufficient to write secure software in the current coding environment.</p> <p>That's also the highest amount of qualifications that can be feasibly brought to bear at any reasonable scale, so in practice that's equivalent to saying it's impossible to write secure software in the current coding environment.</p> <p>Let's talk about why it's so hard. My thesis is simple:</p> <blockquote>We write insecure software because our coding environment makes it easier to write insecure software than secure software.</blockquote> <p>But exploring what it fully means can lead some surprising places. Please join me on a journey as I try to show you why that is not trivially true, but in fact, <i>profoundly</i> true. We do not occasionally pick up insecure tools, like a broken encryption routine or misusing a web framework; we are fish swimming in an ocean of insecurity, oblivious to how steeped in it we are.</p> <p><a href="http://www.jerf.org/iri/post/2942">Read the rest...</a></p> jerf@jerf.org (jerf)Mon, 19 Jan 2015 15:07:07 -0000http://www.jerf.org/iri/post/2942ProgrammingGolang I thought I&#39;d use Prime Music to explore some classical I hadn&#39;t gotten around to ... http://www.jerf.org/iri/post/2939 <p style='text-align: center'><img src='http://jerf.org/images/hammer.png' alt='You are listening to Symphony Number 1 in E Flat Major, K 16. Allegro molto. Customers who bought this song also bought: U Can&apos;t Touch This by MC Hammer' /></p> <p>I thought I'd use Prime Music to explore some classical I hadn't gotten around to yet. You know... Mozart, some stuff by Beethoven I haven't heard yet, Bach, MC Hammer... you know, the classics.</p> jerf@jerf.org (jerf)Fri, 12 Dec 2014 15:12:09 -0000http://www.jerf.org/iri/post/2939Bloviation Only a poor student of history could fail to notice history&#39;s cycles. The future can&#39;t ... http://www.jerf.org/iri/post/2938 <p>Only a poor student of history could fail to notice history's cycles. The future can't be fortold in detail, but asking the question "Where are the cycles taking us?" gives you a better chance of guessing general shapes than anything else I know.</p> <p>So it's easy for a student of history to look out at the United States and guess that we're approaching a libertine peak, and that over the next couple of decades we should expect to see the pendulum swing away from the wild excesses of the Baby Boomers back in a more "conservative" direction.</p> <p>But at my age, I've never <i>lived</i> through a shift. So had I guessed how the counter-libertine shift would occur last week, I would have guessed a gradual cultural waning of the libertines and a gradual cultural waxing of those of a more conservative bent, with the advocates not changing their own views but their relative influence changing over time.</p> <p><a href="http://www.jerf.org/iri/post/2938">Read the rest...</a></p> jerf@jerf.org (jerf)Wed, 15 Oct 2014 22:33:55 -0000http://www.jerf.org/iri/post/2938Bloviation The debate about the reproducibility of science bubbles onward, with everyone agreeing that it&#39;s a ... http://www.jerf.org/iri/post/2937 <p>The debate about the reproducibility of science <a href='http://www.nytimes.com/2014/09/19/upshot/to-get-more-out-of-science-show-the-rejected-research.html?_r=0'>bubbles onward</a>, with everyone agreeing that it's a problem but of course nobody with power to fix it doing anything about it.</p> <p>Recently I've been thinking that science as we know it sits in a very unpleasant middle ground.</p> <p>On the one hand, despite the propaganda institutional science is biased against replication. This holes it below the waterline, and any serious scientist (alas) must consider fixing this in their field their top priority or they are consenting to just spin their wheels forever. We do not work formally enough to produce good results, because merely reaching "Peer Approved Once" and getting published is provably not a solid foundation to build on.</p> <p>If one is inclined to take offense to that, consider the fact that scientists are supposed to be building on the work of others. It's very simple math to see that <i>even if</i> a uniformly-distributed 95% of the papers published are perfectly correct, that 5% has a disproportional impact on the accuracy of a tower of knowledge; as the tower grows, the chances of any particular new result containing a false result in the set of results it is building on approaches 1 quickly.</p> <p>Many scientific disciplines would be lucky to have a 95% accuracy rate.</p> <p>On the other hand, scientists are also not allowed to just "fool around", by virtue of not being able to get funding for it. Even simple experiments must be submitted, approved, funded, etc, all involving processes a great deal more complicated than the simple little English words imply. As a second-order effect it becomes a waste of time to go through the process for a small experiment, making the small experiments even less likely to be conducted than you would initially think. And yet, historically, a lot of great stuff happened from very skilled, knowledgeable scientists just fooling around. In only a few fields can a scientist afford to fool around on their own time and money, mostly the mathematical ones.</p> <p>The system both crushes away the rigor we're promised in the brochure, and also crushes away any chance of serendipity or discovery on the cheap. The miracle is when we get any science at all.</p> jerf@jerf.org (jerf)Sat, 20 Sep 2014 18:25:06 -0000http://www.jerf.org/iri/post/2937Bloviation