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…
A normal thought would be “overloaded” with too much data coming in, but the 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.
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 friend of mine lives in a condo tower that has one of those buzz-in intercoms beside the front door: to visit I press #162, it calls him and gives him the option of pressing “6″ to buzz open the lobby door. Of course those were designed back in the days of land lines, but it works perfectly well with his mobile phone. And, because it’s a mobile phone, it works even better: for example, when he locked himself out one evening, he stood at the front door, buzzed #162, answered his mobile and pressed ’6′. Ta-da, instant iPhone-key-replacement.
So while I was reading “Top 10 Things That Bother Me About Hotel Rooms“, it struck me that the solution to his issue #10 (check-in delays) would be better served by having a smartphone app for frequent travelers that just acts as the hotel room key. It would be like buzzing #162 and pressing ’6′ except that it would be for the hotel room assigned to me. I wouldn’t even have to go to the front desk: the app would say “your room 1534 is ready” and I’d go straight to the 15th floor. When I got to room 1534, I’d press the “unlock” button on the app and, bzzzt, the door would unlock and I’d stroll in. No delays, no need for a card key: just my frequent traveler app.
The software psychologist thought here is to think about better processes, not just efficiency improvements for existing processes.
Update Jan 27: apparently other people think this is a good idea [TechCrunch]
Back when we were poor college students, our first vacuum cleaner was a well-used Filter Queen Majestic. It served us well for decades but finally gave up the ghost. It’s probably easy to fix – I think it’s just the switch – but the filters are getting hard to find and so I decided it was time to try something new. Of course the Dyson bag-less vacuum is all the rage, but it’s also expensive, so I spent some quality time with Consumer Reports and learned that, actually, the Sears Kenmore 22614 is equally good (especially with pet hair) and more reasonably priced. Less than an hour later, we’re the proud owners of a new vacuum.
But what I failed to realize is that vacuum technology has advanced dramatically in the 30 years since our old Filter Queen was manufactured. We probably could have bought any lousy new vacuum and overjoyed (or as overjoyed as one gets about vacuum cleaners). The 22614 is quieter (in spite of it’s Consumer Reports complaint about being “on the noisy side” – I guess that was written by people who didn’t own a 30-year-old Filter Queen) and more powerful (I thought the carpets were clean but boy was I wrong) and much easier to use (no filters! no bags!).
The software psychologist thought is not to assume that things are the unchanged for everyone just because they are unchanged for me/you.
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.