The value of automated testing is predicated on trust. It begins innocently with a test suite that reports incorrectly. Maybe the test suite reports a lot of false positives, or maybe the test suite does catch enough failures. In either case, people stop running the tests. They stop maintaining the tests, and eventually the tests no longer function and are discarded.

For tests to remain relevant, this pervasive question runs throughout software testing: how can I trust that a unit test is actually exercising the code in question? This post talks about how mutation testing can provide a definitive answer.

Read more...


Marketing is not all about positioning product; it’s also about connecting with your consumer base.

This post contrasts two television advertising approaches to September 11th. Both ads refer to the destruction of the Twin Towers in New York City on September 11th, 2001 – 15 years ago today at the time of this posting.

The first ad is from a nationally-known beer brewer, Budweiser. It shows a delivery wagon being pulled quietly through a small town street by the company’s iconic Clydesdale horses. They somberly walk up to a park overlooking Manhattan, as the camera pans to the part of the skyline where the Twin Towers stood just four months prior. The ad ends with the Clydesdale horses kneeling in respect, then a fade to black with the words, “We’ll never forget”.

The second is a recent commercial from a San Antonio-based mattress company, Miracle Mattress. In this ad, a spokeswomen explains their special promotion for 9-11, that you can get any size mattress for the size of a twin. Behind her stand two salesmen, both in front of a tower of mattresses. She throws her arms back into the two men, who stumble backwards and knock over the two towers of mattresses. She acts upset about the accident, and then ends the commercial by saying jokingly, “We’ll never forget.”

Let’s compare the two ads. The Budweiser ad only aired once in January 2002, during the Super Bowl. Many people in the country were still in shock after 9-11. This ad showed no product, and was purely a positioning ad. It communicated its message of solidarity with and mourning alongside its consumer base. It did so visually with no voice-over, only backed by a somber soundtrack. They sought and obtained the approval of members of Congress and New York City’s mayor. You can read more about the making of the commercial here. AdAge rated this ad as the “most effective of the quarter”, as reported by Business Insider.

By contrast, the mattress ad had the opposite effect. Public opinion about Miracle Mattress was so negative after the ad aired, that the company had to close their doors indefinitely, as reported by CNBC. What happened?

Although I’m no expert on the mattress business, I understand that it is a high-margin reselling business. A firm like Miracle Mattress can probably afford a deep discount on its products for a limited time. The Twin Tower Sale tied into the theme of Patriot Day, making the promotion itself sound.

The execution of the commercial was adequate. The people in the ad seemed uncomfortable in front of the camera, and the visual gag of toppling a tower of mattresses was amateurish. Overall, though, the ad was on par with other low-budget, self-produced television ads that often get aired on late-night TV.

However, few would argue against the idea that the mattress ad was in poor taste. Many people compare the 9-11 attack to Pearl Harbor, in that both provoked a declaration of war and a military response. Even though Pearl Harbor was 75 years ago, I do not recall seeing any Pearl Harbor sales or other attempts to capitalize on that tragedy. That mattress ad showed a lack of understanding of the sentiment of its target market toward 9-11, and that insensitivity proved fatal to the business.

With proper framing, the promotion might have been successful. If Miracle Mattress had targeted the demographic of military and first responders in respect for the sacrifices made on 9-11, I think many people would have seen the ad favorably. For example, they could have limited the offer to just that demographic. Another possibility would have been to offer the twin price promotion to everyone, while also providing an additional benefit to members of that group like interest-free financing or free delivery.

Targeting is only one option. Miracle Mattress could have tied the promotion to their brand by highlighting some of the miracles of circumstance that happened on 9-11, and offered to donate a portion of the sale’s proceeds to an advocacy group like The Feal Good Foundation, which was founded by John Feal, a 9-11 first responder who was denied benefits for injuries sustained during the recovery efforts. In doing so, they could have strengthened their position as a consumer-minded member of the San Antonio small business community.

Marketing is not all about positioning product; it’s also about connecting with your consumer base. It is sad that Miracle Mattress had to learn this in such a swift and damning manner.


Today I want to describe another aspect of my bullet journaling, my weekly review. This is the first week I’ve taken a data analysis approach, and I am pleased with the results. I took a quick picture, which shows last week’s charts. (The page wasn’t flat, so the edges are blurry but legible.)

weekly review charts

As you can see, the picture consists of three sections. The left chart is a hyperdex, just like the ones I use for my daily entries (see my initial bullet journaling post for details). Here, I take an average of the entries for the 7 days. The legend is:

Color Meaning
Blue Highly productive
White Mildly productive
Red Unproductive
Green Relaxing

I tend to track time in 15 minute increments, though I’m not strict about it. Under the hyperdex, I show the order of precedence. If an hour in a day is classified into multiple categories, I choose the first color in order. So a half-blue, half-white hour is counted as blue. I then use the most common color in the week, with order of precedence breaking any ties.

This graph shows that more often than not, I’m sleeping between the hours of 11pm and 6am, and that I’m usually productive from 8am to 4pm. I found the red hour from 9pm to 10pm interesting, too. I don’t have enough data to discern a pattern yet.

The center section accumulates the niko-niko data into a bar chart. I first learned about them during my days as a scrum master, and they are a great data point to gather about teams (see also Agile Trail). A niko-niko chart is a simple rating of happiness on a scale. I use five values: very unhappy, unhappy, meh, happy, and very happy. Another popular variation is to eliminate the middle, neutral face. I kept it so that I wouldn’t have to weigh whether a day is slightly happy or unhappy on days when I’m feeling a mix of emotions.

Last week, I was happy four out of seven days, which honestly was more than I was expecting. When I look back at my week, I tend to focus on more negative items. By asking myself this question every day, it caused me to gain a new perspective.

The right figure is a radar chart based on Zig Ziglar’s Wheel of Life. Ziglar came up with seven categories, with a section in the middle for yourself. I moved that section to its own sector, which gives the circle eight pieces and is thus easier to draw.

Those sectors are: enrichment (the center “you” piece, fun, life-enhancing experiences), social (friends, community), work (including career), family (which I subdivide into wife and children/other), spiritual (faith), financial, mind (learning, intellectual pursuits), and health (including exercise).

When I do my weekly review, I rate each area on the same niko-niko scale as I do each day. That 5-point scale translates to filling in 0-4 segments. The blue area shows the current value. The green areas show growth from the previous week. If there were shrinkage, those would be shown in red. I’m pleased to see growth but no withering.


Today, I want to talk to you about a different kind of database than the ones you are probably used to. I start with a brief description of common types of databases, then introduce graph databases with a couple of examples.

If you have been in the software development industry for a long time, you probably started with relational databases. If you’ve ever used a spreadsheet, this concept should sound familiar. A relational database stores data items in life-structured groups called tables that contains rows and columns. The row represents a discrete piece of data, and a column represents a characteristic of the item common to every row in the table. In a database proper, that structure is enforced by a specification called a schema.

Graph databases can be powerful tools for analyzing the way items relate to one another.

It’s called a relational database because data characteristics like key values can be used to relate items to rows in other tables, without moving the data. That saves on data storage costs and makes it easy to update, I can keep a common value like the office’s address in one table and my employees in other, without having to store a copy of the office address with each employee. If the office moves, I only have to update the address table, and that change will be reflected for all those related employees.

Relational database don’t handle both unstructured data and large objects very well. They also lead to situations where you have data structures that are only supporting. For example, it’s hard to imagine what I might want to use the office address table for by itself, without knowing anything about the offices those addresses belong to. It’s possible to employ workarounds to combat these issues, but it’s often at the expense of usability and performance. As these edge cases became more common, it led to the growth of a different style of database that thrived in those circumstances.

The most common form of non-relational databases store data in records, which are similar to tables in some respects, but those records do not have a strict schema enforcing a structure. MongoDB and Cassandra as two well know non-relational databases.

An example of this style of data store is a blog like this one. I’m using Jekyll, which takes a set of files and compiles them into a static website. This very blog entry is contained in a text file in a folder, lightly formatted using the Markdown specification. The Jekyll engine reads through the file looking for header text in a certain format called YAML (Yet Another Markup Language) in order to know how to treat this blog entry: what category it belongs in, what tags to apply, and so on.

There are other ways to store data that aren’t relational, though, and one of these ways is what I want to share with you. At work, our team makes heavy use of a graph database engine called Neo4J. Graph theory is a mathematical discipline that speaks to the relationship between things, and a graph database structures data into nodes and edges in accordance with that theory. A node is like a record in a non-relational database, in that lacks a lot of imposed structure. The power of a graph database comes from the way that relationships between nodes are handled. In a relational database, these relationships are modeled as links using common data values like IDs to connect two rows. In a graph database, these relationships are called edges, and like nodes, they can have attributes of their own.

Let me give you an example of why this might be useful. Let’s say I have a movie database. In a relational database, I might have a movie table, an actor table, and a director table. Values in these three tables might be related through IDs. However, let’s look at an edge case. The 2004 film Primer was directed by Shane Carruth, produced by Shane, written by Shane, and starred Shane. He also wrote the music and edited the film. A relational database would have a difficult time expressing the fact that all these Shanes are indeed the same person.

A graph database would have no such trouble. You could model this with two nodes, a Primer node and a Shane Carruth node. These two nodes would have multiple edges between these two nodes. There’s a DIRECTED_BY edge, a WRITTEN_BY edge, and so on. The case where there are multiple writers is easy for a graph database, but can require a schema update with collateral code changes for a relational database.

If you’re interested in exploring such a database, Neo4J offers an example database with IMDB-style records. With a graph database, there’s a SQL-esque language for expressing these queries called Cypher. Neo4J has a page with basic queries and explains them.

Not convinced about the utility of graph databases? How about a LinkedIn-style query, again from the example page linked above. Let’s say I want to find all the “second-degree” actors of Tom Hanks. In other words, actors who have appeared with Tom Hanks are direct or “first-degree” connections. Any actor who’s worked with a direct connection of Tom’s who isn’t a direct connection would be one degree removed, or a second degree connection. In a relational database, this would require a large association table with some subqueries to achieve. Here’s the query shown on that page:

MATCH (tom:Person)-[:ACTED_IN]->(movie1)<-[:ACTED_IN]-(coActor:Person),
         (coActor)-[:ACTED_IN]->(movie2)<-[:ACTED_IN]-(coCoActor:Person)
WHERE tom.name = "Tom Hanks"
AND NOT (tom)-[:ACTED_IN]->(movie2)
RETURN coCoActor.name

I think Cypher queries are easy to read if you are used to SQL. Nodes are in parentheses. Edges are in square brackets. Item specifications that need to be referred to elsewhere in the query can be given names using colons, like the “tom” or “coActor” nodes. Arrows between then show the direction of the relationship – more on that in a moment.

However, I prefer to play around with more personally meaningful data. The site Graph your network! allows you to do just that with your personal Twitter data. This is an interactive tutorial that uses your public Twitter information as data. I’ve captured a picture of the data model here.

Queries that graph databases excel at are ones that explore relationships with the data. An example would be finding out people I’m mentioning on Twitter. In this example, the Cypher query would be:

MATCH
  (u:User {screen_name:'ChuckDurfee'})-[p:POSTS]->(t:Tweet)-[:MENTIONS]->(m:User)
WITH
  u,p,t,m, COUNT(m.screen_name) AS count
ORDER BY
  count DESC
RETURN
  u,p,t,m
LIMIT 10

If I want the reverse, people who mention me, I simply need to change the query slightly:

MATCH
  (u:User)-[p:POSTS]->(t:Tweet)-[:MENTIONS]->(m:User {screen_name:'ChuckDurfee'})
WITH
  u,p,t,m, COUNT(m.screen_name) AS count
ORDER BY
  count DESC
RETURN
  u,p,t,m
LIMIT 10

Notice here that the direction of the relationship has been reversed just by changing the specification on the nodes. I could also rewrite this query by changing the direction of the arrows.

MATCH
  (u:User {screen_name:'ChuckDurfee'})<-[:MENTIONS]-(t:Tweet)<-[p:POSTS]-(m:User)
WITH
  u,p,t,m, COUNT(m.screen_name) AS count
ORDER BY
  count DESC
RETURN
  u,p,t,m
LIMIT 10

I hope this post has whet your appetite for looking into graph databases. They can be powerful tools for analyzing the way items relate to one another.