Forum: Ruby on Rails How do you estimate the price of a RoR application

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Pepe S. (Guest)
on 2006-12-30 01:23
Hi all

how do you estimate the price of a RoR application.

Do you calculate the value:
  - counting the days or hours you worked in, and multiply that by a
rate?
  - estimate a price for the whole applicatiion using other criterias?


Pepe
Greg Ray (Guest)
on 2006-12-30 01:40
(Received via mailing list)
Well this is more of a matter of opinion than anything. It really also
depends on what purpose you're trying to evaluate it for. If it's for a
single one time sell to another business you would calculate the worth
of
the application based off the potential income it will bring to that
buyer.
If you're trying to determine the value of an application as far as what
it
would cost to duplicate it - you would base it off a formula of hours *
avg.
industry pay rate * 50% (overhead). You might also base the price on the
current income it's generating * 4 years.
Sergio B. (Guest)
on 2006-12-30 05:52
The method for calculating the price of a ROR app isn't any different
than calculating it for any other web app. In my view, since developing
time is shorter than other frameworks/languages, I can charge more per
hour than say a PHP or .NET application. That's if you choose to charge
based on estimated development time.
Michael J. (Guest)
on 2006-12-31 04:21
(Received via mailing list)
On Dec 29, 2006, at 3:23 PM, Jose P. wrote:

>
> Pepe

Hi Pepe,

The subject is so complicated, I don't think a good answer is
possible without referring you to other sources. (e.g., the book,
"Eric Sink on the Business of Software" is a good one.)

With that said, I've been doing this for a few years.  Here's some
stuff to think about:

* What are your competitors charging?  Adjust your prices to how much
better or worse you are than them.  For example, if you're 50%
better, charge 50% more.  It's not perfect, but it's a reasonable
place to start.

*  Almost everyone equates price with quality.  Cheap = bad.
Expensive = good.  If you undercut your competitors because you
really need the money, your customer is going to second-guess
everything you do and expect you to work weekends and nights.  If
you're expensive, they'll let you work in peace and when you make
suggestions, they'll actually listen to you.

* Some corporations have rules that require them to take a discount
if one is available.  You can use that to your advantage by offering
a discount if they pay in advance.  Most of my bids are paid for in
advance.  (I offer 15% off.)

* Per hour rates are scary for clients.  What's to stop you from
taking your time?  It's like a blank check.

* A flat price is much easier to get accepted.  It's
straightforward.  But it's dangerous for you.  You're going to have
to really protect yourself.  Specify exactly what is going to be done
for that price.  Don't be vague about anything.  Because in the
middle of the project, when they ask for something not in the
original agreement, you're going to have to be firm from the start.
Say something like, "That's a great idea.  But I'm going to have to
run some numbers and get back to you on what it's going to cost."  If
you give them anything free, they'll ask for something else, then
something else, then something else, then the next thing.  And
there's going to be hurt feelings when you finally put your foot
down.  You can avoid all of that by being firm the first time they
ask, then they'll respect you as a professional.

Good luck!

- Michael J.
boboroshi (Guest)
on 2006-12-31 06:07
(Received via mailing list)
Micahel's got a lot of great points.

We tend to do it one of two ways: Lump sum or in phases.

With lump sum, we feel that the requirements are complete enough to
give them a hard bid for the deliverable. We are picky about ANY change
to the scope as clients love to creep the scope. If the client doesn't
know the scope enough, they usually know the basic core. So we say
we're going to do the work in phases with very high level phases
(releases) mapped out. This also gets something released in the
client's hands faster.

They can spend money to a point they're happy with (a few thousand vs
$20k +) and have something to show for it that allows them to get more
funding. We find this to be a big problem in the non-profit world,
where a non-technical person budgets a tech project and the project
manager's hands are tied for that fiscal year.

We have a good working relationship with a non-profit in town so that
they call us and ask us to help them scope a project. We've done about
8 different database driven sites for them in the past few years, one
of which was a massive content site that we bid poorly. Client got a
great deal. But we learned the hard way.

-John
www.boboroshi.com | www.meticulous.com
Pepe S. (Guest)
on 2006-12-31 18:20
Michael, John thank you very much for you advice.

One of the big limitations in our job – developing RoR or other IT
applications- is that requirements are rarely complete. And it is hard
to find customers that are able to specify them clearly. Also new Agile
development techniques, explain that requirements do not need to be
completed before starting a new project, and are part of the iterative
process where requirements, analysis, design and coding loop until the
project is completed, creating releases, milestones and versions.

Do you apply any Agile to estimate the cost of a project?

Do Agile methodologies help you estimate?

Pepe
Antonio E. (Guest)
on 2006-12-31 18:33
Jose P. wrote:

>
> Do you apply any Agile to estimate the cost of a project?

I am not sure what you mean? what is Agile method has to do with
pricing? Seems like you are trying to sell consulting services. Tell
your customer X number of hours needed for Y and then charge the amount.
I prefer to be honest with customers cos that customers keep coming back
for more... Which is far more important then another extra 20%.. If you
are trying to make a one shot delivery and don't want to see your
customer thats another story..

>
> Do Agile methodologies help you estimate?

NO.. Agile is not a life saving method.. its a way of
developing/delivering projects thats all.

> Pepe
Pepe S. (Guest)
on 2006-12-31 18:39
Where can I get any information about the average industry pay rate for
developing RoR applications?

How do you know that when equating price with quality, that you are not
on the Cheap = bad level?


thank you
Pepe
Zaheed Haque (Guest)
on 2006-12-31 18:48
(Received via mailing list)
An example ..

http://www.payscale.com/research/US/Industry=Consu...

Cheers

On 12/31/06, Jose P. <removed_email_address@domain.invalid> wrote:
>
> Where can I get any information about the average industry pay rate for
> developing RoR applications?
>
> How do you know that when equating price with quality, that you are not
> on the Cheap = bad level?

No clue.. something you have to learn by doing ..
Xavier N. (Guest)
on 2006-12-31 20:57
(Received via mailing list)
On Dec 31, 2006, at 5:33 PM, Antonio E. wrote:

>> Do you apply any Agile to estimate the cost of a project?
>
> I am not sure what you mean? what is Agile method has to do with
> pricing? Seems like you are trying to sell consulting services.
> Tell your customer X number of hours needed for Y and then charge
> the amount. I prefer to be honest with customers cos that customers
> keep coming back for more... Which is far more important then
> another extra 20%.. If you are trying to make a one shot delivery
> and don't want to see your customer thats another story..

Problem with agile methodologies is they assume the project takes
shape via short iterations, they are more adaptative. That's the
selling point. Nobody knows in advance enough about the project to be
able to give a price based on features/effort. You have a more or
less vague high-level vision of what they want, and perhaps a time
constraint, and start working from there. Less docs, less formal stuff.

The answer to that is that since the client gets involved and sees
the evolution of the project by first hand, (ideally) they will
reasonably agree about the scope within the price as the project
takes shape.

-- fxn
Tom M. (Guest)
on 2006-12-31 22:41
(Received via mailing list)
On Dec 31, 2006, at 8:39 AM, Jose P. wrote:

> Where can I get any information about the average industry pay rate
> for developing RoR applications?
>
> How do you know that when equating price with quality, that you are
> not on the Cheap = bad level?

There's absolutely zero need to know the average industry pay rate.

The *only* important metric you need to know is how much you can get
for a given job from a given customer.

This information is not easy to come by.

Basically no amount of research will help you determine it, other
than getting in from of potential customers and finding out how much
they're willing to pay you, and how much you can convince them to pay!

This discussion comes up in development forums all the time, and I
always see technical people giving technical answers. These answers
are often detailed, logical, based upon (their) experiences, and are
almost always *dead wrong*.

The question you're asking is *not* a technical question. It's
largely a question of (gasp!) sales and marketing.

Assuming you live and work in a free market economy, the *only*
correct answer to the general question "How much should I charge for
a job?" is the simple and painfully obvious "As much as you can."

My answer will likely get flamed, as it tends to make technical
people very nervous because it makes obvious the *truth* that the
question does not have a technical answer, only a social answer. :-)

If you try to apply a technical answer to this problem, there's a
very high likelihood that you'll either charge too little, or not
work enough, to make ends meet. You'll be continuously befuddled how
other companies that you know, who are far less technically adept
than you are, continuously win the juiciest bids and live in the
nicest neighborhoods. :-)

--
-- Tom M., CTO
-- Engine Y., Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)
Tom M. (Guest)
on 2006-12-31 22:43
(Received via mailing list)
On Dec 31, 2006, at 8:20 AM, Jose P. wrote:

>
> Do you apply any Agile to estimate the cost of a project?
>
> Do Agile methodologies help you estimate?
>

A fully Agile development shop would, almost by definition, charge by
time and materials.

Truly agile development means there's no way to estimate time and
energy in advance.

--
-- Tom M., CTO
-- Engine Y., Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)
Steve R. (Guest)
on 2006-12-31 23:21
(Received via mailing list)
I agree with Tom in large measure. I don't estimate Rails apps any
differently than C++ or whatever. I charge time & materials at a rate I
can
live with (and I don't refer to what anyone else is making). When a
client
wants to know what it's likely to cost, I (at their expense) break out
stories (components of functionality) as well as startup, design,
outside
dependencies, configuration, and deployment. I make some adjustments to
include having good tests. Then I apply the usual arithmetic and attach
the
BIG CAVEAT that depending on the way the project goes, it could be less
or
more but this is a dart at the wall.

Back to what everyone else is making. As a consultant, you may want to
consider this in determining your hourly rate, but I recommend against
it.
Again, if you decide you are worth $x because you're a good developer
and
have experience in lots of problem domains, then if someone balks at it,
that might be business you don't want. How would that potential client
react
to you if you didn't bring the project in on budget? Shopping for a
developer is not like shopping for detergent where the best price wins.
Low
cost solutions can turn into high cost ones very quickly if the wrong
people
are applied to the task.

Just my $.02



Zaheed Haque wrote:
>> Where can I get any information about the average industry pay rate for
>> --
>> Posted via http://www.ruby-forum.com/.
>>
>> >
>>
>
> >
>
>

--
View this message in context:
http://www.nabble.com/-Rails--How-do-you-estimate-...
Sent from the RubyOnRails Users mailing list archive at Nabble.com.
Michael J. (Guest)
on 2007-01-01 00:40
(Received via mailing list)
Hi,

On Dec 31, 2006, at 8:20 AM, Jose P. wrote:

> Michael, John thank you very much for you advice.
>
> One of the big limitations in our job – developing RoR or other IT
> applications- is that requirements are rarely complete. And it is
> hard to find customers that are able to specify them clearly. Also
> new Agile development techniques, explain that requirements do not
> need to be completed before starting a new project, and are part of
> the iterative process where requirements, analysis, design and
> coding loop until the project is completed, creating releases,
> milestones and versions.

(I don't know anything about the Agile methodology.   But I
understand what you're saying.  Not every project you're asked to bid
on has clearly defined requirements [e.g.,  how much would it cost to
make a web 2.0 community website for _____ who are interested in ____?])

These kinds of projects have always been disasters for me.

It makes sense now that I think about it.  I'm a developer.  I make
people happy by selling solutions to problems.  When the customer
can't describe their problem, how am I supposed to solve it?  How
will we both know if I succeed?  What if it's not a real problem, but
a hypothetical one, meant to be sold to hypothetical people, in a
hypothetical market, and the customer doesn't know anyone real who
has experienced the problem, so we can't even ask anyone about it?
That's madness.

Kind regards,

Michael J.
Tom M. (Guest)
on 2007-01-01 02:00
(Received via mailing list)
On Dec 31, 2006, at 2:37 PM, Michael J. wrote:

>> design and  coding loop until the project is completed, creating
> It makes sense now that I think about it.  I'm a developer.  I
> make  people happy by selling solutions to problems.  When the
> customer  can't describe their problem, how am I supposed to solve
> it?  How  will we both know if I succeed?  What if it's not a real
> problem, but  a hypothetical one, meant to be sold to hypothetical
> people, in a  hypothetical market, and the customer doesn't know
> anyone real who  has experienced the problem, so we can't even ask
> anyone about it?   That's madness.

This is what time and materials is all about.

I've recently come to realize that project based billing makes no
sense! It guarantees, even under the best of circumstances and
customer relationships, that you and your customer are at odds from
day one, regardless of how well you perform.

You want to finish the job as soon as possible, which maximizes the
value for you. The customer wants as many features and polish as
possible, which maximizes the value for them.

And if the situation is less than ideal, there're problems as well.

If you're early, the customer will, in a sense, feel cheated. Even
though they decided to pay X amount for Y project, if the hourly/
monthly/yearly income that generates for you seems too high to them,
they're going to feel gouged.

And, if the project goes over time, the customer is pissed because
it's late, and you're pissed because your income is dropping below
expectations.

The *only* way that project based jobs can be entirely successful is if:

1) You estimate the time time and value perfectly
2) That time and value match the customers' expectations
3) Your value matches the customers expectations of your value.
4) You have a perfect plan at the beginning
5) The customer is satisfied when you execute the plan perfectly.
This seems like it would be a truism, but rarely is! Very often, if
you produce what the customer communicated, they *will* end up unhappy.

Now, as previously stated, you must realize that what's right isn't
necessarily what works. :-)

The Rails community would do the web development a larger favor
bringing in time and materials billing, based upon Agile development
practices and the Getting Real business mechanics, and leave fixed
bid billing far, far behind.

I do not expect this will happen, however.

--
-- Tom M., CTO
-- Engine Y., Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)
Pepe S. (Guest)
on 2007-01-02 00:52
Thank you for all these excellent answers. They cover aspects that I
have not though about, before I read them.

I am currently working in a group that is trying to define standards for
IT people that are involved in software development. We already had
several meetings where we decided that the subject must be split in
three different parts
•  Technical standards: such as coding conventions, database naming
conventions, web application templates, and other tools that can
simplify development tasks
•  Software life cycle standards, that cover requirements, analysis,
design, coding, testing, delivery, and maintenance
•  Project life cycle, where aspects of cost, time and quality (scope).

One of the major questions is about how to estimate the cost, duration
of a project, and also when several projects are in a waiting list, how
to define priorities to select one versus the other.

UML, UP and Agile methodologies can help implementing a project, but
stay in my opinion very confusing in the beginning of a Project to
initiate and plan the famous “iron triangle”: cost, time, quality.
Phlip (Guest)
on 2007-01-02 01:20
(Received via mailing list)
Jose P. wrote:

> UML, UP and Agile methodologies can help implementing a project, but stay
> in my opinion very confusing in the beginning of a Project to initiate and
> plan the famous iron triangle: cost, time, quality.

UML is not a methodology, and UP can be used as an Agile methodology.

They are confusing around the project estimation "phase" because they
don't
lie (unlike some methodologies). Instead, they cast light on just how
confusing this topic is. You cannot set a quarterly schedule for 1,000
features, and then hit your ship date. You must estimate in terms of
"horizons", where the near-term features are specified in detail, and
the
long-term ones are just general goals.

Sort features by business priority, do the highest value ones first,
demonstrate them to your goal-donor early and often, and let them
calculate
your velocity and make the predictions. The best estimate is a
measurement.

The iron triangle looks like this:

 - Time
 - Treasure
 - Talent
 - Technique
 - Target

You should only try to vary Target (scope). Your goal-donor's job is to
intercept and censor as many requirements as they can. If you think you
need
a tree-view, they will order you to get by with a simple list box, for
example.

To keep your velocity fast, over time, you must keep your Technique
(quality) as high as possible. In Rails, that means adding tests, in
every
test rig, for every feature, no matter how trivial.

--
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Pepe S. (Guest)
on 2007-01-04 13:02
Phlip,

very interesting. Thank you!!!
Phlip (Guest)
on 2007-01-04 14:56
(Received via mailing list)
Jose P. wrote:

> very interesting. Thank you!!!

Read one of the Lean Software Development books by the Poppendeicks.

--
  Phlip
Chris (Guest)
on 2007-01-04 15:31
Michael J. wrote:
> *  Almost everyone equates price with quality.  Cheap = bad.
> Expensive = good.  If you undercut your competitors because you
> really need the money, your customer is going to second-guess
> everything you do and expect you to work weekends and nights.  If
> you're expensive, they'll let you work in peace and when you make
> suggestions, they'll actually listen to you.

This piece of advice is gold, as it took me a long time to appreciate.

Several times in the past I submitted very low bids to projects I wanted
to ensure winning. I learned the hard way that if you charge too little,
your customers won't respect you.

By charging too little, you are communicating that:

1) You are worth less. Your work's quality is less than your
competitors'. Which can naturally lead to the customer thinking he can
and even must supervise you, with his own IT department or even himself.
Also, think for a second: do you really want to work with someone who
aims for low-quality product for (usually relatively insignificantly)
lower cost? Most serious enterprises would pay a lot more for a quality
product. Usually, paying the developer even the best salary would still
be chump change compared to what they stand to earn off your work
assuming it is good.

2) You are somehow weak, or in difficulties. Or both. Which, amazingly
enough, leads him to be more neglectful of your meagre pay than what he
would have been if you charged more. They do that either because these
sums are so small, they can't possibly be important to you. Or because
they assume you make too little to be able to legally threaten them with
lawsuits, especially over such relatively small sums. Or because they
generally disrespect you. If you are in financial difficulties, and this
project is the only thing that stands between you and the street. Which
leads to the next point -

3) You will put up with abuse. They assume you are less important than a
normal developer; therefore you are not a factor in their
considerations. They won't listen to you, on the contrary: they'll
happily hurl many arbitrary decisions at you, without consulting you.
Specs would change more often, without proper notice. You will be put in
inconvenient situations, and nobody would bother or care to make you
feel better about anything. In particula:

4) Your time is less valuable. In fact, they'll totally disregard the
amount of your time anything takes: your time has become a free,
unlimited resource. I usually throw in an extra 5%-10% uncharged time to
good customers. They usually appreciate it a lot, and it's very much
worth it in the long run; the customer will feel good that you gifted
him with 10-20 hours of your expensive (!) time for free, and next
project would accept a higher bid from you since he enjoyed the
experience. But if your time is very cheap, what's to appreciate?
Moreover, because of 1 and particularly 2, they'll assume you can't cut
off. So you easily end up working 150%-200% or more of the time in the
original bid, for the same bad pay. And the icing: they won't appreciate
it. At all. Hey, your time is virtually free, why would they apprecite
you spending it?

-Chris
seth b. (Guest)
on 2007-01-06 20:18
(Received via mailing list)
> On 1/1/07, Phlip <removed_email_address@domain.invalid> wrote:
> The iron triangle looks like this:
>
> - Time
> - Treasure
> - Talent
> - Technique
> - Target

I thought triangles had 3 sides...that looks more like an iron pentagon
to
me.

--------------------
seth at subimage interactive
-----
http://www.subimage.com
http://sublog.subimage.com
-----
http://www.getcashboard.com
http://dev.subimage.com/projects/substruct
Phlip (Guest)
on 2007-01-06 20:30
(Received via mailing list)
subimage interactive wrote:

>  > - Time
>  > - Treasure
>  > - Talent
>  > - Technique
>  > - Target
>
> I thought triangles had 3 sides...that looks more like an iron pentagon to
> me.

What do I look like? A Pragmatic Programmers author?? Who invents
catchy backronyms all day???

It's the Iron Triangle, and they all start with T. Triangle, T, get
it??!!

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!
Phlip (Guest)
on 2007-01-06 20:31
(Received via mailing list)
Chris wrote:

> This piece of advice is gold, as it took me a long time to appreciate.

I don't know if the following advice is good or bad, but here goes.

Each week, I review the project with my customer, then ask what to
work on the next week. Each thing he says I write on a card. Then I
write acceptance criteria for each item, and (alone without the
customer), I think of an "ideal hours" for each time.

Then I present to the customer a list of features, each with its
line-items and their ideal hour estimates. The customer censors any
line-items he doesn't want.

Then I charge that many hours for that week.

This way, if I get stuck on a bug or an irritating piece of research,
I don't need to worry about charging the customer for my stupidity. I
can take my time, receive interruptions, clean up the garage for no
apparent reason, hang out at the mall with my family, noodle around on
a notebook while watching TV, etc. I don't need to log each danged
minute that I'm making "progress".

Without this "ideal hours" system, we expect such research to average
out over time, but I don't want to wait for that average. I want the
customer to own the feature requirements and their priorities, and I
want him to censor any item that would slow down a delivery.

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!
Dan P. (Guest)
on 2007-01-07 23:09
I thought I'd mention a cost, quality, time formula I like to keep in
mind when creating proposals. It sometimes comes in handy when needing
to explain to clients why rush projects cost more or how they could have
a high quality result at a lower cost. Mostly I base hours needed on the
actuals tracked from past experiences with similar project to create
flat-rate quotes though.

The three variables being:
Cost - the project to be done for a low cost.
Quality - the project to be high quality (full of features or content
say).
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.
If the client picks cost and time, then the quality will not be as high
(less features).
If the client picks quality and time then the cost goes up.
And so on...

For someone working within a company with fixed salaries the only
options would be quality and time. The more man hours spent on projects
the higher the quality of final result typically.

Depends on what the most or least important factors are.

DAN
Phlip (Guest)
on 2007-01-07 23:20
(Received via mailing list)
Dan P. 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.

--
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Dan P. (Guest)
on 2007-01-08 00:55
Phlip wrote:
> Dan P. 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.

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.

>
>> 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.

That's has more to do with project management work flow than pricing. A
larger scope (for example adding more features) usually means the
project will cost more and/ or take longer to complete. The order of
tasks and deployment strategies are consistent enough in my environment
from project to project so I can use the formula and not itemize those
out as a separate issue or price each time.

>
>> 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.)

An early deployment is still a deployment with a date on it and all
features should be useful and have some value. In general keep in mind
that scaling down the number of features for your project should mean
less time is needed and lower the cost. You might price each deployment
by the amount of work needed to develop the necessary features at each
stage if it helps.

A low cost project created in little time usually has less features than
otherwise. If your client spends more, they get more, bottom line.  If
your project has a large scope (no matter what technology or methodology
is used) it will costs more or takes longer to compelete.

The first iteration refered to cost and quality instead of cost and
time. Say the client wants bug proof, acccessible, validated, pretty
printing, highly commented code - that takes a little extra time to do
compared to just hacking something together. The quality vs. time needed
is a fundamental difference that should not be overlooked in pricing.

>
>> If the client picks quality and time then the cost goes up.
>
> How? How do you get more features in less time?

Hire more people is the typical way. If you have more people working on
a project then they can each be working on different features at the
same time (or in more groups of two if you prefer). More eye's looking
for bugs can catch more of them quicker for example.

Another way would be to buy a prebuilt solution that can be modified
rather than building from scratch. It always takes longer and costs more
to create a custom solution compared to buying something that's close
and extending it.

It ultimately depends on your situation, constraints, and creativity.

>
> 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.
>

Higher quality does takes longer to achieve. Creating a lower quality
product should not take longer. If you spend 100 hours on a project and
it's of lower quality, or has less features, than an project you spent 1
hour on, there's something wrong. Lower quality should not be taking
longer.

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

> --
>   Phlip
>   http://www.greencheese.us/ZeekLand <-- NOT a blog!!!


Hope that helps!

DAN
Phlip (Guest)
on 2007-01-08 03:39
(Received via mailing list)
----- Original Message -----
From: "Dan P." <removed_email_address@domain.invalid>

> 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!

--
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Dan P. (Guest)
on 2007-01-08 04:17
Hey Phlip,

Keep in mind the cost, quality, time formula is general business
practice to estimate price. It's not RoR specific. Salt to taste.

Good points about using proper management techniques and talented
contractors to help keep the client happy.

Cheers,
DAN
Tom M. (Guest)
on 2007-01-19 17:30
(Received via mailing list)
On Jan 4, 2007, at 7:37 AM, Phlip wrote:

>
> out over time, but I don't want to wait for that average. I want the
> customer to own the feature requirements and their priorities, and I
> want him to censor any item that would slow down a delivery.

I think this is a bad policy.

A lot of developers think they shouldn't charge for "learning" or
"debugging" time.

Everyone needs to learn or we'd all be writing FORTRAN, and everyone
needs to debug, or TDD wouldn't be important!

It's like a painter not charging you for masking and cleanup.

It's *part* of the job.

--
-- Tom M., CTO
-- Engine Y., Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)
R K (Guest)
on 2007-01-19 17:30
(Received via mailing list)
But if I'm paying for their learning process I want some evidence that
these guys are super-learners (and not the usual crop of lazy,
indifferent,  narrow-minded slobs that I know number out there in the
millions)
Brian H. (Guest)
on 2007-09-26 00:33
(Received via mailing list)
I agree with Tom. Charge for your learning.  If your project needs to do
some AJAX, and you know that RJS will help out but you've not used RJS,
you
need to learn it. You'll learn it by implementing it on their project,
therefore they should be charged accordingly.

If you're good (read: able to learn quickly and adapt) then you won't
burn
too much time learning.  If it makes you feel better, do your learning
at a
lower rate. If you don't think you're able to learn on the fly, then do
something to boost your skills or confidence.

When I hire a developer, I know they don't know everything. I hope they
know
how to find out what they don't know.
Phlip (Guest)
on 2007-09-26 00:43
(Received via mailing list)
R K wrote:

> But if I'm paying for their learning process I want some evidence that
> these guys are super-learners (and not the usual crop of lazy,
> indifferent,  narrow-minded slobs that I know number out there in the
> millions)

Hence I split the difference.

"Why is the chat feature 15 points?"

"Because I gotta research how to send a tiny message over unstable
Ajax pipes in 1/3rd second"

"Just do it within 10 seconds"

"Okay. Three points."

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!
This topic is locked and can not be replied to.