Re: The Revenge of the Geeks

From: BGB <cr88192_at_hotmail.com>
Date: Wed, 30 Jan 2013 03:22:58 -0600
Message-ID: <keaot9$9rv$1_at_news.albasani.net>



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

sometimes a person may be working more towards the most "elegant" solution, regarding whether or not it actually works, as a secondary concern (say, their whole premise is basically to write it, so that they can write a research paper about it).

...

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.

granted, in general, I guess I tend to go under the premise of "there should not be should", though there are exceptions to this, usually in cases where there is a significant potential impact on product quality, safety, or if there are potential legal, ethical, or moral, consequences.

so, yeah, while freedom of choice is important, it also seems to be the case that a person should try to do the right thing.

which in the case of a product, would mostly boil down to potential impacts to the quality of life or quality of experience to the end-users of a product (like, it is better not to rip people off of put their personal health or safety at risk, ...).

but, it all depends a lot on the product.

(like, if the product is actually in a position to pose a risk, ...).

like, it is hard to find universal rules that would apply equally well to every sort of software.

it is even like answering the question of which is better between float and double. and, meanwhile, some people think double isn't precise enough, leading to 128-bit floats, and others think a 32-bit float isn't cheap enough, leading to 16-bit half-floats.

and, while both 128-bit and 16-bit floats are useful, what sorts of things they are useful for are very different (like, for example, if a person needs more than about 3 decimal digits of precision, ...).

or such... Received on Wed Jan 30 2013 - 10:22:58 CET

Original text of this message