On Sat, 26 May 2012 23:22:22 -0700 Grant <emailgr...@gmail.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.mckin...@gmail.com
