Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
"What approach they choose doesn’t matter; until someone starts insisting that these intermediate designs should be products in their own right. It’s the code that matters. If you get good code, does it really matter how it came about? If you don’t get good code, does it really matter how much other garbage you made people do before they wrote the bad code?"
If 'source code' includes tests, then absolutely. If you have automated acceptance tests (good ones) then they tell you what the solution does and why it does it - and they never go out of date.
And the same for lower level unit tests - you don't need to see a design *if* the tests are good & expressive.
In some cases, however, it may be the case that a high level design document is produced.
This can be useful as it tends to flush out elements of a technical design, that require further definition, or those that simply won't work.
I certainly wouldn't be expecting to produce this after development is complete.
Business user and business analyst engage to try and determine requirements, from which emerges a badly written BRD, with virtually none of the pre-requisite detail.
Business analyst and technical analyst engage to discuss requirement, from which emerges a, poor quality, functional-spec, due to the lack of definition of the business requirement.
BA tries to translate gobbledygook to English for the end user, with as much smoke and mirrors, as possible, purely to get the thing signed off.
Solution picked, usually by who holds the strongest political will, in the organisation, at that time, or which software company provides the best lunches.
Technical analyst, systems architect and developers engage to try and thrash out, some kind of, design document and/or tech spec.
Development handed over to, untrained, off shore team, chosen by whatever offshore provider was the cheapest, on that day.
Solution gets delivered two years late, with 80% of the functionality missing, by which time, the competitive advantage is lost, or, the business user has either lost interest, or have left the business.
Generally what someone thinks they want and what they actually need are quite different. It is much easier to understand when you have something in front of you to complain about, so there is a lot to be said for "just deliver something".
You forgot the bit where the solution had been determined by the CEO on the golf course and the rest of the organisation are left to make it so.
I thought this covered it, apologies, if not :-
Solution picked, usually by who holds the strongest political will, in the organisation, at that time, or which software company provides the best lunches.
In some cases, however, it may be the case that a high level design document is produced.
This can be useful as it tends to flush out elements of a technical design, that require further definition, or those that simply won't work.
I certainly wouldn't be expecting to produce this after development is complete.
Sure. But the question is (and I can think of situations where it is worthwhile for large systems) do you want to keep them for posterity (and therefore keep them up-to-date throughout).
Sure. But the question is (and I can think of situations where it is worthwhile for large systems) do you want to keep them for posterity (and therefore keep them up-to-date throughout).
Hmmmm, difficult one.
I have usually used them to prove the architectural concept.
Important in what I do, as I work with enterprise level stuff that all has to talk to each other.
Comment