Hacker News Reader

Comment by koliber | Hacker News Reader

You can't code without specifications, period. Specifications can have various forms but in ultimately define how your program should work.

The problem with what people call "Waterfall" is that there is an assumption that at some point you have a complete and correct spec and you code off of that.

A spec is never complete. Any methodology applied in a way that does not allow you to go back to revise and/or clarify specs will cause trouble. This was possible with waterfall and is more explicitly encouraged with various agile processes. How much it actually happens in practice differs regardless of how you name the methodology that you use.

View on HN

Of course you can code without specifications. Most software projects don't have them these days.

In contrast they're still the standard in the hardware design world.

> Of course you can code without specifications. Most software projects don't have them these days.

And most software projects are complete mess that waste unfathomable amounts of resources. But yeah, you “can” develop like that.

Code is a specification. You cannot have a program unless you specify how it works.

And TTD would say "start with a failing test, it is an executable specification for the code that you will need to make it pass. Then make it pass, then refactor to make nice code that still passes all tests - red, green, refactor under tests"

Most code is not a specification in the sense that we're talking about.

This is a Tyranny of Structurelessness sort of thing. In that essay there is a structure in structureless organizations but it's implicit and unarticulated which makes it inscrutable, potentially more malleable (which could be good), but also constricting to those who don't know the actual structure when they try and accomplish things.

If you don't have explicit specifications (which don't have to be complete before starting to develop code), you still have specs, but they're unarticulated. They exist in the minds of the developers, managers, customers, and what you end up with is a confused mess. You have specs, but you don't necessarily know what they are, or you know something about them but you've failed to communicate them to others and they've failed to communicate with you.

> you still have specs, but they're unarticulated

Most people call this "not having specs".

If you define “specifications” as a formal document with that title atop, then you’re right.

If you define it as a description of what needs to be built then by definition you can’t build what is not described.

User stories are a type of specification. “Build me a Facebook clone” is a type of specification. A well-refined Figma doc is a type of specification. They all specify what needs to be built at various levels of fidelity.

You need specifications.

Reply on news.ycombinator.com