Post

Fred Hebert
@ferd.ca

The ongoing stream of software engineering pieces that mention that the future is in writing spec but never bother to define what a specification is or at what abstraction levels it should be is appalling; arguably, tickets are a spec, the code is a spec, and work between both is connecting dots.

5 reposts32 likes

Fred Hebert
@ferd.ca

The underlying argument as far as I can tell is that we might now operate at a higher level of abstraction in spec definition, but without stating which level it is or how we can switch across abstraction layers for various degrees of specificity, this whole thing is meaningless.

Amy Tobey
@renice.bsky.social

I don't buy the spec thing. a complete specification of a program is called code. human-language descriptions are always going to have dots to connect before a machine can consume them. this is why rewrites kinda work. this is why XP and "true" agile still matter

Fred Hebert
@ferd.ca

right; bits that are underspecified in the large allow degrees of freedom to make things work by adjusting them in the small. Part of the lack of definition is critical, and a real challenge (though not the only one) is knowing which bits should or shouldn't be specified.

Spritanium
@spritanium.bsky.social

I call it software. The compiled code is not self-documenting, you'd need to reverse engineer it to reveal the spec. I guess uncompiled code could be referred to as a spec though, since it's describing how the compilation should take place.

Fred Hebert
@ferd.ca

right, and doubly so in declarative languages, or cases like HCL for terraform, which is technically code.