Embrace copy+paste-driven development

This week, I inherited a half-finished proof-of-concept codebase that sort-of implements a teleconferencing service. The fellow I'm inheriting from is wonderful to work with; an old, grizzled sort of guy.

He walked me through the backend. It has two event buses, an enormously complex JS framework that does all sorts of automatic dependency injection, implements socket.io for you, etc.

At the same time, the team he works with (that I am now managing) consists of people who are either early in their career, or resistant to learning.

I asked him what he was hoping to achieve with both the tech choices and the architecture. He described the many functional requirements he was trying to fulfill; separation of concerns, granular events for the client, and many more.

I said: "I'm guessing our team will not have any idea what's going on in here, and will just try to copy/paste until they get things working?"

He nodded. "Yeah, they'll probably bugger it up pretty badly."

Just let them copy/paste

Since shortly after the birth of the internet, programmers have been making jokes about copy-pasting code from websites. One of my favorite things about the adoption of LLMs for programming has been observing the natural evolution of these copy/paste jokes to match the current programming zeitgeist.

I wonder why more software designers don't just relent and try to make it easier for people to copy-paste code within their own codebase.

We often dance around this idea; how do we make things more readable, better standardized, thoroughly documented, repeatable, etc.

Why can't we just call a spade a spade? I think it's an interesting exercise to add a "must be easy to copy/paste" requirement to your project.

I like to think about this at multiple levels. If someone copy/pastes a function, how likely are they to screw it up? Does this kind of function only belong at a certain layer in your architecture? What happens if the copy/paster doesn't realize this?

What about modules? If someone has to implement a whole new capability in a module, what might they try to copy/paste first?

Features? If they have to implement something that cuts across multiple layers or modules, how hard is it to start by copy-pasting from somewhere else?

Tests? I've noticed you can get a meticulous coder who does everything from first principles, and they'll still likely copy-paste code in great swathes when it's time to write the tests.

Frameworks, coding, and comfort

What about frameworks? On paper, they should establish a good copy-pasting development environment.

However, frameworks aren't a software architecture. The architecture is partially what you get when the programmers add all the extra stuff that they think is missing from the framework.

The thing I've found interesting about this part is that often times, when you ask someone to enumerate the reasons why they're adding the extra stuff in the first place, they can usually enumerate a reasonable set of requirements.

However, if you probe further, their connection between the real-world environment in which the software is likely to be deployed often has little direct connection to their desired functional requirements. Worse, it's often hard to see how their design choices fulfill their own functional requirements.

I feel that most developer-led functional requirements are about comfort rather than function. It's tiring to do things another person's way every day, especially when the task at hand involves something as meticulous as writing code line-by-line.

This is why I find the notion of copy+paste-driven development to be pragmatic. It may suck to have to write code in a way that feels alien to you; however, it's much less exhausting when you can copy-paste entire chunks of it without losing the guiding principles in the process.

So what?

You're probably asking what you can do with this style of thinking. Well, I'm not here to give any guidelines. I'm not that smart, and it's Saturday.

However, the next time you're put in the software designer's seat, try this:

Instead of thinking about how things would go if "everyone knew what they were doing", you can instead cut to the chase by writing code that can easily be copy-pasted while retaining the characteristics that you think are most important to the project.

If you've done something of this nature before, I'd like to hear about it.

me@hearsay.tech