Hacker News Reader

Comment by tbrownaw | Hacker News Reader

Sure, don't build your system to keep audit trails until after you have questions to answer so that you know what needs to go in those audit trails.

Don't insist on file-based data ingestion being a wrapper around a json-rpc api just because most similar things are moving that direction; what matters is whether someone has specifically asked for that for this particular system yet.

Not all decisions can be usefully revisited later. Sometimes you really do need to go "what if..." and make sure none of the possibilities will bite too hard. Leaving the pizza cave occasionally and making sure you (have contacts who) have some idea about the direction of the industry you're writing stuff for can help.

View on HN

    > Sure, don't build your system to keep audit trails until after you have questions to answer so that you know what needs to go in those audit trails...what matters is whether someone has specifically asked for that for this particular system yet.

I spent ~15 years in life sciences.

You're going to build an audit trail, no matter what. There's no validated system in LS that does not have an audit trail.

It's just like e-commerce; you're going to have a cart and a checkout page. There's no point in calling that a premature optimization. Every e-commerce website has more or less the same set of flows with simply different configuration/parameters/providers.

Going "what if?" and then validating a customer requirement that exists NOW is NOT the same thing as trying to pre-empt a customer's requirement which might exist in the future.

Audit trails are commonly neglected coz somebody didnt ask the right questions, not coz somebody didnt try to anticipate the future.

> Audit trails are commonly neglected coz somebody didnt ask the right questions, not coz somebody didnt try to anticipate the future.

But how do you ask "the right questions" without imagining many future possibilities and then trying to discern which ones are important?

It seems like a distinction without a difference to me.

Imagining future possibilities and implementing software to account for them are two different things.

The argument here is to validate those possibilities before acting on them.

> Imagining future possibilities and implementing software to account for them are two different things.

True.

> The argument here is to validate those possibilities before acting on them.

I agree this should be done. It's not clear that was the original argument, because the same guy previously wrote:

> The number 1 issue Ive experienced with poor programmers is a belief that theyre special snowflakes who can anticipate the future.

"The future" is a not-so-special case of "the now."

Reply on news.ycombinator.com