3 ms·

[Replying to the quoted part.] So when it is convenient, the waterfall model is suddenly modern again? The waterfall model didn't work, because many inefficie

[Replying to the quoted part.] So when it is convenient, the waterfall model is suddenly modern again? The waterfall model didn't work, because many inefficiencies and wrong assumptions are found when writing code. This is also the advantage of Lisp and other languages that are malleable and not like a block of concrete. LLMs are like a block of concrete in that they spit out the same (plagiarized) solutions over and over again. They remove you from the code, they impede flow state due to the constant interactions and outsource your thinking to some GPUs in California. This waterfall rationalization is just one of the latest absurdities in the LLM blogging industrial complex.

hedora 2y ago
I watched extreme programming, and then agile morph into "waterfall, but on a one week cycle!" (For extreme programming, two weeks for agile.) "Modern" software development is based on the idea that waterfall doesn't work, but that you can fix it by only allowing projects that take either one week (dot com boom) or two weeks (web 2.0 boom). Personally, I avoid all this stuff as much as possible, since I've never seen any of it work. I have had good luck with LLMs, for what it's worth. I've found for step 4, writing an informal spec at the top of the source file works well: // $ curl https://api.com/foo/bar?baz // { json: "response", goes: "here" } along with instructions like "implement the interface defined in some other file", and "look at some other existing file for guidance" works well, as does "implement some trivial data structure from scratch". Then I have to read what it wrote and fix the inevitable 2-3 bugs + compilation errors. It usually gets the boilerplate right, but misunderstands fundamental things. This maybe saves me 50% of coding time, since my first draft usually has bugs + doesn't compile on the first attempt either. This really shines in step 5 (not listed above): Writing tests. I generally end up with more thorough tests than I'd write from scratch in maybe 20% of the time. Anyway, LLM's let me get about 10-20% more done per week. Most time is still spent designing stuff and evaluating solutions. The above workflow doesn't work for non-trivial modules. It just saves time on boilerplate. It's plagiarism the same way IDE auto-complete and copy / paste (from the same codebase) are.
ebiester 2y ago
So, while I've written about it before (see https://www.ebiester.com/agile/2023/04/22/what-agile-alternative.html https://www.ebiester.com/agile/2023/04/22/what-agile-alterna... ), all methodologies are based on the constraints of the time. Consider that The Pragmatic Programmer (and Andrew Hunt and Dave Thomas are original signatories to the manifesto) suggested in Pragmatic Programmer, “Build One to Throw Away (You will anyway)” And Fred Brooks said the same thing in the Mythical Man Month. The new constraint is that we can build a prototype much quicker for user testing. If it takes a week to build a trash version to throw away by vibe coding, you should build the trash version and get it in front of users to try out. Then, you can throw it away or do it again. If you can hammer out a prototype in 2 days (or two or three even) then that's pretty agile. If I can hammer out that prototype apart from the larger system, even better, because the cost of that prototype is cheap. And so I can totally choose to build it in larger chunks. I can think of an 18 month project - with a team - back in the day that I could bang out today in a prototype in a month. And I could have gotten it into the customer's hands screen by screen rather than a slow increment every two weeks. (This was an agile project.) I could have built a mock server with mock data. Some of the project would have taken just as long, but that would have been a hell of a lot more agile. And this project needed 20% novel solution and 80% best practices. Like most software.

hedora 2y ago

I watched extreme programming, and then agile morph into "waterfall, but on a one week cycle!" (For extreme programming, two weeks for agile.) "Modern" software development is based on the idea that waterfall doesn't work, but that you can fix it by only allowing projects that take either one week (dot com boom) or two weeks (web 2.0 boom). Personally, I avoid all this stuff as much as possible, since I've never seen any of it work. I have had good luck with LLMs, for what it's worth. I've found for step 4, writing an informal spec at the top of the source file works well: // $ curl https://api.com/foo/bar?baz // { json: "response", goes: "here" } along with instructions like "implement the interface defined in some other file", and "look at some other existing file for guidance" works well, as does "implement some trivial data structure from scratch". Then I have to read what it wrote and fix the inevitable 2-3 bugs + compilation errors. It usually gets the boilerplate right, but misunderstands fundamental things. This maybe saves me 50% of coding time, since my first draft usually has bugs + doesn't compile on the first attempt either. This really shines in step 5 (not listed above): Writing tests. I generally end up with more thorough tests than I'd write from scratch in maybe 20% of the time. Anyway, LLM's let me get about 10-20% more done per week. Most time is still spent designing stuff and evaluating solutions. The above workflow doesn't work for non-trivial modules. It just saves time on boilerplate. It's plagiarism the same way IDE auto-complete and copy / paste (from the same codebase) are.

ebiester 2y ago

So, while I've written about it before (see https://www.ebiester.com/agile/2023/04/22/what-agile-alternative.html https://www.ebiester.com/agile/2023/04/22/what-agile-alterna... ), all methodologies are based on the constraints of the time. Consider that The Pragmatic Programmer (and Andrew Hunt and Dave Thomas are original signatories to the manifesto) suggested in Pragmatic Programmer, “Build One to Throw Away (You will anyway)” And Fred Brooks said the same thing in the Mythical Man Month. The new constraint is that we can build a prototype much quicker for user testing. If it takes a week to build a trash version to throw away by vibe coding, you should build the trash version and get it in front of users to try out. Then, you can throw it away or do it again. If you can hammer out a prototype in 2 days (or two or three even) then that's pretty agile. If I can hammer out that prototype apart from the larger system, even better, because the cost of that prototype is cheap. And so I can totally choose to build it in larger chunks. I can think of an 18 month project - with a team - back in the day that I could bang out today in a prototype in a month. And I could have gotten it into the customer's hands screen by screen rather than a slow increment every two weeks. (This was an agile project.) I could have built a mock server with mock data. Some of the project would have taken just as long, but that would have been a hell of a lot more agile. And this project needed 20% novel solution and 80% best practices. Like most software.