As April came to a close, the month could be summarized by a saying attributed to one of our country’s Founding Fathers, Benjamin Franklin, who said “but in the world nothing can be said to be certain except death and taxes.”

On April 15th, we (those of us who are US citizens) “celebrated” Tax Day – a day when we file our annual tax returns. While I could go off on a rant about how privileged we are to pay to file our taxes electronically in this day and age, I’ll save that for another time.

Secondarily, I ran across an article on how blogging may kill you in the New York Times. The article references the sudden deaths of two well known bloggers and the near death experience of a third blogger (he survived a recent heart attack). The article speaks to the unhealthy lifestyle that these bloggers adopted. However, it does clarify that death by blogging has not reached an epidemic level. (Phew – I was starting to get worried!)

In all seriousness, reading the NYT article does raise an important life lesson: too much of anything is bad for you. While that clearly applies to standard activities such as eating, drinking, etc., it can also apply to software development work - since coding at an extreme pace for extended periods of time will earn you a fatigued, non-productive development team.

You see, software development is often equated to a runner’s sprint, where energy is expanded at the instant that the runner leaves the block (IOW, development project starts) and peaks until the runner crosses the finish line (IOW, the site/application launches). And while runners recognize that once the race is done they need to maintain movement, albeit at a slower pace, organizations/development leaders often struggle with letting the team slow down since there’s more work to be done. Right, there are new projects to complete, clients to serve and a business to run?!

While some developers are known to furiously code for days and nights and then just vanish off the radar, others have found that they can take a break by doing R&D work. Why R&D work? Well, the one common motivator in developers is that they have an insatiable appetite for learning and problem solving. It’s the developer mind-set (and some may say it is in the developer’s DNA). So assigning developers formal R&D time after a project enables them to take a crack at a new technique that they’ve read about but never had time to get it working. This is also a tenent of Agile software development, which we follow at Enguage and find helpful in getting projects done on time. So when developers seek a break, I’m thrilled that they focus on R&D work because it is development.

While this works for us, I’m wondering what else have you tried to give your mind a rest in between projects that still allows the company run like a business?