5 ms·

Just one of the many aspects of so called "Requirements Engineering" (which some unfortunate souls have even somehow ended up spending their entire academic car

Just one of the many aspects of so called "Requirements Engineering" (which some unfortunate souls have even somehow ended up spending their entire academic career on) which is more or less complete utter BS from start to end if I'm allowed to be clear. I have yet to see a single successful software company that attributed their success in any significant manner to practicing any or all of the mumbo jumbo that is taught in this pseudo-discipline. Reality has taught us over and over again that absolutely nothing beats just doing the damn job! Certainly not circle jerking around the bush with some nonsense User Stories. /rant

kneebonian 3y ago
I find it interesting how there are entire disciplines now built around doing exactly what was outlined in the OSS Simple Sabatoge Field Manual https://archive.org/details/SimpleSabotageFieldManual/page/n17/mode/2up https://archive.org/details/SimpleSabotageFieldManual/page/n...
EddieEngineers 3y ago
Have you ever written software for critical systems, such as pacemakers or nuclear power stations? Or a role where software integrates with large electrical and mechanical engineering teams? This is fine for some projects but there are other projects where "doing the damn job" is a bad idea or even illegal. Requirements engineering for a startup iterating quickly is pointless but for a well-defined critical system makes more sense.
- jdthedisciple 3y ago
  While I see your point pointing out potential exceptions, your examples imo sound least suitable for something like "I as user want to sort my notes alphabetically" aka User Stories. Rather, for those critical cases you mention, frameworks like the Waterfall- or V-model, in combination with proper testing, perhaps seem much more called for to ensure compliance, security, and rigidity.
  - EddieEngineers 3y ago
    That's fair, I was focused on defending requirements engineering in general than just user stories. But yes you'd follow something like the V-model and you'd need these requirements, that could resemble something like user stories, to fill out a remarkably boring requirements traceability matrix on the other side. If you look at Appendix C of IBMs manual on writing requirements in DOORS [0] you'll see they can easily turn into something similar to "I as a user...". Not that I think that fits everything, nor do I think anyone should need to use DOORS lol. [0] https://www.ibm.com/docs/en/SSYQBZ_9.7.0/com.ibm.doors.requirements.doc/topics/get_it_right_the_first_time.pdf https://www.ibm.com/docs/en/SSYQBZ_9.7.0/com.ibm.doors.requi...
  - slothtrop 3y ago
    You'll admit however that User Stories =/= Requirements Engineering, or by extension AGILE/SOLID. Stories may be a component of those, but there are alternatives.
    - jdlshore 3y ago
      “Agile” is not an acronym, FYI. (And SOLID is a collection of five object-oriented design principles. Not sure why you put them together like that.)
  - codyb 3y ago
    I as a user would like to maintain a beating heart is a pretty compelling story though.
    - jdthedisciple 3y ago
      Not a very useful thing to write down though, is it? I mean sure, if there truly was some uncertainty about this left.
theteapot 3y ago
> Reality has taught us over and over again that absolutely nothing beats just doing the damn job! I would have thought practical experience of the last 50 years has shown "just doing the damn job" is not something that turns out well in software.
- jdthedisciple 3y ago
  Like anything, it can go wrong due to lack of experience and/or competence, or even technical debt. But it's clear what the real issue is in those cases.
  - micromacrofoot 3y ago
    It's clear in hindsight
idopmstuff 3y ago
> nothing beats just doing the damn job! Okay, but you have to define what the job is. That's what user stories are for. You don't have to use them (there are many other ways of scoping and defining work), but you literally can't just do the damn job unless there is a definition of what the job is. > I have yet to see a single successful software company that attributed their success in any significant manner to practicing any or all of the mumbo jumbo that is taught in this pseudo-discipline. There are lots of multi-billion dollar companies that use user stories. I guess they don't attribute their success to it by proclaiming that user stories are amazing on earnings calls, but if you're suggesting that there are no successful companies that use Agile and related methodologies, you're demonstrably wrong.
- jdthedisciple 3y ago
  I truly would like to see just one successful software company that started out by creating User Stories vs just simply creating and building their vision. Sure, plenty started incorporating all sorts of stuff much much later on. I haven't seen it be a significant initial contributor for the eventual success. Especially not vs simply doing. The vision defines what needs to be done better than anything else ever could. That said, some of the companies with the most budget out there (cough something from Redmond cough) probably use these sorts of modern "techniques" all the times yet manage to regularly fail utterly when it comes to basic usability of their products.
- jofer 3y ago
  I have yet to see a single user story that actually gives any correct details of what the user wants or is doing, though. They're invariably written by product managers who have never been in the users shoes and have absolutely zero understanding of what the product is or what the users do. The engineers building a product have typically actually been in the users shoes. The product managers almost never have. When I start seeing user stories that aren't actively harmful, I might feel differently. As it is, the first thing you should do as an engineer is throw away the user story or management's description of the problem and go straight to the actual user feedback. User stories are like watching a fish try to describe a bicycle....
ebiester 3y ago
When I see something like this, I think the appropriate response is that with requirements, there is no "best way" for every circumstance. If you have an internal user or small set of internal users, you are likely better off spending time with them, building the smallest thing that can solve their immediate problem, and keep building from there. User stories are great here because your requirements gathering is asking the people doing the job. Don't design too much up front unless you have a particularly hairy business process. If you are B2C, you have no idea what people will want. you are unlikely to get a statistically significant sample. You are often looking at the alternatives and building for personas. Small work sizes are valuable here. If you are replatforming or rewriting, you should be getting Gap analyses and real requirements because you've had a long time to consider the shortcomings. You may build in a way that gets feedback, but you already know what to build. Don't bother with user stories! If you are with a mature system, the easy problems are likely already solved. You're building larger features that there is no easy MVP because if there was a simple way to unlock the value, you would have already done it. You should be spending more time in unlocking specifications. If you are a B2B with larger business systems, they probably already have smaller ways to do what you are trying to sell them, and they're looking to step up. You likely need better requirements than a user story. However, you likely have access to customers through your customer support teams, so you should be taking advantage of asking them and getting feedback. You probably need something in the middle. Use the tool that meets your use case.
watwut 3y ago
Just doing the Damm job led to massive mess, unability to even know what system does literally every single time I have seen it. It seems to be working, if you are one of those people who leave quickly or if you don't care about anything except closed tickets. Even if most of those tickets are bugs, same bugs again and again in cycle.

kneebonian 3y ago

I find it interesting how there are entire disciplines now built around doing exactly what was outlined in the OSS Simple Sabatoge Field Manual https://archive.org/details/SimpleSabotageFieldManual/page/n17/mode/2up https://archive.org/details/SimpleSabotageFieldManual/page/n...

EddieEngineers 3y ago

Have you ever written software for critical systems, such as pacemakers or nuclear power stations? Or a role where software integrates with large electrical and mechanical engineering teams? This is fine for some projects but there are other projects where "doing the damn job" is a bad idea or even illegal. Requirements engineering for a startup iterating quickly is pointless but for a well-defined critical system makes more sense.

jdthedisciple 3y ago
While I see your point pointing out potential exceptions, your examples imo sound least suitable for something like "I as user want to sort my notes alphabetically" aka User Stories. Rather, for those critical cases you mention, frameworks like the Waterfall- or V-model, in combination with proper testing, perhaps seem much more called for to ensure compliance, security, and rigidity.
- EddieEngineers 3y ago
  That's fair, I was focused on defending requirements engineering in general than just user stories. But yes you'd follow something like the V-model and you'd need these requirements, that could resemble something like user stories, to fill out a remarkably boring requirements traceability matrix on the other side. If you look at Appendix C of IBMs manual on writing requirements in DOORS [0] you'll see they can easily turn into something similar to "I as a user...". Not that I think that fits everything, nor do I think anyone should need to use DOORS lol. [0] https://www.ibm.com/docs/en/SSYQBZ_9.7.0/com.ibm.doors.requirements.doc/topics/get_it_right_the_first_time.pdf https://www.ibm.com/docs/en/SSYQBZ_9.7.0/com.ibm.doors.requi...
- slothtrop 3y ago
  You'll admit however that User Stories =/= Requirements Engineering, or by extension AGILE/SOLID. Stories may be a component of those, but there are alternatives.
  - jdlshore 3y ago
    “Agile” is not an acronym, FYI. (And SOLID is a collection of five object-oriented design principles. Not sure why you put them together like that.)
- codyb 3y ago
  I as a user would like to maintain a beating heart is a pretty compelling story though.
  - jdthedisciple 3y ago
    Not a very useful thing to write down though, is it? I mean sure, if there truly was some uncertainty about this left.

theteapot 3y ago

> Reality has taught us over and over again that absolutely nothing beats just doing the damn job! I would have thought practical experience of the last 50 years has shown "just doing the damn job" is not something that turns out well in software.

jdthedisciple 3y ago
Like anything, it can go wrong due to lack of experience and/or competence, or even technical debt. But it's clear what the real issue is in those cases.
- micromacrofoot 3y ago
  It's clear in hindsight

idopmstuff 3y ago

> nothing beats just doing the damn job! Okay, but you have to define what the job is. That's what user stories are for. You don't have to use them (there are many other ways of scoping and defining work), but you literally can't just do the damn job unless there is a definition of what the job is. > I have yet to see a single successful software company that attributed their success in any significant manner to practicing any or all of the mumbo jumbo that is taught in this pseudo-discipline. There are lots of multi-billion dollar companies that use user stories. I guess they don't attribute their success to it by proclaiming that user stories are amazing on earnings calls, but if you're suggesting that there are no successful companies that use Agile and related methodologies, you're demonstrably wrong.

jdthedisciple 3y ago
I truly would like to see just one successful software company that started out by creating User Stories vs just simply creating and building their vision. Sure, plenty started incorporating all sorts of stuff much much later on. I haven't seen it be a significant initial contributor for the eventual success. Especially not vs simply doing. The vision defines what needs to be done better than anything else ever could. That said, some of the companies with the most budget out there (cough something from Redmond cough) probably use these sorts of modern "techniques" all the times yet manage to regularly fail utterly when it comes to basic usability of their products.
jofer 3y ago
I have yet to see a single user story that actually gives any correct details of what the user wants or is doing, though. They're invariably written by product managers who have never been in the users shoes and have absolutely zero understanding of what the product is or what the users do. The engineers building a product have typically actually been in the users shoes. The product managers almost never have. When I start seeing user stories that aren't actively harmful, I might feel differently. As it is, the first thing you should do as an engineer is throw away the user story or management's description of the problem and go straight to the actual user feedback. User stories are like watching a fish try to describe a bicycle....

ebiester 3y ago

When I see something like this, I think the appropriate response is that with requirements, there is no "best way" for every circumstance. If you have an internal user or small set of internal users, you are likely better off spending time with them, building the smallest thing that can solve their immediate problem, and keep building from there. User stories are great here because your requirements gathering is asking the people doing the job. Don't design too much up front unless you have a particularly hairy business process. If you are B2C, you have no idea what people will want. you are unlikely to get a statistically significant sample. You are often looking at the alternatives and building for personas. Small work sizes are valuable here. If you are replatforming or rewriting, you should be getting Gap analyses and real requirements because you've had a long time to consider the shortcomings. You may build in a way that gets feedback, but you already know what to build. Don't bother with user stories! If you are with a mature system, the easy problems are likely already solved. You're building larger features that there is no easy MVP because if there was a simple way to unlock the value, you would have already done it. You should be spending more time in unlocking specifications. If you are a B2B with larger business systems, they probably already have smaller ways to do what you are trying to sell them, and they're looking to step up. You likely need better requirements than a user story. However, you likely have access to customers through your customer support teams, so you should be taking advantage of asking them and getting feedback. You probably need something in the middle. Use the tool that meets your use case.

watwut 3y ago

Just doing the Damm job led to massive mess, unability to even know what system does literally every single time I have seen it. It seems to be working, if you are one of those people who leave quickly or if you don't care about anything except closed tickets. Even if most of those tickets are bugs, same bugs again and again in cycle.