"Sneaking" Ruby into production?
I stopped reading Hal Fulton's interview when he said it was a good idea to "sneak" Ruby into production.
Part of programming professionalism includes self-discipline and creating solutions with tools that the corporation knows about.
Not, passive aggressive technical games.
Passive aggression merely makes actual social change, and even corporate change, that much more difficult.
As regards social change, the passive-aggressive urban male lifestyle of substance abuse, pathological irony, abuse of women and money orientation becomes an "alternative lifestyle" with enough features of dominant behavior to "mature" into the behavior of the neoconservatives in Iraq, where Sixties rhetoric about revolutionary change covered up the destruction of a society, and the failure to replace it by anything except the chaos of young men.
As regards corporate change, the passive aggressive replacement of a common language and a common programming style deprives mature computer people of a voice with which to communicate to management their concerns, because the corporation has already handed over its data system to a male class whose anger is targeted at the real end users, people without any power to challenge the system when, for example, it claims that 100 is not divisible by 20 and in consequence refuses to give the user 20.00 from a 100.00 balance.
On the job, follow the rules and ask for justice. Ask why the executives don't have to worry about their health care. If the company wants you to use Visual Basic .Net then learn how to use it with elegance and safety, even as Brian Kernighan used Fortran with elegance and safety.
And if you get slapped down, come and join me on Lamma Island.
Agreed on Sneaking
After reading your comments, Edward, I went back to check out that part of the interview again. Here is the passage:
I'm in favor of the trickle-up method, and I'm not down on Ruby or Hal Fulton at all, but I must agree that Hal probably crosses a line in advocating a "sneaky" approach to introducing Ruby into one's work environment, especially as uses of the language get closer and closer to production usage.
Edward, you wrote:
I've worked in environments in which programmers were afforded a certain amount of freedom in solving problems in ways they saw fit, and management was smart enough to give them room to do so. I worked on a project where a programmer used YACC to shave a few weeks off of a large testing effort. Management was thrilled, and the programmer was rewarded. Because of the limited scope of the solution, and because the programmer was tacitly working in a situation where this kind of freelancing was OK, there was no discussion about whether the programmer had made an appropriate technology choice or taken too much initiative. But above a certain level in the system, no such freelancing was allowed, and everyone knew to respect that. I've also worked in shops where not only tool choice, but also choice of design patterns and techniques, were critical maintanence factors, and the people in charge had to regulate programmer freedom in these areas closely. In either case, the professional programmers working in those shops worked within the limits--which is not to say that people did not try to push the limits a little, which sometimes led to innovation for the organization.
Edward, you may not agree with my equivocation, but I think sometimes it *is* better (or at least easier) to ask forgiveness than to ask permission, especially when the stakes are the success and failure of a project with which you have been tasked, and especially when the nature of the environment is such that seeking permission would surely lead to failure. But there are definitely lines that when crossed give way to sneakiness and passive aggressive maneuvering.
Dan