Blog

Nov 02 2010

Comments

The Relevant Bits - Nov 2, 2010

In addition to pulling off a successful "Conj", here is the run down of what we at Relevance were doing with our 20% time in October:

  • Chad continued his quest for Vimlander 2 The Quickening to be the only vim config around.
  • Stuart H has been knocking out tickets and applying patches to Clojure. Grab 1.3.0 Alpha 2 if you want to keep up with the latest in Clojure development.
  • Michael was an expert panel judge for the Rails Rumble.
  • Aaron shows off how to do mobile org in his emacs config.
  • Stuart H, Michael and Jon enhanced Mycroft. If you're already using it, see the history to see what's new. If you're not already using, grab it and start inspecting your JVM data.
  • Jon and Michael added paginated lists to their fork of swish.
  • Stuart S released Lazytest 1.0.1, 1.0.2, 1.1.0, 1.1.1 and 1.1.2 of his testing framework. See the changelog to figure out what your version of Lazytest provides.
  • Jon and Aaron updated labrepl, the environment for learning Clojure, for Clojure 1.3.0 compatability and closed out some GitHub issues.
  • Stuart H uploaded his slides from his Clojure presentation on protocols at JAOO.
  • Chris released 1.0 of ValidationReflection, for Rails 3 compatibility.
  • Alan updated reconfig to be Clojure 1.3 compatible. Check out this library if you want to reload config files in Clojure on SIGHUP.
  • Stuart S created Message, experiments in message-passing architectures in Clojure.
  • Chad, Alex R and Larry forked ruby-saml and started adding some new features, including optional HTTP parameter passing and more test coverage.
  • Alex R created Dwarf, a data mining tool for Rails 3.

Sep 27 2010

Comments

The Relevant Bits - Sep 27, 2010

Lots of Clojure stuff going on since our last update. Here's the latest report on what we've done with our 20% time:

Sep 20 2010

Comments

Rotation and the Customer

Rotation and the Customer

As a consulting development organization, we are faced with the reoccurring challenge of "selling" to our customers the value of one of our core techniques: team rotation. We find it an invaluable part of our process and our culture, but one that some customers can't understand immediately why we practice it. This is an attempt to lay out the case for team rotation as not only valuable, but invaluable, to the customer during any development process.

How do we work at Relevance?

Relevance is an agile software development shop. That is not to say that we are a Scrum shop, or an XP shop, or any other flavor. It is that we believe strongly in some core principles, and strive every day to mold how we work to achieve maximal results. All of our processes are built around the following three ideas:

  1. The development team needs daily feedback from our partners to ensure that we are not going down the wrong path.
  2. The team as a whole needs to have a shared understanding of the risks to the project, their possible impacts and the costs of mitigating them.
  3. We need to ship. All the time. Shipping is an excellent way to measure progress.

From these three principles, everything else we do can be logically derived. We have daily standups, and late-day checkins. We love checklists. We TATFT. We use CI. We work in two-week iterations, and organize stories into releasable features. We have risk assessment meetings and team retrospectives on a regular basis. We pair on damn near everything, including management tasks and client communication. And we rotate our team members, constantly.

How does rotation help your customer?

Team rotation is one of those areas we get asked about most. “How does that help? Isn’t is just a cost to the customer? What’s the point?” These are valid questions; most software development teams are established for the life of a project, in order to create “ownership” of the problems and their solutions, and continuity from day to day. Traditionally, ownership and continuity are seen as the best way to achieve lasting velocity. Don’t believe that. Not for an instant. Only one role in your project team should be immune from rotation: the conductor (more traditionally, the project manager). There is enormous value to having continuity of the primary communication channel, such that your partners always know who to call, and who to expect on calls and at meetings. But for the implementation roles (developer, designer, etc.) rotation is a key component of creating value.

Ownership

It isn’t that we don’t believe that “ownership” helps with quality and velocity. We strongly believe that. We just don’t believe that singular, isolated ownership is valuable. Or more specifically, the value doesn't justify the costs. Software developers who “own” a project are single points of failure. The coupled power and responsibility virtually guarantee a certain amount of information hoarding, making them indispensable to the project. When that occurs, velocity is negatively impacted because there is no way a single person can focus on a single problem every day for the life of a project. Because they own all the information, whenever they are unavailable, the project suffers. Sometimes greatly.

Consistently rotating team members is the only way to create shared ownership of a codebase, and more importantly, of the emotional attachment to its success. As you rotate team members through projects, you increase the shared commitment to shipping it that is so vital to good software development. What’s more useful for a customer: knowing that three of your guys are dedicated to their project forever? Or knowing that all of your guys are sharing an interest in getting it shipped?

By rotating team members through this way, you raise your bus number dramatically, buffering against things like (expected or surprise) time off, the ravages of new-school-year plagues, RubyConf, the next iPhone release, Halo Reach, and whatever other major distractions occur in the normal work week. Because so many people will have context on each of your projects, you can roll with the punches and still get people who know the code, know the customer, and know the “project culture” to carry the flag. That’s a huge risk mitigation, and customers benefit from it every day.

Finally, because of the spread ownership, when emergencies arise, there is a much higher chance that the customer will be able to reach somebody knowledgable right away. This benefit is hard to overstate. When today's project team is just three people, but the support list has twelve names on it, you know that you are going to be able to get answers quickly.

Continuity

Continuity sounds great on paper; the devs build up a great deal of domain knowledge and momentum, and can tackle new challenges based on their amassed experience. In practice, there is an upper bound to this benefit; domain knowledge is definitely critical, but you can amass enough of it in a short amount of time that there is a diminishing return beyond that. And once the learning tapers off, the natural corollary tends to creep in: boredom. A bored developer is likely to pay less attention to critical details in coding and testing. It’s just natural. Rotating your people allows them to be consistently re-engaged in your partners’ problems and avoid the stagnation that a six-month project (or longer) typically engenders in its team members.

Second, continuity of development staff has an implicit assumption that all tasks in a project are created equal. That the developers assigned to the project can tackle all tasks, rise to all challenges, ship all features equally well. But if you have a strong, large and diverse team, you will necessarily have an uneven distribution of skills. Some people will be great jQuery people; others will have a security background; others will kick ass at asynchronous code. By limiting yourself to a dedicated team, however continuous it is, you will miss out on the power you gain by having a diverse team. Rotating developers allows you to take advantage of your organization's diverse skills; that gives you leverage. Without rotation, your team will operate at a least-common-denominator level of quality and velocity; every project will feature tasks that its continuously assigned team are terrible at, thus draining the project of momentum. A steady diet of rotation will usually alleviate a lot of that by allowing you to adjust to the needs of the current tasks.

Finally, by establishing rotation as a core value, you can eliminate the traditional friction between UI/UX issues and code development. UI/UX is often defined as “fuzzy”, hard to quantify or estimate, and difficult to integrate with coding teams. But by rotating designers in as half of a development pair, you can achieve two goals at once: using an existing, natural part of the process to layer in design tasks, and creating a shared culture of design and code excellence among all team members. We aren’t nearly as good at this last point as we would like, but we are trying, and noticing that exposing designers and coders to each other in direct pairing sessions has enormous payoff for the project.

#How does rotation help you, the development team?

There is a benefit to your team, as well. The obvious one is direct one-on-one skill sharing. If you couple mandatory rotation with pairing, you get a massive opportunity to have people learn from each other, on the clock, in real world situations, all the time. Your team can level up across your areas of expertise by being conscientious about how and who you rotate, and where. Understand the pairings, and ask for input, and you can create awesome learning experiences every day.

On top of that, by giving everybody on the team the expectation that they will rotate to a new project within a given window, you minimize the likelihood that they will mentally checkout of the project. I don’t know about you, but if I look at a problem space and know, without doubt, that I’ll be still working on it six months from now, some part of my brainstem tries to throttle that other part of my brain that wants to kick ass. And it is an effort to fight back. But if I know I have a limited window to kick ass within, then I’m all in and working. Rotation guarantees the opportunity for change.

#Mitigating the potential pain of rotation

The biggest potential drawback to rotating team members is that velocity can suffer. Regardless of how much shared context there is, every rotation carries the on-ramp burden with it as the developer re-integrates with the project culture, the current codebase and the current priorities of the customer. The key is to rotate thoughtfully and understand that these costs are universal. As long as they don’t surprise you, you can pay them and easily move past. A key method of preventing on-ramp friction is to only rotate half a pair at any time. The pair who stays on the project can carry some of the burden during the on-ramp period, thus dampening the friction effect. Also, communicate clearly and proactively when a rotation is going to occur so everyone knows to expect the resultant effects. As long as the entire team buys into the benefits of the practice, the costs will be easily bourn. But surprise costs are always a problem, so make sure to announce ahead of time when the rotations are occurring. With luck, the team will establish a high enough trust level that the announcements can disappear over time; this is when rotation has proven its value and your customer is no longer trying to weigh the costs vs. the benefits. Until then, be clear about your intentions and schedule.

#Conclusion

Really, rotation of team members is enormously beneficial whether you are a consulting development team or an internal shop. The major question is: how do you take advantage of it within your established practices? If your team has wanted to employ rotation for a while, but can’t find “the right time”, just mandate one. Pick a date: on Oct. 1, half the team will rotate to new projects. Constraints spur creativity. Now is the perfect time.

Sep 06 2010

Comments

The Relevant Bits - Labor Day 2010 Edition

The big result of our "20% time" this week is the release of the clojure-conj web site. That, and other bits, are detailed below:

  • It's live! Announcing more details about the (first clojure-conj). And now, you can register for the event itself. Seats are limited, so don't miss out on this great event we've been planning.
  • Chris has been mentoring Fela Winkelmolen on his Ruby Summer of Code project this summer. Congrats to Fela as he has reached the end! Read about his accomplishments.
  • Stuart H started a four week series of an in-house version of The Pragmatic Studio's Clojure Programming course for a large part of the company in the evenings.
  • Chad & Chris each converted a client app over to be on the latest versions of Ruby 1.9.2, Rails 3.0 and Bundler 1.0. We feel that these technologies are ready for production use, and so should you.
  • Jared released version 0.4.6 of PDFKit.
  • Aaron released clojure-web, a collection of clojure web recipes.
  • Rob updated New World Order, his Rails 3 template, to be compatible with the final release of Rails 3.0.
  • Stuart S continued his crusade to prepare clojure-contrib for future development and releases. Read his detailed proposal.
  • Stuart S also continued improving upon LazyTest. Check out the 24 commits he's pushed over the last few days.

Sep 02 2010

Comments

Notes on Remote Pairing

Here at Relevance, we're committed to the idea of working in pairs. But as the company grows beyond its Durham headquarters, we have more and more people working outside of the office. Pairing is hard enough by itself, but pairing remotely is daunting. This post documents some of the software and processes we've tried.

Being a Mac-heavy office, we started with iChat and its screen-sharing feature. This is quick and easy, and works fairly well for brief use. But several Relevancers have gone multiple-monitor in their home offices. iChat screen sharing doesn't play well with multiple monitors — it shrinks both "host" desktops to fit on one "guest" screen. Also, the audio quality isn't that great, and the connection is flaky on residential Internet.

We switched to Skype for audio chat. The sound quality is much better, but its screen-sharing feature is view-only. We tried VNC for screen-sharing — both the VNC server built-in to OSX and third-party alternatives — but it's much too laggy for any serious use. We even tried a few commercial products, of which TeamViewer was the best. It supports multiple monitors (guests can choose which host monitor to view) and has better responsiveness than VNC. But the license is expensive, and it's still not perfect, especially when the members of the pair have different-sized screens.

The fundamental problem with remote pairing by screen sharing is that one half of the pair is at a severe disadvantage. The "host" is working on a local machine, with no lag or display artifacts. The "guest" is looking at a fuzzy screen with several hundred milliseconds of lag. That might not sound like much, but it's hard to be effective when the text on the screen is half a second behind your typing.

So for the past few weeks I've been experimenting with a different mode of pairing that tries to put everyone on the same level playing field. I set up a persistent Amazon EC2 instance running Ubuntu GNU/Linux and all our favorite development tools. Both members of the pair can SSH into the instance and share a terminal session with tmux. There are still lag issues, but at least everyone has to deal with the same lag.

tmux is a great tool, although there are still configuration headaches. You don't realize how complex "dumb" terminals can be until syntax highlighting renders all text in blinking red italics for one user and completely invisible for another. The trick is to get everyone on the same terminal application (usually iTerm) and match up the TERM environment variable at both ends. Then there's the Emacs/Vim debate, but that's not a problem we're going to solve any time this century.

Pairing in text mode is more efficient, bandwidth-wise, than in graphics mode, but you can't share a web browser to debug a web app in your terminal. (Yes, there are text-mode web browsers, but that doesn't help you debug HTML layouts.)

VNC, we know, is slow, but there are newer remote-screen technologies for Linux, such as the open-source NX protocol. NX is much faster than VNC, with better display quality and security. The free client and server packages from NoMachine.com allow two users to share a single X-Windows session. Just one quirk to deal with: unlike VNC, NX renders the mouse pointer locally. Effectively, each user has their own mouse, and cannot see the other's. This is fine most of the time, until you want to literally "point" at something on the screen to draw attention to it.

Another upside to pairing with NX is that the "remote" window only needs to be big enough for a single shared application, such as a web browser. Each member of the pair can keep their own desktop with their own email, chat, and other applications.

This setup works pretty well, in my opinion, although recently we hit another snag: certain jobs require us to interact with servers on VPNs behind corporate firewalls. We haven't figured out how to make an EC2 instance connect to a VPN while also remaining available to the pair that is using it — I'm not sure if that's even possible. (Amazon's "Virtual Private Cloud" seems geared toward large enterprises with many IPs, not a single instance.)

So that's the current recipe: Skype for audio, tmux for text editing, and NX for shared web browsing. It's far from perfect, but we've managed to get work done this way. Do you have techniques or tools you use to help remote employees stay connected? Let us know!

Aug 31 2010

Comments

Come to Relevance and Be Excellent

Earlier, we posted that we were seeking some new PMs for the Relevance team. At that time, I mentioned that we were always looking for great technical folk as well. I think that deserves its own post.

Our team is growing pretty fast. Our combination of technology platforms and deep devotion to the people side of software is resonating really well with our customers and we want to encourage and enable that growth. So what are we looking for? I'm glad you asked.

Are you excellent at Ruby and/or Clojure? Can you work sitting next to somebody who is at least as smart as you, pairing on solutions to wicked problems? Do you want to work on open source or community projects 20% of the time? Can you jump back and forth between small apps for early-stage startups and giant systems for Fortune 100 companies? How good are you at ping pong? Can you demonstrate a history of having an impact on the projects you contribute to? Do you practice TDD and have strong opinions about testing frameworks (we have an ongoing war over Cucumber here, and we need more combatants)? Have you read Cryptonomicon, Daemon or The Black Swan? Do you like to speak at conferences or write awesome blog posts about cool technology? Are you comfortable getting direct feedback about your work? How many of the founders of GitHub can you name?

If you found yourself in the questions above, we want to talk with you. We're looking for full-time or contract technologists. We especially want people who can work in our Durham office, or who live in DC. Come be part of something growing, special and fun.

Drop us a line at jobs@thinkrelevance.com.

Aug 30 2010

Comments

The Relevant Bits - 08/30/2010 Edition

New point releases, new projects, and more info about the first clojure-conj. Here are The Relevant Bits from last week's "20%" time:

  • Lots of planning and organization on the (first clojure-conj). This is an event you are not going to want to miss! We will be unveiling the fruits of this labor later this week. Keep a close eye on the website for more information.
  • David released Incanter 1.2.3.
  • Jared released Errbit, the open source error catcher that's Hoptoad API compliant. Read more about it in his recent blog post.
  • Rob released watch-me-now 1.9.0
  • Jared can't let a week go about without an improvement to PDFKit, this week, announcing PDFKit 0.4.5.
  • Stuart S also contributed his weekly improvements to Lazytest.
  • Aaron updated labrepl to work with the latest Compojure.

Aug 24 2010

Comments

Introducing Errbit

Here at Relevance, we use Hoptoad for tracking exceptions in our Rails apps. It's great because it gives us a heads up when something goes wrong but it doesn't bury us with tons of email. So, when we found out we couldn't use it on one of our client's apps due to firewall and data confidentiality requirements, we were naturally upset, but we worked around it.

We ended up using a mix of Chatterbox and CapGun to track exceptions and deployments. While this works great, it requires a bit more configuration and doesn't have some of the features that we're used to with Hoptoad. What's a developer to do?

Needing a new project to work on for my Open Source Fridays, I decided to try to tackle this problem. As a result, I'm excited to announce Errbit, the open source, self-hosted error catcher.

Errbit is API-compatible with Hoptoad. This means you can just configure your Hoptoad notifier to send errors to your Errbit server.

It is a pretty standard Rails 3 app that uses MongoDB+Mongoid for the persistence layer. If you have experience with MongoDB and deploying Rails apps, it shouldn't be too much of a learning curve to get up and running.

Take it for a spin and let us know what you think. In the spirit of open source, feel free to fork it, contribute features, or white label it for a more personalized look that your clients will recognize.

Big thanks to Michael Parenteau for his awesome design work on the UI and of course to Relevance for giving me Fridays to make cool stuff.

Note: After developing Errbit, we discovered that Hoptoad does offer a "Hoptoad behind your firewall" solution. Definitely check it out if you want a fully supported exception notifier that has to sit behind a firewall.

Screenshots

  • Apps Index
  • Setup
  • App Show
  • Errs Index
  • Backtrace

Aug 23 2010

Comments

The Relevant Bits - 08/23/2010 Edition

What have we been doing with our "20%" time the past couple weeks? Read on to find out. It's been a busy couple of weeks in the Clojure and Ruby world for us.

  • The (first clojure-conj) was announced. This event is being organized by Clojure/core and Relevance, Inc. Make sure to sign up if you are interested in attending this fantastic opportunity.
  • Clojure/core released Clojure 1.2. If you've been waiting for the official version to be released, the time is now!
  • Alan has been organizing several successful Triangle Hackerspace meetups. Come on by on a Tuesday night if you are in the Triangle area!
  • Rob released a very early version of Nachos, a tool to help you keep all the git repos you care about in sync. Currently it just handles your GitHub watched repos, but feature requests are requested.
  • Shay organized an awesome DevNation in San Francisco, and even delivered a talk about "Getting to Minimum Viable Product."
  • Chris spent a week hanging out at EngineYard hacking on open source software with Carlhuda.
  • Aaron & Stuart S modularized Clojure contrib. Especially if you are a Clojure lib author, read this message.
  • Jason, Jess & Michael released the Venture Dojo website.
  • Stuart S has continued development on Lazytest, his BDD testing framework for Clojure. It is still in an alpha state, but worth checking out to see where he is going with it.
  • Michael released dribbble_desktop, a project for scraping rss feeds of shots from Dribbble.
  • Chad updated his Vimlander 2 config. In addition to other tweaks, he has brought the best Vim config up to MacVim 7.3 compatibility.
  • Aaron, Jon & Stuart H brought labrepl up to Clojure 1.2 goodness. If you are new to Clojure, this is a great way to learn!
  • Jared released version 0.4.4 of PDFKit. If you need to create PDFs, definitely take a look at this library.
  • Alan created a new project reconfig for Reloading configuration files in Clojure daemons.

Aug 17 2010

Comments

Welcome to more of our new teammates

Relevance is growing fast. A hale and hearty welcome to our four newest full-time teammates:

Stuart Sierra: Stuart Sierra is an actor/singer/writer/coder who lives in New York City, where he is a regular at both LispNYC and the downtown theatre scene. As technical lead of the Program on Law & Technology at Columbia Law School, he developed the groundbreaking legal search engine AltLaw.org. Stuart is the co-author of the book Practical Clojure. He received his M.S. in Computer Science from Columbia University and B.F.A. in Theatre from New York University.

Michael Parenteau: Artist, designer and maker of cool stuff, Michael has devoted most of his life to solving visual problems and exploring creative processes. During his explorations, he has travelled to 49 states leaving a trail of doodles and picking up fantastic stories. When he is not design-thinking or pushing pixels, he may be found with his wife and daughter living in the country... and dreaming of one day visiting Alaska.

Alex Warr: Alex graduated from Duke University with a Bachelors of Science in 2008 after dual-majoring in Psychology and History. He worked for two years as the Arts and Entertainment Managing Editor for The Chronicle, Inc., spent a year in London, UK as a paralegal for Clifford Chance LLP, and first joined the Relevance team as an Office Manager in January, 2010. A strong writer and organizer with a wide breadth of skills, Alex's real value lies in a positive mindset and the ability to enable friends and peers to maximize their potential. He works hard to facilitate both the work hard and play hard aspects of our culture, loves games of wit and skill, and believes the core objective in life is to be in a good mood when it ends.

Jon Distad: Jon has been programming in one form or another for most of his life. After moving from MS-DOS batch scripts to QBASIC and eventually to C++, he decided that there was no reason to know another language and wouldn't even consider using one that didn't compile to native code. Thankfully he was introduced to Scheme and Prolog in college and realized that there were far more interesting ways to write and think about code than he'd ever considered. He eventually learned Ruby and started doing Rails, but his infatuation with LISPs lingered. Now, through Clojure, he can satisfy his academic fascination while also serving a practical end. He is a happy developer. Jon graduated from Ohio Wesleyan University in 2008 with a BA in both Philosophy and Computer Science. He hopes some day to be able to express the former via the latter and feels strongly that functional programming and homoiconic languages will help him get there.

This round of additions solidifies our design competencies, extends our Clojure team even more, and adds some much welcome organizational skill to our growing group. We are truly excited about adding such a great group.

Popular Tags