Re: They don't specify because they don't know what they want

[Maclir]

Ahhhh! The clients don't know what they want. So all of us ace coders jump in, knock a proof of concept prototype, and interate this design with the confused client. This is a job for:

Super-Analyst

Yes, faster than a speeding celeron, able to leap tall piles of specifications at a single bound . . .

Ok, seriously folks. There is a role in the development process, called a business analyst. This person does not (or should not) cut code. They have the ability to rapidly understand the underlying business processes and requirements of the users / clients, they know the common problems and "gotchas" that can plague poorly designed systems, and they can turn users' hazy concepts into clear, unambiguous specifications that programmers can then develop good systems from.

An analyst is not a senior programmer, they aren't the gun C++ / Java / Perl coder that can churn out top quality code in their sleep. An analyst is the bridge between the business experts and the developers, able to speak the languages of both groups, and make sure that everyone has a clear understanding of the same set of requirements. An analysts two chief weapons are the ability to write clear, well structured documents and the ability to quickly grasp new business environments and problems (and a fanatical devotion to the pope ... out three chief weapons are -- whoops, wrong story.)

Seriously, all the discussion recently about program specifications, and people's grips about having to work where there are poorly specified requirements indicates one common problem - the lack of a good business analyst working on the project.

And I jus happen to know where there is a highly experience one looking for work . . . here!