5 ms·

I work on a bog standard ERP that was originally CRUD, but a whole module was refactored to event sourcing so clients could have a log and rollback. A couple o

I work on a bog standard ERP that was originally CRUD, but a whole module was refactored to event sourcing so clients could have a log and rollback. A couple of months back, a QA review reported a bug - the log system didn’t work. Turns out it’s never worked. Nobody has ever done a rollback either.

classabove 5y ago
this is absolutely terrifying
- fullstackchris 5y ago
  not if nobody uses it ¯\_(ツ)_/¯
  - nickkell 5y ago
    It's similar to database backups - hopefully you'll never need it, but at some point you might. At that point you'd hope your data was intact
    - blowski 5y ago
      The cost of doing a database backup is usually much lower than the cost of doing event sourcing.
square_usual 5y ago
Oh yeah, I've run into similar situations so many times. A critical piece of functionality was overnegineered and shipped, only months later did we find out that it never worked, and nobody found out because nobody used it.
shironandon 5y ago
Was working on a client's stack and this one critical piece using ES (written by "experts" who had since left the company) was throwing an error every week at 2 AM triggering alerts and chaos. After investigation I found nobody understood what it was doing or why. I thereby found the safest approach was to delete the ES implementation. After that everything worked and everyone was happy.
dm3 5y ago
I understand this thread is about dumping on ES... However, I must notice in your case it was an audit log. An ES system wouldn't work at all without access to events.
- blowski 5y ago
  Yeah, the ES side of the system worked but was completely unnecessary. So loads of extra complexity, with no value for the business.
  - kephasp 5y ago
    If the ES is "unnecessary", then it's not ES by definition. If events are not your source of truth, it's not event sourcing, just event logging.
    - blowski 5y ago
      I’m not sure what you mean. A car that sits in the driveway never being driven is still a car.
      - nivertech 5y ago
        It's a cargo-cult car;)

classabove 5y ago

this is absolutely terrifying

fullstackchris 5y ago
not if nobody uses it ¯\_(ツ)_/¯
- nickkell 5y ago
  It's similar to database backups - hopefully you'll never need it, but at some point you might. At that point you'd hope your data was intact
  - blowski 5y ago
    The cost of doing a database backup is usually much lower than the cost of doing event sourcing.

square_usual 5y ago

Oh yeah, I've run into similar situations so many times. A critical piece of functionality was overnegineered and shipped, only months later did we find out that it never worked, and nobody found out because nobody used it.

shironandon 5y ago

Was working on a client's stack and this one critical piece using ES (written by "experts" who had since left the company) was throwing an error every week at 2 AM triggering alerts and chaos. After investigation I found nobody understood what it was doing or why. I thereby found the safest approach was to delete the ES implementation. After that everything worked and everyone was happy.

dm3 5y ago

I understand this thread is about dumping on ES... However, I must notice in your case it was an audit log. An ES system wouldn't work at all without access to events.

blowski 5y ago
Yeah, the ES side of the system worked but was completely unnecessary. So loads of extra complexity, with no value for the business.
- kephasp 5y ago
  If the ES is "unnecessary", then it's not ES by definition. If events are not your source of truth, it's not event sourcing, just event logging.
  - blowski 5y ago
    I’m not sure what you mean. A car that sits in the driveway never being driven is still a car.
    - nivertech 5y ago
      It's a cargo-cult car;)