Peanut Butter Programming

When I first started messing with dynamic web pages it was using Perl and CGI. It was fun at first getting a page to respond based on some algorithm. It was also easy to overlook the growing mound of HTML strings embedded in your program. It soon became apparent that this approach doesn't scale very well. Keeping track of which tag needed to be closed and when was too much like keeping track of dynamic memory allocations in C.

Java came along with Java Servlet Pages (JSPs) and it seemed like a huge improvement. By inverting the relationship between code and HTML, you didn't have to have your HTML all strung out in little bits in the program. When you wanted to include some program logic in your page, you had two choices: write an extension so your logic could be expressed like an HTML tag, or you could embed it as a code-snippet directly in with the HTML. While there were plenty of examples of how to create your own tags, the overwhelming amount of JSP code I've seen took the other approach. To the extreme. When some behavior was needed in multiple places, sometimes it refactored into a common file and then referred to from multiple pages. Other times (which translates to whenever possible), it was copied and pasted around with the justification of "I just need it to work". The result was a file with little bits of program strung out through your HTML. Sometimes mixing two things can prove to be a good thing. remember the the TV commercial for peanut butter cups? "You have your peanut butter in my chocolate! No, you have your chocolate in my peanut butter!" Unlike that TV commercial, mixing HTML and code is a recipe for heartburn. Peanut butter may be tasty but will stick to everything it touches and you'll end up with a greasy mess to clean up if you're not careful. That's why I call this "Peanut Butter Programming".

Why do developers keep using approaches like 'cut-n-paste' even though they usually know better? When the choice is between doing the expedient thing and the right, people typically want to do the right thing but only to a point. If 'cut-n-paste' is simpler or easier than doing the right thing, the playing field becomes so tilted that some other motivation needs to be strong enough to deter choosing the short-term solution. Code standards are one example of that kind of motivation. They express a value judgment that the increasing maintenance costs of supporting bad code is not worth the time saved by taking short-cuts. If the programmer knows he'll have to face his peers and explain why he took a short-cut, his choice becomes "I can do it quick-and-dirty (QaD) in 5 minutes instead of the right way which would take 15 minutes. But if I do it QaD, I'll have to spend 30 minutes arguing at the code-review. It's not worth the argument so I'll just do it the right way and save myself the trouble." This sort of balancing act shows up naturally during pair-programming where having the second coder around makes it harder to justify writing messy code on the first pass.

Recently, I went to a class on Microsoft's ASP.NET technology. Setting aside any feelings for the company, the way they approached the problem of mixing code and HTML was to make it easier to do the right thing. They introduced the concept of a separate 'Code Behind' file which contains the C# or VB code for a given page. By making it easy to manipulate objects on the page and respond to events while keeping the code separate, they've made the right way also be the easiest way.

Even experienced developers will justify taking a short-cut, however short-sighted, if doing the right thing is hard enough to do relative to the short-cut. Different people have different tolerance level for short-cuts. Understanding why people do the things they do isn't easy but gives us the perspective needed to address the problem.