Brain Food 5-26-2007

In the tradition of some other bloggers out there, I'm going to simply post a few links to things that influenced my thinking in the last few days, and write a sentence or two for each one.

So, without further ado:

• Is SQL Manual Memory Management? - I've been thinking about ORM a lot lately, and this post by Ruby on Rails aficionado Giles Bowkett makes a very tantalizing point/prediction about the future of ORM. This sentence sort of sums it up: "Maybe one day the idea that database management should be part of the language will seem as obvious and basic as the idea that programmers shouldn't have to do memory management by hand." I also found one of the comments left on the post to be very insightful: "Having SQL in a language will most likely turn into the same type of feature as having regular expressions in a language."
• Hanselminutes Podcast 65 with Martin Fowler and David Heinemeier Hansson - This is a mindblowingly good interview that addresses many of the things that have been on my brain lately, and does so with two of the greatest minds in the dev world.
• Rob Conery on Subsonic - This is an excellent .NET Rocks! podcast featuring the creator of an awesome tool called SubSonic that brings many concepts from Rails into ASP.NET.
• Meetuplex - Biting satire of Google from the people at Meetup.com. I love Google, but this is just too funny. "At Google, you get your free Google-approved haircut at the Googleplex by a Googler with an IQ in the 99% percentile of all haircutters."

Moving from .NET to Ruby: The IDE Question

I've been thinking a lot about Ruby lately. From the limited experience I've had with it, it seems like a very cool language. But one thing has always been present in the back of my mind: what about the IDE?

After being severely spoiled by Visual Studio for the past couple years, I can't help but wonder how I could really ever become serious about Ruby (and Rails) development without something equivalent to Visual Studio. More specifically, how could I ever feel productive without IntelliSense and the wonders of ReSharper?

Keep in mind that I programmed for years without ever seeing an IDE. Throughout college, my toolbox consisted solely of Kate and a console. It wasn't until an internship that I undertook during my senior year that I first felt the sweet embrace of Visual Studio and the truly awesome productivity gains a nice IDE can grant you. But now that I've seen these wonders, I can't "unsee" them.

From what I've read, it appears the de facto standard editor for the Ruby hacker is TextMate for OS X. I've heard wonderful things about TextMate, but could it really replace Visual Studio?

If I were determined to get serious about Ruby/Rails, would it be silly of me to continue using Windows and Visual Studio with something like Ruby In Steel (which I just read a great review of on SDTimes)? Or should I abandon my comfort zone and dive in head first with a Mac and a TextMate license?

I would love to hear from other developers who have gotten heavily into Ruby/Rails after spending years in Visual Studio. Which IDE/editor did they end up using? If they eschewed Visual Studio, was it a traumatic experience?

Silverlight != Sugarlight

Why did Microsoft have to rename WPF/E to Silverlight after I'd been listening heavily to X for several months?

The following refrain has been running through my head for days:

"Silverlight! Silverlight! I can't believe..."

Stupid Microsoft! Stupid punk rock!

Dynamic Languages with Silverlight

HOLY CRAP.

Finally

After waiting patiently for nearly two months, SICP is finally here.

Pulling it from the box and seeing it "in the flesh" for the first time was a little magical. The cover is enchanting. A wizard appears to be casting a spell. There's a mysterious lambda floating in the air.

Who knew a computer programming book could be so seductive? The cover superbly captures the mystique of the contents.

I can't wait to dive in and begin casting spells in Scheme.

Conservation of Complexity

I don't remember exactly when it happened, but it was many years ago that I reached an intuitive understanding of the law of conservation of energy. One way to state this law is: "Energy can neither be created nor destroyed." My perception of the world was forever changed the moment that I first understood this idea. This was a similar moment to when I first intuitively understood the theory of evolution. These are ideas, that when you really understand them, reach out their tendrils and snake their way into every aspect of your perception. Nothing can escape their implications.

So I found it fascinating to read this posting to comp.lang.forth (which was linked to from the programming reddit), in which Elizabeth Rather discussed a certain axiom supposedly formulated by Chuck Moore.

She referred to it as "conservation of complexity," and it goes like this:

"Any given problem has a certain intrinsic level of complexity. In the solution of the problem, this complexity will be conserved: if you dive in with too little advance thought, your solution may become very complex by the time it's done. On the other hand, if you invest more in thought, design, and preparation, you may be able to achieve a very simple solution (the complexity hasn't gone away, it's become embodied in the sophistication of the design)."

After reading that description, a light bulb lit up in my head as I realized that this may be another one of those deep ideas. Conservation of complexity may be a special case of conservation of energy. This is very intriguing and seems to me to intuitively make sense. Looking back on software I've written, I have indeed seen this in action. I even once told a co-worker at my last job, when we were discussing the design of a program I was writing for him, that, "I want all the complexity on me, not on the users." I convinced him to change the requirements of the program so I could shove more of the complexity "behind the curtain," as it were, and not burden the users with it.

So really what Chuck Moore has (supposedly) said is just a more elegant formulation of what I have known to be true of software all along: you can move complexity around, but you can't destroy it.

Thoughts on "The Mythical Man-Month"

I just finished reading "The Mythical Man-Month," and I wanted to write down some thoughts before I forgot them.

Although each discussion in the book drips with insight, there were a few things that particularly got my attention.

The thing that most struck me was a thing that had been in my mind and on the tip of my tongue for months before I picked up the book. Brooks calls it "conceptual integrity," and it serves as one of the central themes of the book. The most critical thing to the success of a software system is conceptual integrity. In order to be successful, the idea of what the software system is and what it does cannot be decided by committee, but should instead be determined by one or perhaps two minds. Although I've only been developing software professionally for a couple years, I've seen a lack of conceptual integrity plague just about every piece of software I've worked on.

Another of my favorites was the chapter "Plan to Throw One Away" because, again, it strikes close to home. The general idea here is that when an organization is building software based on a totally new idea, the plan should always be to recognize that this first system will be a prototype that will be discarded and not delivered to customers. The organization and the powers that be must accept that it is literally impossible to get a new concept right the first time. Trying to pile new features on top of a prototype as a long term strategy will only lead to much sorrow and gnashing of teeth.

I also loved the chapter "No Silver Bullet--Essence and Accident in Software Engineering." This is the essay through which I originally became aware of Fred Brooks. Many times I would be reading a discussion of some new magical approach to software engineering on the Web, and someone involved in the discussion would reference this essay. I always thought I knew the general gist of it just going by the context in which I saw it referenced. But now that I've actually read it, it's even more insightful and prophetic than I could have ever imagined. It faithfully predicts many of the trends that have emerged since its original publication in 1986 and which ones would catch on. I was fascinated reading Brooks when he talked about how all the difficulties in software engineering can be classified as either accidental or essential, and that new approaches only really matter if they attack the essential.

As someone who cares deeply about his craft, I feel that I've been enriched tremendously by reading "The Mythical Man-Month." I could certainly never look at software engineering the same way.