Rails Test Prescriptions Blog

Keeping Your Application Healthy Since 2008

Category Archives: Projects

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.


The Point of it All

In true blog form, a declarative statement:

Hear ye, hear ye! Any so-called Agile team that ever tries to translate “points” into actual units of time is presumed dysfunctional until proven otherwise.

You’ve done it, I’ve done it, we’ve all done it. Doesn’t make it a good idea.

In the spirit of my last post, allow me to over-explain.

A typical Agile project handles estimation by splitting the project up into smallish user stories and assigning each one a point value, typically between one and five, though different teams have different standards. During each iteration, typically on the order of two weeks, you count up how many points you accomplished and that becomes your velocity, or the estimate of how many points you can do in an iteration. Then, that total can be used to estimate how many iterations are left in your project. (I oversimplify, of course, but that’s the idea.)

At first glance it seems ridiculous to try and estimate time without using time units, but in fact the idea is genius. It actually doesn’t matter how accurate you are as long as you are consistent. Always underestimate things by 50%? You’ll do less points in the first iteration than you’d expect, but once you establish a baseline, it doesn’t matter, you’ll still do about the same number of points each iteration. Don’t know whether an estimate includes testing or refactoring? Don’t want to estimate bugs? That’s fine. As long as bug fixing or testing or whatever is a reasonably consistent amount of time from week to week the point method will still work.

You’ve replaced a very hard task — estimating exactly how long every programming job will take — with a much easier and more accurate one — estimating the relative size of some of your programming tasks.

There are only a couple of problems with the point/velocity method. One is that you don’t get good estimates until the project is a few weeks underway. Of course, with a more traditional method you don’t really have a good estimate either, but you do have the illusion of one.

Also, there are at least two classes of people who really, really don’t like point estimates: people who pay you by the hour, and people with Gantt charts.

People who pay by the hour are a legitimate issue — they have a reasonable need to understand what their costs are going to be. Interfacing an agile project with a client can be complicated, but it’s also not the issue I want to write about today.

People with Gantt charts, by which I mean anybody outside the technical team who is unwilling to accept point-based estimates, can be a real menace to an agile team. In my experience, this starts with the innocent-sounding question, “What does a point stand for?”. I maintain that the correct answer to this question is, “I don’t know, but we do ten of them a week” if you are feeling generous, you can add “and we have 75 of them left to do.”

Sometimes that will be enough, either the managerial type will trust that you know what you are doing as long as you hit your deadlines, or the person will do the math themselves and fit it into their own process as needed. For instance, my various managers at Motorola were generally okay with me using points internally to my team as long as I was able to provide them a completion date for an entire release, which was not a problem.

Other places will require an estimate in “real” hours or days for reasons of varying legitimacy. You might get asked to provide estimates for each story in real hours or days rather than points, or somebody might come up with a conversion factor between points and days. The origin of an agile story point is the idea of an “ideal day” of development without distraction, so the thought that a simple conversion between days and points might exist has a certain intuitive appeal.

If you are doing this conversion at the behest of the rest of your team, you have at least two problems right now.

First off, you’ve lost the simplicity of the point estimating task, and you’re back to the complexity of absolute estimating. I know it doesn’t seem that way, and I suppose in theory it’s possible to use hours in a point-style estimate. In my experience, though, when external forces want hours, they want exact hour estimates for each task.

The value of points is that there are a lot of implicit assumptions about consistency: time spent on bugs, time spent on non-developer tasks. That works in the points world because it’s relatively abstract. But talking about estimates in hours places a powerful expectation that you need to separate that time back out into each individual task. So even though hours and points seem similar, in fact, it’s very difficult to actually work with them similarly.

Secondly, if you work in points and then translate that to days, you now have two reasonably similar sets of estimates floating around. Confusion is inevitable. Motorola used to distinguish between “unloaded” and “loaded” estimates, where an unloaded estimate was ideal developer time and loaded estimates made the somewhat optimistic assumption that 1/3 of a developers time would be spent on non-developer tasks. What happened? We were forever asking each other whether an estimate was loaded or unloaded, and forever forgetting which it was. I’m pretty sure that some estimates were converted to loaded multiple times.

All this is indicative of the larger problem that you probably have if you have been asked to start converting points to hours. Ideally, in an agile project, it’s the technology team’s responsibility to say how much a feature costs, and the business team’s responsibility to say how valuable the feature is. The combination of the two factors is what makes up the agile project plan. You don’t want the business team determining the estimates any more than you want the technology team determining business value.

If the business team is driving the format and structure of the estimate then it’s the project equivalent of a code smell. It’s not impossible that your project could still be running smoothly, but it is strongly suggestive that the business side is looking to own the cost side of the equation. In which case you potentially have a very large problem, the most likely manifestation of which is strong pressure to claim lower estimates to provide the illusion of being on schedule.

Which brings us, at long last, back to the beginning. An agile project that is converting points into real units of time is potentially dysfunctional because it’s a sign that a) the advantages of the points/velocity system aren’t being fully utilized or b) the business team is having too much influence on the creation of estimates, or possibly worse. It’s possible that things are still okay, but the presumption is that this estimation style does not encourage good agile practice.