General Consulting Advice Urgently Needed

[Novice]

Some consultants - or the consulting bosses who hire them out, if they
work for a larger consultancy - do skirt the truth, or overly
embellish, or lie. It's not an ethical or productive thing to do.

It's always, IMO, abundantly clear in a contract as to what you should
be knowledgeable about, and how expert you should be on this thing or
that other thing. And you had best be, because that's the expectation
of the client.

General-purpose Java programmers - even consultants - do not tend to
be experts, and reasonable clients don't expect that. What they do
expect is journeyman competency. Effectively a client in this scenario
wants a contractor who will perform at least as well as someone he
might want to hire FT for the equivalent position. If that equivalent
position is not that of a technical architect or senior analyst, but
of an intermediate programmer, then there is not usually an
expectation that the contractor will have the skills of a senior
architect (the subject of skills-contract needs mismatch is a whole
different topic).

An example of a mistake one could make is to be knowledgeable in JSF
only, say, but make out like Spring MVC or Struts 2 won't be a problem
either. In fact it almost always will be a problem, in the timeframe
of a typical contract, and you'd be dishonest in letting the client
believe that you could do a competent job of Spring MVC.

Which raises an excellent point. Just what GUI is the best way to go
these days? The customer wants a desktop application that will run on
Windows and Mac. I'm mostly familiar with Swing and see no obvious reason
why it couldn't do the job required by the customer. Would Spring MVC or
Struts 2 be better? If so, why?

I'm not sure what the learning curve would be to get up to speed on
Spring or Struts. I just looked at two YouTube videos, one on Spring and
one on Struts and found both pretty dreadful. I'm sure the products are
good but the videos were very poorly produced with very poor presenters
with heavy accents and rather unfocused content. They were chock full of
vague generalities and very skimpy on actual details. I'm optimistic that
there are better tutorials on both subjects and that I can find those
better tutorials if they exist but, so far, I'm not clear on when/why
Spring or Struts would be better than Swing.

This again raises the question of whether customer should pay me my going
rate to learn Spring or Struts or whether I should eat the cost of the
learning?

[ SNIP ]

Based on the other reply to my question, I'm thinking $40/hr is a
good rate to propose, although I'm inclined to mention that it is
negotiable. Or would that be assumed by the customer?

In North America, for general-purpose Java work done by an
intermediate-level programmer, $40/hr is pretty good for your
take-home. I'd add $10-$20 to cover contractor overhead.

Markspace suggests doubling $40/hr to $80/hr. I'm tempted to do that
given the cost of buying benefits and so forth....

My recommendations are based entirely on your stated level of
experience, the probable nature of the work, the fact that your
overhead very likely doesn't include upkeep on a bricks-and-mortar
consultancy office, things like that.

The client will never negotiate _up_.

Your rate covers usual travel, as a rule. We're not talking about air
travel here. If the contract *work* entails travel, that's a different
matter.

The customer is not in the same city as I am. A commute of up to two
hours (one way) would be necessary to go to their offices each time. I'm
hoping he doesn't object to me from working from home regularly but I'm
not sure what the normal expectation is for commuting from out of town.
If I was a fulltime employee, I'd be expected to eat the cost of the trip
and not get paid for the commute time either. As a contractor, would the
customer expect me to bill for time or gas or both?

 

[Lew]

Which raises an excellent point. Just what GUI is the best way to go
these days? The customer wants a desktop application that will run on
Windows and Mac. I'm mostly familiar with Swing and see no obvious reason
why it couldn't do the job required by the customer. Would Spring MVC or
Struts 2 be better? If so, why?

Spring MVC is not a GUI.

Struts is not a GUI.

Did you look at the Web sites for those frameworks? It's obvious that they are not GUIs.

I'm not sure what the learning curve would be to get up to speed on
Spring or Struts. I just looked at two YouTube videos, one on Spring and
one on Struts and found both pretty dreadful. I'm sure the products are
good but the videos were very poorly produced with very poor presenters

Struts is good. I am not pleased with Spring. Most of what Spring offers has been supplanted by standard Java and Java EE annotations.

with heavy accents and rather unfocused content. They were chock full of
vague generalities and very skimpy on actual details. I'm optimistic that
there are better tutorials on both subjects and that I can find those
better tutorials if they exist but, so far, I'm not clear on when/why
Spring or Struts would be better than Swing.

Applea and oranges. They aren't even for the same architecture as Swing.

This again raises the question of whether customer should pay me my going
rate to learn Spring or Struts or whether I should eat the cost of the
learning?

You should at least learn enough to discern what is relevant and what is not before contemplating entering into such a contract.

 

[Martin Gregorie]

So that's not an unreasonable thing to ask, although I shouldn't take it
for granted that he will go for it, right? He might want me to commit
within a day of getting the spec; if that happens and I'm not
comfortable yet, I think I'd be crazy (or foolhardy) to go ahead with
the job.

If the requirements are complete enough to quote on you might do so,
though IME this needs a spec that has enough detail to let you count
programs/processes, assign complexity scores to each so you can estimate
development time for each. Don't forget that you also need to allow for
unit, integration and system testing and also to estimate the schema
complexity if you need to implement or understand a database schema.

OTOH, if the requirements are unclear or don't contain enough detail to
quote on, you might suggest a preliminary contract to rewrite the
requirements into a form that contains enough fixed detail to allow a
fixed price estimate to be made. Its either that or add contingency to
allow cover the amount of woolliness in the requirements.

In any case you'll need to add a clause to cover requirement changes and
their impact on project cost and timescale: these can be considerable of
the client doesn't know what he wants or, equally problematic, hasn't had
any input from the people who'll use the end product: in general a
manager doesn't know what his staff actually do - he only thinks he does.

 

[Roedy Green]

Yes, there is. If a client asks for something unusual, he should
pay for all time involved. Obviously, there can be a fine line here.
I have, on occasion, char

Sure he should pay, but to play fair, you build that cost into the
fixed price bid. It is not his fault if you get in over your head.

He should pay less that he would pay hiring someone experienced, not
more. You should not be rewarded for incompetence.

By analogy think of an incompetent plumber who takes far more time
than one who knows what his he doing. Why should you pay for the
newbie?

You pay to go to school. When you get out, you expect people to pay
you. I think there should be a more gradual transition, when you work
for free, where the customer does you a favour knowing the work may
take way to long or be of inferior quality, or you make take up more
of his time, then to lower wage, eventually to full wage when you can
produce the same quality and speed as the experienced programmers.
--
Roedy Green Canadian Mind Products
http://mindprod.com
For me, the appeal of computer progamming is that
even though I am quite a klutz,
I can still produce something, in a sense
perfect, because the computer gives me as many
chances as I please to get it right.

 

[Gene Wirchenko]

Sure he should pay, but to play fair, you build that cost into the
fixed price bid. It is not his fault if you get in over your head.

Why have a fixed price bid? This just invites trouble if the
spec is not firm. I would go with frequent deliverables.

He should pay less that he would pay hiring someone experienced, not
more. You should not be rewarded for incompetence.

Non sequitur. I can easily imagine someone being hired where
other consideration are more important than immediate technical
competence. Some examples: 1) The person may be local. 2) The person
may know the rest of the client's systems very well and need this
knowledge to be effective. 3) The person is trustworthy. 4) Bragging
rights: "I was Jo[e] NotANewbieNow's first client!"

By analogy think of an incompetent plumber who takes far more time
than one who knows what his he doing. Why should you pay for the
newbie?

Why not? And youmight be paying less.

You pay to go to school. When you get out, you expect people to pay
you. I think there should be a more gradual transition, when you work
for free, where the customer does you a favour knowing the work may
take way to long or be of inferior quality, or you make take up more
of his time, then to lower wage, eventually to full wage when you can
produce the same quality and speed as the experienced programmers.

Mr. Green, you live in British Columbia so you probably heard
about the training wage that the Liberals brought in. That got widely
abused. And you are proposing someone work for free?

Sincerely,

Gene Wirchenko

 

[Novice]

Spring MVC is not a GUI.

Struts is not a GUI.

Did you look at the Web sites for those frameworks? It's obvious that
they are not GUIs.

Sorry, you are absolutely right. I glanced only very briefly - a few
seconds - at the Spring website and clicked on Tutorials; that took me to
the YouTube videos which didn't specifically mention its applicability. I
just stayed in YouTube to look at a Struts video without even examining
the Struts website. Arved's remarks elsewhere in the thread put Struts
and Spring into my head but I didn't review their natures sufficiently. I
was eager to reply as quickly as possible to the client's email and got
ahead of myself.

Struts is good. I am not pleased with Spring. Most of what Spring
offers has been supplanted by standard Java and Java EE annotations.


Applea and oranges. They aren't even for the same architecture as
Swing.


You should at least learn enough to discern what is relevant and what
is not before contemplating entering into such a contract.

Touche! I certainly deserve that for this mistake.

 

[Lew]

Touche! I certainly deserve that for this mistake.

You have an excellent attitude and you will succeed brilliantly in softwaredevelopment.

As for contracting, you are showing wisdom in doing some research first. Iwill add that there are books and articles out there, none of which I can recall at the moment, that specifically address contractor concerns. Mostly the folks in this thread have already recapitulated the high points, though.

I wouldn't overthink the details of how the other guy will react. I've done a fair bit of consulting, both successful and unsuccessful contracts. I've learned that you need to make yourself comfortable with the terms of satisfaction.

How do you know when you've done the job right? Forget the money - you cancharge almost anything, down to telling the guy, "You decide at the end how much I was worth." Focus on the job - what do you need to accomplish, and by when?

If you cannot succeed at that, the money will either not come to you, or will flow from you to the client.

If you do succeed, the money will flood to you.

So insist on complete disclosure of absofuckinglutely everything you need to know about the task, first (well, after signing an NDA). Spend the time up front, for free, to understand exactly what "done" will look like. Don't take the job unless you can do that. By when they want it.

You may not know how to do it yet. That's fine. You just need to know what knowledge you will need. That is, you need to know what questions to ask, not necessarily their answers at this stage. But you know how you learn,and depending on the scope of WHAT THE PROJECT NEEDS, about how hard it will be to learn it. Try not to learn too much for any one project - you should have a pretty good grasp of 75-80% of the technical matters to start. More is good, but any decent programmer can fill in 25% without having to agonize over, "Should I charge for learning?"

OF COURSE YOU SHOULD CHARGE FOR LEARNING!

Read the passage in /The Bonfire of the Vanities/ where the law partner explains how you bill your client for the minute you thought of them just before you teed off on that fourth hole with the dogleg.

Doesn't matter. All that matters is that you complete the project on time in a way that your client likes.

So you'd better have a pretty clear idea of what they like before you bid.

 

[Novice]

You have an excellent attitude and you will succeed brilliantly in
software development.

As for contracting, you are showing wisdom in doing some research
first. I will add that there are books and articles out there, none
of which I can recall at the moment, that specifically address
contractor concerns. Mostly the folks in this thread have already
recapitulated the high points, though.

I wouldn't overthink the details of how the other guy will react.
I've done a fair bit of consulting, both successful and unsuccessful
contracts. I've learned that you need to make yourself comfortable
with the terms of satisfaction.

How do you know when you've done the job right? Forget the money -
you can charge almost anything, down to telling the guy, "You decide
at the end how much I was worth." Focus on the job - what do you need
to accomplish, and by when?

If you cannot succeed at that, the money will either not come to you,
or will flow from you to the client.

If you do succeed, the money will flood to you.

So insist on complete disclosure of absofuckinglutely everything you
need to know about the task, first (well, after signing an NDA).
Spend the time up front, for free, to understand exactly what "done"
will look like. Don't take the job unless you can do that. By when
they want it.

You may not know how to do it yet. That's fine. You just need to
know what knowledge you will need. That is, you need to know what
questions to ask, not necessarily their answers at this stage. But
you know how you learn, and depending on the scope of WHAT THE PROJECT
NEEDS, about how hard it will be to learn it. Try not to learn too
much for any one project - you should have a pretty good grasp of
75-80% of the technical matters to start. More is good, but any
decent programmer can fill in 25% without having to agonize over,
"Should I charge for learning?"

OF COURSE YOU SHOULD CHARGE FOR LEARNING!

Read the passage in /The Bonfire of the Vanities/ where the law
partner explains how you bill your client for the minute you thought
of them just before you teed off on that fourth hole with the dogleg.

Doesn't matter. All that matters is that you complete the project on
time in a way that your client likes.

So you'd better have a pretty clear idea of what they like before you
bid.

I will take your advice to heart, Lew! I would really love to do this
project and have it be a big success but I really do need to understand
exactly what done is, as you put it, so that I am certain I can do it. If
I can't do it, it's better to take this as a learning experience for what
to do differently the next time than to take the project regardles -
assuming it's offered - and make a mess of it.