Nat Pryce has compiled a list of Laws of Software Development (and an addendum). I hadn’t seen all of them before, but I enjoyed the entire list. Some of my personal favorites:

Brooks’ Law

… adding manpower to a late software project makes it later.

The Cardinal Fundamental Law of Programming

It’s harder to read code than to write it.

And here are some that are perfect reminders for why agile methods are a good idea:

Hartree’s Law

The time from now until the completion of the project tends to become constant.

Hofstadter’s Law

It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Lehman’s Law of Continuing Change

A program that is used in a real-world environment must change, or become progressively less useful in that environment.

Lehman’s Law of Increasing Complexity

As a program evolves, it becomes more complex, and extra resources are needed to preserve and simplify its structure.

The Ninety/Ninety Rule

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.

There’s a lot of good stuff in there. Be sure to check out his full list.

Jonah Lehrer discusses the results of a new study that confirms what Thoreau already knew: Spending time in nature is good for the brain. I think the study is interesting, but I’m not alone in having already been a believer before there was scientific proof – just based on personal anecdotal evidence.

I’ve found that a weekend out of the city, whether it’s camping in Canada, car camping at a state park, or just visiting my parents in the country does a lot to recharge me. It helps me to put things back into perspective. Aside from sleeping enough, I think it’s one of the most important things that keeps me sane.

While I’m on the subject of what’s good for the brain, don’t forget how important play can be for the brain and for keeping your creativity alive.

About six months ago, Jesse and I were talking about how much Javascript code we had been writing and how it would be nice to have better (or any) test coverage of that code.

I had used Selenium a little bit and I spent a little time writing some jsUnit tests, but what we really wanted was to be able to run the javascript tests along with the other test cases in our Grails project. We figured that with Rhino, there should be no reason that you couldn’t use Groovy to write jUnit tests to test our javascript code.

And so Sumatra* was born. With a little invokeMethod goodness, I wrapped the Rhino api, making it more usable and readable. At the June GUM meeting, I did a little show and tell of some working examples and I finally just got around to creating a project home for it.

Give Sumatra a try and let me know what you think. And if anyone is interested in spending time adding to it and enhancing it, join the project!

* I started calling it RhinoUnit and found that there was already another project by that name. Hamlet suggested Sumatra because of the allusions to both the rhinoceros and Java (via the coffee bean).