Re: The Revenge of the Geeks

From: Arne Vajhøj <arne_at_vajhoej.dk>
Date: Wed, 30 Jan 2013 20:12:09 -0500
Message-ID: <5109c4ef$0$281$14726298_at_news.sunsite.dk>

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.

> 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.

Arne Received on Thu Jan 31 2013 - 02:12:09 CET