Be Aware of the Makefile Effect

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system."

– John Gall (1975) Systemantics: How Systems Really Work and How They Fail

https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law

I have an alternate theory: about 10% of developers can actually start something from scratch because they truly understand how things work (not that they always do it, but they could if needed). Another 40% can get the daily job done by copying and pasting code from local sources, Stack Overflow, GitHub, or an LLM—while kinda knowing what’s going on. That leaves 50% who don’t really know much beyond a few LeetCode puzzles and have no real grasp of what they’re copying and pasting.

Given that distribution, I’d guess that well over 50% of Makefiles are just random chunks of copied and pasted code that kinda work. If they’re lifted from something that already works, job done—next ticket.

I’m not blaming the tools themselves. Makefiles are well-known and not too verbose for smaller projects. They can be a bad choice for a 10,000-file monster—though I’ve seen some cleanly written Makefiles even for huge projects. Personally, it wouldn’t be my first choice. That said, I like Makefiles and have been using them on and off for at least 30 years.

At my work I've noticed another contributing factor: tools/systems that devs need to interact with at some point, but otherwise provide little perceived value to learn day-to-day.

Example is build system and CI configuration. We absolutely need these but devs don't think they should be expected to deal with them day to day. CI is perceived as a system that should be "set and forget", like yeah we need it but really I have to learn all this just to build the app? Devs expect it to "just work" and if there are complexities then another team (AKA my role) deals with that. As a result, any time devs interact with the system, there's a high motivation to copy from the last working setup and move on with their day to the "real" work.

The best solution I see is meet the devs halfway. Provide them with tooling that is appropriate simple/complex for the task, provide documentation, minimise belief in "magic". Tools like Make kinda fail here because they are too complex and black-box-like.

Make and Makefiles are incredibly simple when they are not autogenerated by autoconf. If they are generated by autoconf, don’t modify them, they are a build artifact. But also, ditch autoconf if you can.

In the broader sense: yes this effect is very real. You can fall to it or you can exploit it. How I exploit it: write a bit of code (or copy/paste it from somewhere). Use it in a project. Refine as needed. When starting the next project, copy that bit of code in. Modify for the second project. See if changes can be backported to the original project. Once both are running and are in sync, extract the bit of code and make it into a library. Sometimes this takes more projects to distill the thing into what a library should be. In the best case, open source the library so others can use it.

I think Makefile is maybe the wrong analogy - the problem with most people and makefiles is they write so few of them, the general idea of what make does is at hand, but the muscle memory of how to do it from scratch is not.

But, point taken - I've seen so much code copy-pasta'd from the web, there will be like a bunch of dead stuff in it that's actually not used. A good practice here is to keep deleting stuff until you break it, then put whatever that was back... And delete as much as possible - certainly everything you're not using at the moment.

The best term for this is Cargo Cult Development. Cargo Cults arose in the Pacific during World War II, where native islanders would see miraculous planes bringing food, alcohol and goods to the islands and then vanishing into the blue. The islanders copied what they saw the soldiers doing, praying that their bamboo planes and coconut gadgets would impress the gods and restart the flow of cargo to the area.

The issue of course is the islanders did not understand the science behind planes, Wallis talkies, guns, etc.

Likewise, cargo cult devs see what is possible, but do not understand first principles, so they mimic what they see their high priests of technology doing, hoping they can copy their success.

Hence the practice of copying, pasting, trying, fiddling, googling, tugging, pulling and tweaking hoping that this time it will be just right enough to kind of work. Badly, and only with certain data on a Tuesday evening.

Another factor is frequency of use. I use LaTeX to do big write-ups on the order of once per year or less. LaTeX at the level I use it is not a hard tool, but I generally start a new document by copy-pasting a previous document because there is a lot of detail about how to use it that I'm never going to remember given that I only use it for a few weeks once a year.

This is “Copy-Pasta Driven Development” [0] and it’s not even related to makefiles. It’s related to the entire industry copying code from here to there without even knowing what they are copying.

TBH I think copilot has made this even worse, as we are blindly accepting chucks of code into our code bases.

[0] https://andrew.grahamyooll.com/blog/copy-pasta-driven-develo...

If I had a nickel for every time I have seen a Makefile straight up copied from other projects and modified to "work" while leaving completely unrelated unnecessary build steps and targets in place.

It's a major pet peeve of mine.

There are certainly a lot of tools that are more complicated than necessary, but Make as a tool isn’t a good example of that, IMO. With modern tooling, more often than not the complexity problem is compounded by insufficient documentation, the existing documentation being predominantly cookbook-style and not explaining the conceptual models needed to reason about how the tool works, nor providing a detailed and precise enough specification of the tool. That isn’t the case for Make, which is well-documented and not difficult to get a good grasp on, if one only takes the time to actually read the documentation.

The cookbook orientation mentioned above in turn leads to a culture that underemphasizes the importance of learning and understanding the tools that one is using, and of having thorough documentation that facilitates that. Or maybe the direction of causation is the other way around. In any case, I see the problem more in too little time being spent in creating comprehensive and up-to-date documentation on tooling (and designing the tooling to be amenable to that in the first place), and in too little resources being allocated to teaching and learning the necessary tooling.

I wouldn't say this is necessarily a bad thing. I wrote my first version of a Makefile with automatic dependencies and out-of-tree builds 10+ years ago and I have been copying and improving it since. I do try to remove unneeded stuff when possible.

The advantage is that one can go in and modify any aspect of build process easily, provided one takes care to remove cruft so that the Makefile does not become huge. This is very important for embedded projects. For me, the advantages have surpassed the drawbacks (which I admit are quite a few).

You could, in theory, abstract much of this common functionality away in a library (whether for Make or any other software), however properly encapsulating the functionality is additional work, and Make does not have great built-in support for modularization.

In this sense I would not say Make is overly complex but rather the opposite, too simple. Imagine how it would be if in C global variables were visible across translation units. So, in a way, the "Makefile effect" is in part due to the nature of the problem being solved and part due to limitations in Make.

Is not this a very generic phenomenon? I would argue it applies broadly. For example budgeting, you usually start from last year's budget and tweak that, rather than start from scratch. Or when you write an application letter, or a ServiceNow ticket, or whatever. Now I regret that I have brought in ServiceNow in the discussion, it kills the good mood....

I have observed the Makefile effect many times for LaTeX documents. Most researchers I worked with had a LaTeX file full of macros that they have been carrying from project to project for years. These were often inherited from more senior researchers, and were hammered into heavily-modified forks of article templates used in their field or thesis templates used at their institution.

I have made conscious effort in the past to never copy/paste the initial fleshing-out of a Makefile or a PHP class, or HTML boilerplate, or whatever. Like, for years I stuck to that. Then I stopped making that effort because there is no upside. Or rather, there is no downside to copy+paste+modify. It's faster and you save your brain power for things that actually matter.

> However, the occurrence of the Makefile effect in a simple application suggests that the tool is too complicated for that application.

I interpret it in a bit of different way.

Makefile is relatively simple and unopinionated like a brick. Also makefile defines/reflects project’s structure.

From simple blocks one can build any shape one want. Total freedom.

Problem is, make doesn’t impose best practice and doesn’t steer you clear of common pitfalls of project structuring and building and publishing.

One example for illustration: Out of source builds is rather good idea, but not imposed by make.

So makefile is not enough, one needs all the life-lessons of using make, so inherited makefiles are better than written from scratch.

I think LaTeX is the poster child of this. Nobody writes a LaTeX preamble from scratch, you always copy your previous document and tweak it.

Okey but to me, copying - pasting working code (even with sone extra unused bits) really looks no more different than inheriting a library - provided base class, and then extending it to one's needs.

That's literally the basis of all software. There is no need to invent "a Makefile effect/syndrome"

Yes that's an indication that a code sharing mechanism is needed but not implemented. Copying pasting solves that. You don't expect people to rewrite http client for every project which interacts with APIs, so you?

> the tool (or system) is too complicated (or annoying) to use from scratch.

Or boring: some systems require boilerplate with no added value. It's normal to copy & paste from previous works.

Makefiles are a good example. Every makefile author must write their own functionally identical "clean" target. Shouldn't there be an implicit default?

C is not immune, either. How many bits of interesting information do you spot in the following excerpt?

  #include <stdio.h>
  int main(int argc, char **argv)
  {
    printf("Hello\n");
    return 0;
  }

The printf alone is the real payload, the rest conveys no information. (Suggestion for compiler authors: since the programs that include stdio.h outnumber those that don't, wouldn't it be saner for a compiler to automatically do it for us, and accept a flag to not do it in those rare cases where we want to deviate?)

This also happens with tools you have to use but don’t get much payoff from—like internal tooling. At work, we have a shitty in-house feature flag service. It breaks all the time and is super finicky. Learning it properly doesn’t really help me, so I mostly copy and paste my way through it.

Another example is jq. I use it occasionally, and ChatGPT handles the syntax pretty well. For me, learning it properly just isn’t worth the time or effort.

This only happens because people treat build code at a lower standard than app code. IMO you should treat all code with the same rigour. From build scripts to app code to test code.

Why write hacks in build tools when you wouldn’t do in your app code.

We build tool code with the same quality as the app code. That’s why most tooling we use are written in typescript: type safety, code reuse…

Why do some tools have this problem, and others not?

I think it's convention over configuration. Makefile can do anything, so every project is different and needs different configurations, and everything must be configured. Which means that when I use a tool like that, it's sooo many decisions to make, that I just copy something that I know works.

If instead it was some sane defaults, it would be pretty apparent where it deviates. And instead of thinking of hundred things and which to choose, I either don't think about them, or think "do I have a reason to configure this instead of using defaults?"

Makefiles have an even more interesting issue: They lost their main purpose. In many, many projects that I've seen, they only consist of phony targets. No dependency tracking is used whatsoever.

How many Makefiles are there that just Wrap npm, pip, or some other tool like that? A Makefile is supposed to be the build system, not trigger it.

calling this "Makefile" effect is a terrible disservice. one could as easily call it "PHP" effect, "YAML" effect, etc. pick whichever language you'd personally like to denigrate.

there is nothing that makes makefiles inherently more or less susceptible to this. if it's more common, it's because people don't want to take the time doing more solid engineering and clean design for something like a ci/cd config or a makefile, being viewed as ancillary or less important. and so they often don't want to learn the language, so monkey-see-monkey-do.

as sibling comments state, this is better called cargo cult or maybe copy-pasta. and i've seen it with any language c, c++, python, scripts, config files, anything. i even see it in chat gpt answers because it's regurgitating someone else copy pasta.

if it's a problem, it's a problem of discipline.

> Does it need syntax of its own? As a corollary: can it reuse familiar syntax or idioms from other tools/CLIs?

I’m with the author here 100%. Stop inventing new syntaxes and formats for things that don’t need it. It’s not clever, it’s a PITA when it doesn’t work as expected at 3:30 on a Friday.

I see this effect in Java Maven pom.xml files. It's hard to get a straightforward answer on why each build step is needed, what each attribute means, what parts are optional or mandatory, etc. There seems to be a culture of copying these XML files and tweaking a few things without truly understanding what the whole file means. I briefly looked at Ant and Gradle, and their ecosystems don't look any better. The build configuration files seem to have too much unexplainable magic in them.

I guess this is an effect of declarative programming and layered abstractions. The declarative syntax and abstraction are an answer to code being repetitive and long and hard to follow, but this then creates its own issues by making it harder to reason (especially for beginners or occasional users) about what is actually going on. The price for learning how to get it right just becomes much higher with every layer of abstraction inbetween, because you always have to learn what's going on underneath the "cushions" anyway.

For me typical examples are Terraform configurations with their abstracted configuration syntax, which just mimicks some other configuration (e.g. AWS) and executes it in an environment where I don't necessarily have access to. Of course I'm not going to run endless experiments by reading documentation, assembling my own config and running it in painful slow CI pipelines until it works. I'll rather copy it from another project where it works and then go back to work on things that are actually relevant and specific for the business.

I end up doing the copy paste thing quite a lot with build tools, it was very common in Ant, Maven and then in Scala build tool. When your projects all have the same fundamental top level layout and you are doing the same actions over and over you solve the problem once then you copy and paste it and remove the bits that don't apply.

These types of tools there isn't much you do differently they don't give you much in the way of abstractions its just a list of actions which are very similar between projects. Since you typically with them are working in declarations rather than the usual programming primitives it often fundamentally falls down to "does my project need this build feature or not?".

I always write my makefiles from scratch. At some point in the process, I will google “make automatic variables”, because they’re a pain to memorize.

Same with programming: You just copy some old code and modify it, if you have something lying around.

Same with frameworks (Angular, Spring Boot, ...). The tools even come with templates to generate new boilerplate for people who don't have existing ones somewhere.

A better name for this might be the JCL effect, as even experienced mainframe sysprogs copypasta the JCL it takes to build their COBOL programs from a known-good example and then mutatis the mutandis, rather than attempt to build a mental model of how JCL works from the impenetrable documentation and write JCL de novo.

It's no big deal to me to write a small Makefile from scratch. My editor (Emacs) even knows to always use tabs when I hit TAB in a Makefile, removing the confusion of whether I inserted tabs (correct) or spaces (horribly incorrect) on the lines with the commands to build a particular target.

> However, the occurrence of the Makefile effect in a simple application suggests that the tool is too complicated for that application.

The author's overall point is fine (specifically, that one should consider developer cut-and-paste behavior as an indicator of unnecessary complexity in a tool). However, when discussing the designer's perspective, I think the author should have taken a broader view of complexity.

Much of the complexity in Makefiles stems from their generality; essentially, the set of problems to which a Makefile can be a solution. Substantively reducing this complexity necessarily means eliminating some of those use cases. In the case of make, this is clearly possible. Make as a Unix tool has been around for a looong time, and one can look at the early versions for an idea of how simple it could be.

But the rub is, simplifying make doesn't necessarily reduce complexity. Once armed with a simpler, but more limited make, developers are now tasked not only with knowing the easier Makefile syntax, but also knowing when make isn't an appropriate solution, and when and how to use whatever tool exists to fill the gap. Compounding this is the fact documentation and shared knowledge regarding which tool is appropriate for which problem is much harder to come by than documentation for the tool itself. This can easily lead to the tool choice equivalent of developer cut-and-paste behavior: "so-and-so uses build tool X so I must use it too", "if your doing (general description of problem) the only build tool you ever need is Y", "I used Z before, so I'm just going to make it work again".

Essentially you can think of make as one "verb" in a sprawling and uncoordinated domain-specific language that targets building things. Developers need some level of proficiency across this language to succeed at their work. But trading complexity that must be mastered in one tool for complexity that must be mastered across tools can very easily increase overall complexity and promote its own kind of "Makefile Effect", just at a different level.

EDIT: Some might prefer the term "Cargo Culting" rather than "Makefile Effect" here. I suggest they are the same behavior just in different contexts.

I see this often on our codebase. It was mostly written by ex-C# developers who were new to writing Go, and there’s many ham-handed C#-isms in there. At some point, someone took a guess at how something should be, then subsequent changes were done by copy-paste. Years down the road, another copy-paste job happens, and when I point out that the patterns within are not good (like, can actually be buggy), I get a confused response, because that is what was there.

There is an implicit assumption that the code written espouses best-practices, but that is far from the truth.

Apart of not knowing / unable to start from scratch, this is about frequent, and infrequent use. The latter also means not-that-important-in-overall-landscape, and brings forgetting and perceiving it as less "ROI", so one (hopefuly) finds and copy-pastes that-last-working thing into.. whatever Frankenstein.

https://utcc.utoronto.ca/~cks/space/blog/programming/Frequen...

So, it's the tool's fault that the user chose it, and it's the tool's fault the user never learned how it works?

This is like taking a hike up a rocky hill because the trailhead had a smooth path, later tripping over a rock, and then blaming the rock.

I'd redefine the Makefile (or YAML, Bash, etc) effect as:

  Tools that are easy enough that people try to use them
  without learning how they work first, and hard enough that
  people later blame the tool when they crash into their
  own ignorance.

> Complex tools are a necessity; they can’t always be avoided. However, the occurrence of the Makefile effect in a simple application suggests that the tool is too complicated for that application.

This footnote actually made me think about IDEs and the JS toolchain even more than makefiles.

If I'm writing a small project (say, 10 code files) surely an IDE where most people only know how to use 4 of the 1000 buttons is overkill, and I'd use a makefile.

Similarly surely 10 code files with 10 config dotfiles to set up a JS environment and tooling for dependencies, versioning, linting, transpiling, etc is overkill too.

- Basic javac/gcc/swiftc/whatever commands are simple, even if they can scale up through every niche via configuration options.

- Basic makefiles are simple, even if they can scale up to something like the xnu makefile tree (the most complex make system I've encountered).

- Let's not talk about JS.

I'm hesitant to use the word "lazy" to describe people who do what the author is describing - not just because I sometimes do it myself but because I believe that laziness is a derivative observation of time constraint, executive function exhaustion, and other factors. It also reminds me of the classic "I'm going to learn X, which handles/wraps Y, so that I can avoid learning Y", which is generally a bad pattern of motivation.

At its core this feels like a failure to understand (or failure of others to teach) fundamentals / first principles of the tools being used.

> Think about CI/CD setups, where users diagnose their copy-pasted CI/CD by doing print-style debugging over the network with a layer of intermediating VM orchestration. Ridiculous!

I don't think the author understands the point of "CI/CD systems". And I don't really blame them, because workload orchestration systems have been abused and marketed to the point where we call them CI/CD systems instead. Sure, if you think the point of CI/CD is to just provide a unified build and deploy it somewhere, you can write that in whatever language you like, and not need to know a bunch of YAML-fu.

But the whole point of workload orchestration systems is to configure the flow of workloads between machines as they inherently execute on different machines. The status quo is to debug over the network because, fundamentally, different machines will be connected by a network and the workload orchestration system is figuring out which machine to put it on.

If you think you can just run your CI/CD on a single server without networking or virtualization, I have some very large, parallelized testing suites to show you.

This is poor reasoning and poor argumentation.

This particular line is wrong in my opinion:

> the tool (or system) is too complicated (or annoying) to use from scratch

Unless you're doing trivial things, any tool or system will require some setup (which people call "ceremony").

Tools and systems can be easy to use from scratch only if they are either super-specialized or they impose significant constraints on what you will be doing with that tool and how you will be doing it.

Such tools are usually very tightly couple to a specific job/environment/task and are hard to keep around, keep updated and to evolve.

Make and similar tools instead are generic and can be adapted. The fact that you can reuse the previous work done is actually a feature. You can dive as deep as you want or need. They're very widely used so it's not an issue to keep updated. They're so widespread you can find people already familiar with those tools. Learning such tools is a great investment because you can keep using them over and over across project and companies.

Some of those tools are either timeless (gnu make) or have a very long life (more than a decade, which very long for this industry).

Anecdotal example: I learned a bit of apache ant while in high school because my laptop at the time (a netbook with 1GB ram and an atom processor) could not run NetBeans decently, so I had to learn a bit of apache ant and resort to writing and maintaining my own build.xml file. Fast forward 14 years and I see a build.xml file in the $FAANG codebase I was working on. That learning did pay off beautifully many years later.

The article is shortsighted, if anything it's promoting a shallow way of working. You are supposed to learn about the tools you use.

The tacit assumption of the OP is that it is better to do something else. That is, to start with some sort of first principles and create from scratch the artifacts that your project needs. It is telling that his example is a build artifact - these tend to change infrequently. The only way for one human mind to truly "dwell" in the space of project builds is to maintain many of them at once, as many as it takes to fill your days with nothing but build concerns.

"Tools that enable this pattern are harder to use securely..." Harder than what? A totally custom build? One made from first principles? I would, in fact, argue the exact opposite. And in fact I would argue that copy-paste-modify serves practicioners very well, especially when it comes to on-boarding. If you disagree, do the gedankenexperiment where you imagine joining a team with a totally custom build versus one with a lightly edited common make file. Which experience would you prefer, all else being equal?

Copy+tweak happens IRL all the time. There's no reason everyone who bakes should have to reinvent biscuits from scratch. There's no reason chip manufacturers should have to reinvent N-type P-type sandwiches from scratch. The existence of adaptations of previous success does not suggest that baking, or physics, or Make, is overly complicated.

Make has to be one of the more unfairly maligned languages out there. Most “replacements” purport to solve problems make doesn’t have, and are strictly worse than make at what they do.

Anyway, the GNU make manual is a good read for anyone that needs to edit a makefile or design a project build. So is “recursive make considered harmful”.

I think this is completely normal for tools that you program seldomly. I write makefiles a couple of times a year, I've been using make for more than 40 years now, I use it every day, but I seldomly program it, and when I want something more than simple dependancies I often clone something that already works.

amazon's internal build tool experiences this same phenomena. engineers are hired based on their leetcode ability; which means the average engineer has gaps in their infrastructure and config tool knowledge/skillset. until the industrys hiring practices shift, this trend will continue.

A design philosophy called "Progressive Disclosure" tries to tackle this problem, where a tool is supposed to present a minimal set of functionality initially to allow a user to be productive without being an expert and progressively "reveal" more complex features as the user becomes more familiar with the tool and attempts to do more complex things.

I've heard the programming language Swift followed this philosophy during development, though I've never written any Swift code to know how well it worked out.

https://en.wikipedia.org/wiki/Progressive_disclosure

At first I couldn't understand what this article is saying. Then, .SECONDEXPANSION: kicked in!

Honestly, my .zshrc file started out as a .kshrc file that was passed down to me by an older developer about 20 years ago, when I was still in university. I've added and removed a lot of things over the years, but there are still a few parts of it that I don't totally understand, simply because they work and I've never had a reason to think about them. The guy I got it from, in turn, got his from someone else.

In the old days, I had a .fvwm2rc config file that I got from my boss in the university computing center. I had no idea how it worked! And neither did he -- he got it from a professor when he was in university.

We use Cargo Cult to refer to this phenomenon: https://en.wikipedia.org/wiki/Cargo_cult_programming

“Just modify someone else’s Borgmon code and you’re good to go.”

— Broccoli Man <https://www.youtube.com/watch?v=3t6L-FlfeaI>

This is pretty thought provoking. I think the issue is "80% of the use of this complicated tool is for very simple ends". From there you get a lot of "I can't be bothered to learn git/make/sed/helm/jenkins, all I'm doing is X 15 minutes a year". My guess is SWEs hate ceilings, so we don't want to use tools that have them, even though they'd be far more fit for purpose. We also don't want to build tools with ceilings: why limit your potential userbase/market?

This is how I feel about systemd unit files for things that I used to use crontab for. They aren't even particularly complicated. But editing cron files was self-explanatory. I leanred it once and I did not need to look it up ever. Whereas, systemd unit files, I still have to lookup every single time. There's something wrong with that. They are of course very much superior in many ways... but not all.

To me it seems fine that a tool that is both complexity and versatile needs a config file that is beyond memorization. So I think this line of reasoning has limitations.

I could see it with say CLI tools though. Like if I need to reference my notes for a CLI command then that may well indicate a failure in tool design.

>repeatedly copy a known-good solution and accrete changes over time.

Alternative phrasing would be that it evolves. Arguably there is a positive trajectory there

I feel this way every time with webpack, npm and babel.

Good points in general.

On the other hand, there are cases where (beneficial/desired) verbosity prompts copy-paste and tweaking - not due to complexity but from some form of scale or size of the input.

In many cases this is a sign of something that should be dynamic data (put it in a db instead of conf) but that's not always the case and worth the tradeoff in the moment.

Old IBM mainframe scripting in JCL https://en.wikipedia.org/wiki/Job_Control_Language (so "OS JCL" now, I suppose) used to have a terrible reputation for this, but I've never actually touched the stuff myself.

> However, at the point of design, this suggests a tool design (or tool application) that is flawed: the tool (or system) is too complicated (or annoying) to use from scratch.

As someone who teaches and sees college-level students ask chatgpt what's 1 + 1, I disagree that it has anything to do with complexity or annoyance.

Humans be humans; that's mostly it.

I do write makefiles de novo (including in corporate settings). But I start "backwards" with the "clean" and "distclean" targets, then get a single basic debug build target working. From there, I find it relatively easy to expand to larger and more complex operations. Brick by brick.

This happens to me all the time with bazel. It is too complicated and the documentation sucks so I just look for prior art and copy paste that. Sometimes I have to do something novel and it takes me several days of deep diving the bazel source code to figure out how to do something.

What is a counterexample?

I cannot think of a single tool which is complex enough but does not show the makefile effect

I dunno they're using copy-paste as if it's a bad thing.

There's no virtue in writing something character by character.

If anything these languages and systems are better for the Makefile effect.

That you can't really do effective copy-pasting in imperative languages is a weakness.

The traditional Unix man page or list of options output with --help is often a firehose of details that most devs will never use. Sometimes there are a few examples shown of common use cases which is a good place to start learning the tool.

There's another similar concept that sort of goes along with this.

Sometimes it's better to duplicate code rather than make a special routine to do it.

Sometimes it's not only easier to copy/paste, but it is better than adding a level of abstraction

What is the counter-example?

We recycle known good stuff to avoid getting bogged down and introducing fresh flaws.

The admonition to know what we're doing and act deliberately applies to so much in life, but flies in the face of Milton Friedman's point in "I, Pencil" => https://youtu.be/67tHtpac5ws?si=yhheE1Y5ELfjWXs-

Common denominator is that people want a complex system to instead be something that can meet their simpler needs without being a time sink.

Ironically enough, I tend to write my Makefiles from scratch nearly every time, which means I have little reason to consider this term fitting.

Alias, cmake effect.

This happens with Slurm/PBS job submission files. Always end up asking the user "where/who did you get this from?"

Yeah I'm just not wasting my life (or professional time) learning Groovy, Maven, DotNET project files, DotNET 4.8, Gradle, Azure DevOps, Grafana, Prometheus, Docker, Docker compose, Kubernetes, Jenkins etc et all.

I need those things once at project setup. I copy-paste and change a bit.

Why copy-paste? It's a proven strategy with a high success rate despite little effort behind it.

I also don't want to learn templating for every little DSL I need to write one file per project with.

But if you love doing it "the right way", you're welcome to do that work for me.

Counterpoint: make is good actually, you should learn it (like all such tools).

I call it the yoghurt effect.

Someone remind me, is it $@ or $< ?

Most of my simple C projects have make.sh instead that has something like:

    clear
    gcc some options -o foo && ./foo

It’s like a variant of Pournelles Law.

A clever point, worth discussing

In other news I like the coherence of your online digital identity and websites.

Reminds me of the early internet. Auras of class, cred, erudition, intelligence, mystery, imagination. Thank you.

No one tell them about Cobal

or ahem... CMake

There are many angles.

Part of the low-code/no-code story is that conventional programming requires programmers to not just decide what has to be done but in what order to put those things. (This is connected with parallelism because if tasks are done in a particular order you can't do more than one at a time.)

An Excel spreadsheet is different from a FORTRAN program, for instance, because you can write a bunch of formulas and Excel updates the results automatically without you sequencing things.

https://en.wikipedia.org/wiki/Topological_sorting

is an easy approach to finding a valid order to do tasks in. It's used frequently in build systems but rarely in other software so it contributes to build systems seeming to be from another planet

---

I work in Java a lot and I used to hate Maven, because, if you look at Maven as "an XML vocabulary" you're going to frequently find "you can't get from here" and looking for answers in Stack Overflow is going to dig you in deeper.

The right way to think about Maven is that, like (part of) Spring, it is a system for writing XML files that configure a group of Java objects. Seen that way, writing a Maven plugin should be a second resort; the moment you're scratching your head wondering if it's possible to do something, you should (1) make sure you can't "go with the flow" and follow conventions, then (2) write a Maven plugin.

The thing is, a Maven plugin is just an ordinary Maven class. You're a Java programmer, you know how to do things in Java. All the skills you use everyday apply, you're no longer in a weird, mysterious and limited environment. That's part of the "makefile program"; you probably build your code (edit files in Java, C, whatever) 1000s of times for every time you change something about your build system. On a team you can be very productive if you know the main language but have no idea about how the build works (if the build the works.)

When you try this though you often run into political problems. In most places, for instance, only a few people on the team have the authority to create new maven projects (a plug-in is a class defined it's own project.) Maybe that makes sense because you don't want them breeding like rabbits, but a lot generally most systems are badly partitioned as it is, and I think many programmers wouldn't want to have the fight it would take to create a new project.

People are accustomed to builds being SNAFU and FUBAR.

When I first saw Maven I was baffled that, as a remote working on a system that had about 20 programmers and about 20 projects I couldn't build the system successfully at all. The build worked maybe 70% of the time at the office and people didn't seem to worry about it. I could live with that because they were building large complex systems that they were always throwing away and I was building simpler spike prototypes that worked.

I worked at a number of places where builds were unreliable in ways that seemed quantitative rather than qualitative, eventually I realized the problem was really simple, if you were using snapshot builds and a lot of people were working on a project and you didn't have any transaction control you would often get a set of snapshots that were not compatible with each other.

Most teams don't take builds seriously enough. I've found it rare to meet an engineering manager who can answer the question "how long does the build take?" and fantasize of going to a job interview, asking that question, and if I don't get an answer, standing up and walking out.

For many projects I've worked on I've built "meta-build systems" where the assumption is that have 12 maven projects and 4 npm projects or something like that (aren't most of us using mixed languages in the React age? why isn't this treated as a first-class problem), and such a system can be smart about what gets built and what gets doesn't, what is running out of snapshots and what can have a fixed version, etc. Merges in changes from develop automatically, and if seven steps are required that take a total of 15 minutes I ought to be able to think about something else entirely for 15 minutes and hear a "beep" when it's done.

Trouble is we don't take builds seriously enough: it's a technical problem and it's a political problem and we often don't face the technical problems because of the political problems.

[dead]

[dead]

Setup.py, cron, makefile, bash scripts, GitHub actions, and devcontainers all had this effect... Until AI came around.

Now AI does a great job of getting you 90-100% of the way there.

Is it not a problem which is basically COMPLETELY SOLVED by LLMs ?

The reason this happens is because Makefiles (or CI/CD pipelines / linters config, bash scripts) are more or less "complete language" on their own, that are not worth learning when you can do ... exactly what the author says (copy/pasting/modifying until it works) 99% of the time.

But LLMs in general know the language so if you ask "write a minimal Makefile that does this" or even "please simplify the Makefile that i copy/pasted/modified", my experience is that they do that very well actually.