Post

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.

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.

0 reposts11 likes

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

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.