Does Rails Obsolete XP?

Rails
1

At least some of you reading this must have exposure to Agile
philosophies and XP in particular. I’m hoping to get some feedback and
opinions from you based on your experience with Rails.

Here’s the story: I did a quick and dirty internal retrospective for
ThoughtWorks today. I added up numbers on the Rails projects that
we’ve been doing at one of our big corporate clients for the last six
months. Quite innocently I have demonstrable 10-20x productivity gains
over comparable scope projects that we’ve done with lightweight Java
stacks.

There’s that damn 10x to 20x productivity boost figure again!

Anyway, the one project we have the best metrics on started with about
5 people doing earnest XP and story cards. After two weeks the team
shrank down to just me and a couple of part-timers and frankly, I
dropped any pretense of doing XP. It was just “crank out features”
mode until it went into QA and bug fixing mode a few weeks later. The
features were invented on the fly based on my understanding of the
problem to be solved or communicated as direct instructions from
stakeholders. Most of them were implemented in as little as a few
minutes or at most a few hours and then refined with client feedback.
(It’s important to note that during this time I was onsite and had
direct access to my customer.)

Right now on the second phase of that project – two developers and
we’re only onsite 1-2 weeks/month. We have new stakeholders, one
project manager and one product manager. The project manager is
working on a detailed functional spec that we use to guide our
development tasks and the product manager does his own prototyping in
Rails and answers questions if we have them.

You know what? I’m pretty happy working from a detailed functional
spec. Since we measure deliverables in terms of days, not months, the
spec never really has a chance to get out of date. We’re implementing
features out of the spec pretty much as they’re written. Easy-peazy…

This isn’t a small insignificant app we’re working on either, it is
designed to scale to thousands of trading partners across the food
supply chain.

So, do you think I am I “getting real” or am I just “getting spoiled”?

Cheers,
Obie

2

Wow, this is really interesting!

I think you’ve really hit on something here… the notion that changing
the
speed of development and the length of iterations has a profound impact
on
“what is the proper process”.

When you get the development and iteration time down to minutes or
hours,
you probably are better off forging ahead. When a problem with a feature
is
uncovered, the rework time (on this time scale) is probably less than
the
extra time that would have been spent doing the planning upfront.

Its probably worth noting some constraints or assumptions. The only one
that
come immediately to mid is that you are a highly skilled, senior level
developer. Its not clear whether or not this would still be true for an
entry level or junior level developer.

If this analysis is not entirely proprietary, I would love to see you
blog
about it so that I can reference it by URL in my own presentations and
writing.

Curt

3

obiefernandez wrote:

… I
dropped any pretense of doing XP. It was just “crank out features”
mode until it went into QA and bug fixing mode a few weeks later. The
features were invented on the fly based on my understanding of the
problem to be solved or communicated as direct instructions from
stakeholders. Most of them were implemented in as little as a few
minutes or at most a few hours and then refined with client feedback.
(It’s important to note that during this time I was onsite and had
direct access to my customer.)

Right now on the second phase of that project – two developers and
we’re only onsite 1-2 weeks/month. We have new stakeholders, one
project manager and one product manager. The project manager is
working on a detailed functional spec that we use to guide our
development tasks and the product manager does his own prototyping in
Rails and answers questions if we have them.

You know what? I’m pretty happy working from a detailed functional
spec. Since we measure deliverables in terms of days, not months, the
spec never really has a chance to get out of date. We’re implementing
features out of the spec pretty much as they’re written. Easy-peazy…
…
So, do you think I am I “getting real” or am I just “getting spoiled”?

I suspect: both. To its credit, Rails makes it dead simple to crank out
business functionality. With its many DSLs and high-level abstractions,
it moves much of the work of building a web app closer to the realm of
authoring. But Rails can be a real pain to test in any sort of decoupled
way. The developers rejected the idea of incorporating dependency
injection into Rails, preferring to bake dependencies in and allow just
enough flexibility to maintain the fast pace of framework development.
While this approach certainly has merit, it leads to frustration for
those of us trying to use or extend the code in unexpected ways. Such
as, unfortunately, writing true (low-dependency) unit tests:

http://www.artima.com/weblogs/viewpost.jsp?thread=126923

If you can’t decouple your code to test it, it’s harder to test (yes,
even with Rails’s baked-in test support), and you test less.

What I hear in your story is that tests are too hard to bring value to
you as you’re iterating so quickly. I hope someday we can get to where
Rails developers have both easy, dependency-free testing and Rails’
quick development cycle.

So far, I’ve always regretted it whenever I left behind the idea of
using tests to verify specifications. In your situation, I’d push to get
at least high-level automated acceptance/customer tests going.

Ryan

4

So, do you think I am I “getting real” or am I just “getting spoiled”?

Your development methods changed to match the needs of the project.
That sounds like a good definition of Agile to me.

-Steven

5

On Thu, Dec 01, 2005 at 12:38:17PM -0500, Obie F. wrote:

You know what? I’m pretty happy working from a detailed functional
spec. Since we measure deliverables in terms of days, not months, the
spec never really has a chance to get out of date. We’re implementing
features out of the spec pretty much as they’re written. Easy-peazy…

So, do you think I am I “getting real” or am I just “getting spoiled”?

It doesn’t sound to me like you’re obsoleting XP as much as doing
XP[1].
Regular customer feedback, small features delivered on a regular basis,
flexibility and adaptability. It’s all there from what I can see –
even if
your specs are electronic or on paper rather than on 250gsm cardboard.

  • Matt

[1] I don’t think of XP as a strict religion comprised of 12
commandments,
so much as a life philosophy. Perhaps I should call myself an agilist
instead, but I cut my teeth on XP so I still kind-of associate myself
with
it more closely than anything else – like a catholic who never goes to
mass
or prays, but just likes the general feel of the thing.

–
You have a 16-bit quantity, but 5 bits of it are here and 2 bits of it
are
there… and 2 bits of it are back here and 3 bits of it are up there.
The
C code to extract useful data had so many >> and << operators in it that
it
looked like the C++ version of “hello world”. – Matt Roberds, ASR

6

— “Steven R. Baker” [email protected] wrote:

So, do you think I am I “getting real” or am I
just “getting spoiled”?

Your development methods changed to match the needs
of the project.
That sounds like a good definition of Agile to me.

Ruby is a language. Rails is a platform. XP is a
methodology. They are different but related things.
Ruby and Rails make it very easy to write test cases.
Ruby in general is a very agile language. But the idea
that Rails would make XP obsolete is odd. One can do
XP in any language. XP will rise or fall on it’s own
merits.

Shawn

Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs

7

On Dec 1, 2005, at 12:38 PM, Obie F. wrote:

Anyway, the one project we have the best metrics on started with about
5 people doing earnest XP and story cards. After two weeks the team
shrank down to just me and a couple of part-timers and frankly, I
dropped any pretense of doing XP. It was just “crank out features”
mode until it went into QA and bug fixing mode a few weeks later. The
features were invented on the fly based on my understanding of the
problem to be solved or communicated as direct instructions from
stakeholders.
…

Right now on the second phase of that project – two developers and
we’re only onsite 1-2 weeks/month.

I am working on a project with 5 developers, an occasional testing
expert, an on-site customer and full-time database expert. The
organization is ecstatic about our progress, but I still feel like we
are moving at a slow pace compared to what I’ve seen come out of
smaller-sized teams. The folks I am working with are all smart, well-
intentioned, and desire to produce the best thing that they can.

We experienced a moment this week where the customer/analyst, who
sits in the same room 60% of the time, came to us with a few people
problems. Although quite satisfied with what has been produced, they
expressed a concern that we are talking far too much. We don’t
discuss the weather, politics or religion. We think we are trying to
understand the domain to develop the best software we can.
Unfortunately, that seems very expensive. Everyone wants to
understand, so we get into a thrashing sort of mode.

I guess that what I am saying is, there can be too many people on a
project. So called ‘enterprise applications’ have the reputation of
being expensive to build, and it appears to me that they can get over-
staffed. Rails is enabling those who are willing to try it to see the
world in a different light. Once they do, and see the productivity
gains, perhaps they recognize that they can reduce the resources on a
project. Then it starts moving faster, maybe because fewer people
need to understand. I appreciate the learning we are doing, but I
wonder if we aren’t, in fact, talking too much.

Rails obsoleting XP - I can’t imagine that. I don’t know for certain,
cause I’ve yet to receive a paycheck for writing a Rails application.
I do know that my close friends have come to believe that pairing is
not all that we were trained to believe it is. It helped me to learn,
and code can be better, but perhaps a good environment (like Ruby
and Rails) is even better at promoting good behavior than constant
companionship and apparent progress (always learning and never coming
to a quality, shipping product).

The application we are working on uses Sails (www.opensails.org),
which has increased our productivity significantly. Rails heavily
inspires Sails, at least as far as the spirit of Rails can be
implemented in Java. The real problems we face, then, aren’t Ajax,
actions, and good HTML generation tools. The real problems have to do
with the nine databases that make up the data we are accessing as we
build this data-mining tool. I am certain that Rails would not help
us there. I am certain Ruby would, if only because of it’s
succinct, powerful self.

Adam W.