Searching \ for '[OT]: Hiring a PIC consultant/developer' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Hiring a PIC consultant/developer'.

Exact match. Not showing close matches.
PICList Thread
'[OT]: Hiring a PIC consultant/developer'
2005\04\19@010834 by Vitaliy

flavicon
face
Hello List,

Our company is looking to hire a consultant to help us develop a product.
Since we've never done this sort of thing before, I am looking for advice
from both consultants and people who have experience working with
consultants.  I believe the responses I get would be very beneficial to many
list members.

At this point, I would like to get a feel for what the consultants want, and
what we should expect from them.  In other words, describe your ideal (but
practical) work arrangement.

Thank you in advance for your time and help in this matter.

Best regards,

Vitaliy

2005\04\19@015157 by Mike Singer

picon face
A bit more info about your company, ok?

On 4/19/05, Vitaliy <spam_OUTvitaliyTakeThisOuTspammaksimov.org> wrote:
> Hello List,
>
> Our company is looking to hire a consultant to help us develop a product.
> Since we've never done this sort of thing before, I am looking for advice
> from both consultants and people who have experience working with
> consultants.  I believe the responses I get would be very beneficial to many
> list members.
>
> At this point, I would like to get a feel for what the consultants want, and
> what we should expect from them.  In other words, describe your ideal (but
> practical) work arrangement.
>
> Thank you in advance for your time and help in this matter.
>
> Best regards,
>
> Vitaliy
>
> -

2005\04\19@020024 by Wouter van Ooijen

face picon face
> At this point, I would like to get a feel for what the
> consultants want

Do you want to hire someone on an hourly rate? In that case the
consultant would want just that: his hourly rate and maybe some
interesting work during those hours.

If you want a job done on a fixed-price basis you will have to make
clear upfront what has to be done, down to the level where the
consultant can determine a price. This will most likely be much more
detailed than you expect. And when you change your specs during the run
don't be surprises when the bill expands.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2005\04\19@024900 by Andrew Warren

face
flavicon
face
Vitaliy <.....piclistKILLspamspam@spam@mit.edu> wrote:

> I am looking for advice from both consultants and people who have
> experience working with consultants. .... I would like to get a feel
> for what the consultants want, and what we should expect from them.
> In other words, describe your ideal (but practical) work arrangement.

Vitaliy:

I was a consultant in what now seems like a past life.  From my
clients, I expected:

   1.  A clear specification of the product.  The best possible
   specification would be a complete User's Manual, since that document
   completely describes what the thing does, but DOESN'T dictate how
   it's implemented.

   2.  A schedule.

   3.  Reasonable access to their people, facilities, equipment, etc.,
   if necessary.

   4.  Prompt, no-hassle payment of my invoices.

In return, they received:

   1.  Regular status reports, either emailed, over the phone, or at
   brief weekly meetings.

   2.  Regular invoices so they were never surprised by an unexpectedly
   large bill.

   3.  A couple of programmed PICs (or whatever), source code (usually),
   schematics/layout/Gerbers/whatever if hardware was involved, and an
   irrevocable license (usually exclusive) to use all of it in any way
   they liked.

   4.  Reasonable access to me afterward for advice, training, etc.

   5.  The assurance that any proprietary information they'd shared
   with me would remain confidential.

   5.  Free bug-fixes forever (although I don't know any other
   consultants who offered that deal).

What they didn't receive:

   1.  My home telephone number, or unlimited free conversation time on
   my office phone.

   2.  A free spec-writing service.  If they were unable to provide a
   spec, I'd write one... But I'd charge the same hourly rate for that
   as for the rest of the development.

   3.  The right to dictate the specific hours or place that I'd work
   on their projects.

   4.  No-charge changes to the scope of the work.  Lack of a clear
   vision of the product in advance of its development is YOUR problem,
   not your consultant's.  If you discover that you don't like the thing
   that you defined and he built, he gets paid to do it over.  It's
   easiest to do this if he's working at an hourly rate; if he's being
   paid a flat fee, he might not accept any changes to the spec without
   a formal renegotiation of your contract.

-Andy

=== Andrew Warren - fastfwdspamKILLspamix.netcom.com

2005\04\19@035257 by Alan B. Pearce

face picon face
> I am looking for advice from both consultants and people who have
> experience working with consultants. .... I would like to get a feel
> for what the consultants want, and what we should expect from them.
> In other words, describe your ideal (but practical) work arrangement.

This seems to be coming around quite often now, from both sides of the
fence. Check in the PIC archives, probably using "consult" or "consult*" (or
whatever the wildcard char is) and see what you get.

2005\04\19@071623 by John J. McDonough

flavicon
face
Vitaliy:

Much of what Andrew says is good stuff, and more than that, most of what he
says is required in the United States to be able to call the consultant a
"contractor" as opposed to an "employee".  In the US, the employee thing is
very burdensome and lots of companies would like to hire employees on a
contractor basis.  Whether this is your intention or not, it is important to
keep clean in this regard so as not to get a nasty visit from the IRS.
Obviously, in other jurisdictions the rules will be different, but probably
similar.

There is a pretty huge difference between small, often one man band, sorts
of consultants and large houses.  The large houses have refined the art of
selling hours and really have no interest in solving your problem.  Smaller
guys often are interested in the project, and recognize that one unhappy
customer can really spoil their business.  Still, some of the smaller guys
have learned a few tricks from the large shops, so watch out.  I strongly
recommend that anyone considering a consultant read "Consulting Demons"  by
Lewis Pinault.  Forewarned is forearmed.

I have a pad of post-it's on my desk that says "Consulting: If you're not
part of the solution, there's good money to be made in prolonging the
problem".

Something else that I think needs a little emphasis.  You want to describe
what you need very precisely, but avoid describing things you don't need.
Andrew mentioned what and not how, but it is often hard to tell the
difference.  Even among the what, if you don't describe characteristics that
you don't care about, the consultant has more flexibility in the design.
Often, characteristics that may be unimportant to you can have a huge impact
on the cost of something.  If you don't care, then make that clear so that
the design is not unnecessarily complicated.  On the other hand, anything
not said are decisions that need to be made, and decisions take time and
cost money, so it is a fine balancing act.

--McD


2005\04\19@094154 by Dave VanHorn

flavicon
face
At 12:08 AM 4/19/2005, Vitaliy wrote:
>Hello List,
>
>Our company is looking to hire a consultant to help us develop a product.
>Since we've never done this sort of thing before, I am looking for advice
>from both consultants and people who have experience working with
>consultants.  I believe the responses I get would be very beneficial to many
>list members.
>
>At this point, I would like to get a feel for what the consultants want, and
>what we should expect from them.  In other words, describe your ideal (but
>practical) work arrangement.


A clearly defined task.
A sane amount of time to do it in.
Paid on time
Check don't bounce :)



2005\04\19@165940 by Peter

picon face

On Tue, 19 Apr 2005, Dave VanHorn wrote:

> At 12:08 AM 4/19/2005, Vitaliy wrote:
>> Hello List,
>>
>> Our company is looking to hire a consultant to help us develop a product.
>> Since we've never done this sort of thing before, I am looking for advice
>> from both consultants and people who have experience working with
>> consultants.  I believe the responses I get would be very beneficial to
>> many
>> list members.
>>
>> At this point, I would like to get a feel for what the consultants want,
>> and
>> what we should expect from them.  In other words, describe your ideal (but
>> practical) work arrangement.
>
> A clearly defined task.
> A sane amount of time to do it in.
> Paid on time
> Check don't bounce :)

Pick any three.

Peter

2005\04\19@191604 by Vitaliy

flavicon
face
Hello Everyone,

Mike Singer wrote:
>A bit more info about your company, ok?

The e-mail was not a solicitation (yet), although I guess it appeared to be
since we received a couple of offers already.

When I was writing my original post, I started out by describing the project
in detail and listing the questions I had.  However, when I re-read the
e-mail I decided that it would be better to start out with a very open-ended
question in order not to limit the responses.  I think it worked very well,
so I will begin asking the specific questions now.  :)

Dave VanHorn wrote:
> A clearly defined task.
> A sane amount of time to do it in.
> Paid on time
> Check don't bounce :)

I agree with all of Dave's points, and I am confident we can satisfy all
four requirements.

Andrew Warren's response was the most useful and comprehensive so far (thank
you Andrew):

>    1.  A clear specification of the product.  The best possible
>    specification would be a complete User's Manual, since that document
>    completely describes what the thing does, but DOESN'T dictate how
>    it's implemented.

This is a great idea.  It sounds obvious now, but we were thinking more in
terms of functional specs (not quite the same) rather than a complete Users
Manual.

>    2.  A schedule.

This is something we should discuss with the developer, right?  Do
consultants normally charge the client for analyzing the requirements and
coming up with the deadline?

>    3.  Reasonable access to their people, facilities, equipment, etc.,
>    if necessary.

No problem.

>    4.  Prompt, no-hassle payment of my invoices.

No problem here, either.

>    1.  Regular status reports, either emailed, over the phone, or at
>    brief weekly meetings.

This is one of my areas of concern.  We've outsourced some projects before,
and from my experience communication is the greatest challenge, and the
major bottleneck.  Therefore, we would like to be able to give and receive
feedback in real-time.  Therefore, the ideal candidate would have to be a
local resident.  What are your thoughts on this?

>    2.  Regular invoices so they were never surprised by an unexpectedly
>    large bill.

How often would you bill for a project that is, say, 3 months long?  Would
it be periodic (every 2 weeks), or based on the milestones of the project?

>    3.  A couple of programmed PICs (or whatever), source code (usually),
>    schematics/layout/Gerbers/whatever if hardware was involved, and an
>    irrevocable license (usually exclusive) to use all of it in any way
>    they liked.

We would require all of the above, since we must have the ability to modify
the design later.

>    4.  Reasonable access to me afterward for advice, training, etc.

How would this be worded in a contract?

[snip]
>    1.  My home telephone number, or unlimited free conversation time on
>    my office phone.

Do consultants normally work on several projects at the same time?  I would
expect the developer to be 100% dedicated to our project, from the beginning
to completion.

[snip]
>    3.  The right to dictate the specific hours or place that I'd work
>    on their projects.

What if we were to ask you to work on our premises?  The motivation here is
the same as for #1 above - we would like to be able to give and receive
feedback in real time.  The hours are flexible (we have two overlapping
shifts).

Gentlemen, I truly appreciate your advice, thank you for your time and look
forward to your responses.

Wouter's e-mail is next.  :)

Vitaliy

2005\04\19@192838 by Vitaliy

flavicon
face
> Do you want to hire someone on an hourly rate? In that case the
> consultant would want just that: his hourly rate and maybe some
> interesting work during those hours.

So you're saying consultants prefer to work on an hourly basis?  What would
he/she say if we asked them to analyze the project and come up with a fixed
dollar amount?  My concern is that if the consultant is not working on our
premises 100% of the time, we cannot verify the actual number of hours
worked.

> If you want a job done on a fixed-price basis you will have to make
> clear upfront what has to be done, down to the level where the
> consultant can determine a price. This will most likely be much more
> detailed than you expect. And when you change your specs during the run
> don't be surprises when the bill expands.

If we were to write a complete Users Manual like Andrew Warren suggested,
would that be detailed enough, in your opinion?  What would be the best
contingency plan in case the specs have to be changed sometime during the
development process?

Best regards,

Vitaliy

2005\04\19@195104 by Dave VanHorn

flavicon
face
At 06:28 PM 4/19/2005, Vitaliy wrote:
>>Do you want to hire someone on an hourly rate? In that case the
>>consultant would want just that: his hourly rate and maybe some
>>interesting work during those hours.
>
>So you're saying consultants prefer to work on an hourly
>basis?  What would he/she say if we asked them to analyze the
>project and come up with a fixed dollar amount?  My concern is that
>if the consultant is not working on our premises 100% of the time,
>we cannot verify the actual number of hours worked.

It's always a trade-off.
If the spec is complete, then it's a lot less risky to bid the job.
But, it takes time to write the spec, and a lot of companies don't
want to do that.
Also, it depends on how risky the development work is.


2005\04\19@201435 by Mauricio Jancic

flavicon
face
Hi,

>>This is a great idea.  It sounds obvious now, but we were thinking more in
terms of functional specs (not quite >>the same) rather than a complete
Users Manual.

       I think the user manual is much better because it will describe
exactly what you need the device to do. This is specially good for complete
project, rather than for a part of a much bigger project.
       Why? Well, you might want to specify that the device must measure a
given parameter at a given rate, just because you think it would be correct,
but that will limit the "space" that one would have to work. It would be
much better to specify the parameter to measure and to point out the
response that the system should have when using that specific parameter.

>> Do consultants normally charge the client for analyzing the requirements
and coming up with the deadline?
       
       I usually don't, but I think that if the analysis has a long
investigation period you might be charged, and perhaps part of that amount
of money can be taken as a part of the total payment for the job, I think...
I never actually did such thing.


>>>    1.  Regular status reports, either emailed, over the phone, or at
>>>    brief weekly meetings.

>>This is one of my areas of concern.  We've outsourced some projects
before, and from my experience communication >>is the greatest challenge,
and the major bottleneck.  Therefore, we would like to be able to give and
receive
>>feedback in real-time.  Therefore, the ideal candidate would have to be a
local resident.  What are your
>>thoughts on this?

       I have worked overseas with no problem in the past. I think it's not
so good for a consultant (guys you can correct me if I'm wrong at this) to
work all the time side by side with the customer. I prefer much more to have
regular meetings and organize my time to meet the milestones. Why? Well, me,
and the people I know in the business, usually work 9~10 hrs/day and
sometimes you just need to take a brake, live the desk, the computer, and
everything else. Then, you came back to the work with and open mind and make
things happen. IF I'm with the customer he will start to comply that I don't
work as he would like or that I work in strange hours, etc, etc etc. PLUS I
will have (might) to explain the customer what I'm doing, why I'm doing my
code this or that way and stuff like that. I think it doesn't really help
most of the times. However I must admit that I have enjoyed working and
helping brilliant guys a couple of times and even that they where hiring me
I learned a lot from them in the time.

>> How often would you bill for a project that is, say, 3 months long?
Would it be periodic (every 2 weeks), or
>> based on the milestones of the project?
       
       What I do is to say: "this is the total amount of money for the
project. You'll have to pay it in 3 or 4 times at these dates. You'll also
receive "this" on that dates (plus the inter-payment presentations)

>>    4.  Reasonable access to me afterward for advice, training, etc.
>How would this be worded in a contract?

I don't really know... I think you can't....

>> Do consultants normally work on several projects at the same time?  I
would expect the developer to be 100%
>> dedicated to our project, from the beginning to completion.

       Well, exclusiveness is expensive, you know... When I work on a
project I can do it myself and I can also delegate to employees, I think you
must just ask for real time schedules and agree that those must be meet.

>>What if we were to ask you to work on our premises?  The motivation here
is the same as for #1 above - we would
>>like to be able to give and receive feedback in real time.  The hours are
flexible (we have two overlapping
>>shifts).

       I just replied this. Again, it can be done, but you'll be limiting
the income and "freedom" of that person, so the price might be a little
higher


Regards,

Mauricio Jancic
Janso Desarrollos - Microchip Consultants Program Member
.....infoKILLspamspam.....janso.com.ar
http://www.janso.com.ar
(54) 11 - 4542 - 3519

2005\04\19@215130 by Bob Ammerman

picon face
>> Do you want to hire someone on an hourly rate? In that case the
>> consultant would want just that: his hourly rate and maybe some
>> interesting work during those hours.
>
> So you're saying consultants prefer to work on an hourly basis?  What
> would he/she say if we asked them to analyze the project and come up with
> a fixed dollar amount?  My concern is that if the consultant is not
> working on our premises 100% of the time, we cannot verify the actual
> number of hours worked.

Yes, a certain amount of trust is required.

>> If you want a job done on a fixed-price basis you will have to make
>> clear upfront what has to be done, down to the level where the
>> consultant can determine a price. This will most likely be much more
>> detailed than you expect. And when you change your specs during the run
>> don't be surprises when the bill expands.

And expect the fixed price to include an 'adder' to account for uncertainty
over and above the consultants 'honest' estimate of the time required.

> If we were to write a complete Users Manual like Andrew Warren suggested,
> would that be detailed enough, in your opinion?  What would be the best
> contingency plan in case the specs have to be changed sometime during the
> development process?

A user's manual is a great idea.

Changes are negotiated. This can be a simple addendum to the contract: user
defines required change, consultant prices it, use accepts (or negotiates),
addendum is added to contract.


Bob Ammerman
RAm Systems

2005\04\19@232338 by Vitaliy

flavicon
face
Hello Mauricio,

[snip]
{Quote hidden}

I understand what you're saying.  However, we would REALLY like to have the
ability to interact with the developer face-to-face, preferably on a daily
basis.  Here are my reasons:

1. Ease of communication.  Even though we had a couple of projects done
remotely, which were relatively successful, others failed miserably because
of poor communication.  If someone is working on the premises, they can
always stop by my office and ask a question (and vice versa).  The more
difficult it is to ask a question, the more one relies on his own
assumptions (often incorrect).
2. Documentation.  This is related to #1 - we have hundreds of pages of
standards and specifications, which the developer may need to access as
needed.  They are not in the public domain, and neither are they cheap.
3. Equipment.  We have certain tools and test equipment that the developer
may need, which are unique to this project.

To make this project even more unusual, it was originally to be done
in-house.  In fact, we have already built the hardware for the prototype and
started working on the firmware.  The reason we're looking for a developer
right now is time - we'd like to put the device into production sooner than
we would be able to do on our own.

There are a couple of other reasons why we'd like to work alongside the
developer:

A. Since we expect to make changes to the firmware during the lifetime of
the product, the code must be well structured and commented.
B. Chances are, we have more knowledge related to the operation of the
device and a better understanding of how certain things should be done.
C. In order to finish the project faster, we plan to set up a CVS so that we
can collaborate with the developer.

I know this goes against what you and Andrew Warren said ("Tell me what to
do, but don't tell me how to do it") - however, this is one of the few
things that are not negotiable.   We don't want to end up with code that is
write-only.

It would be great if someone "from the other side of the fence" could
comment on their experience working with consultants.  Especially someone
who had concerns similar to ours.

[snip]
> What I do is to say: "this is the total amount of money for the
> project. You'll have to pay it in 3 or 4 times at these dates. You'll also
> receive "this" on that dates (plus the inter-payment presentations)

Sounds reasonable.  I assume the contract would include a clause stating
that you don't receive the next payment until you deliver what you promised.
;)

>>>    4.  Reasonable access to me afterward for advice, training, etc.
>>How would this be worded in a contract?
>
> I don't really know... I think you can't....

How come?  The probability that we will require such services is low, but we
would like to have the ability to ask a question about an unusually
complicated section of code, or whatnot.  Naturally, we would agree to pay a
certain amount in exchange for the technical support.

> Well, exclusiveness is expensive, you know... When I work on a
> project I can do it myself and I can also delegate to employees, I think
> you
> must just ask for real time schedules and agree that those must be meet.

I feel a bit uneasy about such arrangement.  What if you come in for an
interview, make a great impression, and then delegate the work to a recent
grad?  This is exactly what happened in the <sad story> below - the project
was "delegated" several times, and we ended up with spaghetti code.

[snip (...working on premises...)]
> I just replied this. Again, it can be done, but you'll be limiting
> the income and "freedom" of that person, so the price might be a little
> higher.

Let's say it takes the developer one month to complete the project while
working full time.  At a pace of 3 hours per day, it would take him four
months to complete the project, because of the overhead associated with
"starting to start" and switching between projects.  We would much rather go
with the first option, even if it is more expensive.

Thank you for taking the time to answer my questions.

Best regards,

Vitaliy

PS
<sad story about a project that failed>
A software project which was originally supposed to take three weeks to
complete, was finally delivered to us five months later.  The program wasn't
working the way it was supposed to, but at that point we were frustrated
enough to make the final payment and get the source code.  It took my
partner two weeks to go through the code, weed out the bugs, and make it
work according to the specs.  To give you an idea how bad the code was,
here's a snippet (quoting from memory):
  if (log_write_error)
    write_log("Could not write to the log file!");
</sad story>

2005\04\19@234319 by Vitaliy

flavicon
face
Hello Bob,

Before I reply to your e-mail, I would like to make a short announcement to
those people who already submitted their work proposals.  Once we put
together project description and requirements, I will post them here (under
the appropriate subject/tag).  In the meantime, I will forward your e-mails
to our "jobs" account to be reviewed later.  In order to be objective and
fair to everyone, I will not have private discussions with consultants at
this time.  Thank you all for taking the time to write me.

[snip]
>> a fixed dollar amount?  My concern is that if the consultant is not
>> working on our premises 100% of the time, we cannot verify the actual
>> number of hours worked.
>
> Yes, a certain amount of trust is required.

I can see how this can create tensions in case the project takes longer to
complete than expected.  Also, it takes away the incentive to complete the
project on time.

How about something like this: let's say that we agree on a fixed (total)
price for the project, and set the deadlines.  Then, we pay extra 10% if
that part of the project is completed on or before the deadline.  Does
anyone have experience with such arrangements?

[snip]
>>> detailed than you expect. And when you change your specs during the run
>>> don't be surprises when the bill expands.
>
> And expect the fixed price to include an 'adder' to account for
> uncertainty over and above the consultants 'honest' estimate of the time
> required.

Absolutely, in fact we are counting on it.  An experienced consultant should
be familiar with Murphy's Law.

[snip]
> Changes are negotiated. This can be a simple addendum to the contract:
> user defines required change, consultant prices it, use accepts (or
> negotiates), addendum is added to contract.

Great, thank you for the pointer.

Best regards,

Vitaliy

2005\04\20@002845 by Denny Esterline

picon face
> >    4.  Reasonable access to me afterward for advice, training, etc.
>
> How would this be worded in a contract?
>

IME this is assured by working with a reputable consultant that plans to be
in business in the future :-) Often this is specified in a contract such as
"X hours of support after delivery is included", or "Post delivery support
will be billed at X $/hr".

> [snip]
> >    1.  My home telephone number, or unlimited free conversation time on
> >    my office phone.
>
> Do consultants normally work on several projects at the same time?  I
would
> expect the developer to be 100% dedicated to our project, from the
beginning
> to completion.
>

>From my experience this is totally unreasonable. And may not even be what
you're thinking. As a customer you should want competent developer(s)
spending the necessary time on your project to meet the agreed upon
timeline. If you dictate that a developer is to be 100% dedicated to your
project, then he/she can't support previous projects, or bid future
projects, or reply to PICLIST e-mail ;-), or a lot of other things small
business people have to do every day.

> [snip]
> >    3.  The right to dictate the specific hours or place that I'd work
> >    on their projects.
>
> What if we were to ask you to work on our premises?  The motivation here
is
> the same as for #1 above - we would like to be able to give and receive
> feedback in real time.  The hours are flexible (we have two overlapping
> shifts).
>

The real time issue becomes less important as the size of the project
increases. Small jobs (~1 day or less) I almost always do at the customer's
site. For larger jobs I tend to do more of my work at the office, but it's
dependent on the tools neccessary for the task too. And don't underestimate
the 'home-court-advantage'. Sure I can work in somebody else's office with
my laptop and what I can carry, but I'm a lot more productive at my desk
with a regular keyboard, a 19" LCD and a stack of databooks at the ready.
And if you're paying by the hour, wouldn't you rather I was more productive?

Remember, consulting is a special kind of work and attracts atypical people.
Myself for example, I do my best work between midnight and dawn and I like
to sleep till noon, other's take to consulting for the scheduling
flexibility for family or other obligations. As a customer, you have the
right to have your project completed by agreed upon deadlines - but I became
a consultant to get away from somebody else thinking they had control of my
daily schedule.


BTW, the quality of the advice from the PICLIST is usualy poportional to the
amount of information we have about the problem. Give us a little more info
about what you're looking for. (hardware / software development, prototypes,
mechanical, ect)

-Denny

2005\04\20@003547 by Bob Ammerman

picon face
With all the constraints you've outlined I really think your only reasonable
choice is to just hire somebody on an hourly basis to work at your site [so
where are you ;-)]

Bob Ammerman
RAm Systems

{Original Message removed}

2005\04\20@012140 by Denny Esterline

picon face
> I understand what you're saying.  However, we would REALLY like to have
the
> ability to interact with the developer face-to-face, preferably on a daily
> basis.  Here are my reasons:
>
> 1. Ease of communication.  Even though we had a couple of projects done
> remotely, which were relatively successful, others failed miserably
because
> of poor communication.  If someone is working on the premises, they can
> always stop by my office and ask a question (and vice versa).  The more
> difficult it is to ask a question, the more one relies on his own
> assumptions (often incorrect).

Agreed, communication is the key to understanding. And that relates back to
having a good and complete specification at the beginning of the project.
With a adequate specification I shouldn't need to ask any questions or make
assumptions.

> 2. Documentation.  This is related to #1 - we have hundreds of pages of
> standards and specifications, which the developer may need to access as
> needed.  They are not in the public domain, and neither are they cheap.

I don't get it - it's documentation - how can it be 'not cheap'. If it
already exists, just make a copy. Even several hundred pages of copies isn't
very costly compared to other costs in a project like this. As to being not
public domain - if you can't trust your consultant for confidentiality in
such matters, you've hired the wrong consultant.

> 3. Equipment.  We have certain tools and test equipment that the developer
> may need, which are unique to this project.
>

In that case, at least "some" of the development work would need to be on
site.

> To make this project even more unusual, it was originally to be done
> in-house.  In fact, we have already built the hardware for the prototype
and
> started working on the firmware.  The reason we're looking for a developer
> right now is time - we'd like to put the device into production sooner
than
> we would be able to do on our own.
>
> There are a couple of other reasons why we'd like to work alongside the
> developer:
>
> A. Since we expect to make changes to the firmware during the lifetime of
> the product, the code must be well structured and commented.
> B. Chances are, we have more knowledge related to the operation of the
> device and a better understanding of how certain things should be done.
> C. In order to finish the project faster, we plan to set up a CVS so that
we
> can collaborate with the developer.

A) is a must. In fact, I'd say that's part of the prerequisite to be a
software developer. It should be part of the interview process - ask for a
sample of some code the consultant has produced.

B) could be a point of contention. Are you hiring a consultant, or an
instructor. I've done both and I don't bill them at the same rate. There's
an old joke - a sign hung in a mechanics garage:

Standard rate - $20/hr
You wait  - $30/hr
You watch - $40/hr
You help - $50/hr

It's meant to be a joke, but there's some truth to it.

CVS is usually a good thing, but think carefully about the reasons you want
it. Getting your consultant up to speed on CVS system he/she may not be
familiar with and then having you're in house developers working on some of
the same code does not necessarily translate to "faster"

>
> I know this goes against what you and Andrew Warren said ("Tell me what to
> do, but don't tell me how to do it") - however, this is one of the few
> things that are not negotiable.   We don't want to end up with code that
is
> write-only.

And you shouldn't. If that's part of the contract, you should get what's
agreed upon or not pay.

> [snip]
> > What I do is to say: "this is the total amount of money for the
> > project. You'll have to pay it in 3 or 4 times at these dates. You'll
also
> > receive "this" on that dates (plus the inter-payment presentations)
>
> Sounds reasonable.  I assume the contract would include a clause stating
> that you don't receive the next payment until you deliver what you
promised.
> ;)
>

ABSOLUTELY! Contracts go both ways.

>
> Let's say it takes the developer one month to complete the project while
> working full time.  At a pace of 3 hours per day, it would take him four
> months to complete the project, because of the overhead associated with
> "starting to start" and switching between projects.  We would much rather
go
> with the first option, even if it is more expensive.

Not to be insulting, but you're thinking like a manager/supervisor instead
of a customer. When you go to a restaurant, you don't care if Joe's working
the grill or if Sara's mopping the floor, or if Dave's late to work today,
that's their manager's problem. You're just a customer, you want your meal
prepared to certain specifications and delivered in a timely manner. When
you hire a consultant it's the same thing, you want product X to be
delivered on date Y and meet specifications Z.

And there should be deliverables along the way so things like code reviews
can be conducted. If it doesn't meet the agreed specs, the developer fixes
it or you find somebody else.

By the sounds of it, you may actually be looking for a "contract employee"
instead of a consultant. Traditionally you hand a consultant a specified
problem, they give you a solution and a bill. How they get from point A to
point B is usually irrelevant. And many times the decision to hire an
outside consultant is driven by the fact that they can get from A to B by a
path that you can't, whether that be because of regulatory issues, internal
bureaucracy, or personnel skill-set. A contract employee is a normal
employee with a fixed duration employment agreement - it's not a entry level
position. It's a highly skilled and experienced person that doesn't want a
long term commitment.

-Denny



2005\04\20@013054 by William Chops Westfield

face picon face

On Apr 19, 2005, at 9:32 PM, Denny Esterline wrote:

>>>    1.  My home telephone number, or unlimited free conversation time
>>> on
>>>    my office phone.
>>
>> Do consultants normally work on several projects at the same time?
>>  I would expect the developer to be 100% dedicated to our project,
>> from the beginning to completion.
>>
This would be an example of two different types of 'consultant.'

A "type 1" consultant has many smaller projects "in the air" at once.
They get a task, and a due date, and it's up to them whether they think
they can complete the task by the due date or not, taking into account
their other commitments.  Work will probably be done remotely.  Some
"type
1" consultants have another full-time job, and dabble as a consultant
for
extra money or experience (and that's frequently understood by both
employers.)


A "type 2" consultant works for you full time, usually at your site.
This usually requires a bigger project, more pay (overall), and
frequently
some hope of additional projects.  After all, you're asking the
consultant
to suspend other business activities, including (presumably) searching
for
their next client.  This is more of a short-term employment contract
with
rule-bending to prevent certain types of business expenses from
occurring
rather than hiring an outside expert to polish off some task much more
quickly than your internal experts can do it.

BillW

2005\04\20@015207 by Spehro Pefhany

picon face
At 01:24 AM 4/20/2005 -0400, you wrote:


>I don't get it - it's documentation - how can it be 'not cheap'. If it
>already exists, just make a copy. Even several hundred pages of copies isn't
>very costly compared to other costs in a project like this. As to being not
>public domain - if you can't trust your consultant for confidentiality in
>such matters, you've hired the wrong consultant.

For a third party to "just make a copy" of a standard would likely involve
a copyright violation.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
EraseMEspeffspam_OUTspamTakeThisOuTinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com




2005\04\20@015220 by Andrew Warren

face
flavicon
face
Vitaliy <piclistspamspam_OUTmit.edu> wrote:

> Andrew Warren's response was the most useful and comprehensive so far
> (thank you Andrew)

   I live to serve, Vitaliy.

   I should preface the rest of this with a disclaimer:  I'm only
   speaking for myself, describing how I did business when I was a
   consultant.  I know there are others who work very differently, and
   hardly anything I say here is an absolute description of how things
   MUST work... Or even, I guess, of how they necessarily SHOULD work.

> > 1.  A clear specification of the product.  The best possible
> > specification would be a complete User's Manual, since that
> > document completely describes what the thing does, but DOESN'T
> > dictate how it's implemented.
>
> This is a great idea.  It sounds obvious now, but we were thinking more
> in terms of functional specs (not quite the same) rather than a
> complete Users Manual.

   If you know EXACTLY what you want and you're skilled in the art of
   writing engineering specs, a Functional Specification would be just
   fine.  My clients were often non-engineers, though, so their attempts
   at writing design specs were often almost useless... They'd draw
   complicated flowcharts (usually with obvious logical errors and
   omissions) to describe simple things like keyboard auto-repeat or
   scrolling, they'd go into exquisite detail on some small aspect of
   the design that they understood while practically ignoring the larger
   ones that they didn't, they'd use engineering terminology
   inaccurately and confusingly, etc.

   If they'd never seen an engineering spec, they usually had a strange
   idea of what one should look like... They seemed to think that they
   were required to write very formally using lots of big words, so the
   formatting and phrasing of the spec got in the way of actually
   expressing what they wanted.

   A User's Manual, on the other hand, is a document that EVERYONE is
   familiar with, and it expresses the functional requirements exactly
   as most clients already think about them.

   For a great example, try writing directions for setting the time and
   alarm on a digital clock-radio, then try writing a flowchart for it.
   No matter how detailed you make your instructions, it'll be hard to
   stretch them beyond a single page, and the time required to write
   those instructions is likely to be determined primarily by your
   typing speed.

   The flowchart, though, will cover many pages, take hours and hours
   to draw, and will almost certainly have errors even if you ARE
   skilled at designing such things.  Depending on the level of detail
   you use, it could vary hugely in size.

   It'll also be harder to understand ("can't see the forest for the
   trees"), and it'll unnecessarily restrict the implementor's creativity:
   Your flowchart may be written under the assumption that you're using
   common-cathode displays, for instance, but do you really care whether
   the final design uses common-anode?  And why specify up-front the
   length in milliseconds of things like key-repeat delays or scrolling
   speed, or the debounce time of the switches?  That's just unnecessary
   detail (and your initial guesses are likely to be wrong, anyway).

   And... You're going to have to write a manual at some point, anyway.
   If your design spec WAS the User's Manual, then you'll already have
   it -- and it will have been reviewed, checked for accuracy, edited,
   and approved -- the moment that your product is finished.

   Of course, there are often internal details and implementation
   requirements that are necessary to communicate to your developer but
   that wouldn't normally be in a User's Manual.  You still need to
   spell them out in some form, but it's likely that those requirements
   will be quite easy to describe once all the basic functionality has
   already been pulled out and described in a clear User's Manual.

> > 2.  A schedule.
>
> This is something we should discuss with the developer, right?

   Yes.  If you have a hard deadline (a trade show, a delivery contract,
   a narrow market window, etc.), he or she needs to know that and agree
   to it. If you're more flexible, it's in your interest to let him help
   define the schedule.  It does neither of you ANY good to set a
   schedule that he knows will be impossible to meet.

> Do consultants normally charge the client for analyzing the
> requirements and coming up with the deadline?

   No, they shouldn't.

> > 1.  Regular status reports, either emailed, over the phone, or at
> > brief weekly meetings.
>
> This is one of my areas of concern.  We've outsourced some projects
> before, and from my experience communication is the greatest challenge,
> and the major bottleneck.  Therefore, we would like to be able to give
> and receive feedback in real-time.  Therefore, the ideal candidate
> would have to be a local resident.  What are your thoughts on this?

   Many of my clients were local, but just as many were out-of-town or
   even out of the country.  It's easier for everyone if you're
   physically close to each other, but you have to be careful not to
   abuse that situation.  I often didn't charge clients for the
   drive-time to and from their office, and if they were really likable
   I often didn't charge for the time I spent there, either... But if
   they were the micromanaging type who constantly called me to their
   offices to check up on my progress, the meter was running the whole
   time.

   Some situations, of course, required that I be at their place very
   regularly.  If they had specialized equipment or facilities that I
   needed to work with -- an RF test range or an engine dyno or whatever
   -- I might be over there every day.  In those cases, I didn't charge
   for driving there and back; the commute was just part of my cost of
   doing business.

   With all that said, though, the communications challenge/bottleneck
   can largely be avoided by having a really good initial spec.  Don't
   rush the process of creating it or underestimate its importance; the
   better it is, the less you'll have to communicate during development.

   Also... At some level, you really do need to trust your consultant.
   If you're very concerned about this, ask for references (preferably
   from people with whom he's no longer doing any business, as well as
   someone he recently or currently worked for), and call them.

> > 2.  Regular invoices so they were never surprised by an
> > unexpectedly large bill.
>
> How often would you bill for a project that is, say, 3 months long?
> Would it be periodic (every 2 weeks), or based on the milestones of the
> project?

   It varied.  My usual arrangement was much like my lawyer's:  A client
   would pay a retainer in advance, and I'd draw from that "bucket" at
   my hourly rate until it (nearly) ran out.  At that point, I'd send an
   invoice and he'd refill the bucket.  The amount of each "fill"
   varied, but it often worked out to about 50 hours of my time.

   With that arrangement, I always knew I'd get paid (because the money
   was already in my account), and my client knew he'd never be
   astonished by a huge bill (because I'd never bill for more hours than
   he'd already paid for).

   I'd occasionally agree to a different scheme, but that was rare...
   Other consultants may be able to give you better insight into
   more-traditional payment arrangements.

> we must have the ability to modify the design later.

   Make sure that you've spelled out very clearly, then, exactly what
   your consultant's deliverables are, and what rights you have to the
   IP he develops.  An intellectual-property lawyer can help.

> > 4.  Reasonable access to me afterward for advice, training, etc.
>
> How would this be worded in a contract?

   In my contract, it was worded like this:

       5.        Technical Support by Consultant. For a period of 60 days
       after Client's acceptance of the Product, the Consultant will
       provide to the Client reasonable technical assistance relating to
       the use of the Product.  This assistance will be provided at no
       charge to the Client.

   The definition of "reasonable" might vary from person to person, of
   course, but that's ok with me and was always ok with my clients.

   You can TRY to pin down every little detail -- I've seen a 217-page
   software-development contract, for example -- but things really are
   always open to interpretation, and it's just easier to a) have some
   trust, and b) just be nice to work with, so your consultant will want
   to be nice in return.

> > 1.  My home telephone number, or unlimited free conversation time
> > on my office phone.
>
> Do consultants normally work on several projects at the same time?  I
> would expect the developer to be 100% dedicated to our project, from
> the beginning to completion.

   Ah, that WOULD be ideal... But unless yours is a very long-term
   project, or a very short one that could be done in a day or two, the
   reality is that he'll probably be working on something else at the
   same time, at least at the beginning of your project and/or near the
   end.

   Remember, he wants to maintain a more-or-less steady income flow
   throughout the year, and it's difficult for him to schedule jobs so
   they align precisely on his calendar without overlapping (especially
   since he often has to define schedules based on "specs" written on
   the back of a cocktail napkin, work with clients who change their
   minds all the time, deal with unpredictable supply issues, etc.)

   If you called a consultant to ask for a quote and he told you, "Sure
   I can do your job... But I'm waiting to hear whether my current
   client wants any changes to the thing I just did for him, and I don't
   know when he's going to call, so I don't know when I'll be able to
   start on yours.  Let me get back to you in a week or two when I know
   for sure," you'd probably cross him off your list and call the next
   guy, right?

   Your consultant will almost ALWAYS have something else going on in
   the background, even if he's not actively working on another client's
   code or schematic or whatever.  Let HIM worry about whether he has
   time to take on your job, or whether he'll have to work 60- or
   80-hour weeks to handle the load and meet your schedule; that's why
   he makes the big bucks.

> > 3.  The right to dictate the specific hours or place that I'd
> > work on their projects.
>
> What if we were to ask you to work on our premises?  The motivation
> here is the same as for #1 above - we would like to be able to give and
> receive feedback in real time.  The hours are flexible (we have two
> overlapping shifts).

   You have to be very careful about that, at least in this country.
   The Internal Revenue Service has strict rules about what
   differentiates a contractor from an employee.  If they decide that
   your "consultant" is actually an employee, you may be required to
   withhold income tax and FICA (and pay the employer's share of FICA),
   pay for workman's comp and unemployment insurance, etc.

   The IRS has a "twenty questions" list for making the determination;
   you should take a look at it.

   Also... People become freelance consultants for a reason.  Often,
   it's at least partially because they enjoy the (illusion of) freedom
   that comes with it.  I know ONE consultant -- a freelance Windows
   programmer -- who wakes up every weekday and drives to his
   client-of-the-day's office, where he works from 8:00 to 5:00.  He
   likes that, but most consultants prefer to set their own hours and
   work in their familiar surroundings with their own specialized
   equipment.

   Your consultant is -- or should be, anyway, for what you're paying
   him -- really good at what he does.  He's highly employable, right?
   If he WANTED to work in someone else's cubicle farm, on someone
   else's daily schedule, he'd already be doing that as someone's
   employee, INSTEAD of consulting.

   -Andrew

=== Andrew Warren - @spam@fastfwdKILLspamspamix.netcom.com

2005\04\20@024011 by Denny Esterline

picon face
> >I don't get it - it's documentation - how can it be 'not cheap'. If it
> >already exists, just make a copy. Even several hundred pages of copies
isn't
> >very costly compared to other costs in a project like this. As to being
not
> >public domain - if you can't trust your consultant for confidentiality in
> >such matters, you've hired the wrong consultant.
>
> For a third party to "just make a copy" of a standard would likely involve
> a copyright violation.
>

Well, that might be an issue, but my point stands - lack of available
standards documentation is not a good reason to restrict 'where' the
development can be done. And if you can't share that documentation with a
consultant, you've got bigger problems.

-Denny

2005\04\20@035147 by Wouter van Ooijen

face picon face
> > Do you want to hire someone on an hourly rate? In that case the
> > consultant would want just that: his hourly rate and maybe some
> > interesting work during those hours.
>
> So you're saying consultants prefer to work on an hourly
> basis?

no, I wanted to say that the startup requirements are very different for
a pay-per-hour project (track the hours worked) than for a
pay-for-result project (in which case you must define the result very
carefully).

> What would
> he/she say if we asked them to analyze the project and come
> up with a fixed dollar amount?

Dunno, depends on who he/she is, and in particular on the amount of
trust you have build up. Might be a good idea, but only when trust is
sufficient. Otherwise the first question I would ask is 'what exactly do
you mean by analyse' (in other words: tell me which end product would
make you happy).

> My concern is that if the consultant is not
> working on our
> premises 100% of the time, we cannot verify the actual number
> of hours worked.

In that case you might want him on your premises. But in my country that
could make the gouvernment consider him an employee.

But when you don't trust him, why hire him? And if you don't trust his
working-hours-registration, do you trust his hourly work? A person on
your premises can spend hours and hours without achieving anything.
Would that make you happy?

> If we were to write a complete Users Manual like Andrew
> Warren suggested,
> would that be detailed enough, in your opinion?

I fully agree with Andrew that a user manual is often a better
specification that a traditional spec. Note however that some essential
things (like parts/production cost, current consumption, reliability,
source code language) are not often found in a user manual.

> What would be the best
> contingency plan in case the specs have to be changed
> sometime during the development process?

That's a very difficult one. Best is not to change, and/or to consult
with your consultant before commiting to the change. But such
consultance will take time = money. It is true that a software-driven
thingy can always be changed during the development process, but
contrary to popular belief this will in a lot of cases not be cheap. It
might cost as much as the original developmen cost.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\04\20@045716 by Alan B. Pearce

face picon face
{Quote hidden}

On the basis of this lot, I think you may end up actually working in stages
with the developer.

stage 1 - developer comes into your office, reviews hardware, learns
software requirements, reviews standards documents related to requirements,
takes copious notes, and generally gets a feel for the project. This stage
could take a day or two or three.

stage 2 - developer disappears from your office for a period, and writes
software. This period would need to be an agreed time between you and the
developer, but may be anywhere between two and four weeks, at a guess.
During this time I would suggest that developer gives weekly email updates
on progress, and (s)he may well need to come in to office to further peruse
standards documents or discuss finer points on the hardware.

stage 3 - effectively the initial delivery phase of software, developer
supplies initial software for downloading, and works with your hardware
people on debugging and fine tuning. Developer works on site during this
time.

stage 4 - your development team thrash the software every which way they
can, noting possible defects and bugs, and list further fine tuning items.
Comprehensive list of items is returned to developer. Depending on time this
takes, this may involve weekly reporting to developer of bugs, and he may
provide software updates as needed, for serious bugs that stop other
testing, but is otherwise not involved.

stage 5 - developer provides debugged code, either by working on site, but
may have worked on code in background depending on what reports he has
received during stage 4. However during the further debugging of this stage
he works on site.

stage 6 - Developer hands over all source code (as agreed in contract) and
any further coding is done in house. There may be an agreed clause for
contacting the developer to clear up some information points, but any
further code work is now extra to the contract, unless there is a clause for
clearing up serious flaws that come to light.

This is just my view on how it could happen, not having done it myself, so I
would appreciate any comment from others as well.

2005\04\20@074212 by Gerhard Fiedler

picon face
Vitaliy wrote:

>> 1.  A clear specification of the product.  The best possible
>> specification would be a complete User's Manual, since that document
>> completely describes what the thing does, but DOESN'T dictate how it's
>> implemented.
>
> This is a great idea.  It sounds obvious now, but we were thinking more
> in terms of functional specs (not quite the same) rather than a complete
> Users Manual.

As some already said, it's a very good idea, but it's not enough. Usually
you have some constraints that are not in a user's manual. Baseline is, you
want to specify what you want with as much precision as necessary to get
what you want, without specifying too much of what you don't need. It's an
art in itself to write a good spec, people tend to underestimate this.

>> 2.  A schedule.
>
> This is something we should discuss with the developer, right?  Do
> consultants normally charge the client for analyzing the requirements
> and coming up with the deadline?

Depends, but usually not (IMO).

>> 1.  Regular status reports, either emailed, over the phone, or at brief
>> weekly meetings.
>
> This is one of my areas of concern.  We've outsourced some projects
> before, and from my experience communication is the greatest challenge,
> and the major bottleneck.  Therefore, we would like to be able to give
> and receive feedback in real-time.  Therefore, the ideal candidate would
> have to be a local resident.  What are your thoughts on this?

Locality is no guarantee for good communication, it's not necessary for it
and it doesn't buy you much either. Think of it. Unless the consultant
lives literally around the corner and works on-site, in terms of
communication it doesn't really matter much whether she lives on the other
side of NY or the other side of the country -- or in another continent. In
neither case the communication will be in person; it will be by phone,
email, IM, whatever. I have been working with teams as big as 40
developers, distributed in locations from Brazil to Canada, with very good
communication.

You are better off with a good understanding of what you want in terms of
communication, making this sufficiently clear to the consultant, and having
a good communication from the start -- that is, in the phase before the
contract. If it doesn't work well then, it won't work well afterwards.

>> 2.  Regular invoices so they were never surprised by an unexpectedly
>> large bill.
>
> How often would you bill for a project that is, say, 3 months long?
> Would it be periodic (every 2 weeks), or based on the milestones of the
> project?

Depends on the contract. Hourly contracts usually are billed in regular
intervals (2 weeks is good for me); with fixed price contracts you usually
want to bind the payments to deliverables.

I also like the idea of a bonus for on-time delivery. In my experience it's
not that common, but I think it should be. The difficulty is probably to
come to an agreement whether it should be a bonus (on top of the "normal"
price) for on-time delivery, or a penalty (taken off of the "normal" price)
for late delivery... :) That's possibly one of the reasons why this is not
that common; usually one of the two parties will have some kind of hard
feelings.

>> 1.  My home telephone number, or unlimited free conversation time on my
>> office phone.
>
> Do consultants normally work on several projects at the same time?  I
> would expect the developer to be 100% dedicated to our project, from the
> beginning to completion.

That's a difficult proposition. If a developer is good, she will have had
projects before yours. If she offers you fixing future problems, she has
offered that before. You can't really expect to get something you want to
deny her previous customers -- unless you pay an extra premium for that.
Which you probably don't want to pay :)

OTOH, why would you want that? You need to have better means to track
whether the project is on schedule -- and to make sure it stays on
schedule. 100% dedication doesn't guarantee anything. A realistic schedule
with relevant milestones, regular and meaningful status reports, otherwise
good communication, a bonus for on-time delivery; all these are more
important than 100% dedication for properly tracking the project and making
sure the schedule gets kept.

> What if we were to ask you to work on our premises?  The motivation here
> is the same as for #1 above - we would like to be able to give and
> receive feedback in real time.  The hours are flexible (we have two
> overlapping shifts).

For some people that doesn't work well, for others it's the only way they
can work. Most people who are used to work in their own environment are
much more productive in their own environment, besides commuting and other
detrimental factors. Which for them makes working on-site much more
expensive and you'd have to pay a premium (if one of these is offering at
all). OTOH there are others who don't have the necessary infrastructure
available and need to work on-site.

Depends on what you want. You probably will get more easily a fixed price
offer from someone working in his own shop, and you will get hourly offers
from people who go on-site. I probably would have to be pressed hard to
give you a fixed price offer if I had to work at your location -- besides
not liking it, there are even more uncertainties involved than already are
with any project.

Gerhard

2005\04\20@090021 by Mauricio Jancic

flavicon
face
Hello Vitality,

> I understand what you're saying.  However, we would REALLY
> like to have the ability to interact with the developer
> face-to-face, preferably on a daily basis.  Here are my reasons:

[SNIP]
       Well, you have a point. I still think that, specially if you are
saying you want a colaborative job, it can be done with just a few meetings
and over the internet or the phone.

> A. Since we expect to make changes to the firmware during the
> lifetime of the product, the code must be well structured and
> commented.
[SNIP]

Usually all consultants do code like that, I think. You migh want to ask for
examples?

> B. Chances are, we have more knowledge related to the
> operation of the device and a better understanding of how
> certain things should be done.
> C. In order to finish the project faster, we plan to set up a
> CVS so that we can collaborate with the developer.

[SNIP] Collaboration is fine, but, specially in assembler, there might be
"interactions" between code parts and you might not want to spend time
finding who's code is not working well

> I know this goes against what you and Andrew Warren said
> ("Tell me what to do, but don't tell me how to do it") -
> however, this is one of the few
> things that are not negotiable.   We don't want to end up
> with code that is
> write-only.
[SNIP]

One should neved do such thing. My codes are always writen so when you call
me to update it I can doit in no-time. Recently a customer who asked me to
do some code with a multiple screen menu, asked to add a menu item and some
functions. I did it on the day, not because I'm fast, but because the code
was modular and I have to add few lines to make it work.


> Sounds reasonable.  I assume the contract would include a
> clause stating that you don't receive the next payment until
> you deliver what you promised.
> ;)

OBVIOUSLY :)

> >>>    4.  Reasonable access to me afterward for advice,
> training, etc.
> >>How would this be worded in a contract?
> >
> > I don't really know... I think you can't....

I meant that you cant make shure that your consultant travels to... I don't
know, let say Sweden, and he starts he's own bussines as a restauranter....
He will have a hard time helping you, see?
Off course that if he's still in the bussines you will be able to contant
him, but I don't think you can force him "for ever" to reply your questions,
even if you pay. I personally do reply the questions, sometime charging,
sometimes not, but if a customer screw me I more lickely not answer anything
else to him...

> I feel a bit uneasy about such arrangement.  What if you come
> in for an interview, make a great impression, and then
> delegate the work to a recent grad?  This is exactly what
> happened in the <sad story> below - the project was
> "delegated" several times, and we ended up with spaghetti code.

Well, you hire me right? You'll receibe the exact code that I promised not
other's. Sometimes, on big projects and tight schedules you have to work
with someone else. And I will not take to the interview my employees and
show you "hi, this guy is going to do all the coding..."

The fact is that I do all the coding. But lets picture a complex project ok?
Well, I can ask one of the guys to acondition a LCD routine or keyboard or
something I already have done. Also, sometimes I find it very usefull to
write code with someone ovelooking it over my shoulder, and, finally, some
code meetings to revise the code prior to testing it. Ofcourse, it all
depends on the project budgetn and schedule.

> Let's say it takes the developer one month to complete the
> project while working full time.  At a pace of 3 hours per
> day, it would take him four months to complete the project,
> because of the overhead associated with "starting to start"
> and switching between projects.  We would much rather go with
> the first option, even if it is more expensive.

OK, that's understandable, how ever some customers doesn't care if a project
takes 3 weeks instead of 2, but not all.


Regards,

Mauricio Jancic
Janso Desarrollos - Microchip Consultants Program Member
KILLspaminfoKILLspamspamjanso.com.ar
http://www.janso.com.ar
(54) 11 - 4542 - 3519

2005\04\20@092001 by Dave VanHorn

flavicon
face

>
> > I know this goes against what you and Andrew Warren said
> > ("Tell me what to do, but don't tell me how to do it") -
> > however, this is one of the few
> > things that are not negotiable.   We don't want to end up
> > with code that is
> > write-only.
>[SNIP]
>
>One should neved do such thing. My codes are always writen so when you call
>me to update it I can doit in no-time. Recently a customer who asked me to
>do some code with a multiple screen menu, asked to add a menu item and some
>functions. I did it on the day, not because I'm fast, but because the code
>was modular and I have to add few lines to make it work.

IMHO too many coders fail to remember that when you are writing code
for a customer, IT BELONGS TO THE CUSTOMER.

They write in ways that make it impossible for anyone else to follow
them, which I guess is supposed to enhance their job security.


2005\04\20@092150 by olin_piclist

face picon face
Vitaliy wrote:
>>    1.  A clear specification of the product.  The best possible
>>    specification would be a complete User's Manual, since that document
>>    completely describes what the thing does, but DOESN'T dictate how
>>    it's implemented.
>
> This is a great idea.  It sounds obvious now, but we were thinking more
> in terms of functional specs (not quite the same) rather than a
> complete Users Manual.

I disagree with Andrew a bit here.  While a user's manual would certainly be
helpful, I've never seen one available that early in product development.
I've also very very rarely (can't actually think of a case, but I may have
forgotten one) seen a customer spec that was sufficient to provide a fixed
price quote from.  For this reason, I'd rather discuss the requirements with
the customer, take notes, and write the formal spec myself.  I charge for
this on a time+materials basis.  Once the spec is agreed upon, I can provide
a fixed price quote for the implementation, if it's the kind of project that
lends itself to that.  The customer has to understand that a real spec is a
lot different from a wish list, and requires expertise and some real
engineering to write properly.  Having a good spec is critical to the
success of the project, and they'd have to pay someone to write it anyway.

>>    2.  A schedule.
>
> This is something we should discuss with the developer, right?

Yes.

> Do
> consultants normally charge the client for analyzing the requirements
> and coming up with the deadline?

Usually there isn't that luxury.  Most deadlines are imposed externally for
reasons that have nothing to do with the desing process.  About 3/4 of the
time I have to explain why the customer's deadlines are unrealistic.

>>    1.  Regular status reports, either emailed, over the phone, or at
>>    brief weekly meetings.
>
> This is one of my areas of concern.  We've outsourced some projects
> before, and from my experience communication is the greatest challenge,
> and the major bottleneck.

There is no need for this to be true.

> Therefore, we would like to be able to give
> and receive feedback in real-time.

You definitely need to drop this thinking.  Most consultants will run away
screaming when they here this.  Consultants can be more cost effective for
several reasons.  First, they have the specific expertise for the project,
and you can't afford to carry that expertise on an ongoing basis.  Second,
they can put their head down and get the project done without the
distractions of the normal company BS, like meetings, people walking by
chatting, and the endless discussions of who ate the last 2/3 of a donut
left in the conference room.  You absolutely don't want to be bugging a
consultant in real time.  Give him a well defined task to do, then get out
of his way and let him do it.  Of course you can have regular status
updates.  This is probably best done at specific milestones.  Asking for
weekly updates on where the work is in relation to those milestones is OK.
Calling the consultant every day to see where he's at is going to be
counterproductive.  Whether you like it or not, you're going to put a
considerable amount of trust in a consultant, moreso than a regular employee
in some ways.  If you can't buy into that concept, then the consultant route
isn't for you.  It also means that getting the right consultant is very
important.  You need to interview carefully, check up on references, etc.

> Therefore, the ideal candidate
> would have to be a local resident.

Again, not necessary, although it can add to the convenience.  Being able to
meet the customer for an hour or two travel time is a plus, but I've also
done projects where I've never been to the customer site.

> How often would you bill for a project that is, say, 3 months long?
> Would it be periodic (every 2 weeks), or based on the milestones of the
> project?

This can be arranged different ways as long as its agreed to up front.  For
a time+materials job, I like to invoice twice per month, at least until we
get to know the customer better and see that they pay their bills on time.
For fixed price jobs, you'd typically pay a bit up front, pay a bit more at
each milestone, then pay the rest on final delivery.  The exact details are
negotiated before work starts, and there should be some flexibility from
both parties to meet the other's constraints.

>>    3.  A couple of programmed PICs (or whatever), source code
>>    (usually), schematics/layout/Gerbers/whatever if hardware was
>>    involved, and an irrevocable license (usually exclusive) to use all
>>    of it in any way they liked.

This needs clarification.  Any consultant that has been in business for a
while has a large amount of designs and source code already on the disk when
they start your project.  Generic parts of previous projects will end up in
your project as they fit.  This saves the consultant work and therefore
saves you money, in addition to getting you previously proven designs.
However, for this system to work, the consultant can't have you restrict the
future use of the design he creates for you.  Obviously you don't want the
complete design sold to a competitor, and you have a right to be protected
from that, but you also can't expect to lock down the whole thing.  Most
consultants would either refuse to work with that constraint, or charge
exorbitant fees.  In fact, watch out for the ones that don't, since they
don't know what they are doing and clearly have limited experience.

> Do consultants normally work on several projects at the same time?

Yes, they have to.  Think of the consultant's problem of always having
exactly the right amount of work to do.  What are the chances that the next
job will come in the day after the previous one ends?  A consultant has to
have several concurrent jobs so that they hopefully come and go staggered.
As one finishes, he can pick up the slack by concentrating more on the
others, then drop back a bit when the next job comes in.  This is always a
tough juggling act for a consultant.  This is why it's important to discuss
schedule up front.

> I
> would expect the developer to be 100% dedicated to our project, from
> the beginning to completion.

Ain't gonna happen, get over it.  If that's really what you require (and it
probably isn't when you think about it), then you're looking for a temporary
employee or contractor, not a consultant.  As long as the consultant
delivers the work on time, why do you care how much of his time he spent on
it?

> What if we were to ask you to work on our premises?

Most consultants wouldn't be able to agree to that.  It also limits you to
people in the local geographic area.

> The motivation
> here is the same as for #1 above - we would like to be able to give and
> receive feedback in real time.  The hours are flexible (we have two
> overlapping shifts).

All in all you need to understand that your relationship with a consultant
will be different from that with an employee or contractor (which is
essentially a temporary employee).  The consultant brings you a higher level
of expertise than you can afford to keep on the payroll permanently, or
gives you access to expertise not immediately available in your local area.
You also direct a consultant at a higher level than you would an employee.
You agree on the job to be done, how it will be measured, what it will cost,
then get out of his way and let him do that job.  Yes, you end up trusting
in the consultant's expertise and professionalism more than you would an
employee.  If you can't make that mental adjustment, then a consultant isn't
for you.  This is why chosing the right consultant is very important.

Note that the consultant also has to put considerable trust in you.  Getting
paid, and especially getting paid on time is a serious issue.  W2 employees
are well protected under the law, but consultants go out on a limb with
every job they accept.  Don't be offended when a consultant interviews you
as much as you interview him.  You will both end up trusting each other and
need to feel comfortable with each other.

Most consultants work that way because they are very good at what they do
and have discovered that consulting is the only way to get varied and
consistantly challanging projects and get paid well for them.  However,
anyone can claim to be a consultant, and it's up to you to sort the real
ones from the frauds.  Your brother in law's neighbor's friend Vinny you
just got laid off alst week will tell you a story you want to believe.  Half
the time at a quarter of the cost sounds good.  By the time you figure out
Vinny doesn't have a clue you've spent a bunch of money and time with
nothing to show for it.  Vinnys seem to crawl out of the woodwork when the
economy turns bad.  I've lost jobs to Vinny before.  It's hard to explain to
an unsophisticated customer why they'll be better off in the long run to pay
you $20K to for a job Vinny is promising to do for $5K.  Everything you say
just sounds like you're trying to justify an exorbitant fee.  After all
Vinny says he can do a good job too.  By the time they figure out he can't,
it's too late.  In the end it costs a lot more than $20K not to do the job
right the first time, but not everyone understands that until they've run
into it.  I've learned to not waste my breath on those kinds of customers.

Since you are looking for a PIC consultant, you have a little bit of a
headstart.  Microchip has a consultant program, and all the consultants are
listed on their web site by geographic region.  What is less obvious from
the web site is that consultants are classified into bronze, silver, and
gold levels.  Last year at Masters there were over 300 consultants world
wide, with only 35 being gold level (We have been gold level for something
like 5 years in a row).  While there isn't much of a hurdle to become a
bronze level consultant, Vinny isn't going to make it to gold level.  This
isn't a guarantee of anything, but one more data point for your evaluation
process.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\20@102001 by olin_piclist

face picon face
Vitaliy wrote:
> I know this goes against what you and Andrew Warren said ("Tell me what
> to do, but don't tell me how to do it") - however, this is one of the
> few things that are not negotiable.   We don't want to end up with code
> that is write-only.

But the two aren't related.  You should ask to see some code samples when
you interview consultants, and ask to see code a few times early in the
project, but that does not require a consultant to be on site.  This is one
reason I put so much source code of my PIC development environment on the
web (http://www.embedinc.com).  This shows sophisticated customers the kind
of code quality they will be getting.  I've actually gotten jobs on the
strength of the code samples even though it turned out I was the highest
bidder.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\20@103343 by Wouter van Ooijen

face picon face
> IMHO too many coders fail to remember that when you are writing code
> for a customer, IT BELONGS TO THE CUSTOMER.

I guess it depends on what you agreed on. I sometimes write code for a
customer who just wants to buy PICs with that code in it. Sometimes the
customer even forgets to ask for a copy of the source, or for the right
to use the code (should I fail to deliver programmed PICs).

But of course, when the customer asks for the source, and especially
when he mentions that he wants to be able to make modifications, you
must keep that in mind when writing the code.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\04\20@103503 by olin_piclist

face picon face
William Chops Westfield wrote:
> A "type 2" consultant works for you full time, usually at your site.

I call this a "contractor" as apposed to "consultant".

I agree with Bob that Vitaliy needs a contractor, not necessarily because
that's what's really needed, but because he can't get comfortable with a
consulting arrangement.  In particular he is not willing to trust a
consultant's professionalism and is therefore not willing to let go of the
details.  Without a change in mindset, this would not work well neither for
him nor the consultant.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\20@111416 by Wouter van Ooijen

face picon face
> I disagree with Andrew a bit here.  While a user's manual
> would certainly be helpful, I've never seen one available
> that early in product development.

I guess that depends a lot on the kind of thingies you make. For some it
would be very appropriate (think watches, alarm clocks, tamagotchies),
for some it would be almost useless (an IP router).

> For this reason, I'd rather discuss the
> requirements with
> the customer, take notes, and write the formal spec myself.  

Whether that is a good idea depends a lot on your customer. If he can't
read that formal spec, and can't reasonably be expected to, he might not
even be legally bound by it. And some (but not all) of the other
customers, the ones who can read a formal spec, could have written it
themselves. That leaves some for whom it is usefull that the consultant
writes a formal spec.

> > and coming up with the deadline?
>
> Usually there isn't that luxury.  Most deadlines are imposed
> externally for
> reasons that have nothing to do with the desing process.  
> About 3/4 of the
> time I have to explain why the customer's deadlines are unrealistic.

Only 3/4 ? :)

>> and from my experience communication is the
>> greatest challenge,
>> and the major bottleneck.
>
> There is no need for this to be true.

This again depends (among other things) on the characteristics of the
project. There are projects that can be spec'ed perfectly in half an
hour on a single A4, yet take man-years to implement (think:
ANSI-compilaint C++ compiler for the entire PIC range, with a specified
level generated code efficiency - no, C++ is not impossible, just very
very difficult). OTOH there are projects that will take forever to get
the specs right, yet can be implemented in an afternoon (think:
something with (only) a lot of user interaction).

> > Therefore, the ideal candidate
> > would have to be a local resident.

Is locality more important that his/her level of expertise? Your call,
your party, your money :)

> All in all you need to understand that your relationship with
> a consultant
> will be different from that with an employee or contractor

I think this is good terminology. Let's use 'consultant' for the type
that does the work off-premises, on his own schedule, works on multiple
projects, has his own tools, etc. Use contractor for someone you hire by
the day, week or month, who will work on your premises, with tools you
provide, and on your project only.

I guess the OP wants a contractor. Whether that is wise is up to him.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\04\20@112333 by olin_piclist

face picon face
Wouter van Ooijen wrote:
> But of course, when the customer asks for the source, and especially
> when he mentions that he wants to be able to make modifications, you
> must keep that in mind when writing the code.

Why?  It's OK to write sloppy code when you think nobody else will ever see
it?

I always write code as if someone else will need to understand it later.  I
think good comments can *only* be written with that mindset.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\20@112535 by olin_piclist

face picon face
Olin Lathrop wrote:
> This is one reason I put so much source code of my PIC development
> environment on the web (http://www.embedinc.com).

Oops.  That should have been http://www.embedinc.com/pic.

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\20@112640 by Andrew Warren

face
flavicon
face
Olin Lathrop <RemoveMEpiclistTakeThisOuTspammit.edu> wrote:

> I disagree with Andrew a bit here.  While a user's manual would
> certainly be helpful, I've never seen one available that early in
> product development. I've also very very rarely (can't actually think
> of a case, but I may have forgotten one) seen a customer spec that was
> sufficient to provide a fixed price quote from.

Olin:

Actually, maybe we don't disagree.

Like you, I've rarely seen a customer spec that was sufficient...
Which on the surface seems strange, since the customer has probably
been thinking very intently about his product for a long time.  Why
can't he describe it in a useful way?  I think it's because he's
hampered by his (understandable, else he wouldn't be hiring me) lack
of engineering knowledge, coupled with an (also understandably)
wrongheaded idea of what an Engineering Spec spec should look like.  

You're right: no one ever writes a complete, well-thought-out User's
Manual that early.  What I'm saying, though, is that they probably
SHOULD, and give that to me instead of a clumsily-written "spec",
since (in no particular order):

   a) the User's Manual is a familiar format, so they already know how
   to structure it,

   b) because they're writing for presumably-dumb users, they'll explain
   things V-E-R-Y  C-L-E-A-R-L-Y, using small words and carefully
   describing EVERYTHING,

   c) since they've presumably been imagining how their product will
   work for a long time, it'll be easy for them to write the manual --
   it describes the product in exactly the same terms and from the same
   perspective as they've already been thinking of it,

   d) it just happens to have exactly the right level of detail for a
   functional spec,

   e) because even completely non-technical people can understand a
   User's Manual, they can show it to their salesmen, target users,
   etc., and refine it before they even call me,

   f) again because it's so easy to understand, ambiguity and omissions
   will be easy to spot and correct,

   g) it has exactly the right scope -- it quite naturally avoids
   discussing how the thing is implemented and instead describes only
   what it does,

   h) they'll have to write a manual eventually, anyway, so they may as
   well write it first.

As I said earlier, there will naturally be certain internal
requirements that wouldn't normally appear in a User's Manual, so
those would have to be described separately.  

I agree with you that client and consultant will always have to
discuss and edit the spec before work begins, regardless of what form
the spec actually takes.  My only point is that of all the possible
ways for a client to communicate a description of his product to me,
writing it as a User's Manual is likely to give us the largest
headstart on the product's development.  

-Andrew, who's surprised that he's had so much to say on this topic
(and a little annoyed that he's been unable to say it more concisely)

=== Andrew Warren - spamBeGonefastfwdspamBeGonespamix.netcom.com

2005\04\20@113456 by Herbert Graf

flavicon
face
On Wed, 2005-04-20 at 08:20 -0500, Dave VanHorn wrote:
> IMHO too many coders fail to remember that when you are writing code
> for a customer, IT BELONGS TO THE CUSTOMER.

I'm not sure why you'd say that, it is NOT a universal thing. Whether or
not the customer owns the code is up to the agreement between the coder
and the customer. There are many times when the agreement ends up being
the code DOESN'T belong to the customer, just the right to use it.

Look at most software you buy, you don't own the code, just the right to
use the compiled result in a limited way.

> They write in ways that make it impossible for anyone else to follow
> them, which I guess is supposed to enhance their job security.

This is just foolish, since it hinders other people but more importantly
the coder themselves. A coder that did something like this would
certainly no longer be on my list.


-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\04\20@113743 by Dave VanHorn

flavicon
face
At 10:24 AM 4/20/2005, Olin Lathrop wrote:
>Wouter van Ooijen wrote:
>>But of course, when the customer asks for the source, and especially
>>when he mentions that he wants to be able to make modifications, you
>>must keep that in mind when writing the code.
>
>Why?  It's OK to write sloppy code when you think nobody else will ever see
>it?
>
>I always write code as if someone else will need to understand it later.  I
>think good comments can *only* be written with that mindset.


It comes in handy, years later, when you are asked to modify
something you wrote, as well.


2005\04\20@114256 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Wouter van Ooijen" <TakeThisOuTwouterEraseMEspamspam_OUTvoti.nl>
Subject: RE: [OT]: Hiring a PIC consultant/developer

> I think this is good terminology. Let's use 'consultant' for the type
> that does the work off-premises, on his own schedule, works on multiple
> projects, has his own tools, etc. Use contractor for someone you hire by
> the day, week or month, who will work on your premises, with tools you
> provide, and on your project only.

You need to be a little careful here.  As I understand it (and IANAL), what
is described here as a contractor would be called an employee in the U.S.
To call someone a contractor for tax purposes, you need to differentiate him
from an employee, and working on your premises, on your schedule, with tools
you provide, and on your project only are all tests the IRS uses to define
an employee.  I think there are others, but before you do this you better
chat with your friendly favorite labor attorney.  This assumes OP is in the
U.S. and I have no data to indicate that he is.  From some of Wouter's
earlier comments, though, it sounds like the Netherlands isn't all that
different.

--McD


2005\04\20@120327 by Wouter van Ooijen

face picon face
> > But of course, when the customer asks for the source, and especially
> > when he mentions that he wants to be able to make modifications, you
> > must keep that in mind when writing the code.
>
> Why?  It's OK to write sloppy code when you think nobody else
> will ever see it?

I never said 'sloppy code'. The point is that what is good depends on
the context. When I write example code for a first-year student I put in
comments that would be outight silly when the code was intended to be
read by a seasoned programmer. Likewise I will treat code that is
intended for a customers eyes differently from code that is for my eyes
only.

> I always write code as if someone else will need to
> understand it later.  I
> think good comments can *only* be written with that mindset.

Good comments can not be written without a specific audience in mind
(same for slecting code constructs, same for selecting the programming
language).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\04\20@120424 by Alan B. Pearce

face picon face
>-Andrew, who's surprised that he's had so much to say on this topic
>(and a little annoyed that he's been unable to say it more concisely)

You may feel it is less than concise, but I think you have done it "about
right". They are certainly going into my archive file.

The only comment I would make about having a user manual as the "design
spec" is that there will be things in the hardware side of the design which
will not appear in the user manual - "item X rotates at Y rpm, generating 4
interrupts per rev, and within so many microseconds of the 3rd interrupt
from the index event Z needs to be handled" type information. I guess this
is the sort of info that would come out in the initial contact between
contractor and customer in your scenario, and from this the "contract spec"
is derived.

2005\04\20@120722 by Alan B. Pearce

face picon face
>You need to be a little careful here.  As I understand it (and IANAL), what
>is described here as a contractor would be called an employee in the U.S.
...
>From some of Wouter's earlier comments, though, it sounds like the
>Netherlands isn't all that different.

The UK is certainly attempting to make its way towards the US model, and it
has created quite some outcry at times.

2005\04\20@124431 by William Chops Westfield

face picon face
>>> and from my experience communication is the greatest challenge,
>>>
One of the interesting things about having worked with a large number of
consultants, contractors, remote development sites, and full-time
telecommuters is seeing the remarkable variety of communications styles
and skill levels.  Some people manage to project a very solid "presence"
via email and etc, while others sort of lose touch and nearly disappear.
I'm working with a guy now who does the "cell phone and blackberry"
thing
extremely well...

But there has to be a MATCH of communications styles.  A manager who
lives by the phone call, and an engineer who lives by eMail, are not
likely to be very happy with each other.

BillW

2005\04\20@125453 by William Chops Westfield

face picon face
On Apr 20, 2005, at 9:04 AM, Alan B. Pearce wrote:

> The only comment I would make about having a user manual as the "design
> spec" is that there will be things in the hardware side of the design
> which
> will not appear in the user manual

A lot of tasks one might use a consultant for don't actually reach
the 'user' level, and so a user manual is unlikely.  "Port the ftp-based
file archiving system to the new version of Galaxy"...

Writing a user manual isn't EASIER than writing a functional spec, and I
think Andrew may be overestimating the quality of many user manuals, but
the point about it being a familiar format that may be needed anyway is
very good...

BillW

2005\04\20@130346 by Dave VanHorn

flavicon
face
At 10:34 AM 4/20/2005, Herbert Graf wrote:
>On Wed, 2005-04-20 at 08:20 -0500, Dave VanHorn wrote:
> > IMHO too many coders fail to remember that when you are writing code
> > for a customer, IT BELONGS TO THE CUSTOMER.
>
>I'm not sure why you'd say that, it is NOT a universal thing. Whether or
>not the customer owns the code is up to the agreement between the coder
>and the customer. There are many times when the agreement ends up being
>the code DOESN'T belong to the customer, just the right to use it.

The first part said "When you are writing code for a customer".


I know you can find cases where the customer wouldn't have rights to
the source, but that's not the point.
The customer has an interest, wether he knows it or not, in the code
being maintainable.
What if I get hit by a bus, or have another round of pancreatitis and die?

My customers can take the code I wrote for them, and have any
competent coder work on it.



2005\04\20@130750 by Dave VanHorn

flavicon
face

>
> > I always write code as if someone else will need to
> > understand it later.  I
> > think good comments can *only* be written with that mindset.
>
>Good comments can not be written without a specific audience in mind
>(same for slecting code constructs, same for selecting the programming
>language).

I'd agree with that.

When you're writing a tutorial, you want to explain what the code is doing.
When you are commenting a real project, I want to see WHY you're
doing what you are, and if it's important, why you didn't do
something else, especially if that was the obvious approach.

Comments like

Inc TEMP        ;TEMP=TEMP+1

aren't much use in real code, but

inc TEMP        ; so that it will fail the next test

are actually useful.



2005\04\20@134330 by Vitaliy
flavicon
face
>>I don't get it - it's documentation - how can it be 'not cheap'. If it
>>already exists, just make a copy. Even several hundred pages of copies
>>isn't
>>very costly compared to other costs in a project like this. As to being
>>not
>>public domain - if you can't trust your consultant for confidentiality in
>>such matters, you've hired the wrong consultant.
>
> For a third party to "just make a copy" of a standard would likely involve
> a copyright violation.

Spehro,

You are absolutely correct.  We order a lot of standards from ISO, and they
are delivered with *my name* on every page!  To give you an idea of the
cost, we paid $50 for a 7-page document.  SAE's standards also tend to be
quite expensive.

Best regards,

Vitaliy

2005\04\20@135949 by Wouter van Ooijen

face picon face
> From some of Wouter's
> earlier comments, though, it sounds like the Netherlands
> isn't all that different.

Much worse! The rules are unclear, changing each year, and there are
different rules and/or interpretations to decide wehther you are to be
considered and employee for
- income taxes
- public insurance tax
- being insured for various risks
etc

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\04\20@142742 by Wouter van Ooijen

face picon face
> Comments like
>
> Inc TEMP        ;TEMP=TEMP+1
>
> aren't much use in real code, but

They would be usefull if this asm line is one of the three assembler
lines in an otherwise C program, probably to be read by C programmers
only. But in that case the comment should of course be "TEMP++".

> inc TEMP        ; so that it will fail the next test
> are actually useful.

That still depends. Put yourself in the position of the reader. He reads
'inc TEMP'. He will understand this up to some level. You comment is
most usefull if it states something around that level (to reassure him),
probably a little bit higher (to extend his understanding).

1) A C programmer sees 'inc TEMP'. He probably understands that this
modifies the TEMP variable, but he does not know exactly how. So a
"TEMP++" comment would be most usefull.

2) A asm programmer who is not very familiar with the use of the TEMP
variable might benefit from the "so that it will fail next time"
comment. A "TEMP++" comment would degrade the readability for this
reader.

3) An asm programmer who *is* familiar with the semantics of this TEMP
variable knows that increasing it will cause something to fail next
time. But he might wonder why you want it to fail. So the comment should
be "CRC error detected" or "time slot exceeded". In this case the "so
that it will fail next time" comment that was so usefull in the previous
case would be superfluous and hinder the reader.

So I keep saying: you need to know your adience before you can decide
which comment is good (this extends to all qualifications on all kinds
of texts).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\04\20@144644 by Mauricio Jancic

flavicon
face
Regarding standars...

I think you can copy them for your internal company use, at least you should
be able to...
Is that wrong?

Mauricio Jancic
Janso Desarrollos - Microchip Consultants Program Member
RemoveMEinfospamTakeThisOuTjanso.com.ar
http://www.janso.com.ar
(54) 11 - 4542 - 3519


2005\04\20@150042 by Spehro Pefhany

picon face
At 03:46 PM 4/20/2005 -0300, you wrote:
>Regarding standars...
>
>I think you can copy them for your internal company use, at least you should
>be able to...
>Is that wrong?

So, if I have a company with 500 employees, I should be able to buy just
one copy of Microsoft Office and make further copies "for internal use"?

>Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffEraseMEspam.....interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com




2005\04\20@154018 by Bradley Ferguson

picon face
On 4/20/05, Spehro Pefhany <EraseMEspeffspaminterlog.com> wrote:
> At 03:46 PM 4/20/2005 -0300, you wrote:
> >Regarding standars...
> >
> >I think you can copy them for your internal company use, at least you should
> >be able to...
> >Is that wrong?
>
> So, if I have a company with 500 employees, I should be able to buy just
> one copy of Microsoft Office and make further copies "for internal use"?

Mums the word. *wink* *wink* Say no more.

Actually, we have downloaded PDF standards that we aren't supposed to
(and don't) email or network.  If you want to read it you have to go
pick up the official copy in QA (to be returned).  Has the company
name, copyright, and licensing information on the bottom of every
page.

Of course, that doesn't mean that some companies don't copy standards
and fax them to customers and use unlicensed software.  It just seems
if you have any property worth protecting you'd want to be on the up
and up with your use copyrighted or intellectual properties.

Bradley

2005\04\20@160845 by Mauricio Jancic

flavicon
face
> > So, if I have a company with 500 employees, I should be able to buy
> > just one copy of Microsoft Office and make further copies
> "for internal use"?

Let's picture this. I buy a standard to be used in the production of product
X. Product X has a given number of design phases, overlapping each other, so
I have 4 teams working at the same time.

I don't see why I have to buy 4 copies of the standard...

Let's don't give software nor Microsoft as an example, that's another chat
and we don't want to go there.

But talking about the standards, I think that you buy them to use them
directly on your products. If your are going to have and engineering meeting
with all the teams sit on the same table to carefully read the standard and
defines the product spec's, will I have to buy (4*team_members) copies?

I really don't like that, whether it's correct or not... And again, lets
keep software out of the conversation.

Regards,

Mauricio Jancic
Janso Desarrollos - Microchip Consultants Program Member
RemoveMEinfoEraseMEspamEraseMEjanso.com.ar
http://www.janso.com.ar
(54) 11 - 4542 - 3519

2005\04\20@162811 by Bradley Ferguson

picon face
On 4/20/05, Mauricio Jancic <RemoveMEinfospam_OUTspamKILLspamjanso.com.ar> wrote:
{Quote hidden}

It's some entity's copyrighted work.  Well, I think it would be in a
standard best interest to be free, that is not the way it is done.

If you take a class, you are expected to purchase the book (new or
used) or borrow the physical book from the library.  There are some
issues of fair-use if you are only using a small portion--a passage,
but I'm unsure of the details of that.

Would it seem fair to simply buy a single book for the entire class
and hand out photocopies?

And to put it in perspective, if you think that your 4*team_members
engineers are doing anything worthwhile, the cost of the standard is
likely to dwarf the cost of your engineering time.  You'd be
penny-wise and pound-foolish, but it seems most bureaucracies are.  So
what if you have to spend an extra few thousand dollars for a several
thousand dollar per hour meeting.  Which is one of many meetings in a
several hundred thousand dollar development project.

Additionally, if you needed a lot of copies, usually you can get
something similar to a site license so that everyone at your site is
allowed a copy.  As with all licensing, this depends on the copyright
holder and the size of your site.  You can also, often times, purchase
access to the entire library that the standards organization offers.
It depends on your organization if this is worthwhile.

Bradley

2005\04\20@181844 by Vitaliy

flavicon
face
Guys, please change the subject.

----- Original Message -----
From: "Bradley Ferguson" <RemoveMEbradleyeeTakeThisOuTspamspamgmail.com>
To: "Microcontroller discussion list - Public." <EraseMEpiclistspamspamspamBeGonemit.edu>
Sent: Wednesday, April 20, 2005 1:28 PM
Subject: Re: [OT]: Hiring a PIC consultant/developer


{Quote hidden}

> --

2005\04\20@220738 by Vitaliy

flavicon
face
Hello List,

I'd like to thank everyone for their time and for sharing their wisdom.  I
cannot possibly address every point in every post, however I assure you that
I read them all and I sincerely appreciate your feedback.

Let's get this out of the way:

Olin Lathrop et al wrote:
> I agree with Bob that Vitaliy needs a contractor, not necessarily because
> that's what's really needed, but because he can't get comfortable with a
> consulting arrangement.  In particular he is not willing to trust a
> consultant's professionalism and is therefore not willing to let go of the
> details.  Without a change in mindset, this would not work well neither
> for
> him nor the consultant.

I consider myself a reasonably open-minded person.  In my original post, I
said that we've never hired a consultant before, and that I'm seeking advice
from the list members.  Obviously, I have opinions based on previous
experience with other types of outsourcing, but since I'm seeking advice it
should also be obvious that I am willing to change them.  I made some
statements which some of the list members strongly disagree with, and I
guess I should have prefixed them with "I may be wrong, but I think that..."
or "In my opinion, ..."  The problem is, *most* of what I say is just my
opinion.  There are exceptions - I have certain convictions, which I am sure
(for whatever reason) are correct.  In such rare instances, I try to make it
clear that that is the case.

So, if you catch me making a statement which you believe is utterly wrong,
add the appropriate prefix.  ;-)  With this issue out of the way, let's talk
about some of the points you made (paraphrased by yours truly):

1. Client must be able to trust the consultant. (Wouter van Ooijen et al)
I agree with this point (in general).  No amount of legal paperwork or
supervision is a guarantee of success, and may actually impede the progress.
However, this statement assumes that both parties are good, honest,
professional people.  I had the misfortune of working with people who were
neither honest nor professional, so I have an instrinctive urge to "cover my
butt" - just in case things go wrong.

2. Most consultants like to have the freedom to choose their work schedule
and location.
Hey, me too!  :)  It was useful to hear this from a number of people,
because I was under the impression that some may actually prefer to work
on-site.

3. One should not underestimate the importance of functional specifications.
(Andrew Warren)
Agree wholeheartedly.

3b. Developer should discuss the requirements with the customer, and write
the spec himself. (Olin Lathrop).
Developer may not have the same level of expertise in a particular area, so
providing a complete spec may speed up the progress considerably.

4. Geographic location of the candidate is of no importance (Gerhard
Fiedler).
I agree that hiring a local candidate does not guarantee there will be
seamless communication, and it probably shouldn't be a requirement.  But, I
can see great benefits in having the ability to meet with the consultant
face-to-face.

5. Expecting a consultant to be 100% dedicated to the project is not
realistic.
Ok, I was wrong.  Or, rather, you misunderstood me!  ;)
I have no problem if the consultant is providing support to existing
customers, nor do I mind if she starts another project two weeks before our
project is completed.  However, I think that at all times there should only
be one project that is the #1 priority.  What I don't want is to have the
developer work on our project 1/2 or 1/3 of the time, trying to meet other
projects' deadlines at our expense.
Note that this doesn't necessarily have to conflict with what some of you
said regarding setting the due dates and not worrying about how or when the
developer is working on the project.

6. Requiring that a consultant work on premises may pose legal problem (also
see #2).
This is something to talk to our attorney about.  I am familiar with the "20
IRS questions", however the guidelines are somewhat vague.

7. Expecting real-time feedback from consultant is unrealistic (Olin
Lathrop).
Perhaps.  However, if a project is complicated, there must be sufficient
feedback.  The meaning of "sufficient" depends on how much time and effort
we would be willing to throw away if the consultant has to redo something
because he misunderstood the requirements.  If we catch the problem the next
day, the cost of correcting it may be significantly less than if we first
noticed the error two weeks later.

CONCLUSION

Again, thank ya'll for taking the time to answer my questions.  We're in the
process of polishing/expanding functional requirements at this time, once
the spec is ready I will post a complete project description here, to see if
there are any takers.  To give you an idea, the project involves writing
firmware for a multi-protocol converter (OBDII to RS232).  The company is
located in Phoenix, Arizona.

I don't want to leave you with a bad impression.  It is not my desire to
micromanage or put unnecessary constraints on anyone.  I too want to be
trusted, and like the freedom to make my own decisions.  Some of the more
controversial statements were made from the point of view of a "devil's
advocate", in order to get the answers to the "what if" questions.  I think
my views on the subject are well aligned with those of most people who
replied to this post.

My apologies for the length of this reply.  More questions to come later.
:)

Best regards,

Vitaliy

2005\04\21@080648 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

>> From some of Wouter's earlier comments, though, it sounds like the
>> Netherlands isn't all that different.
>
> Much worse! The rules are unclear, changing each year, and there are
> different rules and/or interpretations to decide wehther you are to be
> considered and employee for
> - income taxes
> - public insurance tax
> - being insured for various risks
> etc

That's probably because in Europe, employees have more legal benefits.
However, I know many software "consultants" in the USA that are nothing
more than temporary employees, measured by the IRS standards. This possibly
may have changed recently a bit, with the wave of cheap outsourcing to
India and other places, but there still are many. This is probably more
prevalent in the software industry than in others. Not sure why that is --
maybe worse planning?

Gerhard

2005\04\21@082829 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Gerhard Fiedler" <listsSTOPspamspamspam_OUTconnectionbrazil.com>
Subject: Re: [OT]: Hiring a PIC consultant/developer


> That's probably because in Europe, employees have more legal benefits.

As Vitaliy pointed out, the rules aren't all that clear in the U.S., either.
And while there are a few obvious benefits that European employees get that
are lacking in the U.S., we have a government that is amazingly effective at
creating bureaucratic overhead, so I suspect the costs to the employer are
pretty similar.

There is also a pretty big difference in the U.S. from state to state, and
the state rules are often pretty arcane.  Frequently they fall pretty hard
on medium sized businesses.  In some states, an employee can cost 5 times
his salary for some businesses.  Some of this is taxes, but a surprising
amount of the cost is just paperwork.  This makes for a pretty strong
incentive to use contractors.

> However, I know many software "consultants" in the USA that are nothing
> more than temporary employees, measured by the IRS standards. This
possibly
> may have changed recently a bit, with the wave of cheap outsourcing to

It is still pretty common, especially in the software space.  It kind of is
a bad deal.  Most likely you can get away with a lot.  But if you get
caught, it gets REALLY expensive.

--McD


2005\04\21@090042 by olin_piclist

face picon face
Gerhard Fiedler wrote:
> That's probably because in Europe, employees have more legal benefits.
> However, I know many software "consultants" in the USA that are nothing
> more than temporary employees, measured by the IRS standards. This
> possibly may have changed recently a bit, with the wave of cheap
> outsourcing to India and other places, but there still are many. This
> is probably more prevalent in the software industry than in others. Not
> sure why that is -- maybe worse planning?

This is another difference between consultants and contractors.  Contractors
are temporary employees and are paid directly by the company on a 1099 if
they think they can get away with it, or on a W2 if not.  Consultants are
usually incorporated and thus are suppliers instead of employees to the
company.  The company pays the consultant's corporation as a regular
business to business payment.  There is no issue of employment hassles for
the company.  The consultant is paid as an employee by his own corporation.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\23@002033 by Mike Singer

picon face
Plato is my friend …

Olin wrote:> > This is one of my areas of concern.  We've outsourced some projects> > before, and from my experience communication is the greatest challenge,> > and the major bottleneck.> > There is no need for this to be true.
So you think in his experience, communication was not the greatest challengeand the major bottleneck with the project. Perhaps he is just ..eh..fooling us.Great way to start discussing a project with the potential customer ;-)
> > Therefore, we would like to be able to give> > and receive feedback in real-time.>> You definitely need to drop this thinking.  Who, the customer? He is just describing his real life experience.What _MUST_ he drop at this point? He doesn't look as a stupid neededto be taught this way. His thoughts are clear and consistent andlanguage is perfect (as for me).
> Most consultants will run away screaming when they here this.  Let them run and scream – when they will need a job they'll sit quietlike mouse. Wait and choose for the better candidate. The world isgetting a bit different now. Average US EE consultant is not betterthan one from Moscow, st.Petersburg, Kharkov or Dnepropetrovsk in myopinion, of course.
> > Therefore, the ideal candidate would have to be a local resident.> > Again, not necessary, ..
Indeed.
> All in all you need to understand that your relationship > with a consultant will be different …
Perhaps he is able to decide on his own what he needs and what he needn't?
> Last year at Masters there were over 300 consultants world> wide, with only 35 being gold level (We have been gold level > for something like 5 years in a row).  Just trying to imagine what would be the bronz level reply, a torrentof vulgar invective?

Vitaliy replyed:
> I consider myself a reasonably open-minded person.  And extremely tolerant, unlike those who unsubscribed after beingtreated this way.
Regards,Mike
PS Sorry for zero level technical input

2005\04\23@085852 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Mike Singer" <spamBeGonepiclist.allSTOPspamspamEraseMEgmail.com>
Subject: Re: [OT]: Hiring a PIC consultant/developer


> Just trying to imagine what would be the bronz level reply, a torrentof
vulgar invective?

I think that is a little unfair.

Of course, the customer is always right.  However, Vitaliy isn't Olin's
customer, and Olin is trying to give him some honest input.  Anyone who has
been around here a while will recognize that Olin is sometimes a little more
blunt than the average bear, some would say "honest", but I certainly didn't
see any attacking going on.

Having worked with a lot of Dutch guys in the past, who tend to be
ruthlessly honest, perhaps I'm a little more tolerant of Olin's brusqueness
than most. Olin's Massachusetts address doesn't sound like it comes from
.nl, but he sounds a lot like a Dutch guy.  Olin is one of the more
knowledgeable folks on this list, and I for one appreciate that he doesn't
feel compelled to sugar coat his responses.

If Vitaliy wants a contractor on site where he can watch every step, then as
the customer, he has that right.  I think Olin was trying to tell him that
in asking for that, he is asking to pay top dollar for a third rate
consultant.  He is also asking for a lot of schedule uncertainty.  Having
understood that (unfortunately without quantitative measures), Vitaliy now
has more information on which to base his decisions.

Sadly, programmers in general have an issue with communicating things they
know.  In a more common situation, managers tend to ask for unreasonable
schedules.  Programmers know that means higher cost and more bugs, but
managers believe that the compressed schedule will help constrain costs.
The industry has good data to show the programmers are right, but we rarely
present that data in a clear fashion.

Unfortunately, I know of no data to support some of Olin's contentions, but
I suspect he is right.  Some things are fairly obvious.

Clearly, if you can't come up with a good spec, then decisions will have to
be made during development.  Those decisions will take time, and that will
mean downtime for the consultant.  By having the consultant onsite, you are
guaranteeing that you will have to pay full price for that downtime.  If the
consultant has other work, then you don't need to pay for all of that
downtime.

Further, having the consultant right there where you can keep changing the
spec becomes an excuse for a bad spec in the first place, and an expectation
on the consultant's part that there will be a lot of changes.

Also, by expecting 100% commitment, you are preventing the consultant from
lining up the next project, so he has to recover the expected post-project
downtime from you as well.

This is good data for Vitaliy, though.  Now he knows that if the consultant
is not asking a terribly high price for the project, then that consultant
probably doesn't know what he is doing.

--McD


2005\04\24@192302 by Vitaliy

flavicon
face
----- Original Message -----
From: "John J. McDonough" <KILLspammcdspamBeGonespamis-sixsigma.com>
> Of course, the customer is always right.

No, not always.  This cliche has been used so many times that few people
question validity of the statement.  Sometimes the customer doesn't know
what's good for him.  :)

> been around here a while will recognize that Olin is sometimes a little
> more
> blunt than the average bear, some would say "honest", but I certainly
> didn't
> see any attacking going on.
[snip]
> nl, but he sounds a lot like a Dutch guy.  Olin is one of the more.
> knowledgeable folks on this list, and I for one appreciate that he doesn't
> feel compelled to sugar coat his responses.

Olin made some good points, and I am sincerely grateful to him for sharing
his knowledge and experience, and his honestly.  However, let me be frank in
return and say that sometimes I wish that Olin would attack the idea and not
the person.  There is a big difference between "sugar coating" a response
and just being polite.  Give the person you're talking to the benefit of a
doubt, instead of assuming right away that he's an idiot.

> Sadly, programmers in general have an issue with communicating things they
> know.  In a more common situation, managers tend to ask for unreasonable
> schedules.  Programmers know that means higher cost and more bugs, but
> managers believe that the compressed schedule will help constrain costs.
> The industry has good data to show the programmers are right, but we
> rarely
> present that data in a clear fashion.

I believe the book most often cited by programmers when they're trying to
convince their managers that the schedule is unrealistic, is Brook's "The
Mythical Man-Month."

Best regards,

Vitaliy

2005\04\24@200710 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Vitaliy" <EraseMEvitaliyspamEraseMEmaksimov.org>
Subject: Re: [OT]: Hiring a PIC consultant/developer


> I believe the book most often cited by programmers when they're trying to
> convince their managers that the schedule is unrealistic, is Brook's "The
> Mythical Man-Month."

Well, Brooks probably describes it best, and is a favorite among
programmers.  But Barry Boehm (an incredibly boring read) and Capers Jones
(never a favorite among programmers) have the data.

--McD


More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...