Re: Data Constraints Vs Application Constraints
Date: Sat, 12 Mar 2005 12:49:14 GMT
Message-ID: <ezBYd.194530$K7.13880_at_news-server.bigpond.net.au>
Gene Wirchenko wrote:
> On Fri, 11 Mar 2005 11:34:34 GMT, FrankHamersley
> <FrankHamersleyZat_at_hotmail.com> wrote:
>
>
>><heretic> >>I recognised you toned it down a bit in later posts but as they say >>first impressions matter ... >> >>Alfredo Novoa wrote: >> >>>On Wed, 09 Mar 2005 08:37:16 -0500, Kenneth Downs >>><knode.wants.this_at_see.sigblock> wrote: >>> >>> >>>>Do you know why they did it that way? >>> >>>The most probable reason is: incompetence. >> >>Hmmm ... smells like dogma!
>
> Not unless he automatically assumes that it is incompetence.
There wasn't that much evidence in the original post by sparky so I feel relaxed about assuming that "assumption" having been made. In my own mind it was reinforced by the brevity.
> A statement of non-certain probability still allows for exceptions.
Of course, but assigning a probability > 0.5 is a fairly clear signal of the writers basic intent.
>>>>There was definitely a reason and you >>>>don't want to ruffle feathers by criticizing it before you know why it was >>>>done. The normal argument is for portability, >>> >>>No. The normal reason is incompentence. Portability is a poor excuse. >> >>Be wary here...incompetents don't actually achieve the desired results >>(QED) so if this system/solution actually works it might be best to >>engage brain before selecting mouth!
>
> Besides what Mr. Novoa mentioned in his reply, there are other
> possibilities.
And of course there are contras (all pure speculation of course)...
>
> One possibility is that the desired results are achieved but with
> much more effort than would be needed were things done better.
The "more effort" cost was not at all material to the business success...it may have been a simple design that allowed a lot ppl to deliver the solution quicker and allow the business to break in to the market rather than watch an option slip by.
> Another possibility is that the users of the system are not aware
> that it could be better.
So what - if it meets their needs who cares. Note I am not taking an academic view here as this is appears to be a business situation. That said, academics quite rightfully will aim to get students to consider the theoretical state of the art during their stewardship, so as to ensure industry is supplied with well informed types. That doesn't mean however when tempered with experience the ex-student will or should blindly execute according to the curriculumn of their professors.
> In both of these cases, it can be difficult for someone stuck in
> the mess to see that it could be better if that person has had no
> exposure to better.
Accepted.
>>>>if they code things in the >>>>client, their app will run against many databases. According to you this >>>>worked, so I would ask why change it? Technically it may be "wrong" but >>>>technically they somehow got it working and are a big company, so they must >>>>be doing something right? >>> >>>No, that does not mean that they are doing things right. >> >>Dogma now apparently flying in the face of a fat balance sheet.
>
>
> No, it may be working with much more effort than needed, or there
> may be hidden flaws that bite later.
And just as easily, a heavily constrained schema that resists adaption could be considered flawed.
>>>>The other hidden reason may be that they did/do not know much about >>>>databases, and you want to tiptoe-tiptoe around that one. >>> >>>That's incompetence :) >> >>But highly unlikely it seems.
>
> Oh? Why unlikely?
Easy - simply because it (apparently) serves its purpose.
>>>>So to sum up, leading with the idea that a working app has been done wrong >>>>is probably a bad idea. >>> >>>It depends on many things. Specially on how smart and educated the >>>managers are. >>> >>>But the honest and professional behavior is to say the truth. >> >>I restate my case that IT&T is not yet a profession and the truth rarely >>is. The next best thing is to consider "if it ain't broke, don't fix >>it" and IMO its a good guideline to consult the "business" to see if its >>broken.
>
>
> Yes, but if you were developing a new, different system, would
> you do it the same way as the old system?
Soft answer - it depends! I have in my years I have learnt that I am not the sole instigator of _really_ good ideas. I often find some really smart kung fu in other ppls work that isn't always appreciated on the first reading.
> If not, then there is something wrong with the first approach.
Not true at all - perhaps other factors have moved on (time particularly) and so the same decisions taken in a changed context would reach different conclusions. That doesn't mean they were implaccably wrong at the time based on the information that was available at that time.
> I have seen students trying to program by guess. It does not
> work? Change this statement or that one. Why that statement? It is
> something to do. Eventually, they may get something that "works".
> Mr. Novoa is talking about the commercial version of this.
Very true, it happens - bottom line is they should not be in IT. Imagine if your family doctor was allowed through med school on this basis!
[snip]
> I do not see one either. If anything, the situation may get
> worse since systems are getting more complex.
I agree - I'm not sure we are evolving as fast as the demands - which is a bit of a worry.
> I think you and Mr. Novoa disagree less than you may think you
> do. Your differences seem to be surfacial.
I guess the degree is the issue that caused me to post - as I have got older (and hopefully a bit wiser - you judge the latter) I have found lots (and I mean copious) shades of grey but a lot less cases of pure black or pure white! Hence my use of the d word.
Cheers, Frank. Received on Sat Mar 12 2005 - 13:49:14 CET