Software Fundamentals Matter More Than Ever

생각 덩어리

A comforting message for those who feel their skill set is worthless

I have a message for you that I hope will be um a comforting message for folks who believe that uh their skill set is no longer worth anything in this new age, which is I believe that software fundamentals matter now more than they actually ever have.

Specs-to-code — running the compiler keeps producing worse code

The specs to code movement says that okay you can write a specification about how an application is supposed to work then you can use AI to turn it into code. If there's a problem with the application you then go back to the spec. You don't really look at the code. You just change the spec. You run the compiler again and you end up with more code.

I would run it and I would try not to look at the code but I would look at the code and I realized I would get code out first of all and then I would run it I would get worse code and then I did it again I got even worse code and I got it again I kept running the compiler kept running the compiler and I would just end up with garbage.

The idea that we can just ignore the code and just have the code let it manage itself is just sort of v coding by another name.

Bad code = hard to change — Ousterhout's definition of complexity

Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system. Right? So, a a bad codebase is a codebase that's hard to change. If you can't change a codebase without causing bugs, then it's a bad codebase. Good code bases are easy to change.

Software entropy — the system collapses if you only think about one change

Entropy is the idea that things tend towards um disaster and uh floating away from each other and collapse. And this is exactly how most software systems behave too is that every time you make a change to a codebase, if you're only thinking about that change, not thinking about the design of the whole system, your codebase is going to get worse and worse and worse.

Code is not cheap — bad code is the most expensive it's ever been

I don't think this is right. I think code is not cheap. In fact, bad code is the most expensive it's ever been. Because if you have a codebase that's hard to change, you're not able to take all of the bounty that AI can offer because AI in a good codebase actually does really, really well.

And this means good code bases matter more than ever, which means software fundamentals matter more than ever. That's the thesis of this talk.

The design concept — invisible theory you can't put in a markdown file

No one knows exactly what they want. Is that you and the AI, there is a communication barrier there, right?

Frederick P. Brooks, the design of design, and it talks about this idea called the design concept. is that when you have more than one person designing something together, you have this idea sort of floating between you, this ephemeral idea of the thing that you're building. And that thing that you're building or the idea of it is called the design concept. It's not an asset. It's not something you can put in a markdown file. It is the invisible sort of theory of what you're building.

Grill me skill — interview relentlessly until shared understanding

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree which is another thing from Frederick P. Brooks resolving dependencies between decisions one by one.

These couple of lines means the AI asks you like 40 questions, 60 questions. I've had it ask uh people a hundred questions before it's satisfied they've reached a shared understanding.

Plan mode is extremely eager to create an asset. It really wants to uh just create a plan and start working. whereas I think it's a lot nicer to reach a shared design concept first.

The AI is way too verbose — domain expert analogy

If you've ever been a developer for a long time and you've worked with let's say domain experts, someone building an application um let's say the domain expert wants you to build something on uh I don't know microchips. You have no idea what microchips are. You need to establish some kind of shared language, right? Because otherwise they're going to be using terms you don't understand.

Ubiquitous language — a markdown file of shared terms with the AI

With ubiquitous language, conversations among developers and expressions of the code and conversations with domain experts are all derived from the same domain model. It's essentially a markdown file full of a list of terms that you and the AI have in common.

And what I noticed by reading the thinking traces of the AI, it not only improves the planning, but it allows the AI to think in a less verbose way and actually means that the implementation is more aligned with what you actually planned.

Outrunning your headlights — feedback rate is your speed limit

Even with these feedback loops, the LLM doesn't use them very well. It doesn't kind of like get the most out of its feedback loops in the way that a veteran developer would. And so it does what it tends to do is just does way too much at once. it will produce like huge amounts of code and then think, "Oh, I should probably type check that actually or I should uh yeah, maybe check a test on that."

And this in the pragmatic programmer they describe as outrunning your headlights as essentially driving too fast because the rate of feedback is your speed limit. The rate of feedback is your speed limit, which means that you should be testing as you go, taking small deliberate steps. And the AI by default is really not very good at that.

TDD forces small steps — write a failing test first

Skill number three is TDD. You should be using testdriven development because TDD forces the LLM to really take small steps. You create a test first. You make that test pass and then you refactor the code to make it nicer and consider the design.

Good codebases are easy to test — better feedback, better code

What we notice is that good code bases are easy code bases to test, right? So, here we're starting to get back to the idea of code being important is that the better your codebase is, the better your feedback loops are. Because you're able to um give better feedback to the LM, it produces better code.

Deep modules vs shallow modules — hide complexity behind a simple interface

He talks about having deep modules in your codebase. Not shallow modules not lots of modules that expose like kind of um lots of functions. They should be relatively few large deep modules with simple interfaces.

Deep modules, lots of functionality hidden behind a simple interface, hiding the complexity. You can look inside the deep module if you want to, but you don't need to. You can just use the interface. Shallow modules, not much functionality, complex interface.

Shallow modules — AI can't navigate them

Shallow modules in a codebase kind of look like this, where you have a ton of different tiny little blobs that the AI has to walk through and navigate. And this is really hard for the AI to explore actually. ... AI is really good at creating code bases like this is that you'll have a situation where AI doesn't understand what your code is doing.

Design the interface, delegate the implementation

You can kind of treat these modules or these deep modules as gray boxes. you can kind of say okay I'm going to just design the interface but I'm not going to worry too much or not review the implementation too much you can do this obviously with uh things that are less critical in your application can't do this with uh you know various things like finance or whatever but in many many modules in your app you don't need to think about the implementation too much as long as you have a testable boundary outside the module and as long as you understand its purpose and can design it from the outside

So that's tip number five design the interface delegate the implementation

Invest in the design of the system every day — Kent Beck

Whenever we're touching the code whenever we're planning stuff we need to think about and be aware of the modules in our application we need to know that map really well it needs to be part of our ubiquitous language we need to build into our planning skills as well.

And this comes from Kent Beck. Invest in the design of the system every day. And this is the core of it right because specs the code we are not investing in the design of the system we are divesting from it. We're getting rid of that.

Code is not cheap — you are the strategic level above the tactical agent

And so code is not cheap. That's the message I want you to take away. Code is important.

And if we think about AI as a really great on the ground programmer, a kind of tactical programmer, a sergeant on the ground making the code changes, you need someone above that. You need someone thinking on the strategic level and that's you. And that requires software fundamental skills that we've been using for 20 years for longer.