I appreciate both the correction & getting to hear/learn different styles, so thanks for that one! I especially love the term RATS too just as a side note - one of the best things about being in IT is the names people give projects, apps etc.

Yep that maybe ought to be "could" not "should" above there then. I've also worked in a software house which produced a spec, went off & coded then handed over just the end product with little contact between too. In my own experience (& with a lot of hindsight), that was pretty disasterous & led to tons of bugs. I've read several books & articles since that time (most notably the head first software development book which I thought had some great ideas) & really wish we'd have done things differently, involving the cutomer tons more. Maybe that's not applicable to all places though & I hadn't considered every project type or development team there.

Places where the "could" part will fit in better for anyone else reading this post... (i) agile projects (ii) onsite projects where you're writing code or new features ad hoc & in a time and materials basis or (iii) you're working in a multivendor project largely or partly onsite with different vendors & teams.