Design via Proposed Documentation
kovasap.github.io
Design via Proposed Documentation
1–4 of 4 posts
Re: Design via Proposed Documentation
#2When possible (i.e. consent from management), every time (i.e. 10) I have used this approach, I was able to deliver zero-defect software, on time, and within the budget. This kind of documentation is literally the hardest work I've ever done in software. Eliminating ambiguity and vagueness is not for the faint of heart but the result is quite satisfying.
Re: Design via Proposed Documentation
#3When possible (i.e. consent from management), every time (i.e. 10) I have used this approach, I was able to deliver zero-defect software, on time, and within the budget. This kind of documentation is literally the hardest work I've ever done in software. Eliminating ambiguity and vagueness is not for the faint of heart but the result is quite satisfying.
Awesome to hear this has worked for you! I haven't tried this properly, just was just an idea I had that I thought was worth writing down.
Any details I might have missed or things to think about when trying this you have come across?
Re: Design via Proposed Documentation
#4When possible (i.e. consent from management), every time (i.e. 10) I have used this approach, I was able to deliver zero-defect software, on time, and within the budget. This kind of documentation is literally the hardest work I've ever done in software. Eliminating ambiguity and vagueness is not for the faint of heart but the result is quite satisfying.
Awesome to hear this has worked for you! I haven't tried this properly, just was just an idea I had that I thought was worth writing down. Any details I might have missed or things to think about when trying this you have come across?
Buy-in from management (or the funder) is key. They need to understand that more than 50% of the schedule may be taken by the documentation process.
This is not Agile nor Scrum, by any means.
Answering the hard questions will be agonizing.
E.g. - I once spent 3 hours with a UI/UX dev/designer working out the state machine for the key feature of a commercial product. She was frustrated working through the process - i.e. "Can't we just start with something!". And we were literally perspiring from thinking so hard. I explained that multiple versions of the state machine running at the same time was a bad idea. We persevered and that piece of code never had to be modified through the product lifecycle.
Prototyping features to vet user acceptance is quite common and recommended. Pick a prototyping language unsuitable for production ;) That way prototypes can't "accidentally" be turned into production software.
Consider reading "Toward Zero-Defect Programming" (1st Edition) by Allan M. Stavely.