This really clarifies something I've experienced more than once joining companies with a lot of legacy code. More new functionality is always wanted, but building on the existing codebase had already consumed too many of their futures. We had to invest in refactoring and testing first, which felt risky because it delayed features. Your features/futures framing names exactly what I was protecting -- the capacity to keep building after that first feature shipped.
At one company after we did this there was push to build a vast feature, something like 1.5 team-years worth of work. A clever product manager on the team led the fast delivery of the smallest unit of that feature that could provide value, and then found customers used it and liked it. She asked them what else it needed to do, and one enhancement was requested far more than any other. We built that. Total time: three weeks. Customers all but stopped asking for more. They never needed the rest of what we initially envisioned this feature to be! We preserved futures by building only what was actually needed. Reading this makes me realize we were alternating between features and futures without having the language for it. Thank you for giving me that language.
At the same time I’ve found that so much of what happens next depends on the makeup of my team. What values do we share?
I sometimes wonder if I could convince people that gravity exists if they aren’t already interested in the topic.
I could think futures vs features are important. Meanwhile my team mates might be more oriented towards new threading models in Java 25. If that’s the case we’ll have hard time navigating the features vs futures space.
I struggle with this aspect of work more than anything. I guess I’m asking how to apply this in a team setting when it’s not even something on people’s radar.
Is it possible that writing a system with LLM tools will become so cheap that we won’t need to build for the future because when we want a new feature, we throw away the old code and just rebuild everything again with the new feature built in?
I see folks using "spec-driven development" at the feature level now for genies -- do you feel that the compounding game can be played with specs "in the small" like that, or do you feel that specs can never be sufficiently complete/accurate even at a feature level?
In other words, you think they're not really writing a "spec" for a genie to use to write tests (and then write code), they're just writing a detailed prompt and calling it a "spec"? (That is what I suspect, too -- they're trying to sound more "formal" around their AI usage)
Do you dislike the term "feature spec" in the first place? What term would you use instead when describing such a workflow.
ur being nice here lol ... this 1 shot mindset is deeply rooted on whatevs made the water fall long time ago ... i think y'all r being too nice (thinking gojko here too) ... also architects should b called out here on getting their dream of get the specs right code is cheap ... i think stronger voices against it might b more helpful
This really clarifies something I've experienced more than once joining companies with a lot of legacy code. More new functionality is always wanted, but building on the existing codebase had already consumed too many of their futures. We had to invest in refactoring and testing first, which felt risky because it delayed features. Your features/futures framing names exactly what I was protecting -- the capacity to keep building after that first feature shipped.
At one company after we did this there was push to build a vast feature, something like 1.5 team-years worth of work. A clever product manager on the team led the fast delivery of the smallest unit of that feature that could provide value, and then found customers used it and liked it. She asked them what else it needed to do, and one enhancement was requested far more than any other. We built that. Total time: three weeks. Customers all but stopped asking for more. They never needed the rest of what we initially envisioned this feature to be! We preserved futures by building only what was actually needed. Reading this makes me realize we were alternating between features and futures without having the language for it. Thank you for giving me that language.
This is good and helpful.
At the same time I’ve found that so much of what happens next depends on the makeup of my team. What values do we share?
I sometimes wonder if I could convince people that gravity exists if they aren’t already interested in the topic.
I could think futures vs features are important. Meanwhile my team mates might be more oriented towards new threading models in Java 25. If that’s the case we’ll have hard time navigating the features vs futures space.
I struggle with this aspect of work more than anything. I guess I’m asking how to apply this in a team setting when it’s not even something on people’s radar.
Is it possible that writing a system with LLM tools will become so cheap that we won’t need to build for the future because when we want a new feature, we throw away the old code and just rebuild everything again with the new feature built in?
For one user? Maybe. For a system with a billion users, I just can’t see it. (I may be the old fuddy-duddy here.)
I see folks using "spec-driven development" at the feature level now for genies -- do you feel that the compounding game can be played with specs "in the small" like that, or do you feel that specs can never be sufficiently complete/accurate even at a feature level?
What do we mean by “spec”? Feature-level tests? Sure, they’re good enough. Vague prose that the genie can game? Hell no.
In other words, you think they're not really writing a "spec" for a genie to use to write tests (and then write code), they're just writing a detailed prompt and calling it a "spec"? (That is what I suspect, too -- they're trying to sound more "formal" around their AI usage)
Do you dislike the term "feature spec" in the first place? What term would you use instead when describing such a workflow.
Game changer!
ur being nice here lol ... this 1 shot mindset is deeply rooted on whatevs made the water fall long time ago ... i think y'all r being too nice (thinking gojko here too) ... also architects should b called out here on getting their dream of get the specs right code is cheap ... i think stronger voices against it might b more helpful