DeHope

The idea of "code smell" is very valuable to developers. A "smell" warns you that something is amiss. It doesn't say exactly what is wrong, or where. But a stink does tell you something somewhere is wrong, and that can be very valuable.

But what about smells coming from other parts of an application, such as while it's being used? I'm thinking specifically of access control. This is the sort of thing that can consume a lot of development time to get just right. But generally it goes something like this: field F of business object BO cannot be edited when the object is in status S. I venture to guess we've all coded something like that a hundred times. And of course you know what happens immediately after implementing the rule? An exception! We want to let admins update the field any time, for example. Or we want a specific user, such as the person who created the item in the first place, to be able to edit the field, regardless of their role. The coding of access control can get ugly fast. Over time, different developers will implement, adjust, override, and change the order of the rules, ending up in a mish-mash.

Now back up a moment. Let's think about what we are doing here. Let's walk through what is happening with this field and think about it. And I propose when we do, we are going to say to ourselves, access control is hiding a process smell!

If a user wants to update a field, it's because they think the current value is wrong, and they know the correct value. Why else would they want to update it? Notice I said they "think" they know the correct value. So either one of two things is true: either they are right and their value is correct, or they are wrong and their values is actually not the correct one. Disregard who they are, their role, the status of the object, etc. Just think about those two possibilities: either they know the correct different value, or they think they do but they are wrong.

Now if we let them make the update, we get one of two possible outcomes. Either we are happy because this user was right, or we are sad because this user was wrong. If they were right, and they really did know the correct value, then this is a great day. Instead of blocking them with access control, we have allowed them to make the system more accurate. I think we can say this is a win for everyone involved?

Okay now we get to the problem. What if they were wrong? They updated the system and provided bad data! How could we have allowed this to happen? Well I propose this is not as bad as if the system had a rule in place to prevent the user from making any update at all to this field. The reason I say this is because we had a problem *before* the user made any update at all, and that problem is that this user is misinformed about this data. This is a process smell! We have users running around *thinking* they know better than the system what this field should be, and they are in fact *wrong*! By blocking them out and not allowing them to alter the data, we've cut ourselves off from this problem. We can't smell the smell. There's an issue out there but we have no clue.

Some caveats are in order. We need an auditing system in place, so that when people put bad data into the system, we know who did it and when. Without that, you're in too much danger allowing essentially anyone to anonymously screw up the data. Also we have to be talking about things that are not driving vital functionality of the system. If changing the field could cause danger to people, or to the stability of more than just this one business object, then perhaps the safety of access control is warranted. But for most fields, in most systems, I would guess that preventing access causes more problems, in hiding process smell, than it solves.

I stumbled upon a blog entry that asked, What Does One Trillion Dollars Look Like?
That was cute but it missed the point.
Here is what one trillion dollars actually looks like...

Go to LewRockwell.com people.
Now, before it's too late.

With my new iPhone I can post blog entries just by sending an email.
Brilliant!

Here is my order of voting preference.

1. Don't - if my non-vote will be widely understood as a vote against 'government' as a useful technology.
2. Trusted - if there is a candidate I trust.
3. Endorsed - if somebody I trust has endorsed a candidate.
4. Challenger - if one candidate is an incumbent.
5. Don't - if a non-vote is ignored, and there is nobody I trust running, and nobody I trust has endorsed anyone, and there is no incumbent.

I discovered a sadly funny cartoon series about Complexitor. I see a lot of myself in that chicken. At some point along the way, I quite writing programs and started writing applications. I think that was the beginning of my Jeckyl and Hyde relationship with complexity.

I picked up John Resig's book Pro Javascript Techniques, hoping to learn something new about the language I love to mistrust. It didn't take long: page 20 dropped a bomb on me.

It's important to remember that references only point to the final referred object, not a reference itself. ... In Javascript, however, it traverses down the reference chain and only points to the core object.

That quote above explains how closures work. Except that it explains them by showing that there is no such thing as closures! It's just a complexifying word added onto a very simple design decision. When you set one variable (aka reference) to refer to another variable that second reference is just transitory, it's the object that it refers to that the first reference receives. The second reference's scope is not relevant. The fact that the references have different scope is not relevant. There is no "closure".

The way I think of it, objects do not have "scope". Instead all objects live in a special magical world where is meaningless. It's like a magic array out in memory where all objects live together in harmony, regardless of where they were created or what "scope" they were created in. Indeed the objects don't even know what scope means. Now sure, if it comes to pass that nobody is referencing that object, it will be garbage collected. But that doesn't directly have anything to do with scope.

So that's it. Resig taught me that, when variables are set to other variables or arguments, it's the object reference that is recorded, not the other variable or argument itself. So it really doesn't matter where that other variable or argument came from, it doesn't matter what it's scope is. This is not "closures" it's just how references and objects behave. Calling it by some fancy name and trying to explain how it is used, as if that explains how it works, is confusing and distracting. At least it was for me, up until now.

I hate the stupid 16-bit-era apps they still ship with windows. I spent over $100 on vista and can I get a modern, friendly font viewer for it? Nope. So I wrote my own. It's no miracle or anything. It just lets you move around in a folder full of fonts, check them out, delete them if you don't like them, and abandon the program with a single Escape keypress. I think it's a vast improvement over the crappy Windows fontview.exe. This program and source code is in the public domain, do whatever you want with it, it's not my problem. Winforms, C#, .Net 3.5. The code is pretty ugly. This project was a "get 'er done!" more than a "look at the pretty design patterns!"

Screenshot
EXE
Source