Hacker News Reader

Comment by morkalork | Hacker News Reader

The worst code I've ever written is because of shifting or unforeseen requirements. It doesn't matter how good the architect is if the foundation is built on sand.

View on HN

100% agreed. But to me that sounds like a typical case of rushing instead of working like responsible engineers. If the foundation is built on sand then that needs to be fixed. Engineers being expected to magically paper over a lack of clear requirements is what leads to bad code. I am fine with helping gather the requirements but if I get a list of unclear and shifting requirements and just is expected to fix it I obviously will fail.

> If the foundation is built on sand then that needs to be fixed.

Except this is the system working as designed. Leadership 1000% wants to do things as fast and as cheap as possible.

It works as designed if your goal is to get your next promo package. It does not work as designed if the goal is to actually make the company more profitable. This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term.

It depends a lot on the circumstance.

Profitable over what time horizon?

Any really. Rushing the team is more about looking good so you get promoted than about profit in any form.

> This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term.

Being delivered faster or cheaper isn’t the goal. The goal is to look good while doing it. Telling your bosses ‘Yes sir!’ Is apparently a lot more palatable than saying ‘No can do’.

I've worked on projects where if you wait for the requirements to be firmed up, you'll never be able to do anything. Depends on what you're trying to build if that means you need to stop and figure out the requirements or if you need to just deal with the shifting sands. Aircraft built for moving requirements don't work so well; but lots of things are fine with moving requirements. It'd sure be nice to know how users are going to use your product before you build it, but sometimes you build what you think is wanted, and people only use part of it or use it for different things than what was intended, and it's better to adjust and refocus than to start a whole new development process with the found requirements.

Of course you should not wait around. I think rather the opposite that the engineers should be more involved in working on the requirements. The issue is more rushing and being expected to magically just conjure something. Changing requirements is a fact you just have to live with in many industries.

Changing requirements is fine. Changing requirements when it was eminently avoidable is very, very bad.

If I asked you 6 months ago if you might ever consider something other than credit card payments, urged you to seriously consider this and you say no, you shouldn’t come to me now and say that bank transfers (bank transfers!) are absolutely indispensible.

Reply on news.ycombinator.com