4 ms·

"The best product and engineering teams understand their users deeply and are familiar with how their product should work." Surely not. And ironically, it seem

"The best product and engineering teams understand their users deeply and are familiar with how their product should work." Surely not. And ironically, it seems the writer is describing a developer-centric view, not a user-centric one.

macspoofing 6y ago
No kidding. If you write software for specialized domains, you may not be able to get developers with in-depth knowledge of the space (e.g. writing software for Radiologists).
conductr 6y ago
As a self taught developer who only works solo I'd agree. Tasks is exactly how I think. I've never found a use for stories. However, I can imagine how they are helpful to teams who individually do not have the holistic bigger picture or may not have the context of knowing the end goal/UX component. For me, the tasks are brush strokes of the bigger picture and spelling it out in story form just to break it down to tasks is duplicative. That said, sometimes my tasks are bigger strokes like "Add edit profile functionality" where it's obvious I'll have to touch the backend, database, frontend, etc. I don't have to break this into tasks.
- macspoofing 6y ago
  >I can imagine how they are helpful to teams who individually do not have the holistic bigger picture or may not have the context of knowing the end goal/UX component. Yes. Exactly. Because you're a solo developer - so either you're a hobbyist (so you know what you want), or you're talking with your customers. And as a solo developer there isn't really a need for any process or structure or any special productivity tools. You can just use notepad to organize your work. >For me, the tasks are brush strokes of the bigger picture and spelling it out in story form just to break it down to tasks is duplicative. Imagine a scenario where there is a middle-mam between you and the customer. What if that middle-man gave you task to put a button that does X on a toolbar in a web-app, and imagine you have no idea what problems or needs the customer experienced that necessitated this button. But you're a professional, so you do that. Then you get a task that says to remove the button and turn the action into a right-click menu option ... so you do that. Then you get a task that says the right-click menu option needs to be also accessible by a long-press left-click and the context options need to be bigger. Then you get a task that states the options menu when opened needs to centered under the point of long-press/right-click (instead of to the left) .... I can go on, but tell me honestly, at what point do you as a professional developer just stop and ask the middle-man either for a meeting with a customer, or just have them tell you what the customer is trying to do. Because clearly there is some type of "XY problem"[1] happening here. The customer and the middle-man are trying to solve something and they are spinning in circles and you cannot really contribute to the solution because you have no idea what they are trying to solve. Was the need for 'long-press' option added as some sort accessibility functionality or as a way to make the app compatible with mobile devices? Was the need to change the location of the context menu because of a preference, or was it because on certain devices the context menu was truncated by the edge of the screen ... etc. etc. That's the point of stories. They provide context to the developer so they can have a big picture in mind and be part of solving this problem. If you know that your web-app is meant to be used by seniors with compromised dexterity who will be primarily be using a mouse, you'll think of ways to make it easier to navigate the app versus if the app is for teenagers on their phones. You'll be able to collaborate with the middle-man (and customer) to bounce ideas of each other. As a developer, you're not an automaton even if IBM wants you to be. [1] https://xyproblem.info/ https://xyproblem.info/

macspoofing 6y ago

No kidding. If you write software for specialized domains, you may not be able to get developers with in-depth knowledge of the space (e.g. writing software for Radiologists).

conductr 6y ago

As a self taught developer who only works solo I'd agree. Tasks is exactly how I think. I've never found a use for stories. However, I can imagine how they are helpful to teams who individually do not have the holistic bigger picture or may not have the context of knowing the end goal/UX component. For me, the tasks are brush strokes of the bigger picture and spelling it out in story form just to break it down to tasks is duplicative. That said, sometimes my tasks are bigger strokes like "Add edit profile functionality" where it's obvious I'll have to touch the backend, database, frontend, etc. I don't have to break this into tasks.

macspoofing 6y ago
>I can imagine how they are helpful to teams who individually do not have the holistic bigger picture or may not have the context of knowing the end goal/UX component. Yes. Exactly. Because you're a solo developer - so either you're a hobbyist (so you know what you want), or you're talking with your customers. And as a solo developer there isn't really a need for any process or structure or any special productivity tools. You can just use notepad to organize your work. >For me, the tasks are brush strokes of the bigger picture and spelling it out in story form just to break it down to tasks is duplicative. Imagine a scenario where there is a middle-mam between you and the customer. What if that middle-man gave you task to put a button that does X on a toolbar in a web-app, and imagine you have no idea what problems or needs the customer experienced that necessitated this button. But you're a professional, so you do that. Then you get a task that says to remove the button and turn the action into a right-click menu option ... so you do that. Then you get a task that says the right-click menu option needs to be also accessible by a long-press left-click and the context options need to be bigger. Then you get a task that states the options menu when opened needs to centered under the point of long-press/right-click (instead of to the left) .... I can go on, but tell me honestly, at what point do you as a professional developer just stop and ask the middle-man either for a meeting with a customer, or just have them tell you what the customer is trying to do. Because clearly there is some type of "XY problem"[1] happening here. The customer and the middle-man are trying to solve something and they are spinning in circles and you cannot really contribute to the solution because you have no idea what they are trying to solve. Was the need for 'long-press' option added as some sort accessibility functionality or as a way to make the app compatible with mobile devices? Was the need to change the location of the context menu because of a preference, or was it because on certain devices the context menu was truncated by the edge of the screen ... etc. etc. That's the point of stories. They provide context to the developer so they can have a big picture in mind and be part of solving this problem. If you know that your web-app is meant to be used by seniors with compromised dexterity who will be primarily be using a mouse, you'll think of ways to make it easier to navigate the app versus if the app is for teenagers on their phones. You'll be able to collaborate with the middle-man (and customer) to bounce ideas of each other. As a developer, you're not an automaton even if IBM wants you to be. [1] https://xyproblem.info/ https://xyproblem.info/