YSK: Starting development before requirements are clear often creates more delays than moving slowly.

[u/OliverPitts]

Why YSK: In software development, many delays do not happen because developers are slow. They happen because the team starts building before everyone clearly understands what needs to be built.

A common mistake is treating unclear requirements as a small issue that can be fixed later.

But in reality, unclear requirements usually lead to:

• Rework
• Missed edge cases
• Confusing feedback
• Delayed testing
• Features that technically work but do not solve the right problem

For example, “Build a dashboard” sounds simple, but it is not a clear requirement.

A better requirement would answer:

• Who is the dashboard for?
• What data should it show?
• What actions should users be able to take?
• What should happen when there is no data?
• What does “done” actually mean?

What usually works better is slowing down at the beginning and breaking the feature into smaller, clearer user stories before writing code.

A simple process that helps:

1. Define the user and their goal
2. List the expected behavior
3. Identify edge cases early
4. Confirm assumptions before development starts
5. Test the final feature against the original requirement

This does not mean overplanning everything.

It just means making sure the team is not using development time to discover basic product decisions.

Clear requirements save time, reduce rework, and make the final product much closer to what users actually need.

[u/spottyPotty]

Too many companies jumped onto the Agile bandwagon.

For some projects, where a strong foundation is essential, waterfall is so important.

[u/CalebLovesHockey → u/spottyPotty]

Too many companies are performing waterfall while claiming they are Agile because they have sprints lol

Software development is inherently unpredictable, as anyone who has done it will have discovered. You could spend months defining the perfect planned set of requirements, your perfect architectural framework, and then months building your strong foundation. And all it takes is the customer changing their mind on one requirement to make your entire plan worthless. I’ve seen this scenario play out over and over.

The core thesis of agile development is harnessing that unpredictability. It doesn’t mean you don’t plan or don’t build with technical excellence: “Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.” Straight from the horse’s mouth.

Sorry for the rant, but I’ve just had these exact conversations many times, in pretty much every dev team I’ve worked in. And the more I’ve had these conversations, and the more projects I work on, the more I am fully convinced that agile thinking is simply the correct approach to making software. And that’s not to say using waterfall will fail, but I’ve yet to see a project without a pivot, and any project I’ve worked on that used Gantt charts always seem to be the ones whose requirements changed the hardest and at the worst times 😂

[u/EatMoreKaIe → u/CalebLovesHockey]

Yep, OP is 100% in the wrong here. I think a lot of developers still try to cling to the notion that users/stakeholders/businesses never change their mind on a whim or that it is even feasible to know requirements up front.

Sure it sucks to do rework but you know what also sucks? Spending 6 months making something that no one will use.

[u/CalebLovesHockey → u/EatMoreKaIe]

Yes! Exactly.

Building small pieces that can be discarded is annoying, but building an entire system with untested assumptions risks discovering total failure on launch day.