Comment by paulojreis | Hacker News Reader

Comment by paulojreis | Hacker News Reader

Parent Full thread

My concern with this (and my general pet peeve with the "user stories" in software engineering) is: how do we make sure the "user stories" are faithful to real-world usage of the software being built? tl;dr: how do we know the user stories are relevant?

The article defines user stories as "simple scenarios told from the point of view of a person using the software. There can be many types of users for an application". This is very, very problematic. How can I be sure that software developers are able to walk on the shoes of the user? That they even know who are the real users? Their needs, their context?

I have little to no faith in user stories, on software development. It takes a lot of UX knowledge and experience to be able to faithfully depict scenarios and personas, and even more so to have the maturity to do such things grounded on data and not on our preconceptions. I just can't assume software developers will have this kind of knowledge and experience and, as such, user stories will end up being a reflex of their preconceptions, not of the real-world usage of the software.

I've been in many projects where people would iterate numerous times over architecture while completely forgetting what real-world problem they are actually trying to solve. Architecture becoming art pour l'art.

I don't see the point of the article being that every software developer becomes a fully-fledged UX guy, but understands the context in which the system is going to be used and not get lost in the technical rabbit hole.

> I've been in many projects where people would iterate numerous times over architecture while completely forgetting what real-world problem they are actually trying to solve. Architecture becoming art pour l'art.

I completely agree. Unless constrained, software developers will entertain themselves with architecture stuff ad libitum. But this is one problem; the other - a full-blown, bigger one - is truly knowing the real-world problem.

> I don't see the point of the article being that every software developer becomes a fully-fledged UX guy, but understands the context in which the system is going to be used and not get lost in the technical rabbit hole.

The premise is a noble one, and correct IMO. But, as above, truly knowing the real-world problem is hell. We can't really hope to solve the technical rabbit hole just by focusing in the real-world, or simply assume that we know it.

Software developers won't understand the real-world context, most of the times. They aren't trained to do so. Most of the times, companies won't help: organization keeps software developers very far from customers. Hell, I'll say it: many software developers even lack the basic empathy skills to understand the user. Their model of the software is the implementation model, not the usage model. And many times they're too stubborn, and talk very cheap regarding users and usage: software developers say "this is what the user wants" as cheaply I say "the sky is blue". But the thing is that "what the user wants" is not that obvious; the only obvious thing is the mis/preconceptions we have.

The programmers don't have to write the user stories. A UX guy or a product owner can write the stories (which is how you ensure they're relevant). The job of the programmer is then to create a technical solution that solves a user requirement.

I absolutely agree; that's how it should happen. My main contempt is that, in reality, it doesn't. You get "implementation" guys writing user stories, and - in many ways - implementation model thrown into usage model. And, of course, nowhere in this article I found any discussion regarding who should - and which skills are needed to - write user stories.

P.S. As I said above, this is a pet peeve of mine. I'm doing a generalization; of course there are developers which are great at writing user stories and understanding users.

It's just that I believe in being professional and knowledgeable. If user stories matter, you should get someone with the valid skill set to do it. Not only should you get the skill set on your team, you should get the process! User stories without user data are just plain fiction. It's just the movie your team plays in their heads regarding how the software is used.

> You get "implementation" guys writing user stories

That is true... I've seen a fair share of user stories that start "As a developer"...

Reply on news.ycombinator.com