November 2011 Archives

There's been a lot of talk in the last couple years how prophetic Ayn Rand's Atlas Shrugged is. Many have noted the parallels, but one that I haven't seen made anywhere are the ones between Colorado of the book and North Dakota of today.

In the midst of a widespread recession, North Dakota is booming. The oil industry is leading the way with ripples in air traffic, rail traffic, lodging, and even higher education. It's attracting industry and the industrious just like Colorado did in the fictional work.

In the book, what did Colorado desperately need? Reliable rail transportation. The government and its crony capitalist collaborators fought tooth and nail against the heroes of the story, Dagny Taggart and Hank Rearden, as they tried to supply it to the state.

And in real life, we have the spectacle of Obama "delaying" the start of the Keystone XL pipeline. Aside from linking the booming shale oil industry in Canada with the Texas refineries, it was also going to be a vital transportation vehicle for the Bakken Formation.

I'm more than a little worried to see what else might come to pass from Atlas.

It's really tough: I read Steve Yegge's description of the perks of working at Google Kirkland and I'm torn. On the one hand, damn! Can you imagine working in a cushy environment like that? It's the lap of luxury and you don't even have to be a billionaire to enjoy it—you just need to get hired by Google!

On the other hand, damn! Can you imagine working in a cushy environment like that? It seems like you'd get so soft because of the coddling and you'd really have to work to avoid feeling entitled. It seems that Aaron Swartz may have been on to something with his critique of life at Google. It certainly appears that Larry Page might have second thoughts.

Personally, I like the work. All the music studios, dog parks, gyms, and such seem like distractions from work. Don't get me wrong: you definitely should take breaks but a walk would suffice. Moreover, free food and all the rest cost a lot of money. It doesn't come out of salaries or capital expenditures, seemingly, but it's got to come from somewhere. My guess is that Google's generating cash out the wazoo and the cost of perks is not yet registering on shareholders' radars.

The effects of this sort of coddling poses a real threat both to Google and the employee. When there comes a time to reduce the perks—and that seems inevitable—the business risks alienating employees who have come to expect the perks. For the employee, he or she will have a difficult time at the next company if they can even find one comparable in pay. Personally, I say no thanks. I'll take my generous pay, excellent benefits, flexible schedule, and reasonable perks any day.

I have been following TDD since the days of extreme programming, as I am always interested in better ways of doing software development. At first blush, test-driven development sounds like manna from heaven: it embraces YAGNI as a guiding principle and focuses on comprehensive unit testing.

Far too much development is anticipatory, with overengineering the usual result. Faced with huge, complicated code bases (or the prospect of them when commencing a new project) it is tempting to order TDD as a check against that temptation. In my experience, though, the overengineering mindset does not go away under TDD—it just transforms into a zealotry towards code coverage.

And that is my biggest gripe with TDD: creating unit tests feels like development and looks like development but it isn't development. It is very easy to get into the business of producing unit tests rather than releasing product. (I say this as someone who presented a class on unit testing at a company conference in 2008. I did a pragmatic style of TDD for approximately 2 years around that presentation.)

Assuming then that you can rein in that tendency to strive for 100% code coverage, the next biggest problem with TDD is that the biggest part of an application lives on the client—mostly outside the reach of the xUnit systems. Obviously there are ways to attack client-side unit testing but they are all inherently brittle due to cross-browser issues and sometimes frequent changes to user interfaces. As Web applications become increasingly client-based, more and more development is outside the scope of TDD. (Or within scope but at considerable cost and effort.)

I have become disenchanted with TDD and its ilk over the years for these reasons. In my opinion, the best way to improve quality is to build time for developer testing into the estimates and hold developers accountable for quality product. Emphasizing cross-browser and functional testing at the developer level before a handoff to QA has resulted in better quality in my experience than a doctrinaire emphasis on unit testing and code coverage. (Accountability is another subject entirely and I have a lot of thoughts surrounding that as well, which I'll share someday. Read Codermetrics by Jonathan Alexander for more along those lines.)

I've finally decided to take the plunge: I'm installing a Linux distro as a VM on my Mac.

I have resisted doing this for years and years and years. I've long thought that going Linux just meant that you're doomed to perennial tweaking and figuring out incompatible drivers. I don't give a rip about either of the "free as in's" when it comes to operating systems—I'm an unabashed Mac user, I pay for all of my software, and my programmatic life is completely Windows-based.

So why am I doing this? And why now?

Python.

I have been reading some really intriguing books on data analysis, social networking, and monitoring and all of the examples are in Python. I've always been tempted by Python the language and Python the community, and I've even made minor forays into that world. I know that Mac OS X is a great platform for Python but I have zero familiarity with Linux.

In the end, if I make anything significant, I'm going to want to host it on Linux so why not start now. With a virtual machine, I can duplicate my final environment without polluting my Mac or worrying about the differences between the two. I initially looked at Ubuntu but I think it's really more of a consumer-grade distro whereas I want raw server.

A colleague at work said that he uses CentOS; I figured that's as good as any and he certainly knows more than I do. So I downloaded CentOS 6.0 minimal and I'll see how it goes.