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.
"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.
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.
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.
Without contradicting "in general", my anecdotal experience is that even well-oiled teams with good internal communication and team spirit can have bad technologies that end a business.
You may well be correct about the general case: I've not witnessed cat-herding, the closest was managment constantly chasing new shinies and one time forgetting to tell the devs about the latest change.
> 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 :)
This is very true and is exactly why there is no magic right answer other than “it depends”.
There are different stages of company lifecycle, different industries, different regulatory environments etc.
The processes put in place always have a cost - if picked appropriately it is worth paying, otherwise it is a waste that can hurt or even kills a project. This balance is the “art” of the job that I personally am only starting to probe around at my level and so it is still quite interesting. :)
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.
Depends on how good the human reviewers are. It's hard to give a thorough code review, you need to understand the code and requirements, pull the changes locally, manually test the PR, think about security, readability, catch line level bugs like bad conditionals, but also think about the overall structure (classes, patterns, systems). But this requires a lot of effort, especially with larger PRs and it's easy for things to slip through. Nothing is perfect, but you can think of AI review like a supercharged linter, it might not suggest an alternative approach, but it will point out some glaring omissions or unhandled exceptions, etc.
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.
The ad was deceptively inlined in the article IMO. I read most of the ad before I realized it was an ad. I don’t begrudge anyone who wants to monetize with ads but I do think it should be clear what is sponsored. I felt fooled and I stopped reading right now.
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.
Yep, no dispute here. It's just that my and other people's experience is that SOC2 controls are usually passed down by edict and whether you review before or after merge, there's typically (from my experiences at SaaS/Fintech) some form of reviews happening. I've done both styles in the same company for different reasons.
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
That's how I imagine most people would start, but unfortunately that will break on anything beyond basic ascii strings. Arabic, Hindi, Vietnamese, etc use diacritics, combining characters and so on, and this isn't even getting into the mess of emojis and their modifiers.
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.
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.
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.
This just reads like a bucketlist of product recommendations.
I found the following to be most amusing, as the author explains the idea of “Iterations” without mentioning them by name:
> We work in 6-week cycles. Once a cycle is over, we take one or two weeks off of scheduled projects so everyone can roam independently, fix stuff up, pick up some pet projects we’ve wanted to do, and generally wind down prior to starting the next six week cycle.
> Note: These are not sprints. I despise the word sprints. Sprints and work don’t go together. This isn’t about running all out as fast as you can, it’s about working calmly, at a nice pace, and making smart calls along the way. No brute force here, no catching our collective breath at the end.
>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.
I did a course at university on mathematical stability in floating point algorithms which mainly taught me there's no way I was smart enough to write correct code.
Plus then making them work optimally on N different microarchitectures.
I actually wonder what language/system they were using that lacked this in the stdlib or at least in very widely available libraries.
> 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?
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.
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.
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.
You may well be correct about the general case: I've not witnessed cat-herding, the closest was managment constantly chasing new shinies and one time forgetting to tell the devs about the latest change.
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).
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.
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 :)
There are different stages of company lifecycle, different industries, different regulatory environments etc.
The processes put in place always have a cost - if picked appropriately it is worth paying, otherwise it is a waste that can hurt or even kills a project. This balance is the “art” of the job that I personally am only starting to probe around at my level and so it is still quite interesting. :)
It's possible this is more relevant in B2B contexts than B2C
Wtf, it's like I'm reading a Youtube video, except it doesn't have the production costs of an actual Youtube video.
I use it like once a quarter and trying to remember how to mark a task finished makes my eyes water.
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.
From the article:
> I definitely think you should use feature flags - just not abuse them.
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
Anyhow, happy holidays to all of you!
I found the following to be most amusing, as the author explains the idea of “Iterations” without mentioning them by name:
> We work in 6-week cycles. Once a cycle is over, we take one or two weeks off of scheduled projects so everyone can roam independently, fix stuff up, pick up some pet projects we’ve wanted to do, and generally wind down prior to starting the next six week cycle.
> Note: These are not sprints. I despise the word sprints. Sprints and work don’t go together. This isn’t about running all out as fast as you can, it’s about working calmly, at a nice pace, and making smart calls along the way. No brute force here, no catching our collective breath at the end.
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.
Plus then making them work optimally on N different microarchitectures.
I actually wonder what language/system they were using that lacked this in the stdlib or at least in very widely available libraries.
So, rolling your own say ‘cryptography’ is now good advice even if your solution is a worse, because we have LLMs?