3 ms·

If you can't formulate actionable requirements, you're either not the domain expert, or not communicating properly with the domain expert. What your service lo

If you can't formulate actionable requirements, you're either not the domain expert, or not communicating properly with the domain expert. What your service looks like now and what it looks like in five years are obviously two different questions, but a proper analysis will divide the issue between now and 5 years from now and come up with requirements that fill the gaps. This doesn't mean things get set in stone and aren't adaptable to changing needs - when this condition is identified, the manger/developer need only apply the workflow again, and revise the specifications with the updated data, and a new development plan can be formulated. Maybe this is 'agile', but again - it speaks to the fact that waterfall is a naturally occurring phenomenon in engineering/technical matters, and thus should be applied consistently, completely, in order to provide fruitful results. > You cannot analyse how users will empirically interact with a product that does not yet exist. I don't agree with this, as I believe it is very, very glib. You can of course empirically interact, by wearing the user hat. Too often the developer/manager/user hats are considered adversarial - but when the decision is made to be flexible about which of these hats one is wearing, during analysis, makes all the difference between whether your product is successful or not. Software is a social service - rigid developers who cannot put on the user hat, are not providing the most intrinsic aspect of that service in their field. >You're presuming that it's possible to gather the "ideal requirements" when the project first starts, with enough due diligence - and also, that those requirements are fixed. I make the claim that this ideal can be attained, by ensuring that the early steps in the waterfall process are actually applied. You are correct in noting that "when you don't do things right, right things don't happen", however ..

pjc50 5y ago
> > You cannot analyse how users will empirically interact with a product that does not yet exist. > I don't agree with this, as I believe it is very, very glib This implies that all A/B testing is worthless, which is .. surprising.
- boffinAudio 5y ago
  > > You cannot analyse how users will empirically interact with a product that does not yet exist. You can certainly refine the software over time (A/B testing, if you will) to more closely attain the ideal, which you may not have well defined at the beginning of the project if you don't perform an adequate review of the needs of the user. But you can certainly also complete a user analysis that produces requirements, which when fulfilled, solve the problem in its entirety for the user. These two extremes are not absolute - sometimes, if the analysis is incomplete, A/B testing can rescue the project regardless of how poorly the first analysis was performed - but A/B testing, it could be argued, is applying waterfall properly: iteratively, as intended... but by all means, call it 'agile' if that makes the difference to the team involved.
  - Kim_Bruning 5y ago
    Wait a minute, you're a proponent of iterative approaches? In modern parlance most people put <non-iterative approaches> under the heading "waterfall". Can you specify which book/process/document(s) you are using in your day-to-day? This could be very interesting in future discussions with clients, to say the least!
    - Jtsummers 5y ago
      Waterfall is indeed a decidedly non-iterative approach. Anyone calling an iterative approach "Waterfall" is, well, confused about the terms. As soon as you add iteration, you're doing something else. Something intelligent. Often some variation of Iterative & Incremental (of which Scrum is an extreme form), Evolutionary, or perhaps the V-Model.
    - wheelinsupial 5y ago
      You might be interested in [1]. Supposedly it has the diagram that became known as the "waterfall" diagram. I don't think the author is advocating for what we normally associate with waterfall, though, as there are some additional steps they advocate for. They start with a simplified model, criticize it, and then add some more complexity to the model. Also to note, the paper is titled "Managing the Development of Large Software Systems." The author outlines 5 steps they believe need to be used to improve the success of a project. One step is called "do it twice" in which the author advocates the development of a prototype well in advance of delivering the final product. I think this is iteration. It's not indefinite iteration, but it's definitely not showing the big bang single release waterfall approach either. It also advocates to involve the customer throughout the process instead of only at the end. The summary says to refer to Figure 10 as the process that incorporates the author's steps. This final diagram is pretty far from the simplified and flawed waterfall picture that has been pulled from the front of the document. [1] http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...
LaundroMat 5y ago
"Software is a social service - rigid developers who cannot put on the user hat, are not providing the most intrinsic aspect of that service in their field." All the more reason not to rely on the proper wearing of a user hat (how are you going to know, by the way?), but actually work with the users instead and spend time creating the necessary artefacts to capture their perspective as soon and as well as possible.
wiedelphine 5y ago
the challenge I've always seen with putting the user hat on on so to speak is the difficulty in behaving as though you don't know how it works. I've seen enough user research where things that were obvious to the tram were not at all to the user.
Confiks 5y ago
> If you can't formulate actionable requirements, you're (...) not the domain expert Yes, fine. So there is no (true Scotsman) domain expert. Grandparent's point is also just that actually building the application and seeing how users interact with it is a valid method of analysis either in a prototype phase or actual evolving production software.
- devversthro 5y ago
  Is it valid tho? Deploying an app to get feedback is totally backwards. Make an interactive demo with no-code tools, record it and iterate on that based on stakeholder feedback.
  - WesleyJohnson 5y ago
    You're paying your most expensive employees to build something twice, and initially in a lower-fidelity tool that won't quite mimic the functionality or the look the of the final product. So you end up with stakeholders that don't understand it's just an interactive demo, and start wondering why things don't quite work. That or they buy into the demo, you build the real solution and then they're questioning why it doesn't quite work the same, or looks different, because when does an interactive demo in a mockup tool every really get it 100% right?
ivanbakel 5y ago
>but a proper analysis will divide the issue between now and 5 years from now and come up with requirements that fill the gaps The issue with the Waterfall model is that this approach doesn't work. Aiming for "now" means you come out with an outdated product in the future. Aiming for "5 years from now" means speculating on what users will eventually want, which is very error-prone. Trying to adjust course midway through is a nightmare - and completely defeats the point of trying to get requirements "right" the first time. >You can of course empirically interact, by wearing the user hat. This is not empirical: it does not involve observation or measurement of the real world. Speculating about user behaviour is no substitute for concrete data about how users actually behave.
- peteradio 5y ago
  Still you need requirements for what to build today. Often that is brushed aside as "details" in 2-week sprints, just start coding!
unethical_ban 5y ago
Do you work in software development or IT operations? Of if you did but no longer do, how long ago was it? Having been in the field for some time, and reading HN and talking with people in the field for as long, I believe your general attitude is one of someone who has an idea for how things should work in a stable, ideal world with unchanging toolsets and unchanging technologies. This is not the world of technology.
necovek 5y ago
> If you can't formulate actionable requirements, you're either not the domain expert, or not communicating properly with the domain expert. I want to highlight this, because it's almost universally true on any given project that there are no complete experts. But I'll be looking at domain not as a business domain, but actually considering if you can find a domain expert in the technology stack a project is planned in. When requirements are written up, there is never a domain expert on all the technologies to be used that is so experienced in the technology that they will not get things wrong. Software development is so intertwined and so fast-paced that we are at the mercy of tech stack we use too. Imagine you are well-versed in Postgres, but your new project requires you to use Postgres FTS extension. Without learning the ins-and-outs of Postgres FTS extension, you'll make grave estimation and "planning" mistakes. And then you are supposed to deploy on RDS instead, where there is another set of considerations. And this being a new project, you are asked to use asyncio psycopg for the first time, so there will be more gotchas as well. Basically, the number of "tools" we shift between is so vast that nobody can be an expert in them. The rate of change is huge as well. Just count all the Kubernetes tools today, and imagine having to use any one of a dozen of mini-k8s set-ups for local development. Just exploring the tech stack is a full time job for a dozen people, and you wouldn't be getting anything done. While others in the market would. So, if you are in a world where you've got your tech stack pre-set, you've got plenty of experience with it, and you are a domain expert on the business problem you are looking to solve, sure: waterfall-like approach will not put you at a disadvantage. But introduce any one of the newer components (cloud scale-out), and an approach to gain expertise first will have you run-down by the competition.

pjc50 5y ago

> > You cannot analyse how users will empirically interact with a product that does not yet exist. > I don't agree with this, as I believe it is very, very glib This implies that all A/B testing is worthless, which is .. surprising.

boffinAudio 5y ago
> > You cannot analyse how users will empirically interact with a product that does not yet exist. You can certainly refine the software over time (A/B testing, if you will) to more closely attain the ideal, which you may not have well defined at the beginning of the project if you don't perform an adequate review of the needs of the user. But you can certainly also complete a user analysis that produces requirements, which when fulfilled, solve the problem in its entirety for the user. These two extremes are not absolute - sometimes, if the analysis is incomplete, A/B testing can rescue the project regardless of how poorly the first analysis was performed - but A/B testing, it could be argued, is applying waterfall properly: iteratively, as intended... but by all means, call it 'agile' if that makes the difference to the team involved.
- Kim_Bruning 5y ago
  Wait a minute, you're a proponent of iterative approaches? In modern parlance most people put <non-iterative approaches> under the heading "waterfall". Can you specify which book/process/document(s) you are using in your day-to-day? This could be very interesting in future discussions with clients, to say the least!
  - Jtsummers 5y ago
    Waterfall is indeed a decidedly non-iterative approach. Anyone calling an iterative approach "Waterfall" is, well, confused about the terms. As soon as you add iteration, you're doing something else. Something intelligent. Often some variation of Iterative & Incremental (of which Scrum is an extreme form), Evolutionary, or perhaps the V-Model.
  - wheelinsupial 5y ago
    You might be interested in [1]. Supposedly it has the diagram that became known as the "waterfall" diagram. I don't think the author is advocating for what we normally associate with waterfall, though, as there are some additional steps they advocate for. They start with a simplified model, criticize it, and then add some more complexity to the model. Also to note, the paper is titled "Managing the Development of Large Software Systems." The author outlines 5 steps they believe need to be used to improve the success of a project. One step is called "do it twice" in which the author advocates the development of a prototype well in advance of delivering the final product. I think this is iteration. It's not indefinite iteration, but it's definitely not showing the big bang single release waterfall approach either. It also advocates to involve the customer throughout the process instead of only at the end. The summary says to refer to Figure 10 as the process that incorporates the author's steps. This final diagram is pretty far from the simplified and flawed waterfall picture that has been pulled from the front of the document. [1] http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...

LaundroMat 5y ago

"Software is a social service - rigid developers who cannot put on the user hat, are not providing the most intrinsic aspect of that service in their field." All the more reason not to rely on the proper wearing of a user hat (how are you going to know, by the way?), but actually work with the users instead and spend time creating the necessary artefacts to capture their perspective as soon and as well as possible.

wiedelphine 5y ago

the challenge I've always seen with putting the user hat on on so to speak is the difficulty in behaving as though you don't know how it works. I've seen enough user research where things that were obvious to the tram were not at all to the user.

Confiks 5y ago

> If you can't formulate actionable requirements, you're (...) not the domain expert Yes, fine. So there is no (true Scotsman) domain expert. Grandparent's point is also just that actually building the application and seeing how users interact with it is a valid method of analysis either in a prototype phase or actual evolving production software.

devversthro 5y ago
Is it valid tho? Deploying an app to get feedback is totally backwards. Make an interactive demo with no-code tools, record it and iterate on that based on stakeholder feedback.
- WesleyJohnson 5y ago
  You're paying your most expensive employees to build something twice, and initially in a lower-fidelity tool that won't quite mimic the functionality or the look the of the final product. So you end up with stakeholders that don't understand it's just an interactive demo, and start wondering why things don't quite work. That or they buy into the demo, you build the real solution and then they're questioning why it doesn't quite work the same, or looks different, because when does an interactive demo in a mockup tool every really get it 100% right?

ivanbakel 5y ago

>but a proper analysis will divide the issue between now and 5 years from now and come up with requirements that fill the gaps The issue with the Waterfall model is that this approach doesn't work. Aiming for "now" means you come out with an outdated product in the future. Aiming for "5 years from now" means speculating on what users will eventually want, which is very error-prone. Trying to adjust course midway through is a nightmare - and completely defeats the point of trying to get requirements "right" the first time. >You can of course empirically interact, by wearing the user hat. This is not empirical: it does not involve observation or measurement of the real world. Speculating about user behaviour is no substitute for concrete data about how users actually behave.

peteradio 5y ago
Still you need requirements for what to build today. Often that is brushed aside as "details" in 2-week sprints, just start coding!

unethical_ban 5y ago

Do you work in software development or IT operations? Of if you did but no longer do, how long ago was it? Having been in the field for some time, and reading HN and talking with people in the field for as long, I believe your general attitude is one of someone who has an idea for how things should work in a stable, ideal world with unchanging toolsets and unchanging technologies. This is not the world of technology.

necovek 5y ago

> If you can't formulate actionable requirements, you're either not the domain expert, or not communicating properly with the domain expert. I want to highlight this, because it's almost universally true on any given project that there are no complete experts. But I'll be looking at domain not as a business domain, but actually considering if you can find a domain expert in the technology stack a project is planned in. When requirements are written up, there is never a domain expert on all the technologies to be used that is so experienced in the technology that they will not get things wrong. Software development is so intertwined and so fast-paced that we are at the mercy of tech stack we use too. Imagine you are well-versed in Postgres, but your new project requires you to use Postgres FTS extension. Without learning the ins-and-outs of Postgres FTS extension, you'll make grave estimation and "planning" mistakes. And then you are supposed to deploy on RDS instead, where there is another set of considerations. And this being a new project, you are asked to use asyncio psycopg for the first time, so there will be more gotchas as well. Basically, the number of "tools" we shift between is so vast that nobody can be an expert in them. The rate of change is huge as well. Just count all the Kubernetes tools today, and imagine having to use any one of a dozen of mini-k8s set-ups for local development. Just exploring the tech stack is a full time job for a dozen people, and you wouldn't be getting anything done. While others in the market would. So, if you are in a world where you've got your tech stack pre-set, you've got plenty of experience with it, and you are a domain expert on the business problem you are looking to solve, sure: waterfall-like approach will not put you at a disadvantage. But introduce any one of the newer components (cloud scale-out), and an approach to gain expertise first will have you run-down by the competition.