Gentoo Archives: gentoo-user

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] {OT} hire a programmer or company?
Date: Sun, 27 May 2012 08:32:12
In Reply to: Re: [gentoo-user] {OT} hire a programmer or company? by Grant
1 On Sat, 26 May 2012 23:22:22 -0700
2 Grant <emailgrant@×××××.com> wrote:
4 > > Extensive testing, on the other hand, is something a team should do.
5 > > Sure, the lone programmer can write you some unit tests and conduct
6 > > a system test, but testing itself is a profession of its own and
7 > > should be done by a second person with the relevant training.
8 > >
9 > > But in the end, these issues a minor. It really boils down to whom
10 > > you trust more. Ask for references, look at their previous work,
11 > > talk to them, etc.
12 >
13 > Can you tell me what sort of positive and negative things to watch
14 > out for?
16 Here's a quick test that I've never seen fail:
18 When you get the quote stage and are discussing numbers, ask for their
19 estimate of how long it will take to produce a beta. Let's assume they
20 say 6 weeks. You say you need it in 4. Can they do it?
22 If they say yes in a way shape or form, do not use them. Go onto the
23 next one.
25 The reason is that development takes as long as it takes and the old
26 adage of "the production of a baby takes 9 months no matter how many
27 women are assigned to the task". A mature dev or team know this, stand
28 by their estimates and politely won't be swayed.
30 Everything else is common sense, and the best recommendation is word of
31 mouth from someone you already trust
33 >
34 > > All things being equal, paying 1*x instead of 2*x gives you the
35 > > chance to pay another 1*x to a second developer if things don't
36 > > work out with the first one. ;-)
37 >
38 > Once I need more than one developer (which could come sooner rather
39 > than later due to the availability of these guys) am I likely to
40 > struggle managing them? I've read a bit about "Agile" software
41 > development and I plan to read a lot more. Is that the way to go?
43 Agile is nothing more than the way a team organizes itself so they can
44 keep on top of things. If it were software, it would be a neat add-on
45 like bash-completion (without it you still have all of bash). When
46 Agile works out, it works really really well but it takes discipline
47 from the programmers.
49 All Agile methods have some way of bringing constant feedback to the
50 devs so they can assess how they are going and easily deal with the
51 inevitable mistakes. It also lets them experiment a bit with different
52 technologies and change implementations without upsetting the whole
53 apple cart.
55 Agile is subject to much buzz-wording just like everything else in our
56 field :-( A mature dev team who know what they are doing can use it
57 correctly and well.So be sure to look for real evidence that it's being
58 used, not tossed about as a cute buzz-word
60 We use Scrum at work and for us it works well - we get to concentrate on
61 the task at hand and can spot bugs and show-stoppers quite quickly. But
62 it's very important to observe that it's not Scrum that magically makes
63 all things good all by itself - it works because we know what we are
64 doing and Scrum is just giving us the right information at the right
65 time so we can keep on track. There are potentially 100s of ways to do
66 that, but without out basic skills in place Scrum couldn't help at all.
69 >
70 > Would hiring a company make management a non-issue from my
71 > perspective?
73 Not really, you may just end up have to manage the managers that manage
74 the devs :-)
76 A good software house is like a good builder - some you can leave to
77 get on with it even though the truck is shabby (like the chaps that
78 redid my bathroom). Some have flashy shiny trucks but are still short
79 on clue (like the chaps who first quoted my bathroom and didn't get the
80 job)
82 --
83 Alan McKinnnon
84 alan.mckinnon@×××××.com