From: jftucker at gmail.com (James Tucker)
Subject: Windoze almost managed to 200x repeat 9/11

> What seems to read clearly from your replies to this thread is that
> either;
> 
> 1> the code was better done under the original OS, unix

The system was different, although it is likely that the
(designed/intended) functionality is identical. Some older Unixes are
no longer supported both by hardware and by professionals; this is a
problem for supporting old mission critical apps. The need for a
changeover is not uncommon in closed unit systems of this type; and
the newer apps rarely cut the mustard (often due to poor coding and
over complication of the system).

High quality code is a product of the coder, not the operating system.

> 2> considering "how often" you seems to run into this same issue with
> other coders in the windows realm, windows coders tend to be especially
> lazy/clueless as compared to coders in other OS'

This is possibly true, but you may well find that this correlated back
to the whole usage of WYSIWYG OS and design tools and the general non
"tech" nature of the average windows user. It is also possible that
the IDE in use can also contribute to reduced reading of proper API
documents which leads to errors of this sort due to their ease of use
and a lack of attention to detail on the programmers side. Poor
quality assurance practices are what leave this kind of error
unnoticed (least we not forget however that this error WAS noticed and
documented).

Once again however, the type of people that gravitate to a type of OS
is what causes your (general) differences in skill levels. This is not
correlated directly to what you should get in terms of a development
team for such an important application. Using Windows will not make
you a bad coder; not reading documentation will.

You could code the same application in Java and in much the same way
and you would end up with a runtime error; typically however a Java
based system would warn the programmer at compile time with compile
time exception handling. Maybe the programming language itself was to
blame? (I believe otherwise, but seeing as we are trying to spread
blame away from the users and programmers right now)

> 3> tools to code with in the windows realm are not as developed/functional
> as they are in other envs

Visual Studio despite anyones opinion of MS software is actually a
very good development environment. Many of the features are in
constant use to achieve true RAD.

> 4> M$ does not properly provide developers with clued information with which to do their
> job.

I have always found MSDN to be plenty complete enough, if sometimes
dauntingly huge. I hope that you did not derive this statement as a
product of the article posted. The flaw in the system was known and
published but the users simply did not take any action. It would be
easy to solve this problem. It would be easier yet to automatically
reboot the systems on the regular basis (although this would not
provide proper warning across the system I suspect, and ATC dropping
unannounced is not the best of ideas). Why was none of this done? Not
because of poor OS and library documentation.

Was that a knowledgeable bash at MS or was that just another random spasm?

The simple truth is that there are many people who contribute to this
list and others who can vouch for the fact that there exists MS
Windows servers which can stay up plenty longer than 50 days. There
exist many applications (finely timed ones too) which can run on said
systems, again for more than 50 days. If this is the case, and the
software itself has some kind of flaw which causes otherwise, is the
OS to blame or the programmer of the foreign software?

Maybe next time a software development team is chosen to write a
mission critical application they should actually get some coders with
experience in mission critical application development. =)

Powered by blists - more mailing lists