3 ms·

Requirements is always the problem: capturing and realizing user-desired system behavior in a form programmers can build from. Unfortunately big design upfront

Requirements is always the problem: capturing and realizing user-desired system behavior in a form programmers can build from. Unfortunately big design upfront tries to nail these down at the beginning, an Sisyphean task because almost no user knows exactly what they need. Agile development should instead not try to capture every requirement, but get a few big things right to be usable and organically grow incrementally with continuous feedback from users throughout the development process. (It's an anti-pattern to stay incommunicado from users for too long or only involve them at the end for UAT.) Formal requirements in the form of rigid specifications and documentation in waterfall development is useful in high risk, well-specifiable projects such as a nuclear reactor SCADA control system.

magicalhippo 3y ago
> It's an anti-pattern to stay incommunicado from users for too long or only involve them at the end for UAT. In my experience it is key to involve users at a very early stage, as even just one level up key processes are lost. Sure managers known the happy path, but often the weird exceptions that needs to be handled aren't documented and get forgotten by higher-ups.
majesticglue 3y ago
there's a lot you can still do before involving the pricey engineers. Having people just sit down and consider requirements, talking to users, and thinking about what the app should essentially do, while also incorporating a ux/designer as needed to create mocks prior to building an application is still way more cost effective than just telling a developer to "build me an app that ingests all the data at our company"...which is a lovely experience I've had (I'm exaggerating but I had a one page doc about a useless description about data ingestion with no description about users). Heck I've even built hobby projects where I considered many of the details of requirements beforehand and saved myself a lot of time in developing features I wasn't sure about.

magicalhippo 3y ago

> It's an anti-pattern to stay incommunicado from users for too long or only involve them at the end for UAT. In my experience it is key to involve users at a very early stage, as even just one level up key processes are lost. Sure managers known the happy path, but often the weird exceptions that needs to be handled aren't documented and get forgotten by higher-ups.

majesticglue 3y ago

there's a lot you can still do before involving the pricey engineers. Having people just sit down and consider requirements, talking to users, and thinking about what the app should essentially do, while also incorporating a ux/designer as needed to create mocks prior to building an application is still way more cost effective than just telling a developer to "build me an app that ingests all the data at our company"...which is a lovely experience I've had (I'm exaggerating but I had a one page doc about a useless description about data ingestion with no description about users). Heck I've even built hobby projects where I considered many of the details of requirements beforehand and saved myself a lot of time in developing features I wasn't sure about.