Sep 16 2013


Relevance and Metadata Partners Join Forces to Become Cognitect

It is with great pleasure that I announce that Relevance, Inc. has joined forces with Metadata Partners (makers of Datomic) to become Cognitect, Inc. Cognitect maintains all of what made Relevance great -- the same team, the same focus on agile development, the same dedication to open source and sharp tools, but is also a vehicle for exploring those sharp tools and leveraging them to build truly modern information systems and solutions.

For all of our friends, customers, and partners who keep up with us here at the blog, know that this change will be purely additive from your point of view. Nothing changes about how we work with you; we now have better alignment around our products and services and will be even better partners.

It is a happy coincidence that this change comes on the heels of our 10-year anniversary. A decade seems like an excellent unit of measure -- we've had a fantastic decade with Relevance as a stand-alone entity. We're looking forward to doing even more as part of Cognitect.

Sep 16 2013


Cognitect - Podcast Episode 040

cover art

In this landmark episode, Craig interviews Justin Gehtland and Rich Hickey as they discuss the merger of Relevance and Metadata Partners (the company behind Datomic) to form a new company: Cognitect. They discuss why they made the decision to join forces, what will stay the same with the products and services that Relevance and Rich currently provide, and what will be different and better. They discuss the choice of the name, and how it reflects the new company's philosophy of craftsmanship and considered design.

This is the final episode of ThinkRelevance: The Podcast; happily, it is also the first episode of The Cognicast.

Listen to or download this episode.

Read More »

Aug 30 2013


Aug 28 2013


Architecture and Financial Success

At our most recent internal conference, Tim Ewald gave us a passionate talk on the topic of architecture and design. He said that a successful solution must deliver features, while exhibiting certain desirable properties and meeting constraints. Features are the things it should do: send email, display cat photos, and display notifications. Properties are the less visible characteristics, sometimes called "non-functional requirements." Constraints are the boundaries that the solution cannot exceed.

In a contrived example: For structures, the force of gravity is a constraint. Standing for the next 50 years is a property. An auditorium for performances is a feature.

While features are the simplest things to identify, they are not what determines how successful a solution is.

For example, there must be thousands of ways to place a "registration form" on the Web. Custom coded in dozens of languages, countless SaaS sites, platforms like Google docs, the number of possible solutions to this problem goes on and on. You could write a CGI perl script to run on a Raspberry Pi plugged in to a covert power outlet in your neighborhood coffee shop, running on free wifi.

All of these solutions provide the necessary features. So what makes one solution a better fit than another? How do you choose among the array of possibilities? You eliminate the solutions that won't exhibit the necessary properties. Then choose among the remainder.

For instance, does your registration form need high availability? Scalability? Is it OK to miss a few people here and there? Is it OK if the entire list gets revealed? Or are there lives on the line?

Among these properties, I think the most important ones are those that affect the financial success of the system. We tend to relegate all money matters to project managers. However, I think architects are the people who have the right skills to answer the trade-offs inherent in these questions:

  • Can it be built cost-effectively?
  • Can we profit from it, or will operational costs overwhelm us?
  • Will it be available and responsive enough to win customers?
  • Can we support an economically interesting user base?
  • Is it going to be so hard to defend that we end up losing customer data or spending a fortune on security?

All of these questions sit at the intersection of time, cost, and functionality. The architecture skill set helps a team balance these concerns and guide the system to the most positive possible outcome. Viewed this way, architecture is about creating positive financial outcomes.

Aug 27 2013


Alex Miller - Podcast Episode 039

cover art

Alex Miller is the organizer of some of the best conferences I've ever been to (and one I haven't): Strange Loop, Clojure/West, and Lambda Jam. He is also Relevance's newest employee. As we both found ourselves in Durham recently, it was the perfect time to sit down together and talk conferences, community, and Clojure.

Listen to or download this episode.

Read More »

Aug 20 2013


Craig Andera - Podcast Episode 038

cover art

You've had the joy of listening to Craig's insightful questioning of our guests for a long time now; it is our great pleasure to turn the microphones around and capture Craig Andera on the other end of the questions. Guest host Justin Gehtland gets Craig to talk about his career path that led to working at Relevance, his changing taste in technologies, and the genesis and details of ThinkRelevance: the Podcast. We hope you enjoy getting to know Craig a little better.

Listen to or download this episode.

Read More »

Aug 13 2013


Brenton Ashworth - Podcast Episode 037

cover art

On episode 27, Tim Ewald gave us an overview of Pedestal, Relevance's open source framework for building web applications. We spent most of our time talking about the server side of that technology, but I think the app side of Pedestal is in many ways even more fascinating. Because it contains so many new ideas, it's also something people have had a harder time getting started with.

To help people understand the concepts in Pedestal App, Brenton Ashworth recently authored the Pedestal App Tutorial. I highly recommend people check it out - it's a great resource. On this episode, Brenton does a great job of explaining the concepts in Pedestal App. I'm sure you'll come away with a better understanding of the library. I definitely did. I thank Brenton for taking the time to talk to me!

Download this episode.

Read More »

Aug 05 2013


Barnstorming 2013

This went out via Twitter last week, and we've gotten a great response. For anyone who doesn't follow that channel, though, there's still time to get in on the 'storming.

Michael Nygard and Stu Halloway will be in Europe for much of October. We are speaking at a bunch of conferences and hope to see some of you there.

Since we are already on the road, we thought it would be a good opportunity to turn this into a barnstorming tour, working with teams who are looking for help with Clojure, ClojureScript, and/or Datomic. If you would like to have us work with your team, pricing is as follows:

  • Free for user group talks
  • $1500 for a 90 minute talk
  • $5000 for a day of training or consulting
  • $0 for travel expenses (we are already there!)

Our prepared materials are summarized here and here, or feel free to request specific topics.

If you are interested in scheduling a meeting, please send an email to, subject line: "October Barnstorming". Include in the body of the message the kind of event you are interested in, as well as possible dates and locations.

Aug 01 2013


Jul 31 2013


On Naming

Why is naming so difficult? We write functions and arguments, or classes and methods, all day long. Every one of them has a name. With all that practice, you would expect us to be good at it.

One reason is that names are always metaphors. When we say "open a socket", no actual opening happens. Our servers don't grow new orifices like a Transformer. All it means is that we arrange some memory like this and make that entry in a table (a metaphor of its own!) in the kernel (metaphor) of the operating system (metaphor).

In Metaphors We Live By, George Lakoff shows how entirely embedded we are in metaphors. They go much deeper than our primary school teachers have told us. Deep metaphors are ideas such as "Love is War," or "Happy is Up." Sometimes we form compound metaphors, which gain richness through their interaction.

My examples so far are pretty obviously metaphors. Now consider this relationship between three objects arranged linearly: you, another person, and a mountain. The distance from you to the other person is less than the distance from you to the mountain. You would probably say the person is "in front of" the mountain. That's a metaphor. The mountain does not have a front. The idea that the side nearest you is the "front" of the mountain is actually a cultural construct. Lakoff points out that in Hausa that orientation would be reversed. You would say the person was behind the mountain if it were between you and the big rock.

So we see that names can be problematic if the speaker and listener activate different metaphors when they use the same name.

Naming can also be an act of creation. By attaching a name to a phenomenon, we suddenly see that phenomenon as a "thing". Anyone who lived through the U.S. Presidential election in 2000 learned all about "pregnant chads", "hanging chads", and other mangled chads. (I wonder what happened to the frequency of baby boys being named Chad. Did it go up or down after that?) Prior to those tortured neologisms, nobody gave any thought to what you called that little rectangle of paper that got popped out of a hole in a punchcard. Unless, of course, you were in the punch card business. Or punch card machine maintenance, I suppose.

Pretty much every name we use in programming was created by someone, some time. Many are humdrum words to which we have attached our own meanings: window, list, queue, or string. Others are puns or derivatives: trie (from tree), zipper, virus, array.

Object-oriented programming demands tremendous naming ability. Some programmers don't do it very well, and you get classes like "AbstractHandlerManagerFactory" and "HandlerManagerFactorySingletonImpl." Yawn.

Because naming gives us a handle to discuss things, it can be useful to name "non-things" in order to "thingify" them. Even if it's a bit nebulous, you should always name your preferred architectural style, coding conventions, or pattern of interaction. Only in that way can you distinguish it from the older structure. Be careful though, because someone else may come along with an even more nebulous, foggy, but desirable sounding term and outmaneuver you. I contend that "private cloud" would have no traction but for the comforting sound of it.

(The term "in the cloud" seems to have originated with the telecom carriers. Specifically, in their sales groups. Sales reps were often unclear where or how the service was actually being delivered, so they would draw the customer's locations on a diagram, connect them to a fluffy cloud, and show call-center people "in the cloud" handling the customer's calls. That became shorthand for "you shouldn't care where the service is" even though it originally meant "I don't know where it is.")

Once a name is created, it is impossible to destroy. Even when the concept is long past its natural life, it can be difficult to get rid of it. For example, imagine saying "we no longer need a User Acceptance Testing environment because we aren't going to do User Acceptance Testing any more." It sounds like the height of irresponsibility. Removing a flavor of testing is enormously difficult, even if you can prove that it caught zero defects over the last five years.

Fans of Jacques Lacan would describe this as the difference between a thing's death in reality (the death of the thing) and its death in the symbolic order (the death of its name). The "symbolic order" can be language, or ideology, or any other shared symbolic or metaphoric framework for trying to make sense of the universe. ("Agile development" is an example of a symbolic order.) A thing can become useless in reality, but remain quite useful in the symbolic order. For example, let's say your UAT testing never actually uncovers any bugs. (And let's also assume that your software is not perfect, and there are indeed bugs to be found.) Your UAT testing serves no purpose in reality. It's dead. But saying "we're not going to do UAT anymore" sounds irresponsible precisely because "UAT" is a familiar component in the symbolic order of your development process. If you remove "UAT" from that system, then suddenly the validity of the entire symbolic order becomes questionable. That's terrifying. (Or liberating.) Therefore, in order to prevent existential despair or psychosis or revolution, you might cling to this superfluous concept of UAT. This happens anytime you're going through the motions of some empty ritual. You do that because you haven't figured out how to reconfigure the symbolic order to account for reality. You haven't figured out how to rename things.

-Maggie Litton, Relevance coach and literary theory buff

Another tough thing about names is that they are almost always compounds---that is, they bind multiple concepts together. A single noun can give the illusion of conceptual unity. Most of the time, that name can be decomposed into constituent concepts. This is especially true in the world of domain modeling. For example, last week I was in a lengthy discussion at a retail company about the proper owner of "Cart" functionality. Everyone thought they knew what Cart meant, but when we enumerated the different aspects of Cart we found 8 - 12 distinct uses and behaviors. Cart is, of course, a metaphor. There's no secret underground facility where wire-mesh wheeled vehicles wander around letting goods drop into them. Once we started splitting those distinct behaviors apart, we found that Cart actually wasn't a thing at all. Rather, it was a label for a compound of several different things interacting together.

Sometimes we name things to separate them from other things. Retronyms fall into this category: "feature phone" versus "smart phone", "dequeue" versus "queue", "trie" versus "tree." This can be an effective maneuver in a political environment: when you need to steal the wind from another group's sails, name your project such that the semiotics imply superiority. Good words to use here are "open" and "version 2.0." If the enemy project uses names from classical literature, find out who slew their project's eponymous hero. Or, if you want to get in front of Sun, name your project "Eclipse."

Naming is difficult. But it is also a primal, shamanistic power. When you name, you are literally exerting mind control. Use it wisely.

Popular Tags