We are a small team that is about to start developing a localized version of a successful US web app in Korea, using RoR.

Our question is: What process would you recommend we use to go about developing the app?

Should we start with the data models? The views in HTML and then code them? Take a single feature, develop it and then add additional features as necessary?

A few more details about the project:

  1. it is a web app for small business owners
  2. it includes the usual crm-reporting-dashboard-user admin-document mgmtfeatures that most small biz apps tend to have
  3. team size is initially 2 people: a programmer and a designer/CSS guru (just one coder)
  4. experience level is medium. good knowledge of Git, Ruby, Rails and XHTML/CSS, less experienced with deployment issues. this is the first project of its kind that we are doing together as a team

2 Answers 2


I'd recommend the behaviour driven development pattern,

If your not familiar let me give you an overview:

Start at the nuts and bolts the "elevator pitch" of the application..

"What is this thing we're building? What value does it bring?"

And then pick the absolute minimum requirement "feature" and start "specing" it out.. id' recommend using Cucumber: http://cukes.info/ and Rspec: http://rspec.info/ to describe the feature how it must behave.. run the tests/specs and watch them fail..

Then dive in and start implementing the feature and watch the tests pass 1 by 1..

When this feature is done (all the tests pass) repeat the process.. move onto the next minumum requirement "feature" and so on..

As for the workload focus on the feature your building together, the programmer works on the behaviour and the designer works on the look and feel until both work perfectly together..

  • thanks! any recommendation on a good tutorial/book on rspec/cucumber that will not get us bogged down by the details?
    – Kai EV
    May 9, 2011 at 15:46
  • I was looking for the same thing myself not long ago.. Cant go wrong with "the rspec book": pragprog.com/titles/achbd/the-rspec-book I think the important thing about BDD is to make it work for you.. When i got started i spent so much time worrying about how pretty the test suite was i never got any work done.. Also this great screencast from ryan bates was really helpful: railscasts.com/episodes/155-beginning-with-cucumber May 9, 2011 at 15:56

The biggest issue you'll have is managing updates from the main product - you'll need to merge your changes onto it if you want to keep up with their releases. All the other factors are irrelevant IMHO.

So, make sure you take the main product, then make a copy of it to work on. When they release a new version, update your original with theirs and then you can see the changes they've made and merge them onto yours. Refactoring the product is a very big issue - don't do it, as every new file makes things difficult to see where the change from the original occurred. Its also easier if you can keep your changes in separate files.

Otherwise, for developing I'd do it feature by feature, you then have a good way to test it works before moving on to the next feature. Trying to everything all in one go is much more difficult. Keep a test system in place so you can release each feature to it and make sure that it works (ie on a box that is not the developer's)

  • re the dev process - we hear you! seems consitent with Daniel's recommendatio nas well so we will go at it as you propose. however not sure we fully understand the updates management paragraph... are you referering to the post-deployment challenge of adding/changing features? why wouldn't a simple source control system handle these changes?
    – Kai EV
    May 9, 2011 at 15:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.