3 ms·

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

by koliber 11mo ago

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.

IshKebab 11mo ago
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.
- wiseowise 11mo ago
  > 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.
- n0w 11mo ago
  Code is a specification. You cannot have a program unless you specify how it works.
  - SideburnsOfDoom 11mo ago
    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"
  - IshKebab 11mo ago
    Most code is not a specification in the sense that we're talking about.
- Jtsummers 11mo ago
  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.
  - IshKebab 11mo ago
    > you still have specs, but they're unarticulated Most people call this "not having specs".
- koliber 11mo ago
  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.

by koliber 11mo ago

IshKebab 11mo ago

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.

wiseowise 11mo ago
> 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.
n0w 11mo ago
Code is a specification. You cannot have a program unless you specify how it works.
- SideburnsOfDoom 11mo ago
  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"
- IshKebab 11mo ago
  Most code is not a specification in the sense that we're talking about.
Jtsummers 11mo ago
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.
- IshKebab 11mo ago
  > you still have specs, but they're unarticulated Most people call this "not having specs".
koliber 11mo ago
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.