16 ms·

I think "anticipating future requirements" is entirely the wrong way to approach the problem. Instead, you should look at how those requirements will be produc

I think "anticipating future requirements" is entirely the wrong way to approach the problem. Instead, you should look at how those requirements will be produced. If your architecture "thinks" the same way as your users, it will be able to be modified easily to include more of their thinking. So instead of trying to predict future requirements, you should attempt to capture and accurately model the way your users think about the problem. Sometimes that creates designs that mathematically/algorithmically seem pretty ugly. But in the long run I'll often discover that the ugliness exists for a reason--people mostly only add complexity to their mental models because that complexity allows them to solve a problem. So even when the domain expert's thinking seems overcomplicated, it's usually actually the least complicated model that accurately represents the problem.

j45 10y ago
It's a delicate, and necessary balance to pit future requirements or road mapping enough to get a sense of where the architecture could stay, or head in the next 6-18 months. Quite often in super early projects, the domain is not understood, so the architecture reflects the learning (or misguided assumptions).
tensor 10y ago
This has definitely not been my experience. Users vary greatly, some like simple mental models, but some love complex mental models. You definitely shouldn't be letting your users define your product. Rather, listen to your users problems, listen to what they think a solution is, then let your design team determine if there is a better and more simple solution. Sometimes there may not be, but often there is.
- devishard 10y ago
  Of course you shouldn't let users define your product. Nothing about what I said suggests that. When you get requirements from your users, they're going to mix in how they think about the problem with how they think that problem should be represented in the program. The problem with that is that they don't know what computers can do, so they can't possibly be expected to know how the problem should be represented in the program. And in fact, the UI, which is the only thing they ever see, will probably be more task-oriented than representation-oriented, so they probably will never see how your program actually models the problem and therefore won't be able to suggest good changes to it. Ultimately, though, there's an underlying mental model that the user is using for the task. And for most fields, there's really only one correct mental model, so I actually disagree that expert users have different mental models, at least not with significant differences.

j45 10y ago

It's a delicate, and necessary balance to pit future requirements or road mapping enough to get a sense of where the architecture could stay, or head in the next 6-18 months. Quite often in super early projects, the domain is not understood, so the architecture reflects the learning (or misguided assumptions).

tensor 10y ago

This has definitely not been my experience. Users vary greatly, some like simple mental models, but some love complex mental models. You definitely shouldn't be letting your users define your product. Rather, listen to your users problems, listen to what they think a solution is, then let your design team determine if there is a better and more simple solution. Sometimes there may not be, but often there is.

devishard 10y ago
Of course you shouldn't let users define your product. Nothing about what I said suggests that. When you get requirements from your users, they're going to mix in how they think about the problem with how they think that problem should be represented in the program. The problem with that is that they don't know what computers can do, so they can't possibly be expected to know how the problem should be represented in the program. And in fact, the UI, which is the only thing they ever see, will probably be more task-oriented than representation-oriented, so they probably will never see how your program actually models the problem and therefore won't be able to suggest good changes to it. Ultimately, though, there's an underlying mental model that the user is using for the task. And for most fields, there's really only one correct mental model, so I actually disagree that expert users have different mental models, at least not with significant differences.