Rails Test Prescriptions Blog

Keeping Your Application Healthy Since 2008

What I Learned

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.

Advertisements

9 responses to “What I Learned

  1. Kevin Taylor (@ktaylor) September 6, 2011 at 9:31 am

    Why do I suspect a new book in the making? 🙂

  2. Eric September 6, 2011 at 9:40 am

    “I once heard it said that the secret weakness of Agile was that one sociopath could ruin an entire project.”

    Worth noting – that’s unfortunately true of most ‘methodologies’.

  3. manohar September 6, 2011 at 10:58 am

    Agile is about managing change, not continuous change. – Liked it, Every client should understand it.

  4. yachris September 6, 2011 at 5:32 pm

    “That said, I don’t have a better solution for code review yet.” Nor do I 🙂 but we’ve found something that works really good on the project I’m now on. Whenever someone finishes something, they send the CR to someone else marked to review. That person does so (ideally a good bit before the end of the iteration, of course!) and adds comments to the CR, and sends it back.

    It’s the standard pareto principle — 20% of the work of a full sit-down-with-the-whole-team review, 80% of the bugs found.

  5. gspederson September 6, 2011 at 8:19 pm

    Hey, I also left Motorola and (eventually) became a rails consultant.

  6. Diebels September 7, 2011 at 7:26 am

    On one of my agile projects, we also found that the cost of pair programming is pretty high.

    We’ve adapted to having informal code reviews. This has a pretty high overhead as well, but it seems to be more efficient for us.

    We’re currently looking in to using Gitorious to eliminate these public code reviews in favor of ‘merge requests’, which are then reviewed in a more asynchronous fashion.

  7. Joel Parker Henderson September 10, 2011 at 12:48 am

    Gerrit is a better way to do code review. It’s distributed, works well with git, and has full support from tools like Assembla.

  8. gandralf September 12, 2011 at 10:47 am

    Good points. What I can add is that, from my experience, I tend to value context.

    For instance, “ preserving ambiguity” is my favorite. I love and apply it often. But, as you said, some clients can come with a lot of pre-defined stuff. And some of them can get pretty nervous if you talk about changes on that stuff, because “it wasn’t our agreement”. How can I agree, disagree or define something that I am just not prepared to define right now?

    So, it’s application can be extremely limited. And get even worst when the client bough the “agile” mambo-jambo: be adaptive and flexible, but follow the “agreement”. And it’s not Zen, at all.

    About compare individual contributions. Quite often, it has to be done: to help, fire or reward. A team can be too forgiven to nice but bad members, or too lazy to an expert member. So, something like “show me the code” or directly responsible individual can be used.

    “this is out of scope”: I rather “manage scope” in a high level view point of view: objectives based, not story based. But again, context speaks louder. Usually clients are checklist oriented, and stories are good checklists items. So, quite often I roll back to story-based scope.

    “Don’t cross those streams. It’s bad.” Again, it sounds nice (and quite often is), but context is the king. I’ve seen market guys asking nonsense (they were the “client”) and techies (the team) kicking its ass with much better definitions, for the sake of client’s boss (the company). I’ve seen teams ignoring damn good tech advises from a business man (who was a better technician than they all, but they just can’t admit).

    “Agile is about managing change, not continuous change.’ Perfect. Look at this: http://www.slideshare.net/xinu/agile-or-fragile/11

    “The right amount of process is just a little bit less process than you need”. Perfect but, in some contexts (again!), just take care: it can easily produce fear and resistance.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: