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.

State of the Blog Address

I just wanted to list some of the unexpected and wonderful things that have happened since I started this blog last month.

I don't anticipate that anyone reading this will be floored by these things, but they've personally affected and impressed me. I never really thought anyone would find this blog.

So here we go:


1. Within hours of my very first blog post, in which I discussed YubNub and a couple commands I submitted for it, the creator of YubNub himself left me a comment thanking me for my contributions.

2. After lamenting the dearth of shrinkwrap software companies in Grand Rapids and writing a blog post about it, the part owner of a really cool company in Grand Rapids, that was unknown to me at the time, left a comment to tell me about the shrinkwrap software his company was producing.

3. The day after I wrote a blog post about Aardvark'd and why I really enjoyed it, one of my favorite people (who is also featured in Aardvark'd), Aaron Swartz, left me a comment.

4. Within hours of writing a blog post about how I wanted to start contributing code to an open source project for the first time (possibly Firefox), Asa Dotzler wrote a post on his blog asking his readers to help me get started contributing code to Firefox.

5. Also in response to the blog post mentioned in #4 above, the co-founder and executive director of the Participatory Culture Foundation, makers of Democracy Player, emailed me and invited me to work on that project.

6. My blog currently occupies the first search result for "Matt Blodgett" on Yahoo, and the third result on Google.


Yay for blogging!

Contributing to an Open Source Project (Part I)

I'm thinking seriously about contributing to an open source project for the first time.

It's about time I put my money where my mouth is and get some code out there in the open.

As I've never done anything like this before, my head is swimming with questions:

1. Which project should I contribute to?

There are a million of them out there. Should I just pick the one that I respect the most? If that's the case, then it'd be Firefox, hands down. Should I choose the one that needs the most help? Should I choose one that's written in a language I like? What the hell language is Firefox written in anyway? C++?

2. What should I contribute?

Should I start out doing bug fixes? Should I contribute something entirely new...a Firefox extension perhaps? Oh god...I've heard some awful things about Firefox extension programming. I'm hoping the upcoming "Programming Firefox" might be able to lend me a hand there. Maybe I could start really simple and contribute a search plugin to my beloved Mycroft project.

3. How do I contribute?

How the hell do I even get the code I write included in the project? I suppose I'll have to revert back to my college senior project days and fire up TortoiseCVS or perhaps some Subversion client. How long does it take to get new code into the code base? What does that process look like?


As you can see, I've got a lot to learn. But it's about damn time.