Looking for Agile Software Developer in Central NJ

Are you a software craftsman? Do you value growing your skills as you simultaneously learn from and teach the other members of your team? Want to help us build the world’s best cross-platform mobile solutions for field service workers?

The folks that fix your A/C when it’s 100 degrees and keep your toilet from backing up into your living room deserve the best software technology can provide, and we need your help. We are looking for a key addition to our Agile/Scrum/XP team that is building a highly scalable, event-driven, mobile-enabled platform. This person will be test-driven and team-focused. He or she will be a mentor to team members new to TDD and some of the other XP practices.

Must haves:

  • At least two years of test-driven development experience with the .NET platform (C#) on a collaborative team (Scrum, CI, TDD/BDD, Paired-Programming, Collective Code Ownership, Refactoring, Iterative & Incremental Development)
  • Strong foundation in Object-Oriented Design and Programming (Design Patterns, SOLID principles, etc.)
  • Strong desire to learn and teach others

Highly valued:

  • Domain-Driven Design experience
    SOA and/or SaaS experience (especially with NServiceBus or any ESB)
  • Entity Framework Code-first or other ORM experience (especially with RavenDB, MongoDB, or other document databases)
  • Significant JavaScript experience (especially with Sencha Touch, CoffeeScript, or any JavaScript TDD/BDD framework)
  • Mobility experience (iOS, Android, or Web)

Voted as one of the Top 30 Places to Work in NJ, Marathon develops supports and sells SaaS software and marketing solutions to the SMBs in pest control, landscaping, HVAC and other service verticals. Comprehensive benefits package including vacation, insurance, and company sponsored profit sharing plan. Contact me at efarr@marathondata.com or @efarr.

Split the Team or Split the Backlog?

Small software companies often find themselves trying to do too much with too little. This was certainly the case at Agentek. At one point earlier this year, we had a problem… We were not finished with the current release (call it release A), but we could not wait until it was finished to get a start on our next release (call it release B). There was too much unknown involved in release B. We had to get started on it. At the same time, we had just committed to ourselves that we would not leave our customers with anymore half-finished releases. What to do?

Our team had four fully dedicated developers, a tester, and me. We needed to dedicate 25% of our time to release B. The first option was to simply intersperse the backlog with stories from release A and release B…

Interspersed Backlog

Interspersed Backlog

There were two problems with the interspersed backlog. First, release A has a good bit of reactive work; so, the backlog is unpredictable and tends to consume the entire team’s attention. Second, since stories vary in actual effort to complete, we cannot really gauge or control what percentage of our capacity is applied to each effort.

The next idea, was to split the team and apply 25% of the people to release B….

Split the Team

Split the Team

This is the mathematically cleanest solution and the option that traditional software managers would probably pick every time. However, this option has major disadvantages…

  1. Only one developer will know anything about how release B was implemented.
  2. The many advantages of pairing are lost on both efforts because we have only one developer on release B and an odd number on release A.

This option really just throws the team-based approach to building software out the window; so, not an option for us.

Next thought was to create two separate backlogs….

Split the Backlog

Split the Backlog

This makes the problem we are trying to solve clearer, but we still have the problem of how do we stay united as a team, yet timebox each backlog.

The next step was to designate days of the week for servicing each backlog. To give the forward-looking release one fourth of our capacity, we dedicated one pair to that backlog for half of the week. To simplify things, and give it a little more than 25%, went ahead and gave it three full days instead of two and a half. So this is what things looked like…

Split the Backlog and the Week

Split the Backlog and the Week

We rotated the release B pair so that there would always be one person that worked on that last week for continuity and one new person.

In our first retrospective after we finished release A (and moved onto release B fulltime), the team was convinced of a few things:

  1. One team working on two releases at once is hard.
  2. Keeping the team together was really important.
  3. Splitting the backlogs and the week turned out to be a great way to do both at the same time.

Misconceptions about Team Rooms and Open Floor Plans

I see this far too often. Well-meaning software organizations embracing agile software development tear down the walls in order to open up the space and allow easier collaboration. This sounds great, and it’s cheap. An easy win, right? Not if it’s done without some care and thought.

Premise 1: Irrelevant conversations are distractions.

Human beings are trained to pick other human beings’ voices out of the background noise and pay attention to them. There is little that is more distracting to concentration than hearing a conversation that has nothing to do with what you are working on.

Premise 2: A team is a group of people working toward a common goal.

If a team is really acting as a team, there is nothing that one subset of the team could be working on that is irrelevant to the rest of the team.

Imagine Team Green working in an open team room, paired at stations with one monitor and dual mice and keyboards…

Team Room

Let’s say that pair number 1 is having a conversation…

Team Room One Conversation

That conversation is heard by all other members of the team. Because Team Green is a team, the fact that the whole team can hear it is a good thing. I cannot count how many times I have seen this…

Pair #1 overhears pair #2 getting stuck on some problem that sounds familiar. Pair #1 stops and gets involved in what pair #2 is doing. The four people discuss the problem and solve it, based largely on some previous experience that someone on pair #1 had. If one pair had not overheard the other pair struggling, they might have wasted a whole day (or at least until the next stand-up).

Now imagine Team Green is really busy and all working and talking…

Team Room Communication Saturation

I first heard this situations referred to as communication saturation by Jeff Sutherland, but I think he got it from Jim Coplien. Here we have everyone able to hear every other conversation. If a stranger were to come upon this team area, it would sound like noise. But to a high-performing agile software team, it is completely natural because every conversation is related to furthering the goal for this iteration.

Now imagine we have a collaborative, high-performing Team Blue…

Team Room Blue 

Team Blue is enjoying the same open space benefit that Team Green is. Now imagine we take our open-spaces-are-good momentum and co-locate Team Green and Team Blue…

Noise

Now we have green conversations in the blue team area and green conversations in the blue area. This is not good. We now have noise distracting both teams.

If the blue conversations are as useful to the green team as green conversations, then you are not doing team based development.

There are two possible remedies: create more space between the teams, put up acoustically meaningful walls, or both.

Team Room Noise Fix Walls

The bottom line: open spaces and shared conversations are good only within a team, not between teams.

Pair Programming Resources

Looking for a Good, Free Resource

After introducing the concept of pair programming, I went looking for (free, of course) resources to further explain how it worked and what the benefits are. At first I was surprised at how little I found. Sure, there are chapters in all of the XP books on pairing, but I was looking for something that I could just send a link to in an email. I figured there would be lot of good stuff to choose from.

I think there is not a lot of profound work on the Web explaining what pair programming is because, at it’s core, pair programming is pretty simple. In addition, there is not much written on its costs and benefits because it is a relatively new practice and doesn’t have a whole lot of academic research done on it.

What is Pair Programming?

As is the case with a lot of things, a good starting point for a brief overview of pair programming is to go to the Wikipedia entry. It has a surprisingly good, brief overview of the what and the why of the practice.

The Costs and Benefits of Pairing

Once you’ve got a basic idea of the concept, the next step is to analyze the pros and cons of the practice. For this, I recommend Alistair Cockburn and Laurie Williams’ paper The Costs and Benefits of Pair Programming. This paper appears to be about eight years old, but is still perfectly relevant. This might be the best free, less-than-ten-printed-pages introduction to pair programming.

Installing Pair Programming

My limited personal experience was pretty successful, but there are so many dynamics that come into play when introducing a practice like this into an organization where the concept in entirely new. So, I was still looking for more resources on how to introduce the concept and the practice of pairing. I ordered a copy of Pair Programming Illuminated by Laurie Williams and Robert Kessler. I’m only on the second of twenty-seven chapters, but what I’ve read so far seems to be insightful and helpful. I’ll post more about what I find as I work through it.

Introducing Pair Programming: Trying is Believing

I was a long-time skeptic of pair programming. More than anything I think I was resistant because the prospect of sharing a keyboard with another developer sounded unappealing, even if it worked. Like most developers, I like to tinker with code… try one thing… Google for other people’s solutions to the same problem… tinker some more. How would this work in a pairing situation?

People with more agile software development experience than I had would say two things: 1) it works, and 2) you have to try it to believe it. But for years, I only dabbled in it, never getting past the discomfort of it–sort of like deciding to take up running. You put the shoes on and huff out a mile or two only to feel terrible and put up the shoes for another six months until the guilt wells up again. You don’t make the breakthrough to enjoying it and realizing the benefits until you get better at it and get past the initial discomfort.

It was only after trying it for a sustained period of time at VersionOne that I came to appreciate that both things I was always told. It worked and I had to try it to believe it. The increased focus and benefit of talking through the minor design decisions that get made as we write code more than made up for any productivity loss of having each of us work on different problems at the same time. At VersionOne, we even found, during early feature design stages, we would have three of us, Visual Studio, and a whiteboard. We would design and code as a team. The consensus was that we tended to craft our best solutions and write our best code during those sessions.

Now I find myself in a position of advocating pair programming at Agentek. As you might guess, I’m saying things like “It works, but you’ll have to try it out for yourself to believe it.”