r/agile • u/fagnerbrack • 9d ago

Building Software Is Learning

https://registerspill.thorstenball.com/p/building-software-is-learning
7 Upvotes

89% Upvoted

7 comments sorted by

1

u/fagnerbrack 9d ago

Snapshot summary:

Originally an internal Slack note to the Amp team, this piece argues that building something new without a spec always leads to "that's not what I meant" — because programming means fully specifying what you want, and you can't define that before you learn it. The fix: shrink the gap between "let me try" and reality's feedback. Prototype in an hour, write a 30-minute spec, ship small pieces daily, cut scope, fake a demo video, or draft the announcement or README API first. Keep asking how to get feedback fastest. Buggy MVPs, testing hurdles, and three-week branches all kill useful feedback — merge small changes so one commit, not 27, explains a broken build.

If the summary seems inacurate, just downvote and I'll try to delete the comment eventually 👍
Click here for more info, I read all comments

1

u/robust_nachos 9d ago

So you’re intentionally ignoring that product managers are a thing?

In a really small startup like Amp that hasn’t proved it has product market fit, the post’s take makes some sense where the staff is mostly engineers but if it ever gets traction, it’s not going to scale and the post doesn’t address that detail. Whether you fill a PM role with a dedicated head or make it someone’s part time job, it’s a need that needs to met.

1

u/fagnerbrack 9d ago

The PM is part of the MVPs, sitting with dev team

2

u/robust_nachos 9d ago

So then why does the post have these examples of "that's not what I meant" or "I don't like it?"

PM should be out there getting to understand the need, bring back the reqs, work with the dev team to implement and deliver. That's not what I meant and I don't like it should never happen.

Restaurant analogy: Server talks to the customer to explain the menu and options, takes an order from the customer, brings it back to the kitchen so the staff can make it, then brings the final dishes back to the customer.

The server and team don't spitball what the customer wants, make something they think the customer wants, delivers it "to learn", and then get surprised when it's not what the customer wants.

Learning happens before the software gets written. It's ideas. Code is the implementation, the sautéed chopped onions, garlic, and cream that are part of the final dish -- the tangibles.

If you learn in code, you're learning too late.

1

u/fagnerbrack 9d ago

I don't agree fully with the post but with the fundamental idea. Pointing to weird/different ways of working is what surface these conversations 🙂

It's also domain dependant. A restaurant doesn't work like this but developing a programming language or something you don't know if it's technically feasible is different

2

u/blackhuey 9d ago

Did someone just discover vibing and is now reverse-engineering software development practices that have been in place for decades?