[PetiteCloud] grate book on how to specify systems

Aryeh Friedman aryeh.friedman at gmail.com
Fri Feb 14 17:01:05 PST 2014 

A little glue in the *RIGHT* places and a nice skin will win *EVERY* time.
The inappropriate marketing of any kind of product will always fail.
Namely no appropriate marketing is possible if the product sucks.   Only
once you have a soild product can you start the real marketing (this
assumes your aware of marketing 101 and know that without a market to
market to no amount of marketing will sell your product).   But you need
one more element here which is prove that your product does in fact solve
the actual problem the potential customer has.  Now that everything is in
place we can start the real work of marketing which is making the people
who have the problem your product solves know that you have the a solution
(a good healthy multi-vendor market should offer several solutions that are
all appropriately marketed).   Thus the real job marketing of an
appropriately product is to just let people know about what your product is
and what it can do.   If it does not do what they want or in the way they
want then no amount marketing will sell it to them if they are aware of a
number of competing solutions.    If all these competing solutions depend
on a common enabling technology (like a cloud computing platform... in this
case it need not be petitecloud just the ability to manage instances and
such) then it is *CRITICAL* that every competitor have a fair say in it's
creation.... there is a problem here though if you allow everyone to have
an equal say then you end up with crap every time.... there fore the only
reasonable model I see for the above to work for something like petitecloud
is a democratic benevolent dictatorship (the philospher king model)...
namely we (the core team) will take input from everyone and have open
processes and all that but what is actualy committed to code is our say and
our say alone... same goes for contributions we welcome all and except for
cases of introduction a requirement for radical refactoring we will take it
(assuming it is safe, stable and robust).

A comment on "we don't support that feature"... here is a quote from our
business plan on that:

 All software companies to some extent have "technical support" questions
that must be answered (or people will simply stop buying their products).
This is usually delegated to a tech support department. Having to deal with
a "tech support specialist" of large companies is one of the quickest ways
to anger our target market. The reason is despite how long we wait on hold
(with the world's worst music played in a tin can) or how many useless
menus we go through and have very carefully explained for the nth time that
we have already read the manual and searched the online knowledge base it
is still guaranteed that an actual developer who can fix my issue will
never be told about the issue, thus guaranteeing it will never be fixed and
will eventually get buried so deep in the code base that it will be
impossible to fix. This entire process is alienating to freelance
developers because they often know as much, if not more, about the product
then the tech support people do.



On Fri, Feb 14, 2014 at 7:21 PM, Michael Thoreson <m.thoreson at c4labs.ca>wrote:

> Those criticisms perfectly explain why closed source solutions don't work
> when you are trying to make use of features from multiple vendors.
> Businesses spend stupid amounts of money on what sales people say will do
> the job for them and then hand off to the IT staff saying make them work
> together.
>
> You end up with custom scripting that will eventually break something and
> the only people that can fix it are your IT staff but they have to spend
> days on the phone with all the vendor support lines trying to get past the
> "we don't support that configuration" BS.
>
> No wonder Macrocrap (Microsoft) has done so well making lots of small
> programs seem to work together flawlessly.
>
> Michael Thoreson,
>
>
>
> On 14/02/2014 6:00 PM, Aryeh Friedman wrote:
>
>> It is amazing how many people do not get it for example look at
>> http://en.wikipedia.org/wiki/Extreme_programming (criticisms section)
>>
>>
>> On Fri, Feb 14, 2014 at 6:57 PM, Michael Thoreson <m.thoreson at c4labs.ca<mailto:
>> m.thoreson at c4labs.ca>> wrote:
>>
>>     To me the concepts in that book are common sense. I did a medium
>>     sized network setup for a Union Office in my area with vpn between
>>     two cities and before even considering a quote or any real
>>     discussion, I asked to spend a few days observing day to day tasks
>>     at each office so I could understand how the offices functioned.
>>
>>     No sense spending $30,000 on a deployment and the customer say wtf?
>>
>>     Michael Thoreson,
>>
>>
>>     On 14/02/2014 2:41 PM, Aryeh Friedman wrote:
>>
>>         In many ways this book is one of FNWE's bibles (books that
>>         capture our way of doing things [which often predate reading
>>         the book]).
>>         http://www.amazon.com/Specification-Example-
>> Successful-Deliver-Software/dp/1617290084
>>
>>         --         Aryeh M. Friedman, Lead Developer,
>> http://www.PetiteCloud.org
>>
>>
>>         _______________________________________________
>>         petitecloud-general mailing list
>>         petitecloud-general at lists.petitecloud.nyclocal.net
>>         <mailto:petitecloud-general at lists.petitecloud.nyclocal.net>
>>
>>         http://lists.petitecloud.nyclocal.net/listinfo.cgi/
>> petitecloud-general-petitecloud.nyclocal.net
>>
>>
>>     _______________________________________________
>>     petitecloud-general mailing list
>>     petitecloud-general at lists.petitecloud.nyclocal.net
>>     <mailto:petitecloud-general at lists.petitecloud.nyclocal.net>
>>
>>     http://lists.petitecloud.nyclocal.net/listinfo.cgi/
>> petitecloud-general-petitecloud.nyclocal.net
>>
>>
>>
>>
>> --
>> 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
>>
>
> _______________________________________________
> petitecloud-general mailing list
> petitecloud-general at lists.petitecloud.nyclocal.net
> http://lists.petitecloud.nyclocal.net/listinfo.cgi/petitecloud-general-
> petitecloud.nyclocal.net
>



-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.petitecloud.nyclocal.net/pipermail/petitecloud-general-petitecloud.nyclocal.net/attachments/20140214/ed4819fc/attachment-0003.htm>

More information about the petitecloud-general mailing list