Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When deployments are easy, code becomes simpler

bitbytebit.substack.com

Post reply on HN
Print view View original

41–50 of 124 posts

Re: When deployments are easy, code becomes simpler

#41

Post by ehnto »

mvdtnz wrote: post #37
daigoba66 wrote: post #32

As an aside, those “feature flags as a service” tools have some neat features, but are just way too expensive for what most apps probably need: simple binary flags that can change at runtime. Example: just use a database table. Query and cache in memory for 60s. If you want, build a simple internal web page or tool to toggle flags. This works, and scales (from experience). Do many apps really need A/B testing or segm…

"Just use a database table" solves for the simplest cases - a single monolithic app. It works incredibly well in this case. It falls apart when I need to turn features on across multiple apps together.

I think OPs point was a simple app doesn't need this whole suite of tools, but you pay for them anyway, which makes it a bad cost/value proposition for simple apps.

So yes a more complex situation could benefit from all this extra tooling and complexity but otherwise it is dead weight/cost.

Re: When deployments are easy, code becomes simpler

#42

Post by blq10 »

catchnear4321 wrote: post #11
digging wrote: post #9

Earlier quoted context omitted.

> My cynicism is probably not the best approach to change the world for the better, so any hint on how to teach younger colleagues to stop snacking micro service candy is much appreciated. I could be way off base here, but I'd bet a lot of junior devs are just trying to stand out. They want respect, raises, promotions, and new job offers. Invisible good solutions don't bring those.

junior devs are junior devs in part because they do not yet know that there is no guarantee that anyone else has been keeping track of their victories come review time. solutions are only invisible due to a lack of sufficient documentation and communication. boring solutions are part of the job. they can be fun if the goal is shifted from implementing to automating. none of this to say you are wrong, but a junior dev…

Nobody cares about invisible good solutions, because invisible solutions are simple - and developers are to one degree or another, rated on the degree of complexity they can deal with and how smart they can be. It is common here to understand the cleverness behind just doing the dumb thing, but it is not common in many places.

Re: When deployments are easy, code becomes simpler

#44

Post by lmm »

rvrs wrote: post #18
mvdtnz wrote: post #17

Earlier quoted context omitted.

I'd rather have unfinished feature flagged code in master (and therefore production) than have the same unfinished code withering in a long running branch, diverging from master and causing integration problems later. > Either finish your work or delete the unneeded code. It's work in progress. We're working on getting it finished.

>It's work in progress. We're working on getting it finished. So finish it and then I will merge your PR ;) What's the use of putting it in master if it's not finished? It's the author's responsibility to get it merged successfully. If they're taking too long and have to rebase and re-work their code to integrate, that's on them. Pushing it into master is either wasting a reader's time (per the original comment) or,…

> What's the use of putting it in master if it's not finished?

Visibility, and avoiding duplicated effort. What's the use of keeping it out of master?

> Pushing it into master is either wasting a reader's time (per the original comment)

The new parts they'll have to read sooner or later, and for the parts that are changing it's better for them to read the new version than the old version.

> or, worse, inviting an uninitiated collaborator to use it and cause an incident.

Why would that cause an incident? Having someone see the "upcoming" code and realise they can reuse it in something they're working on is the ideal outcome.

Re: When deployments are easy, code becomes simpler

#45

Post by vrosas »

chiefalchemist wrote: post #15
kdmccormick wrote: post #14

Earlier quoted context omitted.

Seems cynical. In my experience, junior devs are just more susceptible to cargo-culting and getting excited about cool ways to apply the things they learned in undergrad. I haven't actually seen a lot of "resume-driven development" in my (relatively limited) time in the industry... just well-intentioned eager people with more knowledge than wisdom.

> just well-intentioned eager people with more knowledge than wisdom. Yup. And that by definition is a junior colleague ;)

I like to describe my colleagues as the delta between how smart they are, and how smart they _think_ they are. “Junior” devs almost always fall in the “wide gap” spectrum but it is by no means restricted to any age group.

Re: When deployments are easy, code becomes simpler

#46

Post by ketchupdebugger »

>Much of the time I’m using flags so I can commit unfinished code because I don’t want to create a separate branch and have one source of truth

This seems like an incident in the making. If each dev on a team commits unfinished code into prod behind flags, the whole project is going to be littered with flags and unfinished code. Some intern is going to delete a flag or an if check and then everything is going to break.

Re: When deployments are easy, code becomes simpler

#47

Post by vrosas »

totallywrong wrote: post #38

TIL there's an industry around feature flags. I can see how it can be useful, but imo if you're doing the modern approach with k8s, gitops, etc. deployments are too easy to bother with this.

Even if deployments took 2 seconds you’ll still find a frontend engineer who wants to “iterate faster” and an ear attached to the purse strings who will listen.

Re: When deployments are easy, code becomes simpler

#48

Post by riffraff »

ketchupdebugger wrote: post #46

>Much of the time I’m using flags so I can commit unfinished code because I don’t want to create a separate branch and have one source of truth This seems like an incident in the making. If each dev on a team commits unfinished code into prod behind flags, the whole project is going to be littered with flags and unfinished code. Some intern is going to delete a flag or an if check and then everything is going to brea…

Why would an intern remove a flag? The flag is not special, it's code like everything else, with tests, ownership, documentation etc..

The idea of the "unfinished code behind a flag" is to be able to work on trunk instead of a long lived branch, increasing the pace of development and reducing integration costs.

This works quite well in my experience, and definitely better than "let's keep a huge branch in sync with the main one for 3 months while we finish".

The problem IME is the opposite: flags do not get removed fast enough, littering the code past their utility.

Re: When deployments are easy, code becomes simpler

#49

Post by mrweasel »

ljm wrote: post #24
dmoy wrote: post #2

> Is this bad because I now have to do a deployment to enable the feature? ... I would argue as long as your deployments are easy, this is the better way to do things because it reduces the complexity of integrating with a third-party tool. Shoot, even when it's all first party tooling, I prefer a release-flags-and-binary as an atomic unit. If the flags and binary are going out as a single push, it simplifies a lot o…

The problem is when your deployment depends on external state like a database. Code rollbacks are trivial, rolling back state (if you even can) is not.

One of the very best development teams I worked with had an interesting take, they always did database migrations first. Any new state that was to be added to the system could only be done so by first adding the new database fields or tables. This ensure that version 1 of the code would work with version 1 and 2 of the database. They would then roll out version 2 of the code, but have the new features hidden behind a feature flags (in the database), ensuring that version 2 could run, without using the new database schema. Once they where confident that everything was still running on version 2 of the code and database they'd enable the new feature. Later the feature flag could be migrated from the database to a properties file, saving the database lookup.

I wouldn't necessarily call this approach simple, but it was incredibly safe and rollbacks was always a none event.

Re: When deployments are easy, code becomes simpler

#50

Post by hsn915 »

ketchupdebugger wrote: post #46

>Much of the time I’m using flags so I can commit unfinished code because I don’t want to create a separate branch and have one source of truth This seems like an incident in the making. If each dev on a team commits unfinished code into prod behind flags, the whole project is going to be littered with flags and unfinished code. Some intern is going to delete a flag or an if check and then everything is going to brea…

There's nothing special about flags that makes them more likely for an intern to delete by mistake.

It's just code.

If the team is so bad that an intern can mess things up, they will, and the mess will have nothing to do with feature flags.

Post reply on HN