In the best scenario the developers are also active users of the software they produce. Then a design flaw or an error that affects the users will also affect the developers and will (hopefully) motivate the latter to correct it.
Its also useful for developers to have a way of bypassing customer support to have direct visibility into what issues the actual users are experiencing. This can come in the form of browsing tickets, online forums, or social media.
Often something that's easily brushed off by a support rep will ring a bell in the mind of a developer who has recently worked in the area of the code related to the issue.
XP putting a customer on the team was the best thing in the methodology. Replacing those with business representatives is one of Scrum's original sins.
It's also worth noting that a customer is not necessarily a user. As a developer I don't care so much about the customer but I care wholeheartedly about the users.
> XP putting a customer on the team was the best thing in the methodology.
Recently my boss said to me: "Customers want something that WORKS. If you deliver something, and it doesn't work, what's the customer going to think?" The huge drawback to putting a customer on the team is that the customer probably doesn't want to know, let alone be involved with, how the sausage is made. They want a turnkey solution unveiled to them on the delivery date, all ready to go, with no effort on their part.
Generally what you want is a customer proxy in that role, who knows or can articulate what the customer needs better than the customer themselves can. Steve Jobs was a fantastic example of someone who filled this role.
There is nothing wrong with early exit, but you have to be sensible.
Just like there's nothing wrong with the ternary operator if you are sensible. I've seen nested ?: abominations that would make Jesus give you a funny look.
I disagree, I think returns should either be at the very start (checking inputs should be able to return before anything happens based on invalid inputs) or at the very end. Proceeding to do a bunch of stuff & then try to undo it because an input was invalid is error-prone.
If the input parameters are invalid there is an error in the program so it makes more sense to use the assert function. Why would you need to undo something due to the restriction of a single point of exit?
Then there is the joy of making the program source code as easy as possible to comprehend. This motivation seems to be rather unusual among programmers unfortunately.
reply