Re: [gentoo-user] {OT} hire a programmer or company?

[Alan McKinnon]

On Sat, 26 May 2012 23:22:22 -0700
Grant <emailgrant@×××××.com> wrote:

> > Extensive testing, on the other hand, is something a team should do.
> > Sure, the lone programmer can write you some unit tests and conduct
> > a system test, but testing itself is a profession of its own and
> > should be done by a second person with the relevant training.
> >
> > But in the end, these issues a minor. It really boils down to whom
> > you trust more. Ask for references, look at their previous work,
> > talk to them, etc.
>
> Can you tell me what sort of positive and negative things to watch
> out for?

Here's a quick test that I've never seen fail:

When you get the quote stage and are discussing numbers, ask for their
estimate of how long it will take to produce a beta. Let's assume they
say 6 weeks. You say you need it in 4. Can they do it?

If they say yes in a way shape or form, do not use them. Go onto the
next one.

The reason is that development takes as long as it takes and the old
adage of "the production of a baby takes 9 months no matter how many
women are assigned to the task". A mature dev or team know this, stand
by their estimates and politely won't be swayed.

Everything else is common sense, and the best recommendation is word of
mouth from someone you already trust

>
> > All things being equal, paying 1*x instead of 2*x gives you the
> > chance to pay another 1*x to a second developer if things don't
> > work out with the first one. ;-)
>
> Once I need more than one developer (which could come sooner rather
> than later due to the availability of these guys) am I likely to
> struggle managing them?  I've read a bit about "Agile" software
> development and I plan to read a lot more.  Is that the way to go?

Agile is nothing more than the way a team organizes itself so they can
keep on top of things. If it were software, it would be a neat add-on
like bash-completion (without it you still have all of bash). When
Agile works out, it works really really well but it takes discipline
from the programmers. 

All Agile methods have some way of bringing constant feedback to the
devs so they can assess how they are going and easily deal with the
inevitable mistakes. It also lets them experiment a bit with different
technologies and change implementations without upsetting the whole
apple cart.

Agile is subject to much buzz-wording just like everything else in our
field :-(   A mature dev team who know what they are doing can use it
correctly and well.So be sure to look for real evidence that it's being
used, not tossed about as a cute buzz-word

We use Scrum at work and for us it works well - we get to concentrate on
the task at hand and can spot bugs and show-stoppers quite quickly. But
it's very important to observe that it's not Scrum that magically makes
all things good all by itself - it works because we know what we are
doing and Scrum is just giving us the right information at the right
time so we can keep on track. There are potentially 100s of ways to do
that, but without out basic skills in place Scrum couldn't help at all.


>
> Would hiring a company make management a non-issue from my
> perspective?

Not really, you may just end up have to manage the managers that manage
the devs :-)

A good software house is like a good builder - some you can leave to
get on with it even though the truck is shabby (like the chaps that
redid my bathroom). Some have flashy shiny trucks but are still short
on clue (like the chaps who first quoted my bathroom and didn't get the
job)

-- 
Alan McKinnnon
alan.mckinnon@×××××.com