Re: The Revenge of the Geeks

From: Arne Vajhøj <arne_at_vajhoej.dk>
Date: Fri, 01 Feb 2013 20:12:39 -0500
Message-ID: <510c680f$0$286$14726298_at_news.sunsite.dk>

On 1/31/2013 3:22 AM, BGB wrote:

> On 1/30/2013 7:12 PM, Arne Vajhøj wrote:
>> On 1/30/2013 4:22 AM, BGB wrote:
>>> On 1/29/2013 9:05 PM, Arne Vajhøj wrote:
>>>> On 1/27/2013 10:16 PM, BGB wrote:
>>>>> On 1/27/2013 6:40 PM, Arne Vajhøj wrote:
>>>>>> On 1/27/2013 1:47 PM, BGB wrote:

>>>>>>> On 1/27/2013 5:46 AM, Arved Sandstrom wrote:

>>>>>>>> Usually in the enterprise world you have little or no leeway as to
>>>>>>>> how
>>>>>>>> systems talk to each other. You may have a few options to choose
>>>>>>>> from,
>>>>>>>> but rolling your own is looked upon askance.
>>>>>>>>
>>>>>>>

>>>>>>> well, this is where the whole "mandatory interop or orders from
>>>>>>> above"
>>>>>>> comes in. in such a case, people say what to do, and the
>>>>>>> programmer is
>>>>>>> expected to do so.

>>>>>>>

>>>>>>> but, I more meant for cases where a person has free say in the
>>>>>>> matter.

>>>>>>>

>>>>>>> and, also, a person still may choose an existing option, even if
>>>>>>> bad,
>>>>>>> because it is the least effort, or because it is still locally the
>>>>>>> best
>>>>>>> solution.

>>>>>>>

>>>>>>> like, rolling ones' own is not required, nor necessarily always the
>>>>>>> best
>>>>>>> option, but can't necessarily be summarily excluded simply for
>>>>>>> sake of
>>>>>>> "standards", as doing so may ultimately just make things worse
>>>>>>> overall.

>>>>>>
>>>>>> It almost can.
>>>>>>
>>>>>> If you go non standard and problems arise, then you are in
>>>>>> deep shit.
>>>>>>
>>>>>
>>>>> depends on costs...
>>>>>
>>>>> if "liability" is involved, or the functioning of the software is
>>>>> "mission critical" or something, then there is more reason for
>>>>> concern.
>>>>>
>>>>>
>>>>> for many types of apps though, hardly anyone gives a crap how any
>>>>> of it
>>>>> works internally anyways, and people can pretty much do whatever.
>>>>>
>>>>> (like, if it crashes or breaks violently, oh well, the user will start
>>>>> it up again, and at worst probably the user will think less of the
>>>>> product if it is too much of a buggy piece of crap, ...).
>>>>
>>>> Not everything is important.
>>>>
>>>> But best practices should be based on an assumption about it
>>>> being important.
>>>>
>>>
>>> could be, or it could be that the importance of the system is another
>>> factor to be weighed in considering design choices (along with other
>>> design-quality concerns, concerns over what other people will think, of
>>> possible consequences, ...).
>>>
>>> like, if the importance is high, then choosing the most well proven
>>> technologies is best, and if fairly low, then it may mostly boil down to
>>> "whatever works".
>>
>> Not really.
>>
>> Unless there really is an advantage of going with the non-standard
>> solution, then you would go for standard even for the less important
>> stuff.
>>
>
> usually, there are advantages in edge-cases.

It certainly happens.

>>> so, a lot is about balancing relevant factors, because while being well
>>> proven and standard technology is one thing, other factors, like
>>> development time, and how well it holds up against the offerings by
>>> ones' competitors, or how much end-user appeal there is, as well as
>>> potentially the computational performance, ... may also be factors.
>>
>> They can.
>>
>> But the home-made solutions often promise to be better but rarely
>> delivers.
>>
>
> I have generally been having generally good results with various
> custom-designed technologies.

By the judgement of the author or by the judgement of neutral judges??

Arne Received on Sat Feb 02 2013 - 02:12:39 CET