Engineering
Engineering B.C. #1: The First Artifact Isn't Code
When I started writing software (and actually, up until recently), a new project usually began the same way.
Read the less-than-stellar requirements.
Create a directory.
Create a source file.
Start coding.
Initialize a Git (or SVN) repo.
Everything else could be figured out along the way.
For the past couple of weeks, I've been starting a new application.
What's interesting isn't what I've built.
It's what I haven't.
There isn't a meaningful application yet.
No production features.
No user interface.
No database schema.
Very little executable code.
Instead, I've created:
- A project Constitution
- An architecture document
- Architecture Decision Records (ADRs)
- A technology stack
- A BUILD guide
- A roadmap
- Licensing
- A deterministic development plan
A few years ago, someone might have looked at that list and said, "So...you haven't started yet."
I think I've already done some of the most important engineering on the project.
Here's why.
For decades, many of those artifacts were treated as supporting documentation. Helpful if you had the time. Nice to have. Often written after the software existed. Lately, the requirements (such as they are), are buried in Jira tickets or discussions in [name your favorite business chat doohickey here] or "tribal knowledge".
Today, those documents don't just explain the software.
They increasingly shape it.
Not because humans suddenly value documentation more.
Because another engineer has joined the team.
Sometimes that engineer is a teammate.
Sometimes it's a future version of you.
Increasingly, it's an AI coding assistant.
The difference is subtle but important.
When another developer joins your project, they ask questions.
"What did you mean here?"
"Why did you choose this approach?"
"What assumptions are we making?"
An AI doesn't ask those questions nearly as often. If at all. Well...never, unless you tell it to.
It implements your assumptions.
If your assumptions aren't written down, you'll still get code.
It just might not be the code you intended.
It hasn't changed the way I think about the beginning of a software project.
But it has reinforced what I've always believed.
The first artifact should never be code.
It's clarity.
Every architectural decision that's documented.
Every constraint that's made explicit.
Every decision that's captured before implementation.
None of those are permanent.
Requirements change.
Architecture evolves.
Better ideas emerge.
That's engineering.
The point isn't to eliminate change.
The point is to eliminate unnecessary ambiguity.
Eliminating unnecessary ambiguity turns out to be one of the highest-leverage things we can do as engineers.
Good engineering doesn't eliminate change.
It makes change intentional.
I've spent the last couple of weeks preparing my project for its first meaningful implementation.
From the outside, it might look like I've been avoiding code.
I see it differently.
I've been engineering.
Tomorrow, implementation begins.
An AI may write a significant portion of the application.
That won't be because the AI is brilliant.
It will be because the engineering that happened before the first line of code made success much more likely.
Maybe that's one of the biggest changes AI has brought to software development.
Not that it writes code.
That it has reminded us how valuable clear thinking has always been.
Question:
I've been calling this Engineering B.C.
What does the B.C. stand for to you?
Before Code?
Before Chaos
Before Codex?
Before Claude?
Before Commit?
Before Copilot?
Before Clarity?
Something else entirely?
I'd genuinely love to hear your interpretation.