Or perhaps it was because there was no layer between those developers and the users, no translations, no requirements gathering, no cards. Just you standing at the desk of the customer service rep, asking them how you could make their life better.

I do miss that often, too. We have so many applications and services in use with shitty bugs, which could probably be fixed in a few days. Of course, all those are proprietary shovelware that I'm not allowed to fix anyways, but the thought remains.

Instead, we just repeatedly spend years building up intricate systems only for them to get cancelled for no good reason, right when they're about to become useful.

I worked on a system whose database setup looked kind of like this. Interesting to see, that they weren't the only ones using that approach.

We had an online database for online transactions, all tables used a sequence generator table (basically a key/value with the key being table name and the value being the last id) l, every few minutes all the new transactions where dumped into a second instance for research and monitoring. Every night a job started, that first dropped all the transactions older than a few weeks from the online db and then exploded every single transaction into a bunch of id, key, value tuples. These were then push/pulled (very weird construct) into the datawarehouse. Since each new value was its own table, we had something like 20 tables, mostly being nulls. You might had columns like serviceA_call1_customer3_adress_streetname. Absolutely bonkers and only one man understood that thing.

This may sound like a mess to you. But it was remarkably enjoyable to work in. Gone were the concerns of code duplication. Gone were the concerns of consistency. Gone were the concerns of extensibility. Code was written to serve a use, to touch as little of the area around it as possible, and to be easily replaceable. Our code was decoupled, because coupling it was simply harder.

Incredible

"Gilfoyle" is an anagram of Cthulu.

My god, this speaks to me.