Software Psychology
Bjorn Freeman-Benson
Code Screams

Martin Fowler explains a code smell as “a surface indication that usually corresponds to a deeper problem in the system”. He explains that there are subtleties and that “The best smells are something that’s easy to spot and most of time lead you to really interesting problems.”

Code screams are my description of something similar, but different: a code scream is a behavioral indication of a deeper problem in the system. It differs from a smell in that it is behavioral rather than structural. For example, a scream is a user interaction action that takes an unusually long time to complete whereas a smell is a method that has more than a dozen lines of code.

Code screams are almost always found in live production systems because reality is much less predictable than anyone can imagine and, as good software developers, we’ve already accounted for all the predictable situations. Thus the only way to hear the code screaming is to have full spectrum software analytics live on the production system.

As a small example of what I’m talking about, here’s one of our production systems screaming for help: the response time goes way up, brown out start happening…

Response time goes up

A normal thought would be “overloaded” with too much data coming in, but the incoming data rate is unchanged:

Incoming data rate is unchanged


With further digging, we discovered that the code was in pain because a DDOS attack was underway on our upstream network provider causing very slow TCP streams and thus too many open and pending sockets, hence the servers couldn’t accept additional requests. That’s the essence of a code scream: a behavioral indication (massive increase in response time) of a deeper problem in the system (inability to handle alive but very slow TCP streams).

The software psychologist action plan is to incorporate full spectrum software analytics and alerting on your production systems and then pay attention when they start screaming.

Inspired by the IndieWeb

At New Relic Portland, we’ve put together a nice series of talks we call FutureTalks. We’ve had a number of great talks already but the most interesting one, in my mind, was last week when Amber Case from Esri spoke about the “Rise of the IndieWeb“. Her thesis was that we should each own all our own content rather than relying on various companies to warehouse it, control it, and potentially lose it all when they go out of business. The extreme position of the IndieWeb is that one should host all one’s own content, but a slightly more reasonable approach is that one should at least have a copy of all one’s content.

Inspired by that talk, and realizing that I have a lot of content on twitter (both @bjorn_fb and @kingofslugs), and a small amount of content on Amazon, StackOverflow, Yelp, and other places, I set about to write an automatic indie-web-izer cron script for myself. So starting soon, I’ll be owning my own contributions (or at least I’ll own the definitive copy of them) and I’ll be archiving them here on this blog.

Stand by for the experiment…

A New Year, A New Leaf

I had been writing a personal blog since the late nineties using the simplest of technologies: static files and some Perl scripts. While working at Eclipse, I blogged regularly there on a WordPress platform. About the time I moved on from there to New Relic, I decided to merge my three blogging efforts (personal, professional, and hobby) into a single effort with tags and permissions and such. Not seeing an obvious technical solution and being a computer scientist, I wrote my own. It wasn’t bad and it did everything I wanted, but it had a seemingly minor feature that had a major impact on my blogging, i.e., my writing rate went to zero.

The feature was well intentioned but, wow, what an unintended consequence. The feature was to model the writing process on software engineering: write everything locally, run a “compiler” to build the blog, and then synchronize (deploy) it to the server for publication. The theory was that I would be able to write while connected or disconnected, that I could manage articles and drafts using git, etc. In hindsight, software engineering ideas are ill-suited to writing: the friction I added over a wysiwyg editor was greater than the occasional benefits of revision control and scripting so, like hitting a brick wall, I stopped writing.

Lesson learned that writing-flow is not the same as coding-flow, I’ve switched to that gold standard of blogging, WordPress. I’ve built a custom theme to match my previous (perhaps dated) look and I may write a plug-in or two to restore some of the features of my previous platform, but all that is in the future. The web is full of posts saying “I’m starting a blog” and so let’s see that I actually write more frequently before declaring victory, but so far it’s feeling better already.