3 ms·

I find, after creating software for 14 years, that 1) clients don't know what they want, 2) they can't communicate what they want 3) describing features is diff

I find, after creating software for 14 years, that 1) clients don't know what they want, 2) they can't communicate what they want 3) describing features is difficult it doesn't matter if we call it a story or an issue, 4) something will always change

marcus_holmes 5y ago
After creating software for almost 30 years, this is still true. But...it's not their fault. Asking anyone to precisely describe a complex system that is subject to change will have the same problem(s). This is why Agile[0] was such a breath of fresh air. And Iterative Prototyping, MVP's, all that. It's massively easier and quicker to slap something together, put it in front of a customer and ask them what's wrong with it, than it is to ask them what they want in the first place. In my experience a quick "it should do this" is good enough to get that going, and then iterate from there. [0]Actual Agile. As in the Manifesto. Not this Scrum bullshit.
- sumtechguy 5y ago
  It is interesting to watch scrumm. I have seen it broken a few times now. Every single time it started off just fine. Then someone decides the process was more important instead of the intent. Then everyone just went along with it. Even worse someone knows they 'still dont like it' but keep tweaking it but making it worse instead of saying 'yeah that did not work at all'. Or my favorite is someone blows in and finds out you have been skipping one ritual (because it was low value to your team). Your team is then declared 'broken'. It is like there is some flaw in scrumm that allows for anti patterns.
- kbenson 5y ago
  > But...it's not their fault. Asking anyone to precisely describe a complex system that is subject to change will have the same problem(s). Yes. In the same breath someone might denigrate users for not knowing what they want and also explain about how they can't accurately timeline their personal coding project where they are the only user and developer. Designing any complex system is hard. Asking users to take part in that design process means asking them to do something hard (or at least that's hard if done well, and hard to tell you aren't doing well unless you put in that effort you didn't know you had to). Complaining about bad user requirements as fine, but truthfully it should be done in a way that's self deprecating...
kaiju0 5y ago
So very true. I usually ask what business outcome they are looking for and then tell them how I'm going to deliver that for them. Saves a lot of hassle.
rmah 5y ago
Exactly right. One thing I often tell younger developers is... 80% of developing software is figuring out exactly what you want to build." Usually, the actual act of building it (i.e. writing the code) is fairly trivial.
rualca 5y ago
> I find, after creating software for 14 years, that 1) clients don't know what they want (..) I've logged in just to point out this fact, and to call out how the author of this anti-user stories rant is completely clueless and out of touch with the reality of developing software. The whole point of user stories is to not only specify an objective target but also a concrete definition of done, in spite of the clients' inherent ambiguity and flexibility, and very often also contradicting notions inherent to their asks. User stories report intent and context along with the goal. User stories adds information that helps developers help the customer. If you remove the out-of-band information, you are creating a process that is a throwback to the bad old days of waterfall, where saying that it's the client's fault that the devs built the exact opposite of what the clients were expecting. All which was old is eventually new again, and in the case of "linear method" the novelty is not having a clue of what you need to do to meet customer's demands and expectations.

marcus_holmes 5y ago

After creating software for almost 30 years, this is still true. But...it's not their fault. Asking anyone to precisely describe a complex system that is subject to change will have the same problem(s). This is why Agile[0] was such a breath of fresh air. And Iterative Prototyping, MVP's, all that. It's massively easier and quicker to slap something together, put it in front of a customer and ask them what's wrong with it, than it is to ask them what they want in the first place. In my experience a quick "it should do this" is good enough to get that going, and then iterate from there. [0]Actual Agile. As in the Manifesto. Not this Scrum bullshit.

sumtechguy 5y ago
It is interesting to watch scrumm. I have seen it broken a few times now. Every single time it started off just fine. Then someone decides the process was more important instead of the intent. Then everyone just went along with it. Even worse someone knows they 'still dont like it' but keep tweaking it but making it worse instead of saying 'yeah that did not work at all'. Or my favorite is someone blows in and finds out you have been skipping one ritual (because it was low value to your team). Your team is then declared 'broken'. It is like there is some flaw in scrumm that allows for anti patterns.
kbenson 5y ago
> But...it's not their fault. Asking anyone to precisely describe a complex system that is subject to change will have the same problem(s). Yes. In the same breath someone might denigrate users for not knowing what they want and also explain about how they can't accurately timeline their personal coding project where they are the only user and developer. Designing any complex system is hard. Asking users to take part in that design process means asking them to do something hard (or at least that's hard if done well, and hard to tell you aren't doing well unless you put in that effort you didn't know you had to). Complaining about bad user requirements as fine, but truthfully it should be done in a way that's self deprecating...

kaiju0 5y ago

So very true. I usually ask what business outcome they are looking for and then tell them how I'm going to deliver that for them. Saves a lot of hassle.

rmah 5y ago

Exactly right. One thing I often tell younger developers is... 80% of developing software is figuring out exactly what you want to build." Usually, the actual act of building it (i.e. writing the code) is fairly trivial.

rualca 5y ago

> I find, after creating software for 14 years, that 1) clients don't know what they want (..) I've logged in just to point out this fact, and to call out how the author of this anti-user stories rant is completely clueless and out of touch with the reality of developing software. The whole point of user stories is to not only specify an objective target but also a concrete definition of done, in spite of the clients' inherent ambiguity and flexibility, and very often also contradicting notions inherent to their asks. User stories report intent and context along with the goal. User stories adds information that helps developers help the customer. If you remove the out-of-band information, you are creating a process that is a throwback to the bad old days of waterfall, where saying that it's the client's fault that the devs built the exact opposite of what the clients were expecting. All which was old is eventually new again, and in the case of "linear method" the novelty is not having a clue of what you need to do to meet customer's demands and expectations.