I guess that’s the difference between “maybe later” and YAGNI. YAGNI is a discipline.
"Maybe later" was a feature
11–20 of 37 posts
Re: "Maybe later" was a feature
#12Doesn't this just mean we need to get better at the active deconstruction and disassembly process? Like it's too easy to build, so we build more things we realize later that we shouldn't. Now, a comparable energy budget we used to use "deciding what to build" (because labour was scarce) is now energy we can divert toward "unbuilding stuff that was a mistake". I'd much rather learn to live in the latter world. That wo…
> Now, a comparable energy budget we used to use "deciding what to build" (because labour was scarce) is now energy we can divert toward "unbuilding stuff that was a mistake"
The hard part is that you very quickly become Salesforce or Jira or .
You have thousands of users who love your product and pay lots of money and find the features absolutely essential to their workflow. Everyone says your product is bloated and has too many useless features, if only you could delete a bunch of crap they don’t use your software would be perfect.
They all use a different 20%. Delete a feature, lose a fifth of your users.
Re: "Maybe later" was a feature
#13Everything is search.
Software development is search through the space of useful/interesting automations. Business is search for product market fit (at the intersection of expertise, capital, problem, etc.) Writing is search for lossless, efficient idea transfer.
AI software development is more search. If we search more, will we find a bunch of garbage? Hell yes. We'll find a TON of garbage. That's not new, though. The world has been writing way more books than you'll ever read, recording more music you'll ever hear, filming more television shows than you'll ever get to watch, etc. A lot of it is garbage, but the good stuff stands the test of time and rises to the top, and I'd rather live in a thriving, flourishing world full of all these things, because there's more cream-of-the-crop when there's more everything.
It's evolutionary fitness operating in the space of ideas. I agree that "maybe later" was indeed a useful mechanism, and maybe even a local optimum in the development methodology search space (which recently experienced a major earthquake!), but evolutionary pressure will bring it back into existence in some form sooner or later.
Re: "Maybe later" was a feature
#14Definitely agree with this. Even without a large backlog, one of the things I find working on my personal project/product where I'm simultaneously the engineer/designer/project manager is it's really easy to ask the LLM to implement an idea I've been mulling for an hour or two, it one-shots it and I'm happy, and then a week or two later it starts to dawn on me that the feature was maybe not a great idea. Which isn't…
That’s why I usually starts with the simplest version of something I want, which is usually a shell or a perl script. When I nailed down my workflows and needs, that’s when I build a proper program. This is one of the reason I like cli programs. They’re like lego blocks for workflows.
Same things with bigger projects. Write the most minimalistic version of a feature, and then ship it (or do a round of testing). Iterate based on feedback.
Re: "Maybe later" was a feature
#15Definitely agree with this. Even without a large backlog, one of the things I find working on my personal project/product where I'm simultaneously the engineer/designer/project manager is it's really easy to ask the LLM to implement an idea I've been mulling for an hour or two, it one-shots it and I'm happy, and then a week or two later it starts to dawn on me that the feature was maybe not a great idea. Which isn't…
The good thing is since the feature was cheap to implement, you can just say "this was a bad idea" and remove it, as long as adding that feature wasn't a one way decision. People are typically more reticent to remove things that were hard to implement, even if that's the right thing to do.
Re: "Maybe later" was a feature
#16Everything is search. Software development is search through the space of useful/interesting automations. Business is search for product market fit (at the intersection of expertise, capital, problem, etc.) Writing is search for lossless, efficient idea transfer. AI software development is more search . If we search more, will we find a bunch of garbage? Hell yes. We'll find a TON of garbage. That's not new, though.…
One of my favorite things about AI is that I don't have to execute the curation and criticism at the "page of monospaced text" stage to anywhere near the degree, difficulty, or criticality. I love being able to build it, try it, say "No, no I don't think I will do this, this is amazingly awful"
Re: "Maybe later" was a feature
#17I guess that’s the difference between “maybe later” and YAGNI. YAGNI is a discipline.
One of the most important things I ever learned from a colleague was YAGNI. He would review my code and mark sections as YAGNI. I didn't know what it meant at the time. He kindly explained and since then I have been the teacher of that very important guideline.
Re: "Maybe later" was a feature
#18Everything is search. Software development is search through the space of useful/interesting automations. Business is search for product market fit (at the intersection of expertise, capital, problem, etc.) Writing is search for lossless, efficient idea transfer. AI software development is more search . If we search more, will we find a bunch of garbage? Hell yes. We'll find a TON of garbage. That's not new, though.…
One of my favorite things about AI is that I don't have to execute the curation and criticism at the "page of monospaced text" stage to anywhere near the degree, difficulty, or criticality. I love being able to build it, try it, say "No, no I don't think I will do this, this is amazingly awful"
I agree but the practical cost is most heavily paid in a collaborative work setting. Now everyone at all layers of a company is doing build prototype exploration but without the intermediary internal-filter check. Instead, these explorations get a straight line to production, for reasons I'm not exactly sure. Because it can I guess?
Re: "Maybe later" was a feature
#19Earlier quoted context omitted.
One of my favorite things about AI is that I don't have to execute the curation and criticism at the "page of monospaced text" stage to anywhere near the degree, difficulty, or criticality. I love being able to build it, try it, say "No, no I don't think I will do this, this is amazingly awful"
I agree but the practical cost is most heavily paid in a collaborative work setting. Now everyone at all layers of a company is doing build prototype exploration but without the intermediary internal-filter check. Instead, these explorations get a straight line to production, for reasons I'm not exactly sure. Because it can I guess?
Yeah that's where my eyebrows go to the moon. My investigations are at best in staging after a dev machine review, if nontech people are involved you need per-user cloud dev I think
Re: "Maybe later" was a feature
#20Definitely agree with this. Even without a large backlog, one of the things I find working on my personal project/product where I'm simultaneously the engineer/designer/project manager is it's really easy to ask the LLM to implement an idea I've been mulling for an hour or two, it one-shots it and I'm happy, and then a week or two later it starts to dawn on me that the feature was maybe not a great idea. Which isn't…
The good thing is since the feature was cheap to implement, you can just say "this was a bad idea" and remove it, as long as adding that feature wasn't a one way decision. People are typically more reticent to remove things that were hard to implement, even if that's the right thing to do.
> People are typically more reticent to remove things that were hard to implement, even if that's the right thing to do.
Careful. The sunk cost fallacy isn't just about time, it's also about money, and people may naturally be reluctant to remove bad features that cost them a lot of tokens, especially if the act of removal itself is going to cost even more tokens.