“Developers Don't Need to Know the Product”
projectsherpa.com
“Developers Don't Need to Know the Product”
1–10 of 27 posts
Re: “Developers Don't Need to Know the Product”
#2> I’m sure that no one has ever said something that stupid out loud
You haven't been around much, have you?
Re: “Developers Don't Need to Know the Product”
#3> I’m sure that no one has ever said something that stupid out loud You haven't been around much, have you?
I have been fortunate to be surrounded by people who are generally intelligent and progressive that believe engineers should be part of the entire lifecycle.
Would you care to share your experience with us?
Re: “Developers Don't Need to Know the Product”
#4There are two kinds of programmers with massive productivity benefits to an organization:
1 - Those that can identify what needs to be done at a level deeper than the end users, can communicate very well, and can code reasonably well. (Coding well enough to understand complexity, and can do things on the fly if needed)
2 - Those who appreciate the difficulties that users have, and have an enormous technical toolset to bring to bear on tough problems.
Much performance literature says, "Play to your strengths" but when people in batch 1 already know their end users in and out, it helps to develop technical skills. And people in bucket 2 - when they make the leap to deeply understand their customer's business, they're extremely powerful. This is also why many firms like to hire CS majors for non-CS jobs.
Re: “Developers Don't Need to Know the Product”
#5There are two kinds of programmers with massive productivity benefits to an organization: 1 - Those that can identify what needs to be done at a level deeper than the end users, can communicate very well, and can code reasonably well. (Coding well enough to understand complexity, and can do things on the fly if needed) 2 - Those who appreciate the difficulties that users have, and have an enormous technical toolset t…
1 - You describe what most Banks and Hedge Funds would call RAD (Rapid Application Developers) Developers (I know redundant like saying "The La Brea Tar Pits...the the tar tar pits ; 0 ). They are those who are good enough with dev, but understand the biz domain well. I've seen some startups where Product Managers can also function in that capacity, prototyping, basic dev.
2 - Couldn't agree more, but ALAS, there aren't enough people graduating with CS degrees, let alone STEM in general. When I tried to do a market analysis, it was a painful experience. My CoFounder (Great Engineer) was able to do in two hours, what would have taken me two days, because of his software and database skills, not to mention that he had more time to interpret the data vs just gathering. I'd be curious to continue the discussion. If you'd like, please send me an email to ben@projectsherpa.com
Re: “Developers Don't Need to Know the Product”
#6There are two kinds of programmers with massive productivity benefits to an organization: 1 - Those that can identify what needs to be done at a level deeper than the end users, can communicate very well, and can code reasonably well. (Coding well enough to understand complexity, and can do things on the fly if needed) 2 - Those who appreciate the difficulties that users have, and have an enormous technical toolset t…
Why are people as short sighted to always say there is a limited number, and expect they define every possibility.
Re: “Developers Don't Need to Know the Product”
#7>"The product side needs to provide a set of requirements, and the development side needs to find out what the client needs, and how to deliver it. The development side has to have enough product knowledge to determine the actual need, not the stated want"
When I've been in "QA-ish" roles and worked with developers like this, I loved them - and told them so - which was the last thing they expected from an extrovert. I was OK with the ones who DIDN'T have the product/business/user knowledge, but were willing to listen to what I had to say - even if I was saying you/we/I need to go back to the product side for clarification; I don't think this is what they really need/want. And I've battled with those developers who neither had nor wanted any business/user/product knowledge AND didn't want to talk to the product side or listen to QA AND still wouldn't listen to QA after QA got clarification from the product side.
Of course, ideally any clarification is received before or - at the latest - during coding, but life ain't ideal.
Re: “Developers Don't Need to Know the Product”
#8There are two kinds of programmers with massive productivity benefits to an organization: 1 - Those that can identify what needs to be done at a level deeper than the end users, can communicate very well, and can code reasonably well. (Coding well enough to understand complexity, and can do things on the fly if needed) 2 - Those who appreciate the difficulties that users have, and have an enormous technical toolset t…
Why are people as short sighted to always say there is a limited number, and expect they define every possibility.
It writes a little easier than, "Here are two dimensions of many. On the X axis consider technical skills. On the Y consider 'knowing your customer's business better than they do'. Plot a line..." :-)
Re: “Developers Don't Need to Know the Product”
#9>"The product side needs to provide a set of requirements, and the development side needs to find out what the client needs, and how to deliver it. The development side has to have enough product knowledge to determine the actual need, not the stated want" When I've been in "QA-ish" roles and worked with developers like this, I loved them - and told them so - which was the last thing they expected from an extrovert.…
Lost in slashes here.
Re: “Developers Don't Need to Know the Product”
#10"The product side needs to provide a set of requirements, and the development side needs to find out what the client needs, and how to deliver it. The development side has to have enough product knowledge to determine the actual need, not the stated want"
disagree with that statement.
"The product side needs to find out what the client really needs and build requirements out of it. The development side has to determine how to deliver it."
Fixed that for you.