Blog Driven Development

A colleague recently pointed out Scott Berkun's post on Asshole Driven Development. Its a very interesting read, both the original article and the numerous comments that follow it. Sadly, as a developer with a fair amount of experience, I have seen and lived through many of the anti-patterns that are described in the article. As a newly minted manager, I am trying hard to avoid slipping into these, but only time will tell if I will be successful.

One of the comments had to do with the Blog Driven Development (BDD) pattern, and it struck really close to home. In the author's own words:

Developers who are constantly thinking about the subject of their next blog post. Nearly every somewhat interesting line of code they write is extracted into a blog post.

I admit that my development work and my blog feed off each other. However, unlike the commenter above, I don't think its necessarily a bad thing, either for me or my employer. How so? Let me explain...

A lot of my posts center around new open source frameworks or tools I started playing with to learn more about them. Examples are Tapestry, HSQLDB, classifier4j, etc. They are not used by my employer, but they are sources of ideas to use in the tools and code that my employer has in use. They also benefit me, since I now know enough about the tool or framework to start using it without training should I happen to work at a shop where it is used.

Some of the frameworks/tools I check out in this manner have actually been implemented at my current employer's site. Examples are Maven2, PyLucene, etc. My employer benefits from the free research I do on my own time to be able to start using it in a corporate environment, and the free evangelism I bring because I genuinely believe in the product. I benefit by having my favorite framework or tool become a corporate standard, with the consequent improvement to my workday quality of life.

Another category of posts describe little scripts that do something interesting. The idea for these scripts usually come out of requirements from my work. However, they are generally useful, and I post them because I could not find something similar when I needed it. Personally, I have benefited enormously from scripts (and other information) posted by others on the Internet, and hopefully my script can save some poor overworked sod with similar requirements from having to spend time writing one himself. All the scripts I describe were done because I felt the need for this, developers before me were comfortable with doing the scripted work, so I guess I must be an incredibly lazy person.

Yet another category of posts describe small bridge programs and associated XML configuration which hook up our legacy system to Spring, our MVC framework of choice. Like the scripts described above, I believe these are generally useful, as they can be adapted to other shops with legacy MVC apps who are trying to move over or co-exist with Spring. Having suffered through quite a few MVC frameworks, both third party open source and home grown, I find that Spring is the cleanest of them (at least so far), so I guess we can simply chalk these up to evangelism.

Some other posts describe small Java applications that implement some of my pet ideas. Some of these ideas are born out of inefficiencies at work, and they demonstrate solutions to address them. My previous employer actually applied for a patent on my behalf based on one of these ideas. I had published the solution on my blog, and then sent my boss an URL to the post so he could decide if the solution was worth implementing in-house. Obviously, I had to pull down the post once the patent was applied for. I mention it here only to demonstrate that BDD can lead to benefits for both the employee and employer.

Employers would like to believe that once they pay you a salary, they own every one of your creative ideas you generate during your tenure. There is also apparently a (dumb IMO) law (at least in Texas) according to Evan Brown's post - Does Your Employer Own Your Thoughts that supports this claim. However, smart employers should realize that a situation like this is inherently unfair and enforcing it can only lead to bad morale. Creative people would love for their ideas to get implemented by their employer, and will often work on their own time to make it happen, but they expect and deserve credit in the form of recognition and money. Things are better in California, where the employer cannot claim your ideas if it is done on your own machine on your own time.

There is also the issue of Non-disclosure Agreements (NDA) between the employer and employee. Employees are typically privy to the companies intellectual property, which they need to do their daily work. An employer expects, and rightly so, that these will not be divulged to the outside world. Bloggers in general obviously tread a very thin line, and often have to rely on their best judgment. I follow a very simple rule to honor this. None of my blogs describe anything that was not first developed by me, based on my own ideas, on my machine, and on my own time. That way, I ensure that all the things I describe do not belong to anyone else. I may choose to implement it at my employer, but until I do this, the intellectual property belongs to me to do as I please with it.

Anyway, I hope I have succeeded in putting forward reasons to illustrate why Blog Driven Development (BDD) is not necessarily bad. Because programmers practicing BDD are driven by the need to publish their ideas on a schedule, they will frequently also generate ideas, either their own or from other tools or frameworks they have looked at. Oh well, on to my next (BDD) project.