3 ms·

I don't think of this as being cargo cult development. Cargo culting has more to do with mimicking practices that have worked before without understanding that

I don't think of this as being cargo cult development. Cargo culting has more to do with mimicking practices that have worked before without understanding that they only worked within a broader context that is now missing. It's about going through motions or rituals that are actually ineffective on their own in the hopes that you'll get the results that other companies got who also happened to perform those same motions or rituals. What OP is describing isn't like this because the thing being copied—the code—actually is effectual in its own right. You can test it and decide whether it works or not. The distinction matters because the symptoms of what OP calls the Makefile effect are different than the symptoms of cargo culting, so treating them as the same thing will make diagnosis harder. With cargo culting you're wasting time doing things that actually don't work out of superstition. With the Makefile effect things will work, provably so, but the code will become gradually harder and harder to maintain as vestigial bits get copied.

themanmaran 2y ago
I would almost call this the "boilerplate effect". Where people copy the giant boilerplate projects for React, K8, Terraform, etc. and go from there. Those boilerplates are ideal for mid to large scale projects. And it's likely you'll need them someday. But in the early stages of development it's going to impart a lot of architecture decisions that really aren't necessary.
- peterldowns 2y ago
  That's a great phrase. A perfect example of what you're talking about is actually built-in to the `helm` tool for creating re-usable kubernetes configs: `helm create myapp` creates the most convoluted junk I've ever seen in my life. As a new `helm` user I was extremely confused, as I had been expecting a minimal example that I could start from. Instead, I got a maximal example. Thankfully a more experienced engineer on the infra team confirmed that it was mostly unnecessary boilerplate and I could remove it. Something to consider for anyone else building tools — boilerplate has costs!
NomDePlum 2y ago
Seeing this exact effect where I am currently working. Main available CI/CD tool is a customised and centrally managed Jenkins fleet. It's pretty much impossible to avoid using and seldom needs changed - until it does. Some attempts have been made at centralised libraries and patterns - but even that requires knowledge and study that most won't know is available or be given time to acquire. So when the inevitable tweak or change is made it's made in the easiest, cheapest way - which is usually copying an existing example, which itself was copied from somewhere else. I see exactly the same in other teams repositories. Easiest path taken to patch what already exists as the cost/benefit just isn't perceived to be there to worth prioritising.
godelski 2y ago
> only worked within a broader context that is now missing > because the thing being copied—the code—actually is effectual in its own right. I don't understand how the second disproves the former. In fact, a cargo cult works because there's the appearance of a casual linkage. It appears things work. But as we know with code, just because it compiles and runs doesn't mean "it works". It's not a binary thing. Personal I find that belief is at the root of a lot of cargo cult development. Where many programmers glue things together say "it works" because they passed some test cases but in reality code shouldn't be a Lovecraftian monster made of spaghetti and duct tape. Just because your wooden plane glides doesn't mean it's AC an actual plane
- scubbo 2y ago
  > a cargo cult works But...it doesn't? That's the whole definitional point of it. If action A _does_ lead to outcome B, then "if we do A, then B will happen" is not a cargo cult perspective, it's just fact.
  - foobarchu 2y ago
    For actual cargo cults, yes. Cargo Cult Development just used the name to invoke a comparison..when CCD is being practiced, devs are doing mystical steps because it's part of the incantation. They wouldn't keep doing them if the project then never worked. Your definition is extremely unlikely to ever be practiced, because those developers would be fired for never getting anything working, and so it's not really a helpful one imo.
    - lolinder 2y ago
      Concrete examples of what I think actually counts as cargo culting: * Incorporating TDD because it's a "best practice". * Using Kubernetes because Google does it. * Moving onto AWS because it's what all the cool companies are doing. The key thing that makes cargo cult development a cargo cult is that it's practices and rituals adopted without any concrete theory for what a bit is supposed to do for you in your context. You're just doing it because you've seen it done before. This is different than small scale copypasta where people know exactly what they're trying to accomplish but don't take the time in any given instance to slow down and re-analyze why this bit of code looks the way that it does. They know that it works, and that's enough in that moment. If we're going to go back to the original analogies that started it all, what you're describing as cargo cult would be more similar to islanders using machinery that was left behind without knowing how it works or how to maintain it. They don't strictly need to know that in order to gain actual concrete value from the machinery, but it would be better in the long term if they knew how to maintain it.

themanmaran 2y ago

I would almost call this the "boilerplate effect". Where people copy the giant boilerplate projects for React, K8, Terraform, etc. and go from there. Those boilerplates are ideal for mid to large scale projects. And it's likely you'll need them someday. But in the early stages of development it's going to impart a lot of architecture decisions that really aren't necessary.

peterldowns 2y ago
That's a great phrase. A perfect example of what you're talking about is actually built-in to the `helm` tool for creating re-usable kubernetes configs: `helm create myapp` creates the most convoluted junk I've ever seen in my life. As a new `helm` user I was extremely confused, as I had been expecting a minimal example that I could start from. Instead, I got a maximal example. Thankfully a more experienced engineer on the infra team confirmed that it was mostly unnecessary boilerplate and I could remove it. Something to consider for anyone else building tools — boilerplate has costs!

NomDePlum 2y ago

Seeing this exact effect where I am currently working. Main available CI/CD tool is a customised and centrally managed Jenkins fleet. It's pretty much impossible to avoid using and seldom needs changed - until it does. Some attempts have been made at centralised libraries and patterns - but even that requires knowledge and study that most won't know is available or be given time to acquire. So when the inevitable tweak or change is made it's made in the easiest, cheapest way - which is usually copying an existing example, which itself was copied from somewhere else. I see exactly the same in other teams repositories. Easiest path taken to patch what already exists as the cost/benefit just isn't perceived to be there to worth prioritising.

godelski 2y ago

> only worked within a broader context that is now missing > because the thing being copied—the code—actually is effectual in its own right. I don't understand how the second disproves the former. In fact, a cargo cult works because there's the appearance of a casual linkage. It appears things work. But as we know with code, just because it compiles and runs doesn't mean "it works". It's not a binary thing. Personal I find that belief is at the root of a lot of cargo cult development. Where many programmers glue things together say "it works" because they passed some test cases but in reality code shouldn't be a Lovecraftian monster made of spaghetti and duct tape. Just because your wooden plane glides doesn't mean it's AC an actual plane

scubbo 2y ago
> a cargo cult works But...it doesn't? That's the whole definitional point of it. If action A _does_ lead to outcome B, then "if we do A, then B will happen" is not a cargo cult perspective, it's just fact.
- foobarchu 2y ago
  For actual cargo cults, yes. Cargo Cult Development just used the name to invoke a comparison..when CCD is being practiced, devs are doing mystical steps because it's part of the incantation. They wouldn't keep doing them if the project then never worked. Your definition is extremely unlikely to ever be practiced, because those developers would be fired for never getting anything working, and so it's not really a helpful one imo.
  - lolinder 2y ago
    Concrete examples of what I think actually counts as cargo culting: * Incorporating TDD because it's a "best practice". * Using Kubernetes because Google does it. * Moving onto AWS because it's what all the cool companies are doing. The key thing that makes cargo cult development a cargo cult is that it's practices and rituals adopted without any concrete theory for what a bit is supposed to do for you in your context. You're just doing it because you've seen it done before. This is different than small scale copypasta where people know exactly what they're trying to accomplish but don't take the time in any given instance to slow down and re-analyze why this bit of code looks the way that it does. They know that it works, and that's enough in that moment. If we're going to go back to the original analogies that started it all, what you're describing as cargo cult would be more similar to islanders using machinery that was left behind without knowing how it works or how to maintain it. They don't strictly need to know that in order to gain actual concrete value from the machinery, but it would be better in the long term if they knew how to maintain it.