[PetiteCloud] more design assumptions

[Michael Thoreson]

On 13/02/2014 6:05 AM, Aryeh Friedman wrote:
> (I have almost all these "assumptions" posts done)
>
> 1. The "user" (human or machine) is out to get us and will do 
> completely random, bizarre and baffling things
YEP!
> 2. The "client" (the ultimate consumers of our work [aka those who put 
> the money up]) will do even more random, bizarre and baffling things 
> and then claim that they are never wrong (and most cases they are 
> right in this).  The client will also come up with endless "small" 
> feature "suggestions" where each one will require almost complete 
> redesigns of central and critical components of the system. That when 
> such requests are made they are always due yesterday and that the 
> system must not have a single hiccup in the switch over.  Finally they 
> will claim that all this comes under the category of it is a "bug" 
> after all so they do not owe us a dime for the "fix".
This one is a 50/50. You can sometimes get money for new features.
> 3. The client never wants to hear from us unless we have fixed their 
> "problem" but if they have a new "problem" we will hear from them 
> endlessly and the most annoying times
Agreed
> 4. That our own work machines/network are out to get us and will at 
> the first opportunity eat all our work.
Yep, been there, done that and then cried.
> 5. We are designing for highly secure mission critical environments 
> (note we purposely do not actually have any such clients and do not 
> "certify" any of our work for such environments) where zero down time 
> is tolerable and that the system must work the first time and every 
> time without flaw
Doesn't mean PC can't evolve into mission critical ready.
> 6. In testing you can (and should) do the most random, bizarre and 
> baffling things you can think of
I am good at this. Very good at this. I started learning about computers 
by intentionally breaking it by deleting files or changing settings and 
then learning how to fix it without the typical nuke and reload.
> 7. Since we are a tiny team we have zero time to fuss with overly 
> complex methodologies or the latest fad in system/software 
> engineering.   This means agile is just as bad for our needs as 
> "waterfall".
>
> 8. Because of #6 everything (including all our testing) has to as near 
> to 100% automated as is possible (certain kinds of tests are 
> impossible to automate without losing the key elements of the test) 
> and that this automation has to be as "push button" as possible
There are a number of projects that have testing scripts that could 
probably be used here with little alterations.
> -- 
> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
>
>
> _______________________________________________
> petitecloud-general mailing list
> petitecloud-general at lists.petitecloud.nyclocal.net
> http://lists.petitecloud.nyclocal.net/listinfo.cgi/petitecloud-general-petitecloud.nyclocal.net