3 ms·

> The complexity doesn't come from the requirements. It comes from the constraints: "We only use this ancient version of this database", "We didn't tell you at

by clarry 7y ago

> The complexity doesn't come from the requirements. It comes from the constraints: "We only use this ancient version of this database", "We didn't tell you at the start that the users expect to interface with this system via email". Those constraints sound like requirements: we require that only this ancient version of this database is used. We require that users can interface with this system via email. Different term, same thing. That's in the bucket with the kind of stuff that I'm advocating people should pay more attention to up-front. Gathering these requirements before you start designing anything is a big deal. If you failed to do so, then you failed to do a proper job at the part I called sitting down and figuring out the actual requirements.

moron4hire 7y ago
A lot of places will never give you access to the people who can answer those questions and will expect you to start work right away and "quit wasting time" or they "put you on a Performance Improvement Plan"/fire you. The problem is not developers doing a bad job, it's management preventing them from doing good job.
- clarry 7y ago
  Agreed, the industry isn't actually allowing engineers to engineer. https://news.ycombinator.com/item?id=22391047 https://news.ycombinator.com/item?id=22391047
thu2111 7y ago
There's another problem not really addressed here; when the requirements you get from the customer are wrong/make no sense/could be done better another way/are for things they won't actually use/are a part of some internal political struggle. This is something that crops up quite frequently in my work. We'll get a requirement like this: "the app should use HTTP like a web browser, not a different protocol". On inquiry as to why it's so important for something that's not a web browser to so strongly resemble a browser, the answer will be something like, "so we don't have to ask IT to open a firewall port". The person deploying the software could just fill out the paperwork, but they find it easier to "require" that the software sneak past their own corporate security controls. This is the sort of requirement that is real in some sense and not in another sense, depending on whether you define the customer as whoever you're talking to on the phone right now or the business as a whole.
nradov 7y ago
You're missing the point. In the real world some of those requirements are unknowable on any reasonable cost or schedule basis regardless of your analysis process. From an economic standpoint sometimes the best choice is to accept some uncertainty and get moving.

by clarry 7y ago

moron4hire 7y ago

A lot of places will never give you access to the people who can answer those questions and will expect you to start work right away and "quit wasting time" or they "put you on a Performance Improvement Plan"/fire you. The problem is not developers doing a bad job, it's management preventing them from doing good job.

clarry 7y ago
Agreed, the industry isn't actually allowing engineers to engineer. https://news.ycombinator.com/item?id=22391047 https://news.ycombinator.com/item?id=22391047

thu2111 7y ago

There's another problem not really addressed here; when the requirements you get from the customer are wrong/make no sense/could be done better another way/are for things they won't actually use/are a part of some internal political struggle. This is something that crops up quite frequently in my work. We'll get a requirement like this: "the app should use HTTP like a web browser, not a different protocol". On inquiry as to why it's so important for something that's not a web browser to so strongly resemble a browser, the answer will be something like, "so we don't have to ask IT to open a firewall port". The person deploying the software could just fill out the paperwork, but they find it easier to "require" that the software sneak past their own corporate security controls. This is the sort of requirement that is real in some sense and not in another sense, depending on whether you define the customer as whoever you're talking to on the phone right now or the business as a whole.

nradov 7y ago

You're missing the point. In the real world some of those requirements are unknowable on any reasonable cost or schedule basis regardless of your analysis process. From an economic standpoint sometimes the best choice is to accept some uncertainty and get moving.