316. I Dislike Spec Driven Development - Here Is Why

What are your thoughts on spec driven development? Does writing better specs mean that I get better output from my AI system? Doesn't a good spec cut down on hallucinations? These are the questions we will answer in today's episode of DevQuestions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_01 0:00

I think that spec-driven development is terrible. I don't want any part of it. But this isn't about bashing a way of doing software development. I think it's important to understand why I disagree with spec-driven development, since development with AI is going more towards spec-driven development. So let's talk about it in today's episode of DevQuestions.

SPEAKER_00 0:29

Welcome to the Dev Questions Podcast with Tim Corey.

SPEAKER_01 0:33

Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about spec-driven development. Now, we're going to start off with what is spec-driven development? Well, it's writing a detailed specification, that's the spec, about what the system should do before you implement it. So you're building an application and you say, here is exactly how it should work. The spec becomes the source of truth. This is what the app does. Now that spec can include API contracts, business rules, data models, the behavior of the app, the outcomes the app should have, et cetera. So that's what the spec-driven development is. And it turns a good idea into a management exercise. And that's the problem. So now this is currently gaining popularity because of AI. We think about it, one of the first things that happened when we got LLMs is we started asking the LLM to do something. And it was at first, you know, hilariously wrong, and it started getting better and better until it's, you know, it's pretty good. And one of the things you'll see is that whenever you get a bad output from AI, people will tell you, well, you're holding it wrong, right? You're prompting it wrong. Um, you need to have a better prompt. And so there's whole schools of thought around how do you craft the perfect prompt? And there's even tools out there to aid in that prompt, you know, where you can have a tool that says, okay, here's how to write good C sharp.net 10 code. And here's how to write, you know, good code for our business, and here's our business rules, and all this stuff. And then you create this really detailed prompt. And sometimes that works, and sometimes you still don't get a good enough result. And now we're we have things like loops where we're letting an AI just do its work in the background and figure out what to do next. And so we're starting to give it detailed specifications and say, okay, here's your specification, and let the loop just iterate over that and figure out how to design it and then pull off pieces and build that piece and test that piece and so on. But the thing is, the more specific we get, the better the output should be, at least. So the English language really isn't precise. So we need to be more precise, and that takes you know, restating the solution. Sometimes it means sometimes using precise language, et cetera, in order to get the right conclusion for us. All right. So that's where we start to kind of spin out a spec. That's where we start to say, this is the specification for my app. And the more precise we can get, the more easily an AI can look at that and say, you want a calculator that can add two plus two and get four. Let's check to see if the current thing I built can do that. You know, and you start having more and more of these things that tell it exactly how it should work. Hopefully, the the um the more specific you can get, the more um impressive the output can be. So let's take this thought process to its logical conclusion. So let's let's think about spec-driven development. Think about how do we get the most precise, most rigid, making sure that yes, we have a non-deterministic AI, but we want to almost lock it into determinism, right? We want to say, this is exactly how I want it to work. How do we do that precise enough so that we always get the right thing out? So that the thing we have in our brains actually gets built by the AI. Because if we can do that, then what we can do is we could actually have the AI build applications because it can give us exactly what we're looking for. So let's let's kind of design this system at the end conclusion, right? Let's the logical conclusion of this spectrum in development. So we're gonna need precise structures and exact symbols to make our specs less ambiguous. You know, English is very imprecise. So let's use specific words and make sure that we do things in a certain way and have some symbols in there so you can say, okay, if you think about um anytime you've seen people talk about um like the cloud and Azure or anything else, they have these symbols, like the database symbol, it's a it's a certain symbol, and we have a server symbol and a web server symbol, and you know, all these different symbols that make it very clear what we're thinking. Well, we can have these symbols and we can make sure that we have specific uh words that we use for certain things. That way we're very precise and it's not um ambiguous what we're looking for. And then you know, if if we got to that level where we've got these precise structures and exact symbols that make our spec unambiguous, very clear, well then we could do is actually have an AI take that that um that spec and have an automated system that takes a spec and turns it into code directly. Like it could be really clear, it could almost be like one-to-one where it takes our spec and turns it into code, which what do we end up with? We end up with a programming language, right? That's exactly what a programming language is, because we don't write things in ones and zeros, which is what you know the eventual outcome is going to be for our code. What we do is we write in C sharp, where we say things like if and for and use English words that represent an idea and they're precise. So that when I say four, you know, i equals zero, i is less than 10, i plus plus, then what I'm doing is saying specifically, I want a variable called i. I want it to be initialized at the with zero in it. I want to loop over this loop until we get to, you know, not once we hit 10, we're done. And I want to increment i by one every time. We're being very, very specific, which is what a specification is. How specific do you want to get? Now, this is the crazy end solution of spec, but that's really where we're headed, right? And you know, if we had an automated way for the AI to take that spec and turn it into code directly, well, that's just what C sharp is or other languages, where we're creating the spec, which is code, and then it takes that spec and it turns it into a compiled code that can then be executed. And it's so specific that it can't be interpreted a different way. It's very specific. It's not not as English, where there could be a variance in how we're thinking about things. You know, my my favorite uh or least favorite word in the English language probably is bi-weekly. What does that mean? Does it mean every two weeks or twice a week? And the answer is yes. That's frustrating me, that's it's not specific enough. But if you're specific enough, you'd say twice a week. You know, um, that's more specific. That's what code is, is a very specific way of doing things. So the logical end conclusion for spectrum development is just to write code. So it's easy to cop in a way to solve a problem. And that's what, you know, we first start off, we had this idea of we want to be more precise in how we specify what the app should do. Because when your manager comes to you and says, I want you to build a calculator, that's not precise enough. That's nowhere near precise enough. And really, management almost never gives you anywhere close to enough of a specification for what the app should do. So the conclusion is let's make a structure for making it more precise. And that's a good thing. And so you start asking the right questions and start building out, you know, how do you want the data to look? And how do you want this to look in the front end? And what problems should it solve? And how do we know when we're done? And all of these are good things. But if you take things too far, what happens is the solution starts drifting in an area where it's already a solution. So too often in software development, we keep adding one more feature to something until it's blurred and messy. Like if you look at really like Microsoft Word, um, that's a great product, but at the same time, it's also kind of blue. There's a whole bunch of stuff in there. It's like most people don't ever use this, and it's you know, hard to figure out. There's a lot of features that you never know about, or Visual Studio, there's so many features people don't even know about. Where those are all good things in themselves, but in the grand picture of things, it makes things very, very difficult to use. So we tend to allow good management ideas to turn into an overbearing bureaucracy. Um I may have just had a whole bunch of people say yes, yes, yes to that sentence. Um I'll say it again. Um, we tend to allow good management ideas to turn into an overbearing bureaucracy. This is very common. It'll probably come up in a future dev question video. Um a lot of the things we do in software development start off as good ideas that turn into a whole bunch of ceremony, a whole bunch of management fluff. Um and it takes away from the task of actually doing the job. Uh, but it started from a good idea. It's just that it got overburdened. In this case, the idea of writing a good, clear specification for what the app should do is a great thing. But spec-driven development takes that concept and turns it into a managerial mess. And that's why I don't like spec-driven development. Thanks for listening. As always, I am Tim Corey.

SPEAKER_00 11:21

Thank you for joining us for this episode of Dev Questions. When you're ready to learn to think and code like a professional developer, head over to imtimcorey.com and enroll in a course.