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
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 On 12/1/05, Obie Fernandez <obiefernandez-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > 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 > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Thu, Dec 01, 2005 at 12:38:17PM -0500, Obie Fernandez 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. <grin> - 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. <grin> -- 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
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 -- Posted via http://www.ruby-forum.com/.
> > 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
--- "Steven R. Baker" <srbaker-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org> 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
On Dec 1, 2005, at 12:38 PM, Obie Fernandez 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 Williams