3 ms·

That is why talking is important. Get all (or a good sample of all) the people who are going to use your software and discuss a draft/UI mockup. Get them in the

by atoav 3y ago

That is why talking is important. Get all (or a good sample of all) the people who are going to use your software and discuss a draft/UI mockup. Get them in the mood where they go wild and creative and spit out all kind of ideas. Rinse and repeat till you get a coherent picture and a list of likely additional requirements. Add potential future requirements that you could think of and keep them in the back of your mind. When everything is done you can offer those. This might not catch all the surprise requirements, but it might catch the worst ones. A sure way to get surprised is to do the opposite: - don't talk to the people who use your software, but some middle-men - just take the customers first idea as gospel and assume they disected the problem space themselves - keep everything constrained and never let anybody get wild or crazy with ideas - don't anticipate potential future requirements and don't let them influence your decisions ever Of course those things don't come for free, but it is important to realize that the initial phase of a project is crucial also for the impression your shop will leave behind. If people feel they have been heared and had a chance to come to a shared understanding with you, they are less likely to view your software in an unfairly harsh light later on. They will remember this and will hire you for the next thing.

thom 3y ago
Yeah this sort of hypothetical paper prototyping is really useful because you can map out the whole territory you're operating in, instead of just finding a single point to work towards. I think the approach actually applies beyond just UI mockups - if you can mock out whole workflows in the business with the right stakeholders/personas represented, you can also start to build up a loose dataflow model right there, and also understand some of the likely articulation points of the resulting systems, just by having conversations like "what if we needed this human process to happen first" or "what if we eventually built a model to automate this process" etc.
- danbruc 3y ago
  This is no problem for the initial version but businesses and the environment they operate in change, you are in general not going to figure out what you will need ten years down the road. And then it really depends, maybe everything is fine, but maybe you also made choices early on that allowed you to save time and the price of limited flexibility and this eventually bites you.
  - atoav 3y ago
    What you say is correct. But there is literally no way to figure out what will be needed 10 years down the road using any kind of methodology. If you are clever you try to use stable things, technology that is likely to be an ok choice years down the line and maintain an architecture that is easy to maintain and modify. But if your software managed to survive a decade of good use without any major issues I'd already count that as a job well done.
    - danbruc 3y ago
      I think there is a tradeoff, you can pick some customizable off the shelf software or some low code platform that fits your initial needs, that will give you speed at the risk of not being flexible enough later. Or you fire up your IDE and start from scratch, do everything on your own, that will make you slow, at the very least in the beginning, but you get all the flexibility and also all the opportunities to screw it up.
  - thom 3y ago
    I'm not sure what you're responding to. I'm suggesting you specifically model how things might change to give you a better chance of identifying the right articulation points for your architecture - as in, what if I have to drop one side of this because our assumptions were wrong, but I don't want to lose _everything_? You can't predict the future, but you can built at least _some_ flex into your business and platforms.
    - danbruc 3y ago
      See my comment on the sibling comment, I was talking about the trade off between speed and flexibility.
      - thom 3y ago
        A tradeoff that’s much easier to reason about with more information.
- atoav 3y ago
  I specifically did say you won't catch all future requirements this way. But you want a mechanism to catch the reasonable and likely ones. And for the unreasonable ones you can always say: "The system we originally intended wasn't meant to do this technically. If you want to have this feature we can help you but it will cost $X and this is a entirely new project." If a graphic designer designs a logo and the customer in the end has the idea that they want that logo as a stamp or in a black and white version ANY graphic designer worth their salt will have anticipated this. If they want a 3D animated video of the whole thing rotating that is a different thing.
danbruc 3y ago
This is in general hopeless, you will not be able to anticipate where the business moves over the coming years. Does not even have to be the business itself, could also be the regulatory environment or whatnot. When you decide to not write your application from scratch, you will always have the risk of running into limitations eventually. If it is low level stuff like your O/R mapper or your logging framework, that is no big deal, but if it is some high-level application or business framework, then things might get tricky. In one of the projects I worked on there suddenly came the requirement that they need metrics on how long people were working on different screens, completely unrelated to the actual business. No big deal in general, just put some code in some base class to collect the current time on enter and on leave. But the application framework we used just does not allow this, you can not modify the base classes used for screen, you have to add code for the enter and leave event on each screen individually. It just never occurred to the people that made the framework that you might want to do the same thing on all your screens and nobody expected that we might ever need this either, until we did.

by atoav 3y ago

thom 3y ago

Yeah this sort of hypothetical paper prototyping is really useful because you can map out the whole territory you're operating in, instead of just finding a single point to work towards. I think the approach actually applies beyond just UI mockups - if you can mock out whole workflows in the business with the right stakeholders/personas represented, you can also start to build up a loose dataflow model right there, and also understand some of the likely articulation points of the resulting systems, just by having conversations like "what if we needed this human process to happen first" or "what if we eventually built a model to automate this process" etc.

danbruc 3y ago
This is no problem for the initial version but businesses and the environment they operate in change, you are in general not going to figure out what you will need ten years down the road. And then it really depends, maybe everything is fine, but maybe you also made choices early on that allowed you to save time and the price of limited flexibility and this eventually bites you.
- atoav 3y ago
  What you say is correct. But there is literally no way to figure out what will be needed 10 years down the road using any kind of methodology. If you are clever you try to use stable things, technology that is likely to be an ok choice years down the line and maintain an architecture that is easy to maintain and modify. But if your software managed to survive a decade of good use without any major issues I'd already count that as a job well done.
  - danbruc 3y ago
    I think there is a tradeoff, you can pick some customizable off the shelf software or some low code platform that fits your initial needs, that will give you speed at the risk of not being flexible enough later. Or you fire up your IDE and start from scratch, do everything on your own, that will make you slow, at the very least in the beginning, but you get all the flexibility and also all the opportunities to screw it up.
- thom 3y ago
  I'm not sure what you're responding to. I'm suggesting you specifically model how things might change to give you a better chance of identifying the right articulation points for your architecture - as in, what if I have to drop one side of this because our assumptions were wrong, but I don't want to lose _everything_? You can't predict the future, but you can built at least _some_ flex into your business and platforms.
  - danbruc 3y ago
    See my comment on the sibling comment, I was talking about the trade off between speed and flexibility.
    - thom 3y ago
      A tradeoff that’s much easier to reason about with more information.
atoav 3y ago
I specifically did say you won't catch all future requirements this way. But you want a mechanism to catch the reasonable and likely ones. And for the unreasonable ones you can always say: "The system we originally intended wasn't meant to do this technically. If you want to have this feature we can help you but it will cost $X and this is a entirely new project." If a graphic designer designs a logo and the customer in the end has the idea that they want that logo as a stamp or in a black and white version ANY graphic designer worth their salt will have anticipated this. If they want a 3D animated video of the whole thing rotating that is a different thing.

danbruc 3y ago

This is in general hopeless, you will not be able to anticipate where the business moves over the coming years. Does not even have to be the business itself, could also be the regulatory environment or whatnot. When you decide to not write your application from scratch, you will always have the risk of running into limitations eventually. If it is low level stuff like your O/R mapper or your logging framework, that is no big deal, but if it is some high-level application or business framework, then things might get tricky. In one of the projects I worked on there suddenly came the requirement that they need metrics on how long people were working on different screens, completely unrelated to the actual business. No big deal in general, just put some code in some base class to collect the current time on enter and on leave. But the application framework we used just does not allow this, you can not modify the base classes used for screen, you have to add code for the enter and leave event on each screen individually. It just never occurred to the people that made the framework that you might want to do the same thing on all your screens and nobody expected that we might ever need this either, until we did.