7 ms·

This is a pretty eternal problem in software development. I now think that it is our jobs as developers to properly identify how things should work. We're ofte

by rtpg 10y ago

This is a pretty eternal problem in software development. I now think that it is our jobs as developers to properly identify how things should work. We're often not experts in the domain we're working on, but by asking questions about a user's workflow on a more holistic level, we probably have more insight into what workflow would be the most productive from a systems standpoint. Of course, this is a back-and-forth. Sometimes users aren't sure of what they want. And sometimes we're not sure of what is the "best" system for what the users want. Instead of asking the user where the button should be, ask them when they press the button.

blowski 10y ago
Behavioural driven development (BDD) encourages this process. The developers flesh out specific examples with the business people using readable language, and that becomes user acceptance criteria. It's no panacea, but it helps because it tries to prevent the business people dictating tech specifics, which the developers take too literally. For example, a business person says "when I press the submit button the results must be stored in MySQL". What they really mean is that whatever they entered into a form must be accessible later, but the developers now believe they must use MySQL and have submit buttons. By focusing on the "When I complete the form with data x, when I look at the form again later, then I see data x" you've moved the conversation to the business requirements and away from the perceived technical requirements.
- ben_jones 10y ago
  "And I need you to write it in PHP because it's cheaper" (not hating on modern PHP, just its reputation and 'outsourceability')
- hueving 10y ago
  mysql isn't a great example because that frequently comes up specifically because they have db analysts with skills in that system, its where the rest of their data is, already have support contracts for it, etc.
  - blowski 10y ago
    While that might be a valid reason to require MySQL as a database, it's probably not a requirement of a given form. It might not even be necessary to have a database at all - it's important to understand 'why' the BAs are saying this, and not take their opinions as the definitive solution. For example, the ticket might look like "When I submit the form, then the DB Analysts are able to run reports on the submitted data".
  - Cthulhu_ 10y ago
    The decision about what database to use still isn't a business requirement in that case though, more of a nonfunctional requirement that can be determined outside of a particular feature.
    - hueving 10y ago
      It very much is. If you told them you might decide not to use mysql so it would be completely incompatible with all of the data storage requirements, they would rightly tell you to get out for wasting their time. Your refusal to use the correct storage could cost them thousands of hours of labor establishing new processes for backups, BI integration, high availability, and just training on managing the system. I have worked with many companies where this was a very hard business requirement. Companies that dont care how the data is stored tend to be pretty small or not actually care that much about the data.
- wolfgke 10y ago
  > It's no panacea, but it helps because it tries to prevent the business people dictating tech specifics, which the developers take too literally. > For example, a business person says "when I press the submit button the results must be stored in MySQL". What they really mean is that whatever they entered into a form must be accessible later, but the developers now believe they must use MySQL and have submit buttons. So in other words business people are plain old lying about the requirements.
  - blowski 10y ago
    Not lying, just not really understanding what they're talking about. For many BAs, 'MySQL' is interchangeable with 'database' so they don't realise that a different database might be a better solution. They're phrasing the requirement in terms of their best understanding of the implementation. The goal of BDD is to focus the language on the business domain instead.
    - tonyedgecombe 10y ago
      Yes, I've often seen business people pick up on technical terms without really understanding what they mean. It is our responsibility to coax users into giving non-technical requirements.
    - wolfgke 10y ago
      > For many BAs, 'MySQL' is interchangeable with 'database' so they don't realise that a different database might be a better solution. One minute of googling can be expected from BAs, too. > They're phrasing the requirement in terms of their best understanding of the implementation. Then they should say "to my knowledge MySQL is a popular database that I know of and is to my knowledge used a lot in the company, but if you know of a better implementation (I don't know much about that - I'm no computer scientist) use it instead.".
      - rahoulb 10y ago
        Or it's the developer's job to ask "why do you say that?" - the BA thinks they're being helpful and shortcutting a decision for you; the least you could do is try to be helpful back.
- auvrw 10y ago
  > Behavioural driven development (BDD) https://cucumber.io/ https://cucumber.io/ is a particularly awesome idea for specifying behavior. really want to try it out for a project sometime: the idea is to write the spec in these domain-specific "gherkin" files. i find it comparatively difficult to get get buy-in on collaborating on anything machine-readable, however, unless it's from people who are comfortable with general-purpose programming languages, anyway. nonetheless, in an industry where it's fairly standard for designers to build in domain-specific languages, i don't think it's an unreasonable skill for product managers to consider acquiring. any user experience stories from cucumber, etc. on rewrites or otherwise?
  - lifeisstillgood 10y ago
    In my experience it's a joke. It's a way for devs to write executable document strings for the tests they also write. Absolutely no business person who is responsible at the level BDD works (the head of marketing for example) ever ever ever writes a working BDD description or frankly bothers reading them. Maybe just maybe they are useful intermediaries for Business analysts but most of those have been fired. Fitnese tests have more traction but then this is just exposing your API for user tests
    - quantumhobbit 10y ago
      This is my experience as well. Cucumber and the like sound like a way to get 'the business' involved more, but in practice the cucumber files just become yet another thing that the developers or testers have to write. At which point you are better off with more traditional testing methods.
      - auvrw 10y ago
        > the cucumber files just become yet another thing that the developers or testers have to write yep, if (and it's sounding more and more like "when," even outside of my anecdotal experience) that decision is made, there's not much point in using cucumber or similar. i was kind of hoping someone would say, "yea, our product manager writes domain-specific specification files, and the workflow is so much easier!" ... but no, i'll just continue being mildly cynical a/b the role of developers in industry.
Terr_ 10y ago
> Of course, this is a back-and-forth. Sometimes users aren't sure of what they want. Or your "product owner" doesn't really know the product and happens to be in a minimal-overlap timezone, and walking to the other side of the local office to ask Real-Users for feedback eventually generates a subtle reprimand about going through proper channels... Yeah, not planning to stick around.
- tonyedgecombe 10y ago
  If I look back over my career the projects where I had direct access to knowledgeable users were always easier and probably more successful. One of the red flags I started to notice was where the client liaison had only been working there for a couple of weeks or months.
cmdkeen 10y ago
This is my life. Replacing software that was written a decade+ ago so that the software has become the process. Users find is down right difficult to think in terms of what is going on a business process rather than the steps they have to do to force the computer to say yes. Many find it genuinely tricky to even describe in even real world terms what is going on without slipping into jargon that is actually just describing the existing system.
- was_boring 10y ago
  I'm currently doing the same and have found a lot of my time is spent interviewing managers and their reports to devine what problem they are solving with the software. In general they are completely unable to describe the job and problems they solve for the company, only how they use the software day to day, with out significant coaching and reframing.
  - Terr_ 10y ago
    It's a vicious cycle: Nobody knows the vision, so they just iterate on the process, and the process is inscrutable, so nobody can extract a vision for it.
dagw 10y ago
In an ideal world, instead of asking the users anything, sit behind them and watch them work for a while. I've found that I learned more about what people actually need that way than any question I've ever asked.
mathattack 10y ago
This is why iterative development is so important. Most non-tech people can't explicitly state what is best for them. Half the issue is not knowing what's possible. Half the issue is not being wired to be so explicit. This does out some burden on documenting what you did after the fact, but it beats the method of locking yourself into something that's wrong to begin with. The developers who can get enough domain knowledge to intuitively understand what's needed add enormous value. They can credibly suggest better ways to operate. I refer to it as the second 10X in productivity gains.

by rtpg 10y ago

blowski 10y ago

Behavioural driven development (BDD) encourages this process. The developers flesh out specific examples with the business people using readable language, and that becomes user acceptance criteria. It's no panacea, but it helps because it tries to prevent the business people dictating tech specifics, which the developers take too literally. For example, a business person says "when I press the submit button the results must be stored in MySQL". What they really mean is that whatever they entered into a form must be accessible later, but the developers now believe they must use MySQL and have submit buttons. By focusing on the "When I complete the form with data x, when I look at the form again later, then I see data x" you've moved the conversation to the business requirements and away from the perceived technical requirements.

ben_jones 10y ago
"And I need you to write it in PHP because it's cheaper" (not hating on modern PHP, just its reputation and 'outsourceability')
hueving 10y ago
mysql isn't a great example because that frequently comes up specifically because they have db analysts with skills in that system, its where the rest of their data is, already have support contracts for it, etc.
- blowski 10y ago
  While that might be a valid reason to require MySQL as a database, it's probably not a requirement of a given form. It might not even be necessary to have a database at all - it's important to understand 'why' the BAs are saying this, and not take their opinions as the definitive solution. For example, the ticket might look like "When I submit the form, then the DB Analysts are able to run reports on the submitted data".
- Cthulhu_ 10y ago
  The decision about what database to use still isn't a business requirement in that case though, more of a nonfunctional requirement that can be determined outside of a particular feature.
  - hueving 10y ago
    It very much is. If you told them you might decide not to use mysql so it would be completely incompatible with all of the data storage requirements, they would rightly tell you to get out for wasting their time. Your refusal to use the correct storage could cost them thousands of hours of labor establishing new processes for backups, BI integration, high availability, and just training on managing the system. I have worked with many companies where this was a very hard business requirement. Companies that dont care how the data is stored tend to be pretty small or not actually care that much about the data.
wolfgke 10y ago
> It's no panacea, but it helps because it tries to prevent the business people dictating tech specifics, which the developers take too literally. > For example, a business person says "when I press the submit button the results must be stored in MySQL". What they really mean is that whatever they entered into a form must be accessible later, but the developers now believe they must use MySQL and have submit buttons. So in other words business people are plain old lying about the requirements.
- blowski 10y ago
  Not lying, just not really understanding what they're talking about. For many BAs, 'MySQL' is interchangeable with 'database' so they don't realise that a different database might be a better solution. They're phrasing the requirement in terms of their best understanding of the implementation. The goal of BDD is to focus the language on the business domain instead.
  - tonyedgecombe 10y ago
    Yes, I've often seen business people pick up on technical terms without really understanding what they mean. It is our responsibility to coax users into giving non-technical requirements.
  - wolfgke 10y ago
    > For many BAs, 'MySQL' is interchangeable with 'database' so they don't realise that a different database might be a better solution. One minute of googling can be expected from BAs, too. > They're phrasing the requirement in terms of their best understanding of the implementation. Then they should say "to my knowledge MySQL is a popular database that I know of and is to my knowledge used a lot in the company, but if you know of a better implementation (I don't know much about that - I'm no computer scientist) use it instead.".
    - rahoulb 10y ago
      Or it's the developer's job to ask "why do you say that?" - the BA thinks they're being helpful and shortcutting a decision for you; the least you could do is try to be helpful back.
auvrw 10y ago
> Behavioural driven development (BDD) https://cucumber.io/ https://cucumber.io/ is a particularly awesome idea for specifying behavior. really want to try it out for a project sometime: the idea is to write the spec in these domain-specific "gherkin" files. i find it comparatively difficult to get get buy-in on collaborating on anything machine-readable, however, unless it's from people who are comfortable with general-purpose programming languages, anyway. nonetheless, in an industry where it's fairly standard for designers to build in domain-specific languages, i don't think it's an unreasonable skill for product managers to consider acquiring. any user experience stories from cucumber, etc. on rewrites or otherwise?
- lifeisstillgood 10y ago
  In my experience it's a joke. It's a way for devs to write executable document strings for the tests they also write. Absolutely no business person who is responsible at the level BDD works (the head of marketing for example) ever ever ever writes a working BDD description or frankly bothers reading them. Maybe just maybe they are useful intermediaries for Business analysts but most of those have been fired. Fitnese tests have more traction but then this is just exposing your API for user tests
  - quantumhobbit 10y ago
    This is my experience as well. Cucumber and the like sound like a way to get 'the business' involved more, but in practice the cucumber files just become yet another thing that the developers or testers have to write. At which point you are better off with more traditional testing methods.
    - auvrw 10y ago
      > the cucumber files just become yet another thing that the developers or testers have to write yep, if (and it's sounding more and more like "when," even outside of my anecdotal experience) that decision is made, there's not much point in using cucumber or similar. i was kind of hoping someone would say, "yea, our product manager writes domain-specific specification files, and the workflow is so much easier!" ... but no, i'll just continue being mildly cynical a/b the role of developers in industry.

Terr_ 10y ago

> Of course, this is a back-and-forth. Sometimes users aren't sure of what they want. Or your "product owner" doesn't really know the product and happens to be in a minimal-overlap timezone, and walking to the other side of the local office to ask Real-Users for feedback eventually generates a subtle reprimand about going through proper channels... Yeah, not planning to stick around.

tonyedgecombe 10y ago
If I look back over my career the projects where I had direct access to knowledgeable users were always easier and probably more successful. One of the red flags I started to notice was where the client liaison had only been working there for a couple of weeks or months.

cmdkeen 10y ago

This is my life. Replacing software that was written a decade+ ago so that the software has become the process. Users find is down right difficult to think in terms of what is going on a business process rather than the steps they have to do to force the computer to say yes. Many find it genuinely tricky to even describe in even real world terms what is going on without slipping into jargon that is actually just describing the existing system.

was_boring 10y ago
I'm currently doing the same and have found a lot of my time is spent interviewing managers and their reports to devine what problem they are solving with the software. In general they are completely unable to describe the job and problems they solve for the company, only how they use the software day to day, with out significant coaching and reframing.
- Terr_ 10y ago
  It's a vicious cycle: Nobody knows the vision, so they just iterate on the process, and the process is inscrutable, so nobody can extract a vision for it.

dagw 10y ago

In an ideal world, instead of asking the users anything, sit behind them and watch them work for a while. I've found that I learned more about what people actually need that way than any question I've ever asked.

mathattack 10y ago

This is why iterative development is so important. Most non-tech people can't explicitly state what is best for them. Half the issue is not knowing what's possible. Half the issue is not being wired to be so explicit. This does out some burden on documenting what you did after the fact, but it beats the method of locking yourself into something that's wrong to begin with. The developers who can get enough domain knowledge to intuitively understand what's needed add enormous value. They can credibly suggest better ways to operate. I refer to it as the second 10X in productivity gains.