How do you estimate the price of a RoR application

Dan Poynor wrote:

Cost - the project to be done for a low cost. Quality - the project to be high quality (full of features or content say).

That's scope, not quality. Quality is how clean, simple, robust, and DRY your code is, and how deep your tests go.

Time - the project needs to be finished quickly.

Help the client define the two most important criteria. If the client picks cost and quality, then time to complete the project will be longer.

That means the client has requested more scope. To get there, do the high-business value things first, deploy continuously, review often, and seek every opportunity to exclude scope.

If the client picks cost and time, then the quality will not be as high (less features).

And that is indistinguishable from your first iteration with the above formula. So if the client wants early deployment, they get a lite website with a few high-value features, but it's useful early. (And thanks to ActiveRecord migrations, Capistrano, gems, and plugins, you don't need to bury yourself in rendundant details.)

If the client picks quality and time then the cost goes up.

How? How do you get more features in less time?

You can't lower quality, because that will make you go slower, and will ruin the "pay as you go" and "just-in-time requirements" formulas.

Think of it as the amount of work needed. A project with a large scope (many features, pretty code, lot's of user testing, etc...) requires more work and could be considered a higher quality product than a project with a smaller scope (fewer features, sloppy code, no use testgin, etc...). It's the same difference.

To make definitions useful, match them to roles in a project. The "onsite customer", or "project manager", or "goal donor" role owns a project's scope. They decide what features to add, how detailed to make each feature, and what level to set their apparent quality.

The developers own the source code quality. It shall be as high as possible at all times. Where I'm coming from on this is experience with a young Rails project which had many of the signs of an old Classical project. Ambitious developers had thrown in a lot of features, and left the quality low in parts.

The difference between this and a Classical project, however, are those pesky unit tests. By increasing the testing, just a little, and by carefully matching the tests' design to the codes' design, we have already turned this code around. New features are now easier to add, because the internal quality is higher.

That's why we need a name for scope, and a different name for "the thing inside the code that makes us faster".

I'm not familiar enough with the pay-as-you-go and JIT requirements to understand how they effect the cost, quality, time formula.

They are what I mean by frequent iterations with high business value in each one. You should develop as if the current iteration is expected to pay for the next one. You want your features to go online, to delight surfers, to cause more revenue, and pay for the next iteration. This is just a mind-game, but it forces you to think of scope in terms of business value.

And if you don't specify your requirements until the iteration where they become features, then you can use the previous iterations to learn the exact details for these features. So your requirements are "just in time". You delayed an important decision until you have facts available to support it.

I have heard that's how Toyota designs cars; I now realize there might be a lot in common between their techniques and ours!