Noel Rappin Writes Here

As you may have heard, Obtiva got bought by Groupon. I’ve been traveling a bunch, so this coming week is my first full week in the Groupon office post-transition. And, well, someday maybe I’ll write retrospectively about Obtiva, but today isn’t that day. I’ll probably write about what I’m going to be doing at Groupon, but today isn’t that day, either.

Instead, I realized that month marks four years since I left Motorola and became a Rails consultant. In that time, I worked, for some definition of worked, on over a dozen projects and probably watched at least another dozen from down the hall.

I must have learned something, right?

I finished out this post, so I guess that means that yes, I do think I learned something. Here are a dozen or so oversimplified, fortune cookie-esque things that I think I learned in the last four years. Some of these are probably blog posts in their own right, which I may get to one of these days.

• It’s a hallmark of successful engineering teams that they understand that if you do not need to make a decision, then you need to not make a decision. That’s sometimes called “preserving ambiguity”, and I remember from back in my days studying engineering education that it’s a hallmark of successful engineering teams across disciplines.

• One reason why preserving ambiguity is necessary is that if you get too concrete too soon, then early decisions have a kind of gravity that makes it hard to escape them even when it’s best to explore the problem space more fully. A couple of times in the last four years, clients have come in with polished visual designs, and even if the layout and structure doesn’t work at all from a functionality or usability standpoint, it’s hard to escape the concreteness of the design to find a better design or a better definition of the project.

• There’s very little that damages a team dynamic more quickly than trying to measure and compare individual contributions. (Technically, I learned this one at Motorola, but it still applies…) On a larger project, measuring subteam contributions also qualifies as problematic.

• One thing you absolutely must have when coming out of your initial project meetings is a list of things that are not part of your project. Again, a common client pattern was trying to be the “YouTube of X” and the “Facebook of X” and the “Twitter of x”. Pick something to do well and do it well.

• You can’t escape the software triangle, of scope, budget, and schedule. Keeping a project on track means saying “this is out of scope”, or “okay, we can do this, but that means something else needs to move out of scope”.

• Hiring is so, so important. I once heard it said that the secret weakness of Agile was that one sociopath could ruin an entire project. That doesn’t mean “just hire your friends”, but it does mean that being able to work as part of a team is important.

• If the business/management team and the development team trust each other, than almost any process works. If they don’t, almost nothing can fix it. One advantage of Agile methods is they provide a lot of quick, easy, and early opportunities for each side to show trustworthiness. (There’s definitely a longer post in this one…)

• Because, ultimately, for a lot of our clients, working with developers is like going to the mechanic. When the mechanics say that the fitzelgurbber has been gazorgenplatzed, and it’s 500 bucks, do you trust them? Why or why not? How do you apply that back to your day job?

• The development team’s job in an Agile project is to honestly estimate the cost of things, it’s the business team’s job to honestly estimate the value. Don’t cross those streams. It’s bad.

• Agile is about managing change, not continuous change. If anybody on your project tries to justify a change with something like “we’re agile, we can change anything whenever we want”, run for the hills.

• I didn’t say this, but I remember hearing it a few years ago. The right amount of process is just a little bit less process than you need. In other words, the slight chaos from too little process is much preferable to the overhead of too much process.

• Look, I’ll admit that those of us that identify as software craftsmen sometimes get overly precious with our naming conventions and of course delivering business value is the number one priority. That said, if you are on a project and are being told to do less than your best work for the good of the project (by not testing, or by incurring too much technical debt), that should at the very least be alarming.

• Pair programming has more overhead than is often acknowledged in Agile literature. I find that, especially on a small team, keeping a pair in sync time-wise is very hard. That said, I don’t have a better solution for code review yet.

Can’t wait to see what I learn this year. A lot of new stuff for me, should be interesting.