Comment by jascha_eng | Hacker News Reader

Comment by jascha_eng | Hacker News Reader

I wholeheartedly agree with this, when I started working on Kviklet we were a team of 3 and one of us was a lot more perfectionist than the others. It took a lot of convincing to even put our (tbf shitty) first website version up. Much more to release our repo. We lost that "co-founder" early on, but man I'm glad we released early and tried to sell.

It didn't work and we found no buyers but imagine we still were working on a product without knowing if anyone would ever want to pay for it, keeping our hopes up in the dark.

By now we went with the backup plan and open sourced and have a few cool users. Could maybe even say it's a small community: https://github.com/kviklet/kviklet

It's not the startup success story that I hoped for a year ago. But it's a lot better than still hoping for it and not being a bit more grounded. Also open-source doesn't mean I can never sell support or a premium version and still make a few bucks right? For now it's just a fun side project though.

> Pull Request-like Review/Approval flow for database queries

Terrible description IMO. a query should not need approval. Should use mutation or edit or update or modification. Even if query is technically correct it just sounds wrong and confusing.

You say it's confusing, but it's exactly what I expected it to be based on the description

I'm not quite sure what you mean. Maybe statement instead of query would be more accurate but I think people get the gist of it just fine.

Also, I disagree a manual query like: "select * from credit_cards;" should probably go through an approval flow if you have a table like that in your prod env.

A guy I used to work with said he worked for a company where all queries had to get approved by one of two full time DBAs - apparently with good reason as someone tried to modify a query that would have joined with half the rows in some gigantic table.

I worked at a place where only certain teams with a dedicated DBA were trusted to write direct queries (based on past incidents). All other teams had to ask a central DBA team to build stored procedures for any interaction with the database. If you think that this would create a huge backlog, you are correct... Non critical updates also needed to be coordinated with a "release train" where the code had to be ready 2 weeks before deployment due to the amount of testing it required. It was one of the major drivers behind an initiative to create micro services with separate databases that each team could do what they wanted with.

We ended up with a huge number of micro services and special orchestrator services to handle distributed transactions. But I guess that in a company of that scale, there are no perfect solution. At least we were able to make changes within minutes/hours instead of weeks.

Paradoxically we also got more pressure to deliver. In the past it was acceptable to leave a healthy buffer at the end of the scrum, to avoid missing the release train. This meant that we often spent the remaining buffer on refactoring, fixing small bugs that we felt we had time for or experimenting with POCs.

Yeah I guess I was too inexperienced at the time to ask how well it worked... but I guess like your experience, there would have been a fair backlog.

No, that's just what everyone calls SQL statements. It's fine.

I like this idea. It sits between "developers have access to prod" (no! bad idea!) and requiring everything to be signed in triplicate. It provides a low-friction way to make reviewable changes to prod.

Big difference between getting rows and changing rows

Reply on news.ycombinator.com