In my experience developers have tended to build to spec – when it’s done it’s done. A tester can then go in and say does it work, yes. Does it work in the best possible way, maybe not.

I think your monetary point is completely correct. Testers are worth as much as developers. To take it a point further – Do you want developers spending development time on testing?

This would be my main advantage of a dedicated tester. In an agile environment developers simply will not be efficient if they are thoroughly testing their new features.

I guess what I’m saying is that, if you’re a decent manager, you don’t need to sit on anyone. The recruitment and on onboarding of the team should be the same whether the team is domestic or outsourced.

“had to send a really great project manager over there[sic] to sit on them”

is a poor choice and unhelpful, can you clarify what the practical difference between that and

“it will involve a considerable investment of time”

is?

Jason, a good BA is worth his/her weight in gold in a good team, and that’s exactly the point, it’s a team effort and, it seems, unless that team consists entirely of developers, you’re uncomfortable.

I will happily concede that the very best BAs are former programmers with some business experience so that they have a common language when communicating with both “camps”. Can a great developer fill this role? Well I’ve never met a great BA who is also a great developer and (you’re not going to like this) I’ve never met a great developer who’s also a great BA. Surely not everyone in your team can fill both roles…properly?

If I’m hiring developers, I want a great developer who can focus on his work and use his/her creativity and ingenuity to provide a brilliant solution. Just like I don’t want a plumber who also does heart surgery to do my bypass, I don’t want a dev who also does analysis sitting in front of my customer, sorry.

As Dave says in his blog, the only problem with this is that the customer isn’t always available on-demand when the developer needs an answer. They may not even be there for sprint planning.
Then who does the developer ask for clarification?

Will he sit there wasting time waiting for a meeting, just develop what he thinks is right, or maybe ask the BA who’s sitting across the room?

Not sure Jason’s got a chip – more like a whole sack of spuds.

It sounds like you are explaining problems associated with a waterfall approach rather than scrum. My reply was so long it created a blog post for it which can be found here:

http://blog.davehawes.com/post/2010/03/05/Developers-are-only-a-cog-in-a-software-development-project.aspx

Definately a good debating point!

If the team sends a developer to talk to the customer who requested a feature, why _wouldn’t_ we send the developers(s) who will be writing that code? Is it ever any better to send a developer to elicit undertanding from someone we sent to elicit that understanding from the customer? That sounds like Chinese whispers whichever way we paint it. If if that analyst “speaks both languages” they must be a programmer, too – since the developer’s language is code. So why aren’t they writing the code? If your BA doesn’t write code, then they don’t speak the developer’s language, which makes getting precise, executable requirements out of them no easier than agreeing them with a non-technical customer. They are a step in the process that adds no value in that sense. A C# compiler that just gives you more C#

I do not agree that teams should not have testers, but again, the most useful testers are the ones who can write executable tests and automate them. Which makes them a kind of programmer.

Both roles – test analyst and requirements analyst – are one and the same in a test-driven approach. And since a useful analyst in both cases is one who both “speaks the developer’s language” (code) and can write executable tests (programs that test software), we inevitably reach the conclusion that the people most qualified to fulfil those roles are people writing code.

The true purpose of the development process is to translate customer requirements into 1’s and 0’s. Necessary in this is the need to narrow down ambiguity into absolute machine-executable precision. MDA, for example, attempted to “cut out the middle man” by having analysts create executable models and then machines turn them into the 1’s and 0’s. So managers could do away with costly and frustrating luxuries like programmers. The reality is that if someone can’t program, they can’t program at any level of abstraction. Logic is logic and Executable UML is a programming language.

And if what you get from an analyst isn’t any more precise and executable than what you get from the customer (and it very, very rarely is) then you’ve brought yourself no closer to satisfying those requirements.

What usually happens is that analysts and managers don’t explore the business goals of the project at all. The subject does doens’t come up. Instead, they shore up in a meeting room somewhere with the customer and emerge weeks or months (or years) later with a system design – a design for a solution nobody has bothered to try to understand.

And us poor programmers are handed this spec and we’re expected to make it happen. Which, of course, we can’t. Because it’s full of ambiguities, logical contradictions and fanciful pipe dreams – often not of the customer’s inception at all – that we’ll never have the time or money to realise. If we push back and say “sorry, here’s a reality check” we are labeled as difficult and obstructive. That’s why dotcom entrepeneurs often have such a low opinion of programmers. We’re spoilsports.

Then the goal of the project becomes about implementing this design rather than solving business problems. And you can’t blame us for being naturally skeptical about it all.

Programmers are no just glorified compilers. Projects need our creativity and spirit of innovation every bit as much as our technical know-how. We’re like actors. It’s no good just handing us a script and telling us to read out the lines (particularly when the scripts just says vague stuff like “Joe says something about his mother” or is loaded with nonsense and contradictions). We need to know our “motivation” for what we’re saying. We need back story. We need goals. We need consistent continuity and logic.

And the absolute worst place to find this stuff out us sitting in meeting rooms gassing about it with analysts and managers. Because, guess what, they probably don’t know, either

And it’s easy to dismiss such debate by saying “he’s got a chip on his shoulder”, but I think you underestimate just how sick and tired programmers really are of all this BS. And I’m speaking as someone who’s “managed” teams, been a BA, and an “enterprise architect” (whatever that means). It’s all 100%-pure magic fairy dust that businesses sprinkle on their projects. It’s magic beans we get in exchange for addressing the real problems.

If our programmers know what they’re doing, we don’t need them. And if they don’t know what they’re doing, we’re stuffed anyway. Short of a miracle, bad programmers will do a bad job.

Getting the business/customer and a developer talking the same language to explain and understand a real world problem that isn’t working in a piece of software isn’t easy. A good BA or ‘middleman’ who has a foot in each camp and understand the language of both can help.

Agreed, a poor BA or manager just gets in the way. But then a poor developer writes rubbish code.