.Net... the saga... - Page 3


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 7 FirstFirst 12345 ... LastLast
Results 31 to 45 of 100

Thread: .Net... the saga...

  1. #31
    W.E. (Bill) Goodrich, PhD Guest

    Re: .Net... the saga...

    In article <3dc1bcc1@tnews.web.devx.com>,
    "John Butler" <nospamjrbutler@btinternet.com> writes:

    > "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    > news:bm12sustgfhcre0ehtahkbr8sqh6ekvbgm@4ax.com...


    > > I cannot remember the last time I had to reboot a BSOD
    > > Win98SE PC, let alone a Win95a one.


    > Ha ha ha ha...you are joking right? Do you actually leave your 98
    > box on for days/weeks/months?


    I can't speak for MM, but *I* certainly do. And in recent side by side
    tests of mission critical apps (such as controlling the company
    telecom functions) on 98SE and XP, the 98SE system hummed along nicely
    for weeks at a time, while the XP system rarely lasted two days before
    throwing a major error or crashing altogether.

    > If you did you'd quickly change your tune.


    I doubt it.

    > You don't know what you're talking about.


    Apparently you are the one who doesn't.

    > Part of my business is customer support, and Win9x support is a
    > continuing thorn in our sides.


    That would seem to be more a function of your software and
    configuration than the OS.

    > As we upgrade and move our customers to Win2000/XP,


    With *identical* software and configurations?

    > their support call volume drops by 85% within days.


    Again, sounds like other problems. And it certainly isn't the same
    as OUR experience.

    > Suddenly our support guys no longer get called out, to discover
    > that the user had a few GPF's "about a week or two ago" and
    > thought nothing of them...


    Definitely sounds software specific. But it is true that they are
    more likely to "think something of" GPFs under XP, what with the
    "report to M$" pop up and all.

    > no their email doesn't work, Word is acting mysterious and
    > everything is sloooow....gee, what a surprise.


    Again, it sounds situational. And is different than our experiences.

    > Your inexperience of the real world betrays you Mike.


    Looks more like the narrowness of YOUR relevant experience is betraying
    YOU.

    > If you had to sweat supporting old MS OS crud, you'd (probably) be
    > less misty-eyed and romantic about how wonderful it all was....and
    > appreciative of the (vastly) increased stability and functionality
    > (Security, management etc) feature that Win2K and XP bring to the
    > business world.


    LOL!!!! XP stable? BELONGS in a stable, maybe! Especially the meadow
    muffin they dropped on the consumer. I was not surprised that SP1
    covered more than 300 bug fixes. And the post SP1 problem reports
    keep coming in. That fertilizer is so fragile that they have to
    *warn* people not to use software which was not explicitly
    "certified" for use thereon.

    As to the issue of "the business world", it is relevant to remind you
    that 98SE was explicitly positioned for home, personal, and small
    business use, while NT was mostly positioned for the larger business
    environments and servers. If your customers were using 98SE in a
    large scale networked environment or the like, the results you claim
    would be less surprising.

    As to the "increased functionality" part of your claim, the "security"
    features have proven surprisingly ineffective (and are almost
    completely irrelevant - even counterproductive - to the consumer and
    small business users). And the "management" overhead has proven
    downright counterproductive in the 98SE target markets.

    --

    W.E. (Bill) Goodrich, PhD

    *-----------------------*--------------------------------------------*
    * CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
    * * *
    * Without Aversive * ctgcentral@earthlink.net *
    * Behavior Modification * Creative Technology Group *
    * or Drugs * PO Box 286 *
    * * Englewood, CO 80151-0286 *
    *-----------------------*--------------------------------------------*

  2. #32
    elliferg Guest

    Re: .Net... the saga...


    "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:
    >In article <3dc19b65$1@tnews.web.devx.com>,
    >"elliferg" <fergusej@agedwards.com> writes:
    >
    >> Mike Mitchell <kylix_is@yahoo.co.uk> wrote:

    >
    >> >Yes, to replace the ones that have *worn out*! Some people do
    >> >replace their cars every year, but not that many in the UK, and
    >> >I'll wager not in the US either, given the current economic climate.


    >> >Software, however, never wears out. It gets broken by people
    >> >continually fiddling with it and fixing what ain't broke.

    >
    >> >MM

    >
    >> mike,

    >
    >> software *does* wear out. it gets stretched out of shape when new
    >> requirements get shoved into the bag.

    >
    >That is not even remotely the same thing as "wearing out". To use the
    >current simile, it would be like declaring the family car "worn out"
    >because you want to haul large appliances and furniture. And most
    >commonly used software - including virtually all consumer software -
    >is not subject to your requirement creep.
    >



    bill, it is the same thing if the family actually decided that they would
    add a trailer hitch to the back of the subcompact. mayber first they would
    pull a little u-haul trailer, then a boat trailer, and finally decided that
    the would try to pull a horse trailer full of appliances. the engine, transmission
    and frame break from overuse/abuse and the famly needs an upgrade from requirements
    creep. they wouldn't want t go back to the subcompact because the 5 feet
    that they managed to pull the horse trailer gave them a sense of power and
    not being able to do it would make them feel cheated.


    >> since refactoring is such a pain and not exciting at all, it is often


    >> neglected until the code is so fragile that it could shatter if you
    >> look at it too hard.

    >
    >Which is completely irrelevant to end users of consumer software and
    >the like. The end users are doing absolutely NO recoding of the
    >software (macros notwithstanding), and couldn't do so even if they
    >wanted to. Again, to use the simile, you are confusing the car
    >manufacturer's issues of "retooling" for production of a new model
    >with the consumer's issue of continuing to use the family car.
    >



    it becomes relevant to the end users when the program is unreliable and can't
    be used.


    >> the only fix is to start over (like M$ did with vb).

    >
    >The M$ VB decision was driven by marketing issues and corporate
    >strategy rather than any such technical issues. According to the
    >decision makers themselves.
    >



    but the technical issues were there.


    >> if it was well modularized then you can fix pieces of it as needed
    >> instead of having to rewrite the whole thing.

    >
    >Which is a good argument for MP (and against OOP, for reasons I have
    >described elsewhere).
    >
    >--
    >


    MP and OOP are not mutually exclusive.






    >W.E. (Bill) Goodrich, PhD
    >
    >*-----------------------*--------------------------------------------*
    >* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
    >* * *
    >* Without Aversive * ctgcentral@earthlink.net *
    >* Behavior Modification * Creative Technology Group *
    >* or Drugs * PO Box 286 *
    >* * Englewood, CO 80151-0286 *
    >*-----------------------*--------------------------------------------*



    elli
    just fine with my sexuality, thank you very much.

  3. #33
    W.E. (Bill) Goodrich, PhD Guest

    Re: .Net... the saga...

    In article <3dc2cce7$1@tnews.web.devx.com>,
    "elliferg" <fergusej@agedwards.com> writes:

    > "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:
    > >In article <3dc19b65$1@tnews.web.devx.com>,
    > >"elliferg" <fergusej@agedwards.com> writes:


    > >> Mike Mitchell <kylix_is@yahoo.co.uk> wrote:


    > >> >Yes, to replace the ones that have *worn out*! Some people
    > >> >do replace their cars every year, but not that many in the UK,
    > >> >and I'll wager not in the US either, given the current economic
    > >> >climate.


    > >> >Software, however, never wears out. It gets broken by people
    > >> >continually fiddling with it and fixing what ain't broke.


    > >> >MM


    > >> mike,


    > >> software *does* wear out. it gets stretched out of shape when new
    > >> requirements get shoved into the bag.


    > >That is not even remotely the same thing as "wearing out". To use the
    > >current simile, it would be like declaring the family car "worn out"
    > >because you want to haul large appliances and furniture. And most
    > >commonly used software - including virtually all consumer software -
    > >is not subject to your requirement creep.


    > bill, it is the same thing if the family actually decided that they
    > would add a trailer hitch to the back of the subcompact.


    That goes right back to MM's point - there is NO way for the user of the
    software to MAKE such a modification in the first place.

    > mayber first they would pull a little u-haul trailer, then a boat
    > trailer, and finally decided that the would try to pull a horse trailer
    > full of appliances. the engine, transmission and frame break from
    > overuse/abuse and the famly needs an upgrade from requirements
    > creep.


    No, the family needs to replace the vehicle because of the BROKEN
    engine,
    transmission, and frame (a result of their abuse of the vehicle). Which
    is exactly what does NOT happen with the software. If you try to use
    some
    software package beyond its spec, it may not work for that use. It may
    even corrupt or destroy some data. But you can turn right around and use
    it in the original, appropriate way and it works just fine. It does NOT
    wear out. You can use it for decades without it showing any sign of
    wear.

    When the family goes to replace their modified and abused vehicle, they
    can consider whether they want to get a single vehicle for Worst Case
    use
    (sacrificing cost, fuel economy, convenience, etc. for the rarely used
    power), get two vehicles (one for general use, one for heavy hauling),
    or
    just replace their little car and rent a larger vehicle when they need
    the room and/or power (which they set a precedent for by renting the
    trailer). But with the software, the equation is a bit different. It is
    like the family being able to continue using their old car - without the
    damage - for free. They can CHOOSE to replace it (at a significant cost)
    with a new "muscle machine" and ignore their old car, or they can get a
    truck for the heavy stuff (buying it or renting it as needed) and keep
    using their old car for all the things it has always done so well. Such
    magic is not available in the real world (not even good insurance will
    restore or replace the old car at no cost), but it IS inherently a part
    of the software scenario.

    > they wouldn't want t go back to the subcompact because the 5 feet that
    > they managed to pull the horse trailer gave them a sense of power and
    > not being able to do it would make them feel cheated.


    Not necessarily. They might indeed go back to the compact (with its
    great
    gas mileage, easy parking, and nimble maneuvering), and either buy or
    rent a truck for the heavy stuff. Especially if the old car continued to
    work as before, at no additional cost.

    > >> since refactoring is such a pain and not exciting at all, it is
    > >> often neglected until the code is so fragile that it could shatter
    > >> if you look at it too hard.


    > >Which is completely irrelevant to end users of consumer software and
    > >the like. The end users are doing absolutely NO recoding of the
    > >software (macros notwithstanding), and couldn't do so even if they
    > >wanted to. Again, to use the simile, you are confusing the car
    > >manufacturer's issues of "retooling" for production of a new model
    > >with the consumer's issue of continuing to use the family car.


    > it becomes relevant to the end users when the program is unreliable
    > and can't be used.


    As opposed to M$'s reputation for releasing NEW software which is
    unreliable and can't be used? The point is that if the program WAS
    usable
    and reliable when it was NEW, it continues to be so indefinitely. It
    does
    not wear out, and it is not user-modified. If the manufacturer screws up
    later versions of the software, that is a separate issue - each release
    is good or bad on its own, and the later releases do not affect the
    earlier versions.

    > >> the only fix is to start over (like M$ did with vb).


    > >The M$ VB decision was driven by marketing issues and corporate
    > >strategy rather than any such technical issues. According to the
    > >decision makers themselves.


    > but the technical issues were there.


    But the Slash and Burn decisions were not driven by any of those
    technical issues - they were purely "Marketing and Strategy" creations.
    As were the decisions to deliberately sabotage the performance of
    certain VB functions (e.g. adding noops to slow down floating point
    operations in VB.NET, building a delay into GOSUB execution in VB6,
    etc.). The decision makers have admitted that the technical issues
    played no part in the relevant decisions.

    > >> if it was well modularized then you can fix pieces of it as needed
    > >> instead of having to rewrite the whole thing.


    > >Which is a good argument for MP (and against OOP, for reasons I have
    > >described elsewhere).


    > MP and OOP are not mutually exclusive.


    As long as you don't use classes, inheritance, overloading, or other
    things which weaken modularity while you are "doing OOP". Otherwise,
    they are indeed at odds.

    --

    W.E. (Bill) Goodrich, PhD

    *-----------------------*--------------------------------------------*
    * CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
    * * *
    * Without Aversive * ctgcentral@earthlink.net *
    * Behavior Modification * Creative Technology Group *
    * or Drugs * PO Box 286 *
    * * Englewood, CO 80151-0286 *
    *-----------------------*--------------------------------------------*

  4. #34
    Tom Shelton Guest

    Re: .Net... the saga...


    "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
    news:3DC2AC86.5D837CF2@netzero.net...
    > In article <3dc1bcc1@tnews.web.devx.com>,
    > "John Butler" <nospamjrbutler@btinternet.com> writes:
    >
    > > "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    > > news:bm12sustgfhcre0ehtahkbr8sqh6ekvbgm@4ax.com...

    >
    > > > I cannot remember the last time I had to reboot a BSOD
    > > > Win98SE PC, let alone a Win95a one.

    >
    > > Ha ha ha ha...you are joking right? Do you actually leave your 98
    > > box on for days/weeks/months?

    >
    > I can't speak for MM, but *I* certainly do. And in recent side by side
    > tests of mission critical apps (such as controlling the company
    > telecom functions) on 98SE and XP, the 98SE system hummed along nicely
    > for weeks at a time, while the XP system rarely lasted two days before
    > throwing a major error or crashing altogether.


    Bill, out of curiosity what kind of telephony equipment? They most likely
    aren't the higher end dialogic cards - especially one of the current crop -
    since those wont even work under 9x. I suppose it could be one of the older
    lower end cards, such as the ProLine/2V, DIALOG4, D/21H, or D/41H, and maybe
    even the D/160-LS (but that is a a big maybe). I know for a fact none of
    the new PCI base cards (all of the above are ISA) support 9x or any of the
    large system cards (except for the D/160-LS noted above, and that is
    questionable). I have telephony systems running on NT4 and 2K and I find
    that it is very stable. Our boxes inhouse go weeks without reboots, both T1
    and anlog systems. I currently have a completly new alpha version (written
    in C#) running on WinXP - and so far XP has been rock solid.

    [I just went and made a quick check to verify my statements above about the
    boards that might work under 9x, and I was essentially correct - except
    ironically for one minor detail, the older large system boards (and that
    includes the D/160-LS, so I was incorrect in stating that it may work on 9x)
    do support MS-DOS & Windows NT, but not 9x - go figure. Note: all of the
    these are the older ISA form factor cards... Absolutely none of the new PCI
    based cards, and that includes the D/4PCI support 9x or DOS.]

    > > If you did you'd quickly change your tune.

    >
    > I doubt it.


    If you were running seriously intesive telephony, you sure would - even if
    you could find a vendor that supported it. Even when Dialogic was putting
    out new cards that supported 9x they warned against it's use. They
    encouraged using Windows NT or Unix - especially for systems with more then
    4 to 8 lines.

    [snip]

    > > their support call volume drops by 85% within days.

    >
    > Again, sounds like other problems. And it certainly isn't the same
    > as OUR experience.


    That's funny. I seem to remember reading an article a few months after the
    release of XP that stated that many OEM's were reporting a significantly
    decreased number of support calls for there XP product lines. I'll have to
    see if I can dig that up.

    Oh, and as an interesting side note... you might want to check out the
    numbers and article here:

    http://www.statmarket.com/cgi-bin/sm...ture&week_stat

    it says that IE6.0/XP is the most popular browser/OS combo on the web right
    now (almost 20% of the global share, compared to about 18% for 98). Seems
    to me XP is getting some play.

    > > Suddenly our support guys no longer get called out, to discover
    > > that the user had a few GPF's "about a week or two ago" and
    > > thought nothing of them...

    >
    > Definitely sounds software specific. But it is true that they are
    > more likely to "think something of" GPFs under XP, what with the
    > "report to M$" pop up and all.


    Which you can turn off (and I have

    > > no their email doesn't work, Word is acting mysterious and
    > > everything is sloooow....gee, what a surprise.

    >
    > Again, it sounds situational. And is different than our experiences.


    And yours is very different from mine, and most people I know...

    > > Your inexperience of the real world betrays you Mike.

    >
    > Looks more like the narrowness of YOUR relevant experience is betraying
    > YOU.
    >
    > > If you had to sweat supporting old MS OS crud, you'd (probably) be
    > > less misty-eyed and romantic about how wonderful it all was....and
    > > appreciative of the (vastly) increased stability and functionality
    > > (Security, management etc) feature that Win2K and XP bring to the
    > > business world.

    >
    > LOL!!!! XP stable? BELONGS in a stable, maybe! Especially the meadow
    > muffin they dropped on the consumer. I was not surprised that SP1
    > covered more than 300 bug fixes. And the post SP1 problem reports
    > keep coming in. That fertilizer is so fragile that they have to
    > *warn* people not to use software which was not explicitly
    > "certified" for use thereon.


    Um, Bill... Have you actually used XP? I use it hard, every day... I can
    honestly say my development systems at work, have never, and I mean not
    once, ever crashed (well, one of them did when I first got the box, but it
    was a hardware issue and once that was resolved it hasn't crashed since -
    that was 7/8 months ago I think...). I have only had to shut them down when
    I was intalling updates. The same goes for my W2K system - though it isn't
    beign driven as hard these days. Now, I can't quite say the same about my
    XP system at home. It crashes every month or so - it's the dang video
    driver. I really need to go get a updated version of the nvida drivers.

    By the way, maybe you should go get out your original 95 disks - they made
    the same recomendation about certified software even back then.

    I will never really understand yours and Mikes undying devotion to all that
    is obsolete. Win9x was a piece, plain and simple. Oh, it got better with
    each version - except for ME, that was truely the biggest piece of dung to
    emmenate from Redmond in quite some time; I think it lasted on my system
    about 1 week, before I reformated my drive and re-installed Win98SE - but
    the NT based systems are much more stable, period.
    Tom Shelton



  5. #35
    Mike Mitchell Guest

    Re: .Net... the saga...

    On Fri, 01 Nov 2002 14:40:59 -0700, "W.E. (Bill) Goodrich, PhD"
    <bgoodric@netzero.net> wrote:

    >As opposed to M$'s reputation for releasing NEW software which is
    >unreliable and can't be used? The point is that if the program WAS
    >usable
    >and reliable when it was NEW, it continues to be so indefinitely. It
    >does
    >not wear out, and it is not user-modified. If the manufacturer screws up
    >later versions of the software, that is a separate issue - each release
    >is good or bad on its own, and the later releases do not affect the
    >earlier versions.


    Unless, of course, a manufacturer were to deliberately engineer the
    latest developments so that earlier software won't run and consumers
    are *forced* to upgrade...

    Imagine if Ford or BMW had special tracks in the road that only
    accepted their latest models? All older models would have to bump
    across open fields to get into town, or just be parked any old where
    until the owners stumped up for one of those "exciting", "new",
    "approved" models...

    MM


    >
    >> >> the only fix is to start over (like M$ did with vb).

    >
    >> >The M$ VB decision was driven by marketing issues and corporate
    >> >strategy rather than any such technical issues. According to the
    >> >decision makers themselves.

    >
    >> but the technical issues were there.

    >
    >But the Slash and Burn decisions were not driven by any of those
    >technical issues - they were purely "Marketing and Strategy" creations.
    >As were the decisions to deliberately sabotage the performance of
    >certain VB functions (e.g. adding noops to slow down floating point
    >operations in VB.NET, building a delay into GOSUB execution in VB6,
    >etc.). The decision makers have admitted that the technical issues
    >played no part in the relevant decisions.
    >
    >> >> if it was well modularized then you can fix pieces of it as needed
    >> >> instead of having to rewrite the whole thing.

    >
    >> >Which is a good argument for MP (and against OOP, for reasons I have
    >> >described elsewhere).

    >
    >> MP and OOP are not mutually exclusive.

    >
    >As long as you don't use classes, inheritance, overloading, or other
    >things which weaken modularity while you are "doing OOP". Otherwise,
    >they are indeed at odds.



  6. #36
    james Guest

    Re: .Net... the saga...


    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:lt87su4frcqa3ioeu9cpvn3pdd5vht237a@4ax.com...
    > Imagine if Ford or BMW had special tracks in the road that only
    > accepted their latest models? All older models would have to bump
    > across open fields to get into town, or just be parked any old where
    > until the owners stumped up for one of those "exciting", "new",
    > "approved" models...
    >
    > MM


    Imagine trying to get Ford or BMW parts to interchange, or better yet,
    imagine trying to get different year models of Ford or BMW parts to work
    on older versions of the same vehicles. Years ago that worked, but not
    anymore.
    So, that comparison doesn't work with software and motor vehicles.
    james



  7. #37
    Jason Sobell \(iGadget\) Guest

    Re: .Net... the saga...

    > >If they followed your logic we would all be driving newly manufactured
    Model
    > >'T's

    >
    > No, that is just you exaggerating because you know your argument is
    > weak.


    Of course I'm exagerating. Every one of the messages you post on here is a
    gross overreaction or exaggeration of a situation, and I've posted a gross
    exaggeration of a simile situation
    I would argue that that while your suggestions are extremely 'to the left',
    there are always counter-suggestions that are extremely 'to the right',
    making these arguments pointless and unanswerable.
    One problem you (and many other people on here) have is in posting your
    "statements of fact" and having to defend them. Perhaps a better thing to
    do is to ask what other peoples' opinions are of a situation so you can see
    if there are any issues you have missed that might clarify things in your
    mind and lead you to a more balanced and less extreme opinion.
    A 'discussion' is always better and more productive than an defensive
    argument.

    Cheers,
    Jason

    p.s. Having got over the initial phobia of learning VB.NET, I actually find
    it very easy to use, and I'm coming up to a similar level of efficiency that
    I had with VB6 (apart from ADO.NET, which I haven't attempted yet).



  8. #38
    Bob Guest

    Re: .Net... the saga...

    In article <3dc19b65$1@tnews.web.devx.com>, fergusej@agedwards.com says...
    >
    > Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    > >
    > >Yes, to replace the ones that have *worn out*! Some people do replace
    > >their cars every year, but not that many in the UK, and I'll wager not
    > >in the US either, given the current economic climate. Software,
    > >however, never wears out. It gets broken by people continually
    > >fiddling with it and fixing what ain't broke.
    > >
    > >MM

    >
    >
    > mike,
    >
    > software *does* wear out. it gets stretched out of shape when new requirements
    > get shoved into the bag. since refactoring is such a pain and not exciting
    > at all, it is often neglected until the code is so fragile that it could
    > shatter if you look at it too hard. the only fix is to start over (like
    > M$ did with vb).
    > if it was well modularized then you can fix pieces of it as needed instead
    > of having to rewrite the whole thing.
    >
    > elli
    >

    elli,

    Software doesn't really wear out. If you don't change it, it will run pretty
    much forever. However, the world changes, business needs change, etc. If the
    software doesn't change to accommodate those changing needs, it becomes
    useless and stops being used.

    The problems start when software is pushed so far beyond its original design
    that it can no longer function properly and the cost of additional changes
    start to increase exponentially. At some point, you just have to start over
    again with a clean slate.

    Bob


  9. #39
    Mike Mitchell Guest

    Re: .Net... the saga...

    On Sun, 3 Nov 2002 19:53:44 -0600, Bob <tooslow42junk@yahoo.com>
    wrote:

    >Software doesn't really wear out. If you don't change it, it will run pretty
    >much forever. However, the world changes, business needs change, etc. If the
    >software doesn't change to accommodate those changing needs, it becomes
    >useless and stops being used.


    What kinds of business changes are you thinking of here? A business
    can do only one of two things: sell or lease products or sell or lease
    services. It needs customers. The product or service is sold or leased
    to the customer. The customer pays the business money. This has been
    the situation since the spice trade routes of the middle ages and
    earlier, the only difference being they didn't have credit cards. They
    also had much more direct ways of fixing bad debts.

    What *are* these "changes" that supposedly cause software not to work
    any longer? Can one not still use Word 6, for example?

    MM

  10. #40
    Jay Glynn Guest

    Re: .Net... the saga...

    >
    > What kinds of business changes are you thinking of here? A business
    > can do only one of two things: sell or lease products or sell or lease
    > services. It needs customers. The product or service is sold or leased
    > to the customer. The customer pays the business money. This has been
    > the situation since the spice trade routes of the middle ages and
    > earlier, the only difference being they didn't have credit cards. They
    > also had much more direct ways of fixing bad debts.
    >
    > What *are* these "changes" that supposedly cause software not to work
    > any longer? Can one not still use Word 6, for example?


    You obviously do not work in the financial services business, especially
    insurance. Not only does business models change, but legislated rules are
    constantly changing, rates and pricing structures change not to mention the
    various products that we sell are always changing. Each of these changes
    requires change to software both pc based and mainframe based.


    >
    > MM




  11. #41
    Jay Glynn Guest

    Re: .Net... the saga...


    >
    >Correct. I do not work in the financial services business. However,
    >surely rates and pricing should not require a software change? If
    >specifically that branch of industry is known to be prone to frequent
    >changes, then the software should be written accordingly with maximum
    >configurability?


    Gee, why didn't I think of that. If all that changed was the interest rate
    that would be easy. The calculation for a life insurance policy is not nearly
    that simple. Takes a couple fo dozen tables with several thousand rows of
    data. We currently have to make quarterly updates to both the code and to
    the data. This is a very competitive business so the rate calculations are
    always being tweaked in order to maximize profitibility of the policy.


    >
    >I wrote an application suite which was almost totally controlled from
    >the database - column widths, field defaults, ranges for testing
    >against, even the addition of NEW fields! And I wasn't even trying to
    >make it future-proof!
    >


    Hooray for you.

    >As for rules "constantly" changing, I wonder what frequency you attach
    >to "constantly"? Legislation in the UK is painfully slow, and I doubt
    >it is much different over in the US. So how often do those rules
    >change? Once a year, tops? Might not someone in development design a
    >system whereby the rules can be added separately from the software?


    This is based on individual states. Each state runs at their own pace and
    agenda. Each month may see anywhere form 1 to 25 state variations and changes.
    Each qtrly release will contain at least some changes related to state variations.
    How might I design software to read the state insurance commissioners mind.


  12. #42
    elliferg Guest

    Re: .Net... the saga...


    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    >On Mon, 4 Nov 2002 06:13:58 -0600, "Jay Glynn" <jlsglynn@hotmail.com>
    >wrote:
    >
    >>You obviously do not work in the financial services business, especially
    >>insurance. Not only does business models change, but legislated rules are
    >>constantly changing, rates and pricing structures change not to mention

    the
    >>various products that we sell are always changing. Each of these changes
    >>requires change to software both pc based and mainframe based.

    >
    >Correct. I do not work in the financial services business. However,
    >surely rates and pricing should not require a software change? If
    >specifically that branch of industry is known to be prone to frequent
    >changes, then the software should be written accordingly with maximum
    >configurability?
    >
    >I wrote an application suite which was almost totally controlled from
    >the database - column widths, field defaults, ranges for testing
    >against, even the addition of NEW fields! And I wasn't even trying to
    >make it future-proof!
    >
    >As for rules "constantly" changing, I wonder what frequency you attach
    >to "constantly"? Legislation in the UK is painfully slow, and I doubt
    >it is much different over in the US. So how often do those rules
    >change? Once a year, tops? Might not someone in development design a
    >system whereby the rules can be added separately from the software?
    >
    >Anyway, I'm pretty sure this kind of thing is done anyway, but you've
    >yet to meet up with it!
    >
    >MM



    Mike,

    I do currently work in financial services in the US (5 years now). It may
    take about forever for most regulations to become effective, but they have
    a cuple of hundred year head start on us. In the past year, we have had
    some hot new regs come down to us (the Patriot Act) that requires changes
    to our software quickly to avoid fines, etc. There are also the moving targets
    of T+1 and straight thru processing. One day it's a really hot topic and
    is mandated to be done in x number of years, then after a few years of effort
    have been expended they decided that it's not quite as important and we'll
    adjust the requirements and deadline.

    Constantly changing is not an exaggeration. And it's not as simple as rates.
    There are new laws and new interpretations of old laws. Both of which can
    require new formulae be used. Large scale financial services apps look nothing
    like your basic checkbook balancing app that can be used for small business
    and homes.

    elli

  13. #43
    Arthur Wood Guest

    Re: .Net... the saga...


    Mike,
    The 'classic' example of major changes that occur, requiring an ALMOST
    complete re-write of the application, is the US Internal Revenue Code (The
    legislation which defines the US Income Tax stucture). The changes that
    occur from one year to the next are so complete, that almost complete re-writes
    are required of the software that MANY tax-payers employ (QuickTax for example)
    to cacluate their income tax returns each year. These same tax-code changes
    are what keep entire industries (H&R Block for instance) in business, providing
    the services to Taxpayers who cannot comprehend the level of complexity that
    is introduced into the US Income Tax structure EVERY year.

    Such changes are not simple "business rules" that can be implemented by a
    few external changes in a flexible program strcutre. These changes are quite
    often wholesale, and far-reaching.



    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    >On Sun, 3 Nov 2002 19:53:44 -0600, Bob <tooslow42junk@yahoo.com>
    >wrote:
    >
    >>Software doesn't really wear out. If you don't change it, it will run pretty


    >>much forever. However, the world changes, business needs change, etc. If

    the
    >>software doesn't change to accommodate those changing needs, it becomes


    >>useless and stops being used.

    >
    >What kinds of business changes are you thinking of here? A business
    >can do only one of two things: sell or lease products or sell or lease
    >services. It needs customers. The product or service is sold or leased
    >to the customer. The customer pays the business money. This has been
    >the situation since the spice trade routes of the middle ages and
    >earlier, the only difference being they didn't have credit cards. They
    >also had much more direct ways of fixing bad debts.
    >
    >What *are* these "changes" that supposedly cause software not to work
    >any longer? Can one not still use Word 6, for example?
    >
    >MM



  14. #44
    Mike Mitchell Guest

    Re: .Net... the saga...

    On Mon, 4 Nov 2002 06:13:58 -0600, "Jay Glynn" <jlsglynn@hotmail.com>
    wrote:

    >You obviously do not work in the financial services business, especially
    >insurance. Not only does business models change, but legislated rules are
    >constantly changing, rates and pricing structures change not to mention the
    >various products that we sell are always changing. Each of these changes
    >requires change to software both pc based and mainframe based.


    Correct. I do not work in the financial services business. However,
    surely rates and pricing should not require a software change? If
    specifically that branch of industry is known to be prone to frequent
    changes, then the software should be written accordingly with maximum
    configurability?

    I wrote an application suite which was almost totally controlled from
    the database - column widths, field defaults, ranges for testing
    against, even the addition of NEW fields! And I wasn't even trying to
    make it future-proof!

    As for rules "constantly" changing, I wonder what frequency you attach
    to "constantly"? Legislation in the UK is painfully slow, and I doubt
    it is much different over in the US. So how often do those rules
    change? Once a year, tops? Might not someone in development design a
    system whereby the rules can be added separately from the software?

    Anyway, I'm pretty sure this kind of thing is done anyway, but you've
    yet to meet up with it!

    MM

  15. #45
    Jason Guest

    Re: .Net... the saga...


    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    >I wrote an application suite which was almost totally controlled from
    >the database - column widths, field defaults, ranges for testing
    >against, even the addition of NEW fields! And I wasn't even trying to
    >make it future-proof!


    Isn't this just a little overkill for a Celsius to Fahrenheit converter?
    And if you weren't trying to make it future-proof, why go to all that trouble?
    Wouldn't it be more expedient to just let VB handle the form layout, since
    that is what it is designed to do? Really.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center