Saturday, July 23, 2011

Apple HFS as a provencial technology

Mac's HFS+ filesystem is case insensitive. I'm a little disappointed that Apple is so provincial and short-sighted.
 
$ touch "Amy"
$ touch "aMy"
$ touch "amY"
$ ls
Amy
^ only one file got created
but
$ touch eñya
$ touch enya
$ ls
eñya
enya
 
So it is OK for some characters to automagically translate but it is not OK for others.
 
Be very careful when copying files from the Web to a Mac. One supports international alphabets in file names, the other apparently does not.

Pairing for the Imperfect

Consider System. Faults. Expected Behavior. 
Reconsider. How to go from Here to There?
How to make it work. 
Maximize coherence, minimize arbitrary decision points.  
Now, go. 
 
Have "pair" step in after work is halfway there. 
Explain. Rationale rebuffed.
"Need to make it go," is the reason, "need to rethink" is the justification. 
Toss out the changes. Then watch as he goes about.
 
Considering System. Ignore faults as unimportant. Dismiss Expected Behavior.
Substitute bald assertion for consideration. Just enough to get by for now. 
Ignore coherence, let number of arbitrary decision points float freely. 
Spend more time fixing faults instead of providing functionality.
Repeat.
 
I've seen that process play out over and over now. Enough to realize that it is a well-defined strategy for playing out a work slowdown while simultaneously playing up to the customer's desire for immediate satisfaction.  
 
Often, after repeating the latter loop two or three times, it dawns that the first path was the right way to go.  Except that in a dishonest environment the original authorship will be discarded, the ideas having been surreptitiously adopted by those who were initially dismissive.  This is an antipattern that pervades the tech industry.

Monday, July 4, 2011

Spurious environments give spurious results

I've said before, and will say it again: the suitability of a programming environment (or platform, or language, or technology stack) to a task is inversely proportional to the number of coercive statements you have to use it to get it to behave the way that is intended.

Put another way, if you find yourself trying to trick your computer to get it to do what you want it to do, you probably aren't working with the right mix of technologies.


That said, most programmers must give in to that dark impulse on a daily basis, creating elaborate fictions as it were, because the mix of technologies they must tolerate is often very unsuitable. Sometimes it seems as if the entire profession is working at the level of medieval barbers, just hacking at bits and hoping their patients don't die before paying the bills. 


A similar heuristic is that an operating environment will be as predictable (unpredictable) as it is closed (open). Or, stable environments give stable results, and spurious environments give spurious results.  You're likely to see this in Web programming when developers fail to grasp the idea of closure, and do not ensure that deployments are provisioned in precisely the same way as development and test environments.

For instance, the difference in a database from version 5.93 to 5.94 is not likely to be very great, but most of the likelyhood of failure arises from the fact that there is a difference, not the particular version numbers used.

I keep running into this issue with a Rails project, because "rake," one of the most central tools in the tool chain, is being treated as a shared component. Rake gets updated from 0.8.7 to version 0.9.2 by the bundler at some point, and things start to break.  Fortunately, bundler complains:


You have already activated rake 0.9.2, but your Gemfile requires rake 0.8.7. Consider using bundle exec.

The "bundle exec" thing is a little misleading perhaps, but at least it is actually telling the truth. The punt for now is to gem uninstall rake and remove the 0.9.2 version. The honest solution is to make sure each project gets to see only its own version of rake.