7 ms·

I like this in general, but the number of times I've had to delay a release because some non/psuedo-technical person has pulled out "12 factor" like a universal

I like this in general, but the number of times I've had to delay a release because some non/psuedo-technical person has pulled out "12 factor" like a universal yellow card has been enough for me, overall, to ignore it almost completely. I guess the same has happened to me for "agile" honestly. I recognize the intent of guidelines like these, but they seem to be much more useful to people whose only "value" is to provide ivory tower technical leadership.

Waterluvian 3y ago
I've had issues like that before. The solution was to have a clear, documented process, and point them to that. I've learned to take issues like that in good faith. Why are they raising an issue? Is the existing process not clear? Is there a deficiency in it? Is there a lack of reliability? If reasonable concerns are found, the process can change (and the documentation is to be updated).
- ChrisMarshallNY 3y ago
  > The solution was to have a clear, documented process, and point them to that. This has its own drawbacks. I worked for a company, in which Process Was God, and Thou Shalt Do Only That Which God Has Proclaimed Good. It worked most of the time, but made it very, very difficult to introduce flexibility and orthogonal approaches. There's really no way to duplicate the results of experienced, cohesive teams of high-functioning engineers, with process. We can get similar results, in many ways, but there's always a price to be paid. T. A. N. S. T. A. A. F. L.
willseth 3y ago
Give an example. Like most things, it's context dependent and there are grey areas, but I think most devs use 12 factor like a north star. I wouldn't block a release due to some minor deviation, but generally lacking alignment should be treated as tech debt as a minimum. If a release regresses significantly in one of the factors, I think it's fair to block or at least force more detailed review to understand why the dev felt the tradeoff was worth it for that release.
- cduzz 3y ago
  There's the "Plumber Problem[1]" by John Siracusa where you watch a story and see a problem in your specific domain that leads you to mistrust the whole story. With the 12 factor nonsense, I see the guidance of "Dump unformatted logs into stdout and make it someone else's problem; they'll hadoop or splunk it and everyone wins." There is no magic splunk that absolve you (the developer) of generating useful data to logs, if you expect useful data out of your logs. You can't reverse "cow -> burger -> sewage" and shouldn't expect some magic hadoop to reverse entropy without a ton of work. So -- I guess the 12 factor app dictum is fine for some trivial "I rewrote twitter in 80 lines of erlang" app, but in my opinion it is a "if we can land a man on the moon we can land a man on the sun" misstatement of complexity in actually getting things done in the real world. [1] https://hypercritical.co/2023/08/18/the-plumber-problem https://hypercritical.co/2023/08/18/the-plumber-problem
  - morelisp 3y ago
    Spoken like someone who has never had to work on a Java application with 22 custom log files, not including stdout, stderr, and two separate syslogs. Yes, if you want useful data from logs you'll need to log useful data, but this is a case where 12 factor is so successful / dominant today I don't think you even know what it's arguing against anymore.
    - cduzz 3y ago
      No, writing files is nearly as bad as writing to stdout -- both imply someone else has to parse the output. If the logs matter -- write them to an API that retains log structure by serializing it. If the logs don't matter, then they don't matter, but typically the logs are used for all sorts of analytics processes after the fact. Asking someone else to parse your data is rude.
      - nightpool 3y ago
        Again, "this is a case where 12 factor is so successful / dominant today I don't think you even know what it's arguing against anymore"
robertlagrant 3y ago
> but they seem to be much more useful to people whose only "value" is to provide ivory tower technical leadership. I've found it pretty useful in practice. I don't see why it's much more useful to those people than it has been for me.
flakes 3y ago
I call that weaponized dogmas. It’s at least better than people who insist on being DRY by writing an inscrutable generic helper function which will only save 3 or 4 lines of code duplication.
- laurent_du 3y ago
  Nothing I hate more than a useless "helper" function that wraps a built-in feature of the language and gets buried in a "common lib" package that you need to inspect when you want to understand what is going on, instead of just relying on your knowledge of the language. Do we really need a function to map a dictionary and a list of keys to the corresponding values?
  - BossingAround 3y ago
    Oh my god I got a flashback to Groovy's missing method [0] which caused us so many issues, and made our codebase so unreadable. When you discover it for the first time, you think, "huh, neat, why not use it". Before you know it, nobody can reason about your code and if you leave, nobody wants to maintain it (esp. if your test suite is not extensive). [0] https://groovy-lang.org/metaprogramming.html https://groovy-lang.org/metaprogramming.html
  - booleandilemma 3y ago
    I'm a huge hater of these and I think they almost always decrease readability of the code and slow down the development and review process. I want to read and write the language I'm developing with, not the helper methods of some overeager developer who wanted to leave his mark on the codebase.
- brodouevencode 3y ago
  The absolute counter to weaponized dogma is itself weaponized dogma. There are times when implementing DRY, 12FA make sense and times when it doesn't. Be careful with hard-lined stances.
samtho 3y ago
This is more a reflection of the organizational structure that allows or tolerates such behavior rather than anything to do with the 12 factor app methodology. I think most reasonable people would agree that if you were able to incorporate most of the list, you’re doing alright.
Aurornis 3y ago
> some non/psuedo-technical person has pulled out "12 factor" like a universal yellow card has been enough for me, overall, to ignore it almost completely. Ignoring it completely on principal is just as bad as the people who treat it like mandatory dogma. I’ve also had over-eager junior engineers or wannabe architects use the 12-factor article as mandatory requirements for any launch. It takes a firm and unified explanation that these are good goals to strive for, but in the real world we need to make compromises for launch and choose which aspects to delay or defer.
- lopatin 3y ago
  Ignoring it completely is a viable strategy. A lot of 12 factor sounds like common sense to people who regularly ship stuff. For example, if I fail to put the config in the environment, the risk that introduces will be immediately obvious in the PR and someone would be able to raise that concern, with real justification, not because it's declared in a 12 factor manifesto.
  - i-use-nixos-btw 3y ago
    I think ignoring it completely is a viable strategy once you've already gone through the stages - when your mind is in the right place. I have moved on a long way from the days that 12 factor was my bible, but those days completely redefined my way of developing software. I'm not exaggerating here - it completely shifted my approach. I guess it's similar to Scrum in that way - it isn't a great end point, but if you're stuck in the old ways (i.e. the methods used before it was even a thing) then it's at least a good approach to sink your teeth into, try it out, shape your approach, and move on from there. Basically, I'd rather see a replacement that improves on 12 factor than throwing out the book entirely.
  - ascendantlogic 3y ago
    > A lot of 12 factor sounds like common sense to people who regularly ship stuff. In 2023, yes. A lot of the 12 factor methodologies became table stakes in the modern cloud era. Back when this was written "cloud" was not nearly as ubiquitous as it is now, although we were certainly headed in that direction. A lot of the comments here are viewing this through a 2023 lens and forgetting it was written in 2011.
darkwater 3y ago
Well, if your app log directly to files on disk (extra bonus if it doesn't respect any verbosity setting) or will only works if secrets are hard coded in config files (even if this could be work-arounded at deploy time probably), I for one will do all that I can to avoid your app reaches production. Yeah, I work in ops^W platform.
brodouevencode 3y ago
No amount of dogma should interfere with a deployment within the scope of an MVP. Once it's out of MVP then anything not addressed best practice-wise is tech debt. If your organization had adopted 12FA as a set of best practices then those should be met, but they should never interfere with a deployment. 12FA is not a single box that is to be checked. It can and in most cases probably should be implemented over time as the product matures, taking each point, point by point (and maybe even breaking those up) and adding that into the product. If you've done good engineering up front (abstractions and interfaces where it makes sense, not hard coding everything) this should not be an issue. inb4 YAGNI: this is just as abused as 12FA. EDIT: the biggest thing 12FA is missing are concrete examples that junior engineers can reference.
_ea1k 3y ago
TBH, most of the value in things like this is for consultants who go into shops that really don't know better. Being able to point management at this can be really useful. For most of us here, it is 99% common sense.
bunderbunder 3y ago
Indeed. Hard to believe that treating best practices as strict rules would not turn out to be best practice, isn't it?
coxley 3y ago
Right? There are gold nuggets in many of this style of "manifesto". It just takes a handful of people treating it as dogma to stink them up.

Waterluvian 3y ago

I've had issues like that before. The solution was to have a clear, documented process, and point them to that. I've learned to take issues like that in good faith. Why are they raising an issue? Is the existing process not clear? Is there a deficiency in it? Is there a lack of reliability? If reasonable concerns are found, the process can change (and the documentation is to be updated).

ChrisMarshallNY 3y ago
> The solution was to have a clear, documented process, and point them to that. This has its own drawbacks. I worked for a company, in which Process Was God, and Thou Shalt Do Only That Which God Has Proclaimed Good. It worked most of the time, but made it very, very difficult to introduce flexibility and orthogonal approaches. There's really no way to duplicate the results of experienced, cohesive teams of high-functioning engineers, with process. We can get similar results, in many ways, but there's always a price to be paid. T. A. N. S. T. A. A. F. L.

willseth 3y ago

Give an example. Like most things, it's context dependent and there are grey areas, but I think most devs use 12 factor like a north star. I wouldn't block a release due to some minor deviation, but generally lacking alignment should be treated as tech debt as a minimum. If a release regresses significantly in one of the factors, I think it's fair to block or at least force more detailed review to understand why the dev felt the tradeoff was worth it for that release.

cduzz 3y ago
There's the "Plumber Problem[1]" by John Siracusa where you watch a story and see a problem in your specific domain that leads you to mistrust the whole story. With the 12 factor nonsense, I see the guidance of "Dump unformatted logs into stdout and make it someone else's problem; they'll hadoop or splunk it and everyone wins." There is no magic splunk that absolve you (the developer) of generating useful data to logs, if you expect useful data out of your logs. You can't reverse "cow -> burger -> sewage" and shouldn't expect some magic hadoop to reverse entropy without a ton of work. So -- I guess the 12 factor app dictum is fine for some trivial "I rewrote twitter in 80 lines of erlang" app, but in my opinion it is a "if we can land a man on the moon we can land a man on the sun" misstatement of complexity in actually getting things done in the real world. [1] https://hypercritical.co/2023/08/18/the-plumber-problem https://hypercritical.co/2023/08/18/the-plumber-problem
- morelisp 3y ago
  Spoken like someone who has never had to work on a Java application with 22 custom log files, not including stdout, stderr, and two separate syslogs. Yes, if you want useful data from logs you'll need to log useful data, but this is a case where 12 factor is so successful / dominant today I don't think you even know what it's arguing against anymore.
  - cduzz 3y ago
    No, writing files is nearly as bad as writing to stdout -- both imply someone else has to parse the output. If the logs matter -- write them to an API that retains log structure by serializing it. If the logs don't matter, then they don't matter, but typically the logs are used for all sorts of analytics processes after the fact. Asking someone else to parse your data is rude.
    - nightpool 3y ago
      Again, "this is a case where 12 factor is so successful / dominant today I don't think you even know what it's arguing against anymore"

robertlagrant 3y ago

> but they seem to be much more useful to people whose only "value" is to provide ivory tower technical leadership. I've found it pretty useful in practice. I don't see why it's much more useful to those people than it has been for me.

flakes 3y ago

I call that weaponized dogmas. It’s at least better than people who insist on being DRY by writing an inscrutable generic helper function which will only save 3 or 4 lines of code duplication.

laurent_du 3y ago
Nothing I hate more than a useless "helper" function that wraps a built-in feature of the language and gets buried in a "common lib" package that you need to inspect when you want to understand what is going on, instead of just relying on your knowledge of the language. Do we really need a function to map a dictionary and a list of keys to the corresponding values?
- BossingAround 3y ago
  Oh my god I got a flashback to Groovy's missing method [0] which caused us so many issues, and made our codebase so unreadable. When you discover it for the first time, you think, "huh, neat, why not use it". Before you know it, nobody can reason about your code and if you leave, nobody wants to maintain it (esp. if your test suite is not extensive). [0] https://groovy-lang.org/metaprogramming.html https://groovy-lang.org/metaprogramming.html
- booleandilemma 3y ago
  I'm a huge hater of these and I think they almost always decrease readability of the code and slow down the development and review process. I want to read and write the language I'm developing with, not the helper methods of some overeager developer who wanted to leave his mark on the codebase.
brodouevencode 3y ago
The absolute counter to weaponized dogma is itself weaponized dogma. There are times when implementing DRY, 12FA make sense and times when it doesn't. Be careful with hard-lined stances.

samtho 3y ago

This is more a reflection of the organizational structure that allows or tolerates such behavior rather than anything to do with the 12 factor app methodology. I think most reasonable people would agree that if you were able to incorporate most of the list, you’re doing alright.

Aurornis 3y ago

> some non/psuedo-technical person has pulled out "12 factor" like a universal yellow card has been enough for me, overall, to ignore it almost completely. Ignoring it completely on principal is just as bad as the people who treat it like mandatory dogma. I’ve also had over-eager junior engineers or wannabe architects use the 12-factor article as mandatory requirements for any launch. It takes a firm and unified explanation that these are good goals to strive for, but in the real world we need to make compromises for launch and choose which aspects to delay or defer.

lopatin 3y ago
Ignoring it completely is a viable strategy. A lot of 12 factor sounds like common sense to people who regularly ship stuff. For example, if I fail to put the config in the environment, the risk that introduces will be immediately obvious in the PR and someone would be able to raise that concern, with real justification, not because it's declared in a 12 factor manifesto.
- i-use-nixos-btw 3y ago
  I think ignoring it completely is a viable strategy once you've already gone through the stages - when your mind is in the right place. I have moved on a long way from the days that 12 factor was my bible, but those days completely redefined my way of developing software. I'm not exaggerating here - it completely shifted my approach. I guess it's similar to Scrum in that way - it isn't a great end point, but if you're stuck in the old ways (i.e. the methods used before it was even a thing) then it's at least a good approach to sink your teeth into, try it out, shape your approach, and move on from there. Basically, I'd rather see a replacement that improves on 12 factor than throwing out the book entirely.
- ascendantlogic 3y ago
  > A lot of 12 factor sounds like common sense to people who regularly ship stuff. In 2023, yes. A lot of the 12 factor methodologies became table stakes in the modern cloud era. Back when this was written "cloud" was not nearly as ubiquitous as it is now, although we were certainly headed in that direction. A lot of the comments here are viewing this through a 2023 lens and forgetting it was written in 2011.

darkwater 3y ago

Well, if your app log directly to files on disk (extra bonus if it doesn't respect any verbosity setting) or will only works if secrets are hard coded in config files (even if this could be work-arounded at deploy time probably), I for one will do all that I can to avoid your app reaches production. Yeah, I work in ops^W platform.

brodouevencode 3y ago

No amount of dogma should interfere with a deployment within the scope of an MVP. Once it's out of MVP then anything not addressed best practice-wise is tech debt. If your organization had adopted 12FA as a set of best practices then those should be met, but they should never interfere with a deployment. 12FA is not a single box that is to be checked. It can and in most cases probably should be implemented over time as the product matures, taking each point, point by point (and maybe even breaking those up) and adding that into the product. If you've done good engineering up front (abstractions and interfaces where it makes sense, not hard coding everything) this should not be an issue. inb4 YAGNI: this is just as abused as 12FA. EDIT: the biggest thing 12FA is missing are concrete examples that junior engineers can reference.

_ea1k 3y ago

TBH, most of the value in things like this is for consultants who go into shops that really don't know better. Being able to point management at this can be really useful. For most of us here, it is 99% common sense.

bunderbunder 3y ago

Indeed. Hard to believe that treating best practices as strict rules would not turn out to be best practice, isn't it?

coxley 3y ago

Right? There are gold nuggets in many of this style of "manifesto". It just takes a handful of people treating it as dogma to stink them up.