Relevance Blog

ThinkRelevance: The Podcast - Episode 012 - Craftsman Swap

2012-05-22T16:00:00Z

One of the core principles we hold to at Relevance is the idea that we should always be striving to get better. A big part of that is recognizing that we can learn a lot from others, especially when those others have the same attitudes about continuous improvement. That's certainly true at Bendyworks, which is why we were happy to do a Craftsman Swap with them recently, where we sent them Jared Pace for a week, and they sent us Chris Wilson.

On this episode, we talk to Jared and Chris and their pair partners Alan Dipert and Devin Walters about that experience. We also talked about accidentally taking the ferry and whether exposure to radioactivity makes you better at using project management tools. It was a fun and interesting conversation that made me want to try a Craftsman Swap myself! Perhaps you'll feel the same. If so, give us a shout - we'd love to spend some time learning from you! And I know the same goes for Bendyworks.

Download the episode here.

The show is available on iTunes! You can also subscribe to the podcast using our podcast feed.

You can send feedback about the show to podcast@thinkrelevance.com, or leave a comment here on the blog. Thanks for listening!

Show Notes

Devin Walters
- His Bendyworks page
- @devn
- GitHub
- Blog
- Email him!
Chris Wilson
Jared Pace
Alan Dipert
- His Relevance page
- @alandipert
- GitHub
- Blog
- Mr. Dipert dresses exclusively in fine outerwear from The Mountain
The music
- The opening music was "It Takes Two", by Rob Base and DJ E-Z Rock
- The closing music was "Happy Together", by The Turtles
People and stuff we mentioned on the show
- Bendyworks
- Madison, Wisconsin
- Durham, North Carolina
- Craftsman Swaps are an aspect of the software craftsmanship movement
- Some previous swaps Relevance has been involved in
- bash
- say
- Voices for say
- Risk Assessments and Retrospectives
- Fermilab
- The Large Hadron Collider (LHC)
- Gordan Freeman
- Pivotal Tracker
- Miami, Florida
- Corey Haines
- Corey's hacker-in-residence visit to Relevance a few years ago
- Chad Humphries
- Colonial Willamsburg
- Jamestown
- Jamestown-Scotland Ferry
- Jason Rudolph
- Stephen Anderson
- National Mustard Museum
- Mad Clojure, the Madison Clojure Meetup
- Clojure
- Ruby
- Haskell
- Bwoken
- Bradley Grzesiak
- Jaymes Waters
- clojuredocs.org
- Midje
- test.generative
- QuickCheck
- RushCheck
- EuroClojure and Devin's talk there
- Sam Aaron's Clojure/conj talk
- Rich Hickey
- Craig's Clojure/conj talk
- Errbit
- Hoptoad/Airbrake
- pdfkit
- The Best Pairing Jams of 2012

ThinkRelevance: The Podcast - Episode 011 - Jen Myers

2012-05-04T14:49:00Z

I've heard several developers at Relevance comment on how much they like working with our designers. I totally agree. The one I've been fortunate enough to work with the most often is Jen Myers. So I welcomed the chance to talk to her about what she's been up to lately... which is a lot! In this episode, we chat about her efforts with Girl Develop It Columbus, responsive web design, conference speaking, and CSS nerd wars.

Jen was an extremely interesting, thoughtful, and humble guest, and I enjoyed talking with her. I know you'll enjoy listening just as much!

Download the episode here.

The show is available on iTunes! You can also subscribe to the podcast using our podcast feed.

You can send feedback about the show to podcast@thinkrelevance.com, or leave a comment here on the blog. Thanks for listening!

Show Notes

Our guest, Jen Myers:
- @antiheroine
- Jen on GitHub
- Her blog
The music
- The opening music was "Northern Lights", by St. Vincent
- The closing music was "Can We Go Wrong", by Hesta Prynn
People and stuff we mentioned on the show
- Artifact, a very unfinished game that Jen has helped Craig with
- ClojureScript One
- Girl Develop It Columbus
- Jen's Introductory HTML/CSS class
- Girl Develop It New York, Philadelphia, Austin, and Ottawa
- Jen's teammates, Michael Parenteau and Kevin Altman
- JavaScript
- Responsive Web Design
- One conversation in the ongoing "CSS Prefix War"
- Jen will be speaking at Stir Trek on May 4th, and at Queen City Merge on May 11th
- Jen spoke at Codepalooza between the time we recorded and when this episode was published. Her session was Developers Can't Design (and Other Completely Mistaken Design Myths)

Why Retrospectives Should Get Personal

2012-05-02T16:02:00Z

What do you get when you cross a bunch of passionate, self-directed engineers with an agile, iterative approach to both software and personal development? Predictably, you get continuous delivery of customer value and solutions to really hard problems. Additionally, as a nifty bonus, you get a new kind of discussion forum that brings all the best qualities of agile software development to individual improvement: the Personal Retrospective.

Before your imagination goes too far, let me assure you this does not require hugging, silly hats, or revealing favorite brands of underwear. Nor is there screaming into a mirror or "Fight Club" activities of any sort. The Personal Retrospective is an undertaking at Relevance that forms a cornerstone of our company culture and a critical ingredient to our goal of continuous improvement at all levels.

Great Feedback in 60 minutes or Less

The key ingredients for a Personal Retrospective at Relevance are five or so team members who have first hand experience with the subject's recent performance and another Relevance employee who serves as a neutral facilitator for the discussion. During the meeting, the individual is provided with an hour of open and honest feedback which validates and appreciates areas where they are providing their best value to their team and clients, and calls out ways they may not be meeting the mark or have the greatest room to grow.

An agenda is set ahead of time by the subject (with the help of the facilitator) to focus the feedback on areas and goals most important to them. The experience can be extremely positive, giving deeper insight into the impact your actions have had on those around you, as well as deeply emotional as you hear the negative effects even your best intentioned actions have had on the team.

Sometimes there are surprises, though often the subject has at least some notion of where things are not going great, and a critical component of a successful Personal Retrospective is a list of clear action items and mechanisms to encourage and monitor improvement once the meeting concludes.

I Never Thought it Would Happen to Me...

Recently I had the opportunity to participate in my own Personal Retrospective to evaluate current performance as an Agile Project Manager and Coach. Although I had requested the meeting and chose the attendees, it was still quite intimidating to hear several people who I respect greatly talk about me both positively and critically (and often in the third person as guided by the facilitator to ensure the messages are clear and actionable). In the end though, it worked wonders to quiet the distracting internal voice of insecurity by hearing where my efforts are helping the team. Additionally, it helped me understand where I have been dropping the ball, along with recommendations on how to get on the right track.

The guesswork has been largely eliminated in the form of a group of trusted peers stating "This set of things you do, they are really good; keep doing them. This other set of things, you're doing okay, and here are some tweaks to make them better. And this set of things, these actions are having a negative effect on us and the project; here are examples of them and some clear ways to change these behaviors."

Bringing the Love Home

This isn't a review. No money, position, or responsibility changes are made as a direct result of what is said. It is a safe forum for enabling feedback to help folks at Relevance along in their journey. Such a personal and sometimes difficult meeting may not be for everyone nor for every organization, but it is an option you and your team should consider when looking for additional ways to get to the next level of individual and group performance. If you'd like more specifics on how the process works, give us a shout and we'll be happy to help. If it doesn't work, you can always go with the silly hats and underwear stories.

Where to Find Relevancers: May Edition

2012-05-01T15:25:00Z

Want to meet a Relevancer in person? Here's where you can find us during the month of May:

Durham, NC Every Tuesday - 7pm @ Splat Space
Splat Space Open Meeting
Attending: Alan Dipert, Splat Space founder and Meetup organizer

Columbus, OH 5/4
Stir Trek, Conference & A Movie
Speaking: Jen Myers
Talk: Developers Can't Design (and Other Completely Mistaken Design Myths)

Cincinnati, OH 5/10-5/11
QC Merge Conference
Speaking: Jen Myers
Talk: Design for Developers

Floyd, VA 5/11-5/13
Code Retreat
Attending: Jason Rudolph, Lake Denman

London, UK 5/21-5/23
EuroClojure, Clojure Training
Trainers: Stuart Sierra, Luke VanderHart
Training Description: Intro to Clojure

London, UK 5/24-5/25
EuroClojure Conference
Speaking: Stuart Halloway
Talk: Evident Code, At Scale (Keynote)

Copenhagen, Denmark 5/21-5/23
GOTO Conference
Speaking: Michael Nygard, DevOps/continuous delivery
Stuart Halloway: Real Life Clojure & The Impedance Mismatch is Our Fault

Durham, NC 5/24
Refresh the Triangle, Project Management Panel
Speaking: Marc Phillips
Panel Discussion: More Fun, Less Stress: What You Should Know About Project Management

Amsterdam, Netherlands 5/24-5/25
GOTO Conference
Speaking: Michael Nygard
Talk: Failure Comes in Flavor: Stability Antipatterns

San Francisco, CA 5/29-5/31
Fluent Conference
Speaking: Luke VanderHart
Talk: Intro to ClojureScript

ThinkRelevance: The Podcast - Episode 010 - Stu Halloway

2012-04-26T13:29:00Z

One of the hardest things about working at Relevance over the last couple of years has been keeping quiet about Datomic. So when we heard that Datomic was being released, I immediately sent an email to Stuart Halloway asking if he'd be willing to do a podcast episode, not just because he had such a big hand in Datomic, but because as one of the founders of Relevance and as an all-around interesting guy I knew it would make for a great show.

I don't think I was wrong. So have a listen as we talk about Datomic, simulation testing, a capella music, and what makes Stu want to drop-kick a gorilla, and see if you agree. Thanks for listening!

Download the episode here.

The show is available on iTunes! You can also subscribe to the podcast using our podcast feed.

You can send feedback about the show to podcast@thinkrelevance.com, or leave a comment here on the blog. Thanks for listening!

Show Notes

Our guest, Stuart Halloway:
- @stuarthalloway
- Stu on GitHub
The music
- Stu chose two songs by The Pitchforks, of Duke University, his alma mater
- The opening music was a cover of "Fireflies", originally by Owl City
- The closing music was a cover of "Hysteria", by Muse
People and stuff we mentioned on the show
- Programming Clojure
- Datomic
- Rich Hickey
- Rich’s Strange Loop keynote from 2011, "Simple Made Easy"
- complect
- Neal Ford
- His "Emergent Design" talk, where he talks about accidental versus essential complexity
- Object-Relational Mapping (ORM)
- Logic Programming
- SQL
- Git
- Subversion
- SourceSafe
- ACID
- NoSql
- Fogus
- Himera, his ClojureScript compilation service
- His blog post talking about separating Read from Eval
- The 2008 JVM Langauge Summit
- The Pragmatic Studio
- Ruby
- Ruby on Rails
- Justin Gehtland
- Document stores
- Key-value stores
- Triplestores
- Alan Dipert
- Episode 009, where Alan was a guest
- Alan’s talk at Clojure/West about data shapes
- "Yak Shaving"
- Metadata Partners, maker of Datomic
- Rich's keynote at the first Clojure/conj
- The Zoom H4n, which I used to record this episode
- Tim Ewald
- How We Work
- IRC
- Campfire
- Skype
- Mikogo
- Omnigraffle
- org-mode
- Mike Nygard
- Test-Driven Development (TDD)
- clojure.data.diff
- test.generative
- ClojureScript
- Datomic pricing
- Clojure
- "The Cloud"
- DynamoDB
- PLTHulk
- idempotency

ThinkRelevance: The Podcast - Episode 009 - Alan Dipert

2012-04-09T14:14:00Z

If you've looked at our website lately, you might have noticed that it's a lot easier to see that we do training. Of course, we've always done training, but lately we've realized that we needed to be a bit more obvious about the fact - hence the new info on the website. So I thought it would be a great time to bring Alan Dipert onto the show, as he had a big hand in both reshaping the website and the courses that we offer.

Of course, we didn't just talk about training. We also hit on the topics of the importance of data, criticisms of the Lambda Calculus, and famous hackers turned dance club owners. I certainly enjoyed my conversation with Alan - have a listen, and I think you will too!

Download the episode here.

The show is available on iTunes! You can also subscribe to the podcast using our podcast feed.

You can send feedback about the show to podcast@thinkrelevance.com, or leave a comment here on the blog. Thanks for listening!

Show Notes

Our guest, Alan:
- @alandipert
- Alan on GitHub
- Alan’s blog
- Mr. Dipert dresses exclusively in fine outerwear from The Mountain
The music
- The opening music was "(April) Spring, Summer & Wednesdays" by Status Quo
- The closing music was "808 PM At the Beach", by Fred Falke
People and stuff we mentioned on the show
- Relevance training
- Clojure
- ClojureScript
- Ruby
- Ruby on Rails
- Rich Hickey
- How We Work
- Agile
- The Pragmatic Studio
- DevelopMentor
- Stu Halloway
- Justin Gehtland
- Stuart Sierra
- Tim Ewald
- Jamie Zawinski aka jwz
- His club: DNA Lounge
- His screensavers
- His mix tapes
- jwz’s Netscape home page
- Netscape these days
- Peter Norvig
- Alan said jwz worked for Peter Norvig at CMU, but that is incorrect. jwz worked for Scott Fahlman at CMU and then later for Peter Norvig at Berkeley.
- jwz hacked on the TI Explorer, not a Xerox Lisp Machine
- Alan’s talk at Clojure/West about data shapes
- C#
- CSS
- Datomic
- Rich’s Strange Loop keynote from 2011
- John Backus
- His Turing award lecture, “Can Programming Be Liberated from the von Neumann Style?”
- Backus-Naur
- FORTRAN
- ALGOL
- Persistent data structures
- “Smug Lisp Weenies”
- “Why Calculating is Better than Scheming”
- The Lambda Calculus
- The FP programming language

Big Data Reference Model

2012-04-04T20:00:00Z

A project that approaches Big Data as a purely technical challenge will not deliver results. It is about more than just massive Hadoop clusters and number-crunching. In order to deliver value, a Big Data project has to enable change and adaptation. This requires that there are known problems to be solved. Yet, identifying the problem can be the hardest part. It's often the case that you have to collect some information to even discover what problem to solve. Deciding how to solve that problem creates a need for more information and analysis. This is an empirical discovery loop similar to that found in any research project or Six Sigma initiative.

Handling the data itself is a technical challenge, and it can be a big one. Still, those other aspects of empirical learning, human decision-making and problem identification must also be addressed.

This model depicts a schematic form of the different aspects to consider, including both human and technological components. It helps discussions by guiding the team to consider the problem space first: the business context, needs, and decision cycles. Then it moves into the solution space: collection, analysis, visualization, and feedback mechanisms. Using this model, projects and project teams are encouraged to pause before implementation to make sure they understand the problem to be solved. They may find that the problem has yet to be identified.

The model is divided into three areas with mutual dependencies and feedback loops. The following sections will discuss each of these areas.

Investigation

This is where efforts begin, especially with the Problem Identification step. "Problem Identification" is always in terms of the business and its situation. A particularly well-formed problem might be "We must raise conversion rates by 0.5% with our top customer segment in consumer electronics this year." Notice that this statement has several dimensions: "what?" (conversion rate), "how much?" (0.5%), "where?" (top customer segment, consumer electronics), and "when?" (this year).

Most problems will not be so well defined. It is very common to see problem identification stall on the need for more information. In our example, "top customer segment" might not actually be known. In that case, one problem identification exercise spawns a subsidiary problem identification, which could then spawn another in a kind of fractal process.

Once a problem is identified, there is an accompanying hypothesis. In the case of our well-formed example, the explicit hypothesis might be that we can effect change in the conversion rate via pricing and promotions, presentation changes, or adjustments to the product assortment. In the subordinate problem, there is an implicit hypothesis that says "our customers can be segmented in meaningful ways, and some segments are more desirable than others."

Once a set of hypotheses are defined, three things must happen. First, testing the hypotheses almost always requires additional information. That may be in the form of assigning customers to randomized trial groups, then attaching their group identification to all their downstream activity. Or, it may be a need to tap into a different data source that hasn't been used before (internal or external.) Virtually all of these information needs will require some changes to existing applications, so identifying the needs before leaping into implementation is important.

In any of these cases, it is tempting to think that we could build a complete panopticon: a universal data warehouse with everything in the company. This is an expensive endeavor, and not a historically successful path. Whether structured or unstructured, any data store is suited to answer some questions but not others. No matter how much you invest in building the panopticon, there will be dimensions you don't think to support. It is better to skip the massive up-front time and expense, focusing instead on making it very fast and easy to add new data sources or new elements to existing sources.

The second thing that happens after describing the hypotheses is creating a way to effect change. For example, if the hypothesis says "we can increase our conversion rate as needed by broadening our product assortment," then there must be some way to add the additional products into the system. This is likely to be well-supported, since it resembles an ordinary business function!

Most often, testing the hypothesis will require some code or data changes in the applications. (Even our expanded assortment hypothesis might require adding an attribute to the applications' databases, to track products and orders that are part of the expanded assortment.) These changes will include ways to split or group entities, apply parameters to the system, or apply differential parameters to test groups. We'll refer to all of these operations as "parameterization" in the general sense: adjusting the behavior of the systems in the space of all possible behaviors.

At this stage, we expect that parameterization is based on ad-hoc analysis, which is the third thing to follow the hypotheses. Because this is still within the empirical discovery loop, we don't want to invest in fully automated machine learning and feedback. That will follow once we validate a hypothesis and want to integrate it into our routine operation.

Ad-hoc analysis refers to human-based data exploration. This can be as simple as spreadsheets with line graphs or as sophisticated as a room full of quants running K programs at light speed. The key aspect is that most of the tools are interactive. Questions are expressed as code, but that code is usually just "one shot" and is not meant for production operations. The main goal of ad-hoc analysis is to discover and validate, not to optimize. Ad-hoc analysis operates on the same kind of large-scale data store that the production tools will operate on. The goal of this activity is to validate the hypotheses and help discover the next round of problems to solve.

Ad-hoc analysis continues even after one set of solutions is operating in production. They should always be working a step ahead of the production environment, looking for the next set of problems or opportunities.

The final activity in Investigation usually happens much later. After one set of hypotheses are validated, the solution should be implemented and operationalized. At that point, the humans' attention will shift to the next set of problems, but they should also keep an eye on results of all the previous efforts. This is necessary because the competitive environment shifts constantly and your big solution today may be neutralized by your competitors tomorrow. In addition, the initial experiments may just show transient effects due to novelty or even the Hawthorne effect. So humans need to have good information—presented in human-digestible ways—to make good decisions. These decisions will feed back into the applications in a way similar to the Needs Identification activity. The main difference is that routine decisions probably use knobs and levers that already exist rather than creating new ones.

Now let's turn our attention to the implementation area.

Implementation

Implementation deals with the technology: applications, data stores, and integration among them. The goal of implementation is to harvest and collect raw data for downstream use.

Implementation covers all sources of data. That includes applications producing business-level metrics and events, but it also includes system and network metrics. (For example, there's a surprising amount of knowledge to be gleaned from web logs.) Implementation increasingly includes external data sources such as advertising and social networks.

The implementation area also covers ongoing changes to applications in order to introduce new parameters or ways to alter the parameters. For example, if Needs Identification says that arriving customers must be split into a control group and a test group, then something in the application or infrastructure needs to support parameters like: "number of groups", "percentage of arrivals in each group", "stickiness of group assignment", and so on.

It is also usually necessary to propagate such parameters along to downstream systems, which may require other incremental changes to the applications or databases.

Raw data is where everything lands. The raw data activity includes any extraction tools needed in order to induct data from the sources. "Raw data" may actually include a processing stage or two if incoming sources need to be joined or split.

A word of caution about data cleansing: it is tempting to canonicalize data here, removing unmatched or otherwise "not sane" records. That is usually a bad idea. Records that get deleted from raw data become "dark matter" than cannot be seen, reported on, or even compared to the amount of "visible matter" later. It is better to handle this with projections.

Technical teams have a tendency to jump into the implementation area first. That's not necessarily wrong, but it may be incomplete. Starting with implementation can be useful when it helps discover and identify problems. In that case, the process would begin with collection and raw data, follow the path through ad-hoc analysis and into problem identification.

Production

Production deals with making routine operations out of useful information.

Once a hypothesis is validated, we would like to integrate the new thing we've learned into every day activity. This is a job of automation and feedback. Like the other areas, "Production" covers several distinct activities.

"Automated Information Extraction" refers to processing of the raw data to find interesting information contained within the data itself. This step usually includes a wide variety of tools and languages. This polyglot can seem chaotic---and it can be difficult to support---but the goal is not to produce a cohesive software environment. Rather, it is to express the fundamental algorithms in the most expressive and performant way possible, given limited time for implementation and a limited lifespan of the algorithm itself. Extraction can include aggregation, grouping, joining, or splitting data. These programs should be small and loosely coupled. These programs should be well-engineered (in contrast to the ad-hoc analysis code). They must be resilient to messy input, changing data volumes, and partial system failures.

The output of automated information extraction is more data, in a condensed format. This digested data could be used directly by applications, but more frequently goes through an augmentation step first.

Augmentation refers to processing that adds new information to the data. This is where we find the statistical and machine learning algorithms. The specific kinds of processing to apply here were defined by the earlier ad-hoc analysis and validation. It would be rare, however, to see exactly the same code running in production operations as on the analysts workstation. The augmentation code will be a new implementation of the same algorithm.

As we discussed in the "Investigation" section, even once a feedback loop is automated in production, humans still need to see the outcomes. Therefore, presentation and visualization is part of ongoing operations. Presenting quantitative information is a specialization of design activities, so this will normally be done by people with command of both graphical design and statistics. They must also understand enough about the psychology of numbers to avoid triggering universal human cognitive biases and failures. Bad visualization provokes bad decisions, just as much as bad data does.

Finally, once the raw data has been digested and augmented, we reach "Optimization and Parameterization". In this activity, we take the validated hypothesis and implement it in software. This software has the power to change the parameters in applications in order to reach the optimum value of some tradeoff. For example, an optimization loop may continually adjust discounting to optimize the tradeoff between revenue and margin. Or, in a different example, it may optimize the tradeoff between new customer registrations and cost per acquisition.

Feedback from optimization back to the applications closes the decision loop and enables automated learning within the system, without requiring humans in the loop. As such, it can go as fast as the total data latency around the lower loop in the model. Batch processes will always have higher latency (so slower optimization) than real-time or streaming processes.

A few words of caution are in order about optimization and parameterization. This activity requires the highest level of organizational maturity about its data and processes. Not every company reaches this activity, or does it for every problem/hypothesis. This is the way to achieve the fastest response time to external events, which means that both great benefits and great harm can be achieved with astonishing speed. Automated optimization has been blamed for stock market crashes (the "Flash Crash") and patently ridiculous pricing events (the $23M textbook). These programs need to be designed very carefully, with governors and automatic limits baked in. They should optimize a trade-off equation rather than just maximizing some metric, or you risk damaging the health of your whole business in mechanistic pursuit of whichever metric has the fastest agent.

Summary

Using this model to guide Big Data projects helps focus efforts on the most productive areas. It puts the first things first, by starting with problem and needs identification. The model incorporates both human and technological activities so we create a fully integrated set of nested decision loops at different time scales.

Where to Find Relevancers: April Edition

2012-03-30T18:00:00Z

Want to meet a Relevancer in person? Here's where you can find us during the month of April...

Kalamazoo, MI 4/21
The KalamazooX No Technology Technology Conference
Speaker: Jen Myers

Durham, NC 4/21, 2PM Splat Space
Arduino Hack Afternoon
Attending: Alan Dipert, Splat Space founder and Meetup organizer

Austin, TX 4/23-24
Railsconf
Attending: Lake Denman

Datomic services

2012-03-29T10:00:00Z

For almost two years, we've been working with Rich Hickey to realize his vision for a next generation database: Datomic. If you haven't looked into Datomic yet, check out the videos at the end of this post, and read the whitepaper.

Now that Datomic has launched, we are excited to make it an option for our customers. We have a limited number of development teams available as they roll off other projects; two slots are currently available, on April 30th and May 21st. Our teams can help you get started, or take your project all the way to the finish line (read more about how we work). If you think you have a project that Datomic is a fit for, and you would like to apply for one of these slots, contact us at datomic@thinkrelevance.com.

Videos

If you're not familiar with Datomic, watch the presentations where Rich and Stu introduce Datomic and its query language, Datalog.

ThinkRelevance: The Podcast - Episode 008 - Michael Fogus

2012-03-28T13:24:00Z

Anyone who's been around Clojure for a little while will have heard the name Michael Fogus, who is our guest on this episode of the podcast. Fogus (as we call him) is a hacker, author, and all-around nice guy. He has recently launched Himera, a web service that compiles ClojureScript to Javascript. I've wanted to interview Fogus for quite a while, and that was all the excuse I needed.

While we were talking, we touched not only on Himera, but on pair programming, Datomic, music, and a bunch of other stuff. I hope you enjoy listening to this episode as much as I enjoyed recording it!

Download the episode here.

The show is available on iTunes! You can also subscribe to the podcast using our podcast feed.

You can send feedback about the show to podcast@thinkrelevance.com, or leave a comment here on the blog. Thanks for listening!

Show Notes

Our guest, Fogus:
- @fogus
- Author of The Joy of Clojure
- Fogus on GitHub
- Embloginations
The music
- The intro was "Mu" by Sun Ra
- On the show, we said the outro was "Witching Hour", by Ladytron. It turns out that's the album on which the song we played actually appears. The song is "The Last One Standing".
People and stuff we mentioned on the show
- ClojureScript
- Rich Hickey
- Chris Houser a.k.a. chouser
- chouser's ClojureScript
- Himera, the ClojureScript compilation service
- Himera, the Russian band
- "Himera" written in Russian: химера
- Heroku
- Paul Bauer: On Twitter @pmbauer and on the web at (def title nil)
- Paul Bauer's ClojureScript compilation service
- Chris Granger, Clojure superhero: On GitHub and on the web
- The live game editing demo he did
- "Inventing on Principle"
- Fogus’s blog post about why ClojureScript doesn’t have eval
- Fogus's Lifehacker article
- The blog post it came from
- The HackerNews discussion about it
- Expert Systems: Principles and Practice, by Giarratano and Riley
- Lisp in Small Pieces
- CiteSeer
- The Association for Computing Machinery (ACM)
- Datomic
- Datalog
- "Pair Programming Considered Harmful?"
- Brenton Ashworth
- ClojureScript One
- Google docs
- We mentioned writely, but they are now Google Docs
- Krautrock

ThinkRelevance: The Podcast - Episode 007 - Clinton Nixon

2012-03-26T13:51:00Z

On this episode, we talk to Clinton Nixon, about his sweet Ruby on Rails setup, amongst other things. We work with a lot of different technologies at Relevance, but Rails has been and continues to be one of the most important for us. So it was fun to hear how a real expert gets his Rails on. I hope you'll agree!

Download the episode here.

The show is available on iTunes! You can also subscribe to the podcast using our podcast feed.

You can send feedback about the show to podcast@thinkrelevance.com, or leave a comment here on the blog. Thanks for listening!

Show Notes

Our guest, Clinton Nixon:
The music
- The intro was "Future Crimes" by Wild Flag
- The outro was "The Street Beater" by Quincy Jones
Stuff we mentioned on the show
- Pry
- A definition of REPL
- rvm
- rbenv
- tmux
- The Ruby 1.9.3 patch for faster Rails boot time
- find-file-in-project
- find-file-in-git-repo
- ctags
- Clinton's emacs setup
- Clinton's dotfiles
- bundler docs
- bundler source
- http://apidock.org
- Vagrant
- Chef
- Puppet
- Cygwin
- Sequel
- Scheme
- Racket
- Perl
- Learn a bit more about B Corporations on our first episode
- Clojure/conj!
- Hunt the Wumpus on prompt.sh

Relevance Makes the B Corp "Best for the World" List!

2012-03-19T15:15:00Z

We are thrilled to be included in the annual B Corporation "Best for the World" list in the Best for Workers category. Relevance has been a B Corporation since 2009. Being a B Corporation means we're dedicated to using the power of business to create value for our community as well as for our customers and employees. Our employees are at the heart of our business, so we're delighted to be recognized as a great place for them!

For more information about becoming a B Corp, visit the B Corporation website.

Where to Find Relevancers: March Edition

2012-02-28T13:30:00Z

Want to meet a Relevancer in person? Here's where you can find us during the month of March:

Durham, NC Every Tuesday - 7pm @ Splat Space
Splat Space Open Meeting
Attending: Alan Dipert, Splat Space founder and Meetup organizer

Columbus, OH 3/7-4/11
Girl Develop It Newbie HTML/CSS Class
Trainer: Jen Myers

San Jose, CA 3/13-3/15
Clojure/West Training
Trainers: Alan Dipert and Stuart Sierra

San Jose, CA 3/16-3/17
Clojure/West Conference
Speaking: Stuart Halloway, Craig Andera, Alan Dipert, Michael Fogus, David Liebke, Stuart Sierra, Luke VanderHart
Attending: Chris Redinger, Brenton Ashworth, Clinton Nixon

Louisville, KY 3/15-17
CodepaLOUsa Conference
Speaking: Jen Myers

Reston, VA 3/23-3/24
RubyNation Conference
Speaking: Justin Gehtland (Keynote), Russ Olsen

ThinkRelevance: The Podcast - Episode 006 - Larry Karnowski

2012-02-27T09:30:00Z

On this episode, we talk to Larry Karnowski, one of our most senior employees, about Relevance culture. Along with his other duties, Larry works with all our new hires to make them aware of the many awesome and unusual practices and resources we have here at Relevance. Larry does a great job of talking about retrospectives, buddies, sponsors, tokens, and guitar lunch, to name just a few.

It was a true pleasure speaking with Larry. I think you’ll enjoy listening to him, too!

Download the episode here.

The show is finally available on iTunes! You can also subscribe to the podcast using our podcast feed.

You can send feedback about the show to podcast@thinkrelevance.com, or leave a comment here on the blog. Thanks for listening!

Show Notes

Our guest, Larry Karnowski:
- @karnowski
- Larry on GitHub
Music:
- Both the intro and outro music this time came from The Suburbs by Arcade Fire.
- The intro was "Month of May" and the outro was "Sprawl II (Mountains Beyond Mountains)".
- Arcade Fire is carried by Merge Records.
People we mentioned during the podcast:
- Rob Sanheim
- Aaron Bedra
- Esther Derby, author of Agile Retrospectives and giver of great workshops
- Justin Gehtland
- Alistair Cockburn, author of "Characterizing people as non-linear, first-order components in software development"
Other things that came up on this show:
- The Venture Dojo (which no longer has a web presence)
- Relevance's How We Work document
- Our good friends at Pruvop

More Creative Chaos

2012-02-15T09:00:00Z

One of the best parts of working at Relevance is that things never, ever settle down. Name the task and if it has to do with software development, helping the customer or gathering the lunch order, there is probably some Relevancer hard at work trying to find a new (maybe even better!) way of doing it. Of course there is a limit to how much positive chaos a given number of people can inflict, so we are always looking to find great people to join us and inflict more.

Case in point is newly minted Relevancer Kevin Altman. Kevin began his great adventure in life with nothing but a pen and a stack of discarded printer paper. Kevin's overactive imagination made him a natural for a life of design. Kevin gets uncontrollably excited when presented with the opportunity to help someone turn their vision into something real. Illustration, animation, front-end development: these are all weapons he's been known to bring to battle. We have also caught Kevin venturing into the back-end depths of a number of applications. Kevin washed up on Relevance's shore at the end of a two year quest at EA Games. Completely blown away by the culture, the team and the free lunches, Kevin accepted his greatest quest yet: supporting the design team at Relevance.

Also new to the Relevance family is Jen Myers. Jen is a web and interface designer out of Columbus, Ohio. Jen is interested in the user experience, teaching innovation and using design as a tool for communication. She spends the rest of her time writing, watching good movies and raising a future geek girl (no pressure!). Jen also teaches HTML/CSS and organizes the coding education program Girl Develop It Columbus.

Along with Kevin and Jen, we have been lucky enough to land Brenton Ashworth. Brenton wrote his first program on a Commodore 64 to solve math homework problems. After getting distracted for 14 years by an obsession with surfing, he found his way back to his true calling, using computers to solve problems and create things. Brenton has written programs to do everything from predicting the levels of ethyl carbamate in wine to helping companies deal with U.S. Customs claims. Brenton worked on his own for eight years but gave all that up to join Relevance in spreading even more happy chaos.

We would also like to welcome Kat Goetz who, as our accounting manager, makes sure that we know where all of the profits of chaos are going. Good thing that Kat has more than 20 years of accounting experience in industries ranging from telecommunications and construction to public accounting. Kat first came to Relevance as a contract accountant in 2010 and, since she seemed extremely skilled at herding cats armed with credit cards, we just had to bring her on as a regular employee. Kat likes to upholster furniture (really!), read, sew and she spends a lot of time cheering for her kids at various sporting events.

We have also recently sent off a couple of our friends who have decided to try something new. Jess Martin and his wife Elizabeth are moving to Swaziland, Africa to serve for a year with a non-profit called Africa Revolution. They will be living on a farm designed to care for just a few of the 200,000 AIDS orphans in Swaziland. To read more about their journey, check out their personal site.

We have also bid bon voyage to Aaron Bedra who, when he discovered that Relevance was not actually Groupon, decided to give the real thing a try. Lucky for us it took Aaron four years to figure it all out. We did manage to get an interview out of Aaron before he left for the wilds of Chicago.

Jess and Aaron, remember we take the same attitude as the Marine Corps and certain organizations involved in the restaurant linen business: There is no such thing as an ex-Relevancer. Make us proud!

Russ

Agile Reboot: Putting the Man back in Manifesto

2012-02-07T14:02:00Z

“Individuals and interactions over process and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.” That's the entirety of the Agile Manifesto, by the way. Seems simple, doesn't it? Yet there are flotillas of books and courses with detailed instructions and steps for "doing" Agile, as if it were a thing with specific rules and regulations. Hogwashery! Hear me now, the road to hell is paved with book covers and exam notes, it's time to rise up and put the 'man' (and woman) back in 'manifesto'. Spoiler alert: getting the 'fest' back in as well will be the topic of a future post...

Great teams do not "do" Agile, great teams "are" Agile. Being agile is not about burn-down charts, or attendant posture during some meetings, or not having other meetings, or some other "official rule" you must follow to pass a certification test. Being agile is a state of mind, a frame of reference from which to make decisions. If you are in the business of delivering software solutions and your strategy for success is adopting formulaic "Agile Processes", you are costing everyone a lot of extra money. Stop it. Stop it now, and let the healing begin.

Here's a quick test to see if you are a member of an agile team. Does the team trust each other and communicate frequently and honestly? Give yourself a point. You're moving faster towards clear, shared goals with less hesitation and fewer missteps. Individuals and interactions - sound familiar? The Speed of Trust can be measured, don't waste your client's money on avoidable drag.

Are team members (regardless of employer) passionately focused on overcoming hurdles blocking the path to shipping as a cohesive unit? Collaboration! That's the spirit! Is the team focused on building effective solutions that make people smile, or on how closely the product matches the original specification? Hint - you should be making people smile.

Teams are not formed to create documentation (not agile development teams anyway), they are formed to do magic, to enable people to do things not previously possible. Never forget that. Real agile teams do not start projects without first mapping a path, but they do not hesitate to adapt when market forces and other realities shift during flight. Respond to change, don't just follow a plan. Seeing a pattern here?

If your team is struggling to ship products on time, or continually ships products that fail to move the ball forward, or is constantly duplicating work due to miscommunication and misunderstandings, simply changing toolsets or making new rules is not going to save you. If every one of your team members cannot clearly state what success means for a project, why the project has been undertaken, and what risks and challenges stand between them and a solution, you're not going to cross the finish line (at least not when and where you want to). Forget the charts. Forget the rules. Talk, trust, learn, adapt. The tools are just that, tools. Use the ones that work for you. On this project. With this team. Success does not hinge on whether you use Jira, or Mingle, or Pivotal Tracker, Google Docs, or Excel, or sticky notes, or hand signals and a series of grunts.

Successful agile teams are characterized by quickness, lightness, and ease of movement. They are mentally quick and alert. They have a resourceful and adaptable character. They are well-coordinated in movement and have the ability to think and draw conclusions quickly. That's the entirety of the dictionary definition of “agile” by the way. Seems simple, doesn't it?

ThinkRelevance: The Podcast - Episode 005 - Michael Parenteau

2012-02-03T15:00:00Z

Ever since I began thinking about doing a Relevance podcast, I knew that I was going to want to have Michael Parenteau on the show. Michael is head of our design department, and a designer himself. He has a great attitude, and brings both that and his considerable talent to everything he does. I happened to be down in Durham the week that we released the new website, which Michael had a big hand in bringing about, so I knew the time was right to have a conversation with him about it.

In this episode, we talk with Michael Parenteau about being a designer at Relevance, Sanskrit, the importance of remembering the human part of software, and washing feet at Burning Man. Enjoy!

Download the episode here.

The show is finally available on iTunes! You can also subscribe to the podcast using our podcast feed.

You can send feedback about the show to podcast@thinkrelevance.com, or leave a comment here on the blog. Thanks for listening!

Show Notes

Our guest, Michael Parenteau
- @parenteau
- Michael on GitHub
We have a brand new website! You're probably looking at it right now.
- Note the hand-drawn illustrations on the team page
- And the How We Work section
- Plus the neat background image
- And don't forget about the interesting typography
- Check out what unmatchedstyle had to say about the website, too
- Please send us feedback about the website
People we mentioned during the podcast
- Jen Myers @antiheroine
- Kevin Altman @itg
Other things that came up on this show
- ClojureScript One
- Pair programming
- Git
- GitHub
- HAML
- Slim
- Jekyll
- Ruby
- Liquid
- Agile Principles
- Clojure
- Software Craftsmanship
- Sanskrit
- Devi Mandir
- Burning Man

Where to Find Relevancers this Month!

2012-01-27T08:50:00Z

Want to meet a Relevancer in person? Here's where you can find us in the next month:

Durham, NC Every Tuesday - 7pm @ Splat Space
Splat Space Open Meeting
Attending: Alan Dipert, Splat Space founder and Meetup organizer

Baltimore, MD 2/1 - 7:30pm @Revelytix
BaltimoreFP Presentation/Hack Night
Speaking: Alex Redington

Aruba 2/6-2/10
SpeakerConf
Speaking: Michael Nygard and Stuart Halloway

Durham, NC 2/6/2012, 7pm @ Splat Space
Monthly TriClojure Meeting
Speaking: Brenton Ashworth, ClojureScript One
Attending: Chris Redinger, TriClojure Founder and Meetup Organizer

Atlanta, GA 2/23-2/24
We're proud sponsors of Lessconf
Attending: A dozen Relevancers

ThinkRelevance: The Podcast - Episode 004 - Aaron Bedra's Valedictory

2012-01-25T19:30:00Z

When I heard that Aaron Bedra was leaving Relevance, I was surprised and a bit saddened. But I also thought, "Hey, we should have him on the podcast." And that's just what we did. I think it's great to work at a place where it's cool to record an interview with someone who has decided to move on.

In this episode, we talk to Aaron about what brought him to Relevance, some of the things he's worked on while he was here and even a bit about what the future holds for him.

Download the episode here.

You may have noticed a sweet new feature on the podcast: cover art! Our crack design team offered to produce "album covers" for our shows, and I realized that I'd be an idiot not to take them up on the offer. It's a fun detail, and one I hope you'll enjoy.

As a reminder, you can subscribe to the podcast using our podcast feed. I'm still working on getting the show added to iTunes, but that should happen pretty soon.

You can send feedback about the show to podcast@thinkrelevance.com, or leave a comment here on the blog. Thanks for listening!

Show Notes

Our guest, Aaron Bedra
Music
- Intro: Red Baron, performed by Billy Cobham off of "Spectrum"
- Outro: Aeroplane, by the Red Hot Chili Peppers, off of "One Hot Minute"
People
- Muness Alrubie: @muness
- Stu Halloway: @stuarthalloway
- Justin Gehtland: @jgethland
- David Liebke: @liebke
- Chris Redinger: @redinger
Links
- Groupon
- RailsConf
- Streamlined
- RubyConf
- ThoughtWorks
- MetaSploit
- Programming Clojure: First Edition, Second Edition
- Building Safe Applications, a PeepCode book by Aaron Bedra
- test.generative
- QuickCheck
- EasyCheck
- Heroku
- Casting SPELs in Lisp
- Land of Lisp
- Rails Recipes
- GitHub
- Strange Loop
- Clojure/conj
- Clojure/West

ThinkRelevance: The Podcast - Episode 003 - Brenton Ashworth on ClojureScript One

2012-01-12T05:00:00Z

I was particularly excited to record this, our third episode of ThinkRelevance: The Podcast. That's because on today's show, we talk with Brenton Ashworth about ClojureScript One, which was released just this week. As Brenton will explain, ClojureScript One is a project aimed at helping people learn how to use ClojureScript quickly and effectively.

Download the episode here.

As a reminder, you can subscribe to the podcast using our podcast feed. I'm still working on getting the show added to iTunes, but that should happen pretty soon.

You can send feedback about the show to podcast@thinkrelevance.com, or leave a comment here on the blog. Thanks for listening!

Show Notes

Our guest, Brenton Ashworth
Music
- The intro song on this episode is Fight Fire With Fire, by Metallica.
- The outro song is Paranoid by Black Sabbath.
People
- Luke Vanderhart: @levanderhart, GitHub
- Jen Myers: @antiheroine, Blog, GitHub
- Kevin Altman @itg
- Michael Parenteau @parenteau
- Rich Hickey: @richhickey
- Fogus: @fogus, Blog, GitHub
- David Nolen: @swannodette, Blog, GitHub
Links
- ClojureScript One
- ClojureScript itself
- Google Closure
- Domina - A ClojureScript DOM manipulation library
- Hiccup - A fast library for rendering HTML in Clojure
- How We Pair- A bit about pair programming at Relevance
- The "Hammock Talk" - Rich's excellent talk about how to solve hard problems

ThinkRelevance: The Podcast - Episode 002 - David Liebke on Avout

2012-01-05T05:00:00Z

Hello, and welcome to the second episode of ThinkRelevance: The Podcast. We had so much fun last time that we thought we'd do it again! This time, we talk to David Liebke (@liebke), a developer here at Relevance. The main thrust of our conversation centers on Avout, a Clojure library for managing distributed state in a consistent manner. Avout is pretty cool, and we get to hear David explain it, as well as talk a bit about the source of the names of all David's projects, the book Anathem.

Download the episode here.

In other exciting news, the show now has an actual feed, just like a real, grown-up podcast. You can find it at http://feeds.feedburner.com/thinkrelevance/podcast. I'll work on getting the show added to iTunes as the next step.

Also, I believe I forgot to mention this last time, but please send feedback about the show to podcast@thinkrelevance.com. Thanks for listening!

Show Notes

David Liebke on the Internet
The intro and outro music today both come from IOLET by David Stutz. The CD is inspired by some of the concepts and themes in Anathem. The intro song is Deriving the Quadratic Equation, and the outro is Approximating Pi.
Avout can be found on the web at http://avout.io. You can ask questions on the Clojure mailing list.
Some of the technologies we talked about on this episode:
The people we mentioned today include:
- Rich Hickey: @richhickey
- Stuart Sierra: @stuartsierra, Blog
- Neil Stephenson

ThinkRelevance: The Podcast - Episode 001

2011-12-19T05:00:00Z

Relevance is a fascinating place to work. The primary reason for that, in my opinion, is the great people that work there. I find I'm constantly having interesting conversations with my coworkers, and it's not always about tech stuff. More than once I've had a random hallway conversation and thought, "Wow, if I had recorded that, it would make a pretty good podcast episode."

So that's what I'm doing. On a roughly weekly basis, I'm going to be releasing conversations with the people I am privileged to work with. We've got no set agenda: just have an interesting conversation about whatever people want to talk about.

As this is our first episode, I'm still figuring out how to do all the usual podcast stuff, like getting it on iTunes, creating a feed, and all that jazz. So for our inaugural episode, we're just going with a simple download link. I'll get all the fancy podcast stuff figured out, soon, I promise.

In this episode, I talk with Justin Gehtland, who's sort of our CEO (he explains the "sort of" in the episode). As is always the case when talking to Justin, it was a fun conversation. I hope you'll agree.

Show Notes

We mention a lot of people in the podcast. Here's a list of where to find them on the web:

Justin Gehtland: @jgehtland, Blog
Alan Dipert: @alandipert, Blog
"Scary" Ron Sumida: Current web whereabouts unknown
Don Box: @donbox, Wikipedia
Chris Sells: @csells, Blog, Wikipedia
Brent Rector: Website
Keith Brown: @keithbrown42, Website
Stu Halloway: @stuarthalloway
Tim Ewald: Current web whereabouts unknown
Glenn Vanderburg: @glv, Blog
Jason Rudolph: @jasonrudolph, Website
Rob Sanheim: @rsanheim
Rich Hickey: @richhickey
Andy Hunt and Dave Thomas are The Pragmatic Programmers

Other notes:

The intro to the podcast is the song Jet City Woman by Queensrÿche.
The outro to the podcast is the song Sultans of Swing by Dire Straits.
Justin, Stu Halloway, Tim, and I all used to work at DevelopMentor.
Relevance's Fridays policy.
You can find out more about B Corporations at www.bcorporation.net.
Justin's books:
Band Together is on the web at www.bandtogethernc.org.
Read about Fan, the obscure programming language. Apparently it's called Fantom now.
Programming Clojure, by Stuart Halloway.
Ruby on Rails.

Documenting Architecture Decisions

2011-11-15T05:00:00Z

Context

Architecture for agile projects has to be described and defined differently. Not all decisions will be made at once, nor will all of them be done when the project begins.

Agile methods are not opposed to documentation, only to valueless documentation. Documents that assist the team itself can have value, but only if they are kept up to date. Large documents are never kept up to date. Small, modular documents have at least a chance at being updated.

Nobody ever reads large documents, either. Most developers have been on at least one project where the specification document was larger (in bytes) than the total source code size. Those documents are too large to open, read, or update. Bite sized pieces are easier for for all stakeholders to consume.

One of the hardest things to track during the life of a project is the motivation behind certain decisions. A new person coming on to a project may be perplexed, baffled, delighted, or infuriated by some past decision. Without understanding the rationale or consequences, this person has only two choices:

Blindly accept the decision.

This response may be OK, if the decision is still valid. It may not be good, however, if the context has changed and the decision should really be revisited. If the project accumulates too many decisions accepted without understanding, then the development team becomes afraid to change anything and the project collapses under its own weight.
Blindly change it.

Again, this may be OK if the decision needs to be reversed. On the other hand, changing the decision without understanding its motivation or consequences could mean damaging the project's overall value without realizing it. (E.g., the decision supported a non-functional requirement that hasn't been tested yet.)

It's better to avoid either blind acceptance or blind reversal.

Decision

We will keep a collection of records for "architecturally significant" decisions: those that affect the structure, non-functional characteristics, dependencies, interfaces, or construction techniques.

An architecture decision record is a short text file in a format similar to an Alexandrian pattern. (Though the decisions themselves are not necessarily patterns, they share the characteristic balancing of forces.) Each record describes a set of forces and a single decision in response to those forces. Note that the decision is the central piece here, so specific forces may appear in multiple ADRs.

We will keep ADRs in the project repository under doc/arch/adr-NNN.md

We should use a lightweight text formatting language like Markdown or Textile.

ADRs will be numbered sequentially and monotonically. Numbers will not be reused.

If a decision is reversed, we will keep the old one around, but mark it as superseded. (It's still relevant to know that it was the decision, but is no longer the decision.)

We will use a format with just a few parts, so each document is easy to digest. The format has just a few parts.

Title These documents have names that are short noun phrases. For example, "ADR 1: Deployment on Ruby on Rails 3.0.10" or "ADR 9: LDAP for Multitenant Integration"

Context This section describes the forces at play, including technological, political, social, and project local. These forces are probably in tension, and should be called out as such. The language in this section is value-neutral. It is simply describing facts.

Decision This section describes our response to these forces. It is stated in full sentences, with active voice. "We will ..."

Status A decision may be "proposed" if the project stakeholders haven't agreed with it yet, or "accepted" once it is agreed. If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement.

Consequences This section describes the resulting context, after applying the decision. All consequences should be listed here, not just the "positive" ones. A particular decision may have positive, negative, and neutral consequences, but all of them affect the team and project in the future.

The whole document should be one or two pages long. We will write each ADR as if it is a conversation with a future developer. This requires good writing style, with full sentences organized into paragraphs. Bullets are acceptable only for visual style, not as an excuse for writing sentence fragments. (Bullets kill people, even PowerPoint bullets.)

Status

Accepted.

Consequences

One ADR describes one significant decision for a specific project. It should be something that has an effect on how the rest of the project will run.

The consequences of one ADR are very likely to become the context for subsequent ADRs. This is also similar to Alexander's idea of a pattern language: the large-scale responses create spaces for the smaller scale to fit into.

Developers and project stakeholders can see the ADRs, even as the team composition changes over time.

The motivation behind previous decisions is visible for everyone, present and future. Nobody is left scratching their heads to understand, "What were they thinking?" and the time to change old decisions will be clear from changes in the project's context.

Experience Report

You may have noticed that this post is formatted like an ADR itself. We've been using this format on a few of our projects since early August. That's not a very long time in the global sense, but early feedback from both clients and developers has been quite positive. In that time, we've had six to ten developers rotate through projects using ADRs. All of them have stated that they appreciate the degree of context they received by reading them.

ADRs have been especially useful for capturing longer-term intentions. We have several clients who are stabilizing their current systems, but looking toward a larger rearchitecture in the not-too-distant future. By writing these intentions down, we don't inadvertently make those future changes harder.

One potential objection is that keeping these in version control with the code makes them less accessible for project managers, client stakeholders, and others who don't live in version control like the development team does. In practice, our projects almost all live in GitHub private repositories, so we can exchange links to the latest version in master. Since GitHub does markdown processing automatically, it looks just as friendly as any wiki page would.

So far, ADRs are proving to be a useful tool, so we'll keep using them.

Now with four more awesome

2011-10-24T04:00:00Z

We may have stopped pretending to be Apple but we haven't stopped adding more awesome to our team: Naoko Chamberlain, Clinton Nixon, Russ Olsen and Jenn Hudson.

Naoko's personality drove her to project management/coach calling. She’s a planner and couldn't help that if she tried. She hugely appreciates the details. It comes naturally to observe and attend to her surroundings, and she truly enjoys teamwork whether at work, play, or playing ball. She also loves to organize everything -- even her sock drawer is organized by color and type.

When Naoko is not planning to-do's or organizing her sock drawer she expresses her love for wine, conversations, and sports. When all three are in one place she is in an extra good mood (except for when Boilermakers, Yankees, or Colts are losing an important game).

Clinton has spent the last 12 years all over the technology industry, from monitoring network security at Three Letter Agencies to hacking for startups to managing teams of developers. After discovering both Ruby and Durham, NC six years ago, he's been a huge fan of both. He's spent enough time at Relevance game nights and other events that he's felt like part of the family for a long while. He has perfectly normal, non-nerdy hobbies outside of programming, like playing Dungeons & Dragons and playing the ukulele.

Russ Olsen started his career doing that other kind of engineering, the sort that involves electricity, gears and getting dirty. Pretty rapidly the wonder of computer programming lured Russ away, which probably explains why most of his fingers are still intact today.

Since turning to coding, Russ has worked on everything from 3D design and image processing software to database query engines and workflow systems. Russ first discovered Ruby back in 2000 when he went looking for a simple programming language to teach to his son. The seven year old lost interest, but Russ never did and he has been building increasingly sophisticated systems in Ruby ever since.

Russ also spends a fair bit of time promoting Ruby via public speaking and he helped found RubyNation, a regional Ruby conference held each Spring in Northern Virginia. Russ has also written extensively about Ruby in the form of two highly regarded books: The first, Design Patterns in Ruby was published in 2008 and is a complete reworking of the classic Gang of Four patterns for a modern dynamic programming language. Russ's second book Eloquent Ruby is a guide to writing idiomatic Ruby. Eloquent Ruby was an instant hit in the Ruby and Rails community when it was published earlier this year.

Russ also has been secretly enamored with parentheses since a very early age and lately has been dabbling in Clojure.

Jenn has 20 years of accounting and analytical experience in a wide range of industries including software, alternative energy, legal, construction, retail and photofinishing, working with both small business and major corporation settings. She has extensive experience at managing an entire business including preparing strategic plans, implementing new programs and products, marketing and analyzing performance. While away from the office, she enjoys cooking and entertaining, travel to far away places and following her daughter's volleyball team around the country.

I'd also like to wish our alumnus Shay Frendt the best of luck with our friends at Chargify. We love you, we miss you.

We're still looking for more awesome. If you'd like to join this awesome team, introduce yourself.

Friday Update 1.1

2011-08-08T04:00:00Z

Welcome to the latest installment of the critically acclaimed "Friday Update"! This week's theme is "In-browser Awesomeness (plus one more)", and boy do we have an exciting lineup for you today!

First up, our brilliant intern Vojto (pronounced VOY-toe) has spiked out a Cocoa library called Atmosphere which waits for client-side changes and pushes those changes to the server automagically. You can read more about it on his blog.

Next we have the illustrious Chad Humphries, who is investigating using Rails 3.1, Backbone.js and Jasmine to build applications. He is excited to announce that the Jasmine tests run both inside and outside the browser.

Continuing our theme, Bobby Calderwood and Alex Redington are working on an in-browser ClojureScript evaluator. A server is required to perform compilation, but, in conjunction with some additonal work from Alan Dipert and Brenton Ashworth, we could soon have a browser-connected REPL!

And our c-c-c-combo breaker: David Liebke is working on a Clojure library called cogito. It's a Clojure implementation of System-Z+, a probabalistic reasoner.

That's it for now!

And don't forget to sign up for Clojure/conj!

Relevance Blog

ThinkRelevance: The Podcast - Episode 012 - Craftsman Swap

Show Notes

ThinkRelevance: The Podcast - Episode 011 - Jen Myers

Show Notes

Why Retrospectives Should Get Personal

Great Feedback in 60 minutes or Less

I Never Thought it Would Happen to Me...

Bringing the Love Home

Where to Find Relevancers: May Edition

ThinkRelevance: The Podcast - Episode 010 - Stu Halloway

Show Notes

ThinkRelevance: The Podcast - Episode 009 - Alan Dipert

Show Notes

Big Data Reference Model

Investigation

Implementation

Production

Summary

Where to Find Relevancers: April Edition

Datomic services

Videos

ThinkRelevance: The Podcast - Episode 008 - Michael Fogus

Show Notes

ThinkRelevance: The Podcast - Episode 007 - Clinton Nixon

Show Notes

Relevance Makes the B Corp "Best for the World" List!

Where to Find Relevancers: March Edition

ThinkRelevance: The Podcast - Episode 006 - Larry Karnowski

Show Notes

More Creative Chaos

Agile Reboot: Putting the Man back in Manifesto

ThinkRelevance: The Podcast - Episode 005 - Michael Parenteau

Show Notes

Where to Find Relevancers this Month!

ThinkRelevance: The Podcast - Episode 004 - Aaron Bedra's Valedictory

Show Notes

ThinkRelevance: The Podcast - Episode 003 - Brenton Ashworth on ClojureScript One

Show Notes

ThinkRelevance: The Podcast - Episode 002 - David Liebke on Avout

Show Notes

ThinkRelevance: The Podcast - Episode 001

Show Notes

Documenting Architecture Decisions

Context

Decision

Status

Consequences

Experience Report

More Reading

Now with four more awesome

Friday Update 1.1