![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
software bureacracy: lost key
May. 9th, 2005 01:06 pmSaturday we went to OSH to buy one roll of sod, just one roll, to cover the results of my lawn sprinkler refactoring. I paid, but sod was in a fenced area, and someone had to unlock it. The nearest guy, one-eyed, said he'd go find the key. Several minutes later I found him peacefully talking to customers.
Meanwhile, another guy started looking for the sod key as well. The guy's name was Amil; he told me that Joe had the key, but told someone that he gave the keys to Amil, and he, Amil, did not get any keys. Then they started looking for Sergio. Walking around, I found Joe, and Joe said that it is Sergio. We all got together, and I asked Amil if he could talk to the managers. He said he was already trying to call them, but nobody answered.
Finally Sergio appeared, and, since there were three customers waiting, he asked for help from other guys. You know, in American corporate culture people that are higher in the pecking order can ask for help from those below them in the pecking order. So there was one more guy opening the back door of my SUV while I was loading my roll of sod. By the way, they all asked each other why could not they keep the keys near the cash register. So, the knew the best practices, but did not follow.
Now let's change the scene, and consider ourselves looking for an instance of a specific object of a class. We, in principle, can identify it, but, thanks God, there is a lot of encapsulation around, and, as a result, we are clueless.
We discover a class that keeps static reference to an instance of another class that can resolve the problem, given the right parameters. In particular, you have to provide a string object key. The key consists of a specific object key tag, then object id (that's all we know - object id), and then a postfix; using all this, that obscure class can retrieve the data from a database and instantiate the object for us. And do it every time we request the object, since who care about cache? Managers? You cannot find them, they are busy managing important things.
Bizarre: instead of an object instance, null is returned, because, as it turns out later, a key should be prepended with a key prefix that more or less demonstrates the usage of this specific key. You could call it namespace, if you only knew that there are consistent namespaces. Actually, the only reason for that prefix existence is to remind those that find it in the database what it is about.
What, normalization? Talk to the managers. We have no time for data normalization. There is release pending, and we are just busy finding the key.
Meanwhile, another guy started looking for the sod key as well. The guy's name was Amil; he told me that Joe had the key, but told someone that he gave the keys to Amil, and he, Amil, did not get any keys. Then they started looking for Sergio. Walking around, I found Joe, and Joe said that it is Sergio. We all got together, and I asked Amil if he could talk to the managers. He said he was already trying to call them, but nobody answered.
Finally Sergio appeared, and, since there were three customers waiting, he asked for help from other guys. You know, in American corporate culture people that are higher in the pecking order can ask for help from those below them in the pecking order. So there was one more guy opening the back door of my SUV while I was loading my roll of sod. By the way, they all asked each other why could not they keep the keys near the cash register. So, the knew the best practices, but did not follow.
Now let's change the scene, and consider ourselves looking for an instance of a specific object of a class. We, in principle, can identify it, but, thanks God, there is a lot of encapsulation around, and, as a result, we are clueless.
We discover a class that keeps static reference to an instance of another class that can resolve the problem, given the right parameters. In particular, you have to provide a string object key. The key consists of a specific object key tag, then object id (that's all we know - object id), and then a postfix; using all this, that obscure class can retrieve the data from a database and instantiate the object for us. And do it every time we request the object, since who care about cache? Managers? You cannot find them, they are busy managing important things.
Bizarre: instead of an object instance, null is returned, because, as it turns out later, a key should be prepended with a key prefix that more or less demonstrates the usage of this specific key. You could call it namespace, if you only knew that there are consistent namespaces. Actually, the only reason for that prefix existence is to remind those that find it in the database what it is about.
What, normalization? Talk to the managers. We have no time for data normalization. There is release pending, and we are just busy finding the key.
