[walshemj]

No coding is not hard! that's the easy bit.

The hard part about the job is

1 Getting the actual real requirements nailed down 2 Designing the system to run in the real world accounting for all those edge cases and falilure modes.

[jarrett]

> Getting the actual real requirements nailed down

Wherein the programmer plays the role of social worker. Seriously though, the skill sets are very similar. The client is typically the ultimate source of the requirements, but it's never a simple case of asking the client "what should I build? More often than not, the client doesn't know what s/he wants, wants something that will actually hurt him/her, is actually seven different people who want opposite things, wants the roses simultaneously painted white and red, etc. Which is why I find requirements collection the most challenging part of the job.

[ayuvar]

That makes me wonder if a business-analyst or product-manager role should involve a technical interview where you spec out a mock product to see how well you gather requirements.

[kasey_junk]

If by technical interview, you mean the common process of making someone do a simulacrum of the job they will do over the course of days, in a few overly tense hours, then no I can't possibly recommend that.

If on the other hand you are saying, "should I be evaluating product specification and requirements gathering when hiring business analysts, or product managers" then I would say of course! What else would be evaluating them on?

[kasey_junk]

I wouldn't say that coding is the easy bit (if it were I wouldn't have seen so many terrible code bases in my life). I'd say that requirements gathering and systems design are also crucial difficult parts of the process of developing software and any developer acquisition methodology should take them into account as well.

[Retric]

Bad code bases are rarely bad due to incompetence so much as changing requirements.

[kasey_junk]

In your experience. Not to be flippant, but if you are developing software in an environment that has lots of changing requirements, there are ways to write that code and developers who are good in those situations.

Similarly, there are environments where static requirements are cornerstone for success. Certain methodologies deal with this environment better than others and certain developers will be more successful than others in these environments.

[troels]

Above a certain threshold, yes. But I have seen so much utterly crazy hacked-together crap, which was clearly not caused by changing requirements, but rather either incompetence or negligence. I'm guessing that so have you.

[lucasnemeth]

Not on every job. Sometimes coding is the hardest part.

[walshemj]

Can you give a real world example here? developing the algorithm to solve the problem is not coding but design.

[dasil003]

Can't very well separate coding from #2 though.