Re: Here's an idea.....
From: Jim Hubbard (reply_at_groups.please)
Date: 01/05/05
- Next message: Jim Hubbard: "Re: HTTP Gateway examples?"
- Previous message: Jim Hubbard: "Re: Here's an idea....."
- In reply to: John Saunders: "Re: Here's an idea....."
- Next in thread: Gerry Hickman: "Re: Here's an idea....."
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 4 Jan 2005 20:16:08 -0500
"John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
news:OKEKyOr8EHA.3700@tk2msftngp13.phx.gbl...
> "Jim Hubbard" <reply@groups.please> wrote in message
> news:afydnZOFI9BGhEbcRVn-rA@giganews.com...
>>
>> "John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
>> news:%23EG5E6n8EHA.2568@TK2MSFTNGP11.phx.gbl...
>>> "Jim Hubbard" <reply@groups.please> wrote in message
>>> news:ysGdnc8xzOyoVEfcRVn-qw@giganews.com...
>>>>
>>>> "John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
>>>> news:Ojq1Ajn8EHA.824@TK2MSFTNGP11.phx.gbl...
>>>>> "Jim Hubbard" <reply@groups.please> wrote in message
>>>>> news:jNmdnWyzz8IvIEfcRVn-hw@giganews.com...
>>>>
>>>> < snip >
>>>>
>>>>>> That has always been the case in every software shop I have worked
>>>>>> in. We wrote the code. We made the mistakes. We cleaned them up.
>>>>>>
>>>>>> With $50 BILLION in cash reserves and investing over $400M in Indian
>>>>>> programmers at once.....don't you think Microsoft should know it's
>>>>>> own code.....or at least be able to test it's own software?
>>>>>
>>>>> No, I don't.
>>>>
>>>> Why not?
>>>
>>> Because there's too much of it to go test for every hotfix.
>>
>> Maybe it's time to start cutting out the fat. When you can't fix one
>> part of your code because it may break another part, that's just poor
>> design. And, in a company the size and importance of Microsoft to daily
>> business, it's dangerous and borders on crimminal misconduct by a
>> corporation.
>>
>>>>> Besides, they not only have to know their own code, they have to know
>>>>> all the crazy things their customers will do with their code. And
>>>>> Microsoft has a rather large number of customers doing crazy things.
>>>>>
>>>>>> Microsoft cannot, obviously, guarantee the hotfixes to work with all
>>>>>> 3rd party software. But, they don't have to.....they just need to
>>>>>> make sure that hotfixes don't break their codebase and alert the
>>>>>> programmers to the affected modules so the programmers can change
>>>>>> their code if needed.
>>>>>
>>>>> Few of the hotfixes break existing code (except to the extent that the
>>>>> code may depend on the bug being fixed).
>>>>>
>>>>> This will absolutely guarantee that the hotfixes will cause random
>>>>> problems on random customers' systems, because they were not all
>>>>> tested together, and weren't tested in that customer's configuration,
>>>>> and because the customer didn't get a chance to go through a proper
>>>>> test cycle.
>>>>>
>>>>>> And, yes.....I do think that programmers paying $2500 for a year's
>>>>>> subscription are entitled to tested hotfixes.
>>>>>
>>>>> Again, Jim, it is my understanding that the hot fixes _are_ tested.
>>>>> They are tested individually, not in all permutations. A Service Pack
>>>>> takes a number of hot fixes and puts them together in a single package
>>>>> which can be thoroughly tested. The fixes in a Service Pack can be
>>>>> tested as a group, and can be tested in many different environments,
>>>>> and can then be released to customers for Beta testing. How long was
>>>>> the Beta period of XP SP2?
>>>>
>>>> The very nature of the .Net framework invalidates your arguments for
>>>> Microsoft's failure to test.
>>>>
>>>> According to Microsoft, many different versions of .Net (both the
>>>> framework and code) should be able to reside on a single machine and
>>>> run side-by-side.
>>>>
>>>> So, what's to stop Microsoft from making a change to the version of the
>>>> .Net framework with each hotfix? Are they going to run out of numbers?
>>>> If so, I have some numbers I can let them borrrow. (For a monthly fee,
>>>> of course.)
>>>>
>>>> The whole idea behind the .Net framework was to allow different
>>>> versions of the framework and code to run side-by-side. Since I have
>>>> only been addressing the .Net framework in my posts, I fail to see any
>>>> validity in your arguments.
>>>>
>>>> Please let me know if I misunderstand the nature of .Net or there are
>>>> reasons for not issuing incrementing versions of .Net with each hotfix.
>>>
>>> You haven't caught my point.
>>>
>>> A great amount of testing is necessary before you release a fix to a
>>> customer for use in a production environment. That testing takes too
>>> long to do it for each hotfix. Instead, hotfixes are grouped together to
>>> create a Service Pack, which is tested appropriately.
>>
>> I agree with these points. The fact is that Microsoft is not doing what
>> you are suggesting. There are hotfixes for the .Net framework (1.1) that
>> have been available for months but have not been placed into any released
>> service packs. I can list some of them if you like.
>
> I don't see what that has to do with my point. They happen not to have
> scheduled a service pack. This could be due to lack of QA resources. For
> instance, if they were working on a major new release, then some of the
> resources which would have been used to test service packs might instead
> be working on testing the new release. BTW, I'm sure you're aware that
> they are working on both SQL Server 2005 and VS.NET 2005 and Framework
> 2.0?
>
>>>
>>> Jim, are you thinking about a production environment, or a development
>>> environment?
>>
>> Production. Programmers don't pay $2500 for beta code. I expect it to
>> work. I expect problems in the framework to be fxed. And I expect the
>> fix to actually fix things....not break new stuff. That's what Microsoft
>> should test for. That *is* what I paid for isn't it? Is expecting
>> working code in exchange for some of the highest software prices in the
>> industry so unreasonable?
>
> Actually, some programmers pay $2700 anually for an MSDN Universal
> subscription, and that's what I thought you might have meant.
>
> If you expect humans to produce perfection, make sure you don't
> accidentally pinch yourself and wake up.
Wow.....no need to continue this thread......
>
>> It seems that you glossed over entirely the easy solution to this
>> problem. When Microsoft fixes the framework, simply increase the version
>> number of the framework and release the newest version! Is that so hard
>> to comprehend? Isn't that one main goal of the .Net framework....to be
>> able to run several different versions on the same machine WITHOUT
>> corrupting each other?
>
> Versioning isn't the issue. The quality of releases is the issue.
>
> You also seem to be assuming that fixes are sequential, and that each
> hotfix can be associated with a single version number.
Not neccesarily. Why not have the avilable hotfixes load like Windows
security updates with a roll-back feature in case it screws something up?
>
>> Let's imagine for a moment that Microsoft used their own technology as
>> they said it was designed to work and issued new versions of .Net with
>> each new service pack (or even hotfix). Let's also say they screw up
>> something new with the latest service pack or hotfix. According to them,
>> this would not break or interfere with the old code you had written in a
>> previous version of the framework. So where's the harm?
>>
>> If it screws up your code, either change your code or drop back and punt
>> from the previous version of .Net that didn't screw up your code.
>
> How often do you plan to do this? And how much do you plan to test your
> code for each new hotfix?
Not often. Mainly in between builds. No programmer in his right mind would
update the production or development machines while still coding the
application.
Testing is mostly automated. We're talking the .Net framework here. A
bunch of pre-compiled classes that you use in your code and a JIT compiler
to make it all come together. Either a class works with the implemented
interfaces or it doesn't. Either the JIT consumes the COM objects correctly
or it doesn't.
>
>> This isn't that difficult to understand. I'm not talking over anybody's
>> head here. They just don't want to do it.
>
> No, you just don't seem to be too clear on how a production operation
> works.
Sadly, I am all too aware of how common production operations work. That's
why I don't code for people like Bellsouth, Porsche, Qwest etc, anymore and
started my own company. They are so frigid in their thought processes
concerning development that precious little actual work gets done.
The shops that get the least amount of work done seem to be those blindly
following the Microsoft SDLC. If it doesn't work for Microsoft.....why in
hell would you put your company on it?
> The very idea of having so many versions around on a set of production
> machines scares the hell out of me.
But, it shouldn't. That's how .Net was written to work. They all use thier
own framework (whatever version they were coded with) and, according to
Microsoft, they will not step on each other's toes.
Jim Hubbard
- Next message: Jim Hubbard: "Re: HTTP Gateway examples?"
- Previous message: Jim Hubbard: "Re: Here's an idea....."
- In reply to: John Saunders: "Re: Here's an idea....."
- Next in thread: Gerry Hickman: "Re: Here's an idea....."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
