Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 17:59:00 GMT)

The Rails birthday party isn't over!

Posted by Tue, 08 Aug 2006 22:47:00 GMT

Ruby on Rails is two years old now and we’ve been hosting Rails applications for over a year and a half now!

To mark this occasion, if you sign up with one of our Shared Rails Hosting plans by Friday, August 11th, we’ll give you an extra month of hosting for free!

Our hosting plans start as low as $11.25/month!

If you’re looking for a great place to deploy your Rails application with some of the cutting edge deployment options (mongrel, pound, lighttpd, capistrano, etc…) take a look at the PLANET ARGON Documentation Project to learn more.

When signing up for your new account, use the following coupon code: RAILS.IS.2.YEARS.OLD!

To learn more about our hosting options, visit http://www.planetargon.com/hosting.html or visit us in our chat room.

d3 not DDD

Posted by Tue, 08 Aug 2006 17:15:00 GMT

6 comments Latest by MSM Thu, 10 Aug 2006 01:40:48 GMT

First, a quick update from our sponsors…

Brian and I talked yesterday and agreed to stop referring to Dialogue-Driven Development as DDD. We’ll leave that for the Domain-Driven Design fans. From now one, the short version for Dialogue-Driven Development will be d3.

MSM posted an email in regards to d3 on a Scrum development mailing list. He writes, “While I believe there’s room for plenty of Agile methodologies in the world and wouldn’t want to discourage the development of DDD if it helps them get their software written, I would hate to see Scrum described inaccurately, especially in a well-oiled meme propagation machine like the Rails community.” (link)

Michael D. Ivey responded with, “That being said…as someone who has gotten 100% into Rails development, I find myself using Scrum less. At least, on the surface, official Scrum. Rails makes meW^WWlets me be so productive that we are basically having 1 day sprints.

What’s interesting here is that we have a someone who is working with Ruby on Rails and finds himself using Scrum less because the environment is much different. This is exactly why Brian and I started seeking out something even more lightweight. We’re not aiming to replace other methodologies, but to structure our own that focuses on dialogue. With Rails, we’re finding that the amount of collaboration and dialogue with clients has both increased and improved tremendously.

Ivey also goes on to say, “I believe, having done Scrum well, and having done the ””Rails experience,”” that what Robby and …. the other guy …. are describing with ””Dialogue Driven Development”” is exactly what happens when you start with Scrum or something Scrummy, add a hyper-productive programming language and framework, mixin a very active and interactive customer, and then just start running at a comfortable pace and see when you get somewhere cool.

Perhaps Michael is right… and of course, this is open for discussion. :-)

Brian and I are spending a good deal of time thinking and talking about this stuff. We want to outline a new pattern that changes how requirements are gathered and documented through dialogue. It’s apparent that as we read different peoples comments on our articles that the general consensus is to interpret the Product Backlog pattern described in the books on Scrum in a way that works best for your team. The approach outlined in Agile Software Development with Scrum doesn’t work for us.

What’s your pattern? Share your story…

Request: Personal Finances for OSX

Posted by Tue, 08 Aug 2006 01:49:00 GMT

19 comments Latest by Jared Burns Tue, 22 Aug 2006 17:12:19 GMT

I’m looking to purchase a program for managing personal finances that runs on OSX.

Any suggestions?

Extreme Motivational Posters

Posted by Mon, 07 Aug 2006 16:55:00 GMT

Take a look at these extreme programming motivational posters.

Found via Think Box.

Clients Deserve Simplicity

Posted by Mon, 07 Aug 2006 03:57:00 GMT

1 comment Latest by Sammy Mon, 07 Aug 2006 11:41:08 GMT

A few months ago, I posted an article titled, Trawling for Requirements, which was just before the Argon Express left for our trip to Chicago for RailsConf 2006. I’ve been kicking around some ideas with Brian ever since that afternoon on how there just seemed to be a big void in software development arena. It’s always felt that so many of the software development methodologies are designed to get developers to find a better way to work for and with clients. It’s our goal to outline a pattern that simplifies this process, not just for ourselves, but also our clients.

With each new project that our team starts, we are given an opportunity to improve on our evolving pattern for communicating with clients to better understand their goals. If there is one thing that we’ve seen help this process, it is consistent dialogue. When good collaboration exists through meaningful dialogue, confidence increases in not only the client. As developers, we are able to be confident that we understand their goals. This should generate better results.

“You are not writing requirements to serve as a contract with your client. Rather, you are writing them to ensure that both of you share the same and demonstrably correct, understanding of what is needed. Do not ask the client to sign off on the requirements; instead, ask the client to sign on to them and make them a collaborative effort.”

—Suzanne and James Robertson, Mastering the Requirements Process, 2nd Ed.

In Mastering the Requirements Process, the authors list the following as being key to identifying the project goal.

  • Purpose: What should the project do?
  • Advantage: What business advantage does it provide?
  • Measurement: How do you measure the advantage?
  • Reasonable: Given what you understand about the constraints, is it possible for the product to achieve the business advantage?
  • Feasible: Given what you have learned from the blastoff, is it possible to build a product to achieve the measure?
  • Achievable: Does the organization have (or can it acquire) the skills to build the product and operate it once built?

At first glance, I would agree that these are good questions to find answers for with your client.

Requirements, Not Solutions

Many clients come to us with a list of solutions (features) that describe implementation. This has been one of our concerns with the Product Backlog as it doesn’t discourage feature lists. Take a moment to read Goal Oriented Requirements, which gives you a few bullets to think about when interacting with your client when extracting requirements.

Take a moment to read Brian’s thoughts on the product backlog.

In Mastering the Requirements Process, the authors give two examples to show the difference between a solution and a requirement.

A Solution

The product shall display pictures of goods for the customer to click on.

A Requirement

The product shall enable the customer to select the goods he wishes to order.

When requirements are defined in this form, it allows for further dialogue about multiple implementations.

For example, we’re working on a project where the product shall enable the users to send messages to a central system. We’ve defined a few specific implementations (email, text message, web form) and know that as new technologies emerge, the same requirement will still apply. It’s important to remember that we are gathering requirements not solutions and from there… we can collaborate with the client to design a solution that fits the requirements. Before we attempt to do solve the problem, we must ask that the requirement is aligned with the project goal.

We want our clients to assimilate our development methodologies quickly and naturally, which is what Dialogue-Driven Development aims to help achieve—namely through communication, something we humans do rather well. By lowering the learning curve and accelerating the integration of clients into our process, we can focus a greater sum of our collective energy on the needs of the client, the purpose of the project, and the goals of it’s users.

Although, perhaps we have it all wrong when trying to make software and the development process simpler as Paul Kedrosky suggested. ;-)

Our clients don’t just want simplicity. They deserve it!

Happy Birthday Rails!

Posted by Mon, 07 Aug 2006 00:37:00 GMT

The Ruby on Rails framework is now two years old!

“We’re past the point of infatuation, this is love, and love is inclusive. Happy birthday Rails, happy birthday Railers.”

—David Heinemeier Hansson

Read David’s blog entry about it.

Older posts: 1 2 3 4 5