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,
very interesting. Thank you!!!
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!!
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
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
Redirecting... ← NOT a blog!!!
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
Redirecting... ← NOT a blog!!!
Hope that helps!
DAN
----- Original Message -----
From: “Dan P.” [email protected]
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
Redirecting... ← NOT a blog!!!
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
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)
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.
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!!
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)
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs