What he describes as bad about feature flags is exactly the reason I want them. In most cases, the timetable to put something online does not need to correlate with deployments or releases. So as a developer, I happily outsource that decision to the product manager, give them the ability to rollback a feature if it's not working and of course I'm giving them the capability to designate a testing group if the feature needs critical evaluation. Yes, managing feature flags is a pain, but they are essential for separating concerns between management and development.
It's good for another reason too: it decouples releases from deployments. Both deployments and releases are high-risk activities. Performing them together increases the risk multiplicatively.
Separating them does also create some incidental complexity (permutations of configurations, feature flag management) but in my experience that complexity is easier to analyse and deal with. (Dealing with feature flag complexity involves retiring them promptly, differentiating between feature flags and kill switches, etc.)
Of course, TFA knows this. They've moved the goalposts by making an extreme claim ("every" change behind a flag) and then argued against it.
I’ve noticed the same pattern. Most “rules” break down once systems get long-running or stateful. Separating decision-making from execution solved more issues for us than any single framework change.
"You can build a way of working that actually fits your team and company, without leaving everyone exhausted."
Many folks that get into software development underestimate how much human interaction and social skill is required to "work together" (me included). Software development is a team effort. Amazingly, just by saying the words "Scrum" or "Sprint", you can get people fuming.
I think it’s crucial to get the idea behind agile software development on every level in a company. It‘s simple, actually: Communicate and get stuff done. Produce something the customer can use, quick. That‘s it. How you get there is your journey to figure out.
With all the conservative movements that are going on in the world right now, I really hope we don’t go back to micromanaging as a counter movement to agile. That would be exhausting.
One of the biggest mind-shifts for me moving from senior dev to lead was realising that technology is much less of an issue than people. The impact of good communication leading to people understanding and agreeing on what they are working on is overwhelmingly greater than the technology choices we devs typically spend our time arguing about.
Decouple your planning cycles and development cycles. You develop at a constant pace, release whenever it is time/convenient to release. You plan regularly.
Planning is hard. Not doing it is not a great plan. Conflating development cycles and planning cycles, which is what a lot of teams end up doing with sprints, either sets the pace too aggressively or not aggressive enough. If it's too aggressive you end up shipping stuff that isn't ready. If it's not aggressive enough, you end up sitting on ready to ship code for too long.
In a company with multiple teams, planning gets harder. Especially if they span multiple timezones. Company sprints are a thing in some companies. But it's not necessarily very effective or scalable.
Calendar driven planning cycles where you ship whatever is in a shippable state is much more scalable and predictable. A lot of large OSS projects practice this (most of them) and it works in large companies too. It allows teams to self organize around known deadlines and work towards them.
That doesn't mean there is no planning but it is acknowledged that plans sometimes don't work out and that that's generally not a reason to stop a release train. If some planned thing isn't ready, park it on a branch and try to get it in the next time. Many OSS projects are very strict on this actually and ship regular as clockwork at a scale and quality level that puts most enterprise teams to shame. A lot of large companies that are typically involved with such OSS work as well do this internally as well. They are too large to orchestrate company wide sprints. So they rally around the calendar instead.
It doesn't actually exclude some teams in such contexts using e.g. Scrum or other agile methodologies. It just doesn't require it. And if you know your agile history, a lot of the Agile manifesto signees were very much into teams electing to use an Agile methodology rather than that being imposed, like is the practice in a lot of companies. It's just that a lot of OSS teams don't seem to bother with that.
> With all the conservative movements that are going on in the world right now, I really hope we don’t go back to micromanaging as a counter movement to agile. That would be exhausting.
Conservatives are more likely to prefer decentralised decision-making, I would say. At least nominally.
At a couple of places I worked at this was a hard compliance requirement: there had to be at least one review by a human to guard against an engineer slipping in malicious code (knowingly or otherwise).
Conversely, feature flags can create annoying issues due to compliance requirements.
I worked on an underwriting system where we had to be able to explain the reason for a decision. This meant that you needed to have on file both the state of the flag and the effective logic at the moment in time that a line of credit was offered to a customer.
Right, they add risk both in terms of inadvertently being turned on / off and also in terms of permutations of possible system configurations that need to be tested. Less of a problem for well engineered systems with good deployment practices but it’s rare to come across these mythical things. :)
It depends a lot on the domain. I've mostly worked in high compliance/regulation worlds. It can be kind of stifling, honestly, but "oops maybe we had the feature flag turned on" is not going to cut the mustard.
Most startups can ignore all that at least until they get to a scale where "run out of money, go bust" is not the biggest risk to their business :)
Yeah, there's whole industries where you simply cannot operate without enforcing this. The author's view is pretty narrow, both on this front and on the other points.
The author mostly write about average startup work, not about industries or more constrained environment. A good example of this is the sprint thing: you can do whatever pace you want when you work on your own product that is a web product, but as soon as you work on something with hardware or marketing, you can't just use random deadlines.
I was going to make the same observation - typically this will be defined in your secure development policy or similar, and be part of your ISMS controls for whatever frameworks you're aligning to.
It's possible this is more relevant in B2B contexts than B2C
Luckily, gemini catches a good amount of errors in PR reviews, less need for manual review unless you need to double check if the code structure and architecture is sane.
Absolutely _baffling_ piece of software. It's like if someone added vim keybindings to a TODO app, then switched the keyboard layout to COLEMAK, then removed all the UI controls.
I use it like once a quarter and trying to remember how to mark a task finished makes my eyes water.
My understanding is code reviews are needed as part of SOC-2 compliance. More to supplement automated testing than explicitly mandated. In other words, it makes auditors happy to check off the requirement about verifying changes going to prod.
The remarks about code comments are little too extreme in my opinion. Some code can be difficult to understand at face value. Like I’m writing a Vite plugin and it has code like this:
Unless you’ve written Vite/rollup plugins, which many folks haven’t, you’re going to appreciate a comment that at least points to some docs.
If anything, succinct code comments that explain obscure conventions or describe relevant critical requirements are worth their weight in gold because they are valuable tokens for a coding assistant.
I generally think most of the points made in the article are a little too extreme. Even feature flags are valuable if you’re trying to get something up for certain key customers to give feedback on while you iterate as an example. There is some hygiene required around maintaining and removing flags but I think that’s in the same bucket as writing tests, updating dependencies and refactoring code: worthwhile effort that additionally unlocks testing in production.
SOC 2 is in theory not that dogmatic about how reviews happen, and I do know people who do reviews after merge and deployment for example with soc2. You need to have compensating controls and work with your auditor. Most people just go with the default of reviews pre commit.
At my previous company, we shortened sprints, to make them fit in one single week. The satisfaction at the end of the week to have finished your planned work is unbeatable. And then we shortly stopped to call them sprints.
For a second, I read dogmas as some kind of X-mas for dogs, and I had a hard time parsing the title. To my defense, I haven't had any coffee yet today.
Every time I hear about tings like left-pad and is_even, I have to wonder... Are JS developers ok? There seem to be a lot of packages for extremely trivial things that nonetheless gets huge amounts of downloads
Many of these issues stem from the fact that Javascript doesn't have anything like stdlib or equivalents. I'm willing to bet money that most people can't write a bug free left-pad in Javascript on the first try without looking stuff up. Reaching for a dependency can make a lot of sense in that context.
I'm not a JS developer, so maybe they'd do it differently, but I'd probably do a bounds check, returning early if the target length is less than the input length, then create a string of spaces that is (targetlength - inputlength) long, and return them concatenated. Quick google shows theres a string.repeat method so probably use that (does that not count as part of an stdlib?).
Also, I'd bet money that most people couldn't write most things bug free on the first try without looking stuff up unless it's trivial
We’re generally fine and well paid. :) Frontend tooling churn is tiresome but the upside is that there is a lot of great tooling that more than makes up for any language deficiencies.
> With LLMs, it’s easier to both get into this mess and get out of it: it’s much easier to install an unneeded dependency by mistake, but it’s also quicker to implement ‘known’ solutions from scratch.
So, rolling your own say ‘cryptography’ is now good advice even if your solution is a worse, because we have LLMs?
>The CTO of a startup I worked at hated dependencies. We worked with some 3D calculations (software for drones), and he was writing tens of mathematical functions himself.
What a terrible idea. Implementing mathematical functions is extremely hard to do well. And by well I mean "function properly at all". This isn't about speed, this is about the fact that if you haven't done actual research into what you are implementing, then your implementation is going to full of errors, many of them totally non obvious. Rolling your DIY numerics, without spending a lot of time on it is just asking for problems.
What he describes as bad about feature flags is exactly the reason I want them. In most cases, the timetable to put something online does not need to correlate with deployments or releases. So as a developer, I happily outsource that decision to the product manager, give them the ability to rollback a feature if it's not working and of course I'm giving them the capability to designate a testing group if the feature needs critical evaluation. Yes, managing feature flags is a pain, but they are essential for separating concerns between management and development.
It's good for another reason too: it decouples releases from deployments. Both deployments and releases are high-risk activities. Performing them together increases the risk multiplicatively.
Separating them does also create some incidental complexity (permutations of configurations, feature flag management) but in my experience that complexity is easier to analyse and deal with. (Dealing with feature flag complexity involves retiring them promptly, differentiating between feature flags and kill switches, etc.)
Of course, TFA knows this. They've moved the goalposts by making an extreme claim ("every" change behind a flag) and then argued against it.
I’ve noticed the same pattern. Most “rules” break down once systems get long-running or stateful. Separating decision-making from execution solved more issues for us than any single framework change.
"You can build a way of working that actually fits your team and company, without leaving everyone exhausted."
Many folks that get into software development underestimate how much human interaction and social skill is required to "work together" (me included). Software development is a team effort. Amazingly, just by saying the words "Scrum" or "Sprint", you can get people fuming.
I think it’s crucial to get the idea behind agile software development on every level in a company. It‘s simple, actually: Communicate and get stuff done. Produce something the customer can use, quick. That‘s it. How you get there is your journey to figure out.
With all the conservative movements that are going on in the world right now, I really hope we don’t go back to micromanaging as a counter movement to agile. That would be exhausting.
One of the biggest mind-shifts for me moving from senior dev to lead was realising that technology is much less of an issue than people. The impact of good communication leading to people understanding and agreeing on what they are working on is overwhelmingly greater than the technology choices we devs typically spend our time arguing about.
Decouple your planning cycles and development cycles. You develop at a constant pace, release whenever it is time/convenient to release. You plan regularly.
Planning is hard. Not doing it is not a great plan. Conflating development cycles and planning cycles, which is what a lot of teams end up doing with sprints, either sets the pace too aggressively or not aggressive enough. If it's too aggressive you end up shipping stuff that isn't ready. If it's not aggressive enough, you end up sitting on ready to ship code for too long.
In a company with multiple teams, planning gets harder. Especially if they span multiple timezones. Company sprints are a thing in some companies. But it's not necessarily very effective or scalable.
Calendar driven planning cycles where you ship whatever is in a shippable state is much more scalable and predictable. A lot of large OSS projects practice this (most of them) and it works in large companies too. It allows teams to self organize around known deadlines and work towards them.
That doesn't mean there is no planning but it is acknowledged that plans sometimes don't work out and that that's generally not a reason to stop a release train. If some planned thing isn't ready, park it on a branch and try to get it in the next time. Many OSS projects are very strict on this actually and ship regular as clockwork at a scale and quality level that puts most enterprise teams to shame. A lot of large companies that are typically involved with such OSS work as well do this internally as well. They are too large to orchestrate company wide sprints. So they rally around the calendar instead.
It doesn't actually exclude some teams in such contexts using e.g. Scrum or other agile methodologies. It just doesn't require it. And if you know your agile history, a lot of the Agile manifesto signees were very much into teams electing to use an Agile methodology rather than that being imposed, like is the practice in a lot of companies. It's just that a lot of OSS teams don't seem to bother with that.
> With all the conservative movements that are going on in the world right now, I really hope we don’t go back to micromanaging as a counter movement to agile. That would be exhausting.
Conservatives are more likely to prefer decentralised decision-making, I would say. At least nominally.
> 2. Every code change must be reviewed
At a couple of places I worked at this was a hard compliance requirement: there had to be at least one review by a human to guard against an engineer slipping in malicious code (knowingly or otherwise).
Conversely, feature flags can create annoying issues due to compliance requirements.
I worked on an underwriting system where we had to be able to explain the reason for a decision. This meant that you needed to have on file both the state of the flag and the effective logic at the moment in time that a line of credit was offered to a customer.
They're useful, but not necessarily simple.
Right, they add risk both in terms of inadvertently being turned on / off and also in terms of permutations of possible system configurations that need to be tested. Less of a problem for well engineered systems with good deployment practices but it’s rare to come across these mythical things. :)
It depends a lot on the domain. I've mostly worked in high compliance/regulation worlds. It can be kind of stifling, honestly, but "oops maybe we had the feature flag turned on" is not going to cut the mustard.
Most startups can ignore all that at least until they get to a scale where "run out of money, go bust" is not the biggest risk to their business :)
Yeah, there's whole industries where you simply cannot operate without enforcing this. The author's view is pretty narrow, both on this front and on the other points.
The author mostly write about average startup work, not about industries or more constrained environment. A good example of this is the sprint thing: you can do whatever pace you want when you work on your own product that is a web product, but as soon as you work on something with hardware or marketing, you can't just use random deadlines.
I was going to make the same observation - typically this will be defined in your secure development policy or similar, and be part of your ISMS controls for whatever frameworks you're aligning to.
It's possible this is more relevant in B2B contexts than B2C
Luckily, gemini catches a good amount of errors in PR reviews, less need for manual review unless you need to double check if the code structure and architecture is sane.
Until it doesn't, you f up but at least it apologizes later
> Thanks Linear for supporting today’s article!
Wtf, it's like I'm reading a Youtube video, except it doesn't have the production costs of an actual Youtube video.
Absolutely _baffling_ piece of software. It's like if someone added vim keybindings to a TODO app, then switched the keyboard layout to COLEMAK, then removed all the UI controls.
I use it like once a quarter and trying to remember how to mark a task finished makes my eyes water.
My understanding is code reviews are needed as part of SOC-2 compliance. More to supplement automated testing than explicitly mandated. In other words, it makes auditors happy to check off the requirement about verifying changes going to prod.
The remarks about code comments are little too extreme in my opinion. Some code can be difficult to understand at face value. Like I’m writing a Vite plugin and it has code like this:
Unless you’ve written Vite/rollup plugins, which many folks haven’t, you’re going to appreciate a comment that at least points to some docs.If anything, succinct code comments that explain obscure conventions or describe relevant critical requirements are worth their weight in gold because they are valuable tokens for a coding assistant.
I generally think most of the points made in the article are a little too extreme. Even feature flags are valuable if you’re trying to get something up for certain key customers to give feedback on while you iterate as an example. There is some hygiene required around maintaining and removing flags but I think that’s in the same bucket as writing tests, updating dependencies and refactoring code: worthwhile effort that additionally unlocks testing in production.
> I generally think most of the points made in the article are a little too extreme. Even feature flags are valuable
From the article:
> I definitely think you should use feature flags - just not abuse them.
SOC 2 is in theory not that dogmatic about how reviews happen, and I do know people who do reviews after merge and deployment for example with soc2. You need to have compensating controls and work with your auditor. Most people just go with the default of reviews pre commit.
At my previous company, we shortened sprints, to make them fit in one single week. The satisfaction at the end of the week to have finished your planned work is unbeatable. And then we shortly stopped to call them sprints.
For a second, I read dogmas as some kind of X-mas for dogs, and I had a hard time parsing the title. To my defense, I haven't had any coffee yet today.
Anyhow, happy holidays to all of you!
That linear ad was icky.
Every time I hear about tings like left-pad and is_even, I have to wonder... Are JS developers ok? There seem to be a lot of packages for extremely trivial things that nonetheless gets huge amounts of downloads
Many of these issues stem from the fact that Javascript doesn't have anything like stdlib or equivalents. I'm willing to bet money that most people can't write a bug free left-pad in Javascript on the first try without looking stuff up. Reaching for a dependency can make a lot of sense in that context.
I'm not a JS developer, so maybe they'd do it differently, but I'd probably do a bounds check, returning early if the target length is less than the input length, then create a string of spaces that is (targetlength - inputlength) long, and return them concatenated. Quick google shows theres a string.repeat method so probably use that (does that not count as part of an stdlib?).
Also, I'd bet money that most people couldn't write most things bug free on the first try without looking stuff up unless it's trivial
We’re generally fine and well paid. :) Frontend tooling churn is tiresome but the upside is that there is a lot of great tooling that more than makes up for any language deficiencies.
is-even was most likely made as a joke
Sure, but it has 170k weekly downloads, and 61 packages depend on it, not all of which seem to be jokes (eg markdown-list and cli-barchart).
> With LLMs, it’s easier to both get into this mess and get out of it: it’s much easier to install an unneeded dependency by mistake, but it’s also quicker to implement ‘known’ solutions from scratch.
So, rolling your own say ‘cryptography’ is now good advice even if your solution is a worse, because we have LLMs?
>The CTO of a startup I worked at hated dependencies. We worked with some 3D calculations (software for drones), and he was writing tens of mathematical functions himself.
What a terrible idea. Implementing mathematical functions is extremely hard to do well. And by well I mean "function properly at all". This isn't about speed, this is about the fact that if you haven't done actual research into what you are implementing, then your implementation is going to full of errors, many of them totally non obvious. Rolling your DIY numerics, without spending a lot of time on it is just asking for problems.