In response to people who proclaim that software developers who "just translate specs into code" are "obsolete"...
Software specification is necessarily a conversation between people with needs – and, ideally, money – and people who specialise in meeting needs using computers. T’was ever thus, t’will ever be.
@jasongorman do you have recommendations for literature about writing specs?
i think I am mostly clear on the "how detailed should it be" part, but I struggle with the structuring. Having one big document feels like I will write this once and no one (besides me) will bother reading/using it. moving things into their own files solves this, but opens another can about where I draw the line.
@brahms Customers can write a headline on an index card, and then when you pick up that card to work on, you can have a conversation with them about it. An effective way to pin down a clear, shared understanding of what they expect the software to do is using concrete examples that can become executable acceptance tests.
Gojko Adzic's book Specification By Example explains this process well.
@jasongorman tbf is my situation a bit special, as in I am both the "customer" as well as the lead architect/engineer 😅
at least I dont have to worry that the spec wont contain my view, but I take great care so that the team also has the same understanding (i hope to solve that with interviews and easy to digest text).
Thanks for the recommendation :)
Steve Fenton ➜
Jason Gorman
Brahms