by Michael S. Kaplan, published on 2010/02/06 11:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/02/06/9959263.aspx
I was at a talk Dave Probert was doing last Friday.
It was not an ordinary one of those Windows Developer talks that Dave was hosting, mind you. Dave was actually giving this talk. It was about some of the stuff he is working on now, architecting now.
That alone makes it one to attend, in my opinion.
And the opinions of others, too. A lot of people were there....
Anyway, I can't talk about what he was talking about. But that is okay, because in terms of what this blog within this Blog is about, what his talk was about is not what this blog is about.
But at one point, Dave was talking about some of the non-goals of the project. And then he spoke to some of the details of why some particular features were of theoretical interest but really went against the target and intent of the work being planned, of the reason for doing it.
Then something occurred to me.
I myself have written a lot of code, some of it that no one other than the person who stumbles on it years later even really know about, and some of it wildly popular and still being used extensively as a de facto method for getting certain tasks done (inside and outside of Microsoft).
I thought about the number of times I ran across some internal or external developer who was trying to do something with that code that was really beyond what the code was intended to do -- the whole scenarios driving these people had quite simply never occurred to me or the people spec'ing the project.
The only time I ever had any real luck convincing people that they needed to stop doing whatever they were trying to do was when doing it was either
Every other time, people would often keep doing it even if it was a bad idea.
So I started wondering about how one would design a feature that was awesome when used correctly but so scary or impossible to use incorrectly that no one would every try to do so for very long.
How would one accomplish this? Is it feasible to architect a feature so as to only allow the right people to use it, where the right people are defined as within one standard deviation of the target customers?
John Cowan on 6 Feb 2010 6:32 PM:
I don't think so. Poor programmers are so arrogant that none of them will believe they are incapable of learning to use a given feature correctly, despite the evidence. This is part of the general result that when you ask people about some particular skill that can be objectively measured, the bottom 25% performers always put themselves in the top 50%, whereas the top 25% generally put themselves between 50% and 25%.
Kemp on 6 Feb 2010 6:54 PM:
Scorched Earth policy. If a function in your library is passed invalid parameters then it formats the user's hard drive. If your library is loaded on a version of the OS other than the one it expects then it formats the user's hard drive. If someone attempts to unload your library while it's holding onto resources which it hasn't been told to free then it formats the user's hard drive. And so on, you get the idea. After a couple of failed attempts I'm pretty sure the coder will get the idea too.
Note: While I really love the idea of beating bad coders senseless (at least in a virtual sense) I realise that this idea would never be implemented because of the huge backlash. Still, a fun thought. I've always thought the same should be true of compilers. If the coder exploits undefined behaviour then the compiler should just go ahead and break his system. We're probably better off that way.
Michael S. Kaplan on 7 Feb 2010 6:47 PM:
How about a gentler version of the scorched earth policy that just makes things that are out of scope totally fail?
Kemp on 10 Feb 2010 3:12 PM:
That would work too, but you have to admit it's far less fun ;-)
I get the feeling that going that route would rapidly tangent into the old "should the caller or the callee be responsible for validating parameters?" argument though, and that never ends well. Usually ends with everyone thinking everyone else is an idiot, as is usual for internet arguments.
referenced by