HOLY JESUS MURPHY ON A MARSHMELLOW ROASTING STICK!!!!!!

[Missing the point]

I was jsut watching a show about computer bugs, adn I found out a pretty good stat. Everyone always complains about Windows having so many bugs in it, and I agree. but have you heard how mcuh work it takes to make it? 29 Million lines of code to make Windows 2000. OHMYGOSH!!!!!!! Imaging trying to find aby bugs in there? 29 Million! Man, I am glad I didn't write that......

[Wiz]

29,000,000 lines of code

50,000 bugs

580 lines per bug...

Not a good stat there. I have written C++ programs with 6000 lines without any bugs...

Oh well

[Missing the point]

How do you figure 50,000 bugs?

[hd581]

Actually its 63000 Defects (http://www.zdnet.com/zdnn/stories/news/0,4586,2436920,00.html?chkpt=zdnntop) according to a Microsoft Development Leader.

Wiz: I'm not sure it's a linear relationship. It's easy to keep small programs entirely bug free, but when programs get as bloated as windows, there will be bugs no matter what. (i.e. 1 Wiz writing 6000 lines of bug-free code in no way means 4833 Wiz clones's can write 29,000,000 lines of bug-free code.)

[Paul V]

I can write large code without errors either. Using OOP it's not at all hard to track down errors. Eash object is a miniprogram, a small self-contained entity. All you need to do is test each one, and test them well, and so long as they conform to your specifications then the whole program should work fine, assuming your specifications are complete and correct.

OOP makes it every bit as easy to write a huge program as a small (assuming sufficient man-hurs or work) because you DON'T write one big program, you write and test a ton of small programs.

[hd581]

Bottom up programming is what that's called if I'm not mistaken. Interesting that OOP works that well.... What language are you talking about in particular? C++? VB? I was thinking about getting into one of those...

[Paul V]

I think OOP works on the top down model, if I'm not mistaken. C++ lends itself to OOP easily.

The real key to OOP is to clearly define all the classes and objects on paper first, then implementing them is easy.

I wrote a Java prog that did Scrabble once. This is the basic strategy I followed:

I started with Main, which was the main body, it basically initialized the game object, called the Game.start() procedure, computed scores and left. All the functionality was elsewhere.

I had the following classes:

Game: this basically was a managerial class. It was the creator of many objects, and served only to direct requests to the other classes. No functionality besides getting info from some classes and sending them to others, it handled no requests itself.

Tile: Object to hold a letter, a point value, a bitmap for the tile.

Board: The graphical output routines for the gameboard.

Rules: Checks validity of input, computes point values.

PlacedTiles: A user's move, basically a Vector of Tiles, to be checked for validity, and scored.

TileBag: A bag holding the tiles at the onset, has draw and return functions.

Player: Holds player's name, and is the input routines.

Rack: Holds a player's tiles.

I think I had a few more misc. objects. I think all the other objects I used were used only as communication between the classes mentioned here though, I like wrapping all parameters passed between classes related to a single action into a single object for simplicity; instead of having calls with a huge number of parameters whose order I have to remember, I can set the variables in the object and pass a single parameter.

[Wiz]

I understand that hd, but that is an enormous amount of bug, bugs they know about!

I would think that they could fix bugs they know about.

[SoopaStar]

You also have to take into considerations that:
1) its not one programmer writing the 29 million lines of code, but a team. Then MS throws it all together
2) an OS is a little more hi-tech then scrabble.
3) they have to write a software package that accepts hundreds of thousands of different hardware configurations not to mention the software configurations.

Paul

[Paul V]

Actually, the drivers are generally written by the hw manufacturers so MS does less.

OSs are more complex in that they require more classes to operate, but on a class by class basis they are not much more difficult to program than any other. It's more programming, not necessarily harder programming.

I WILL say that the conceptual end, where you define classes and their interactions, is more complicated in an OS because of the number of classes.

And OOP is best in a team effort, because each team can work and test one class.

MS is just plain sloppy. These 63,000 bugs were known BEFORE they released, but did they delay the release? Did they make ANY effort whatsoever to ship a product as bug-free as possible? No. I understand bugs creeping in, every program of mine needs a little debugging, but before *I* submit a program either to the internet community or to an instructor for a grade I make sure all known bugs are fixed.

[Roraycr]

All operating systems, mainframe, midrange, whatever, have problems when they are initally distributed. All of them require numerous program fixes because it is nearly impossible to contemplate each user's configuration and usage. Updating operating systems is an ongoing job in all shops. In application programs, I have seen programs work fine for 2 to 3 years until someone does something nobody including the author thought would or could be done, and the program crashes and has to be fixed. Windows may have a lot of "bugs", but it is definately not unique.

[UncaDanno]

hd581 and Paul V, you're both right in a way. Back in the '80s it was called Structured, then came Object-Oriented, and now is the Component Model. With all three, it's design from the top down (Top-Down design from the 70s) and build from the bottom up (the Component Model of software construction).

Just don't ever, EVER mention to someone who has not developed in both (PC and mainframe) arenas the Top-Down design and OOD are anything near being related. Even though they are the same thing.

You'll be ripped to shreds by either faction.

[Paul V]

I know that OSs will have issues. My problem is not the bugs, it's the fact that MS KNEW of 63,000 bugs and shipped anyway.

That is not just an issue, that is an incredibly poor business and design philosophy.

[Roraycr]

All vendors do the same thing. They promise their customers, set a drop-dead date, then as long as the OS (or application) "works", they ship it and patch it later as the issues arise. I've been installing OS's, supporting software, and applications for 30 years, and believe me, Microsoft and the other vendors are doing exactly what has gone on in the software market for years and will continue in the future. It's just a fact of working in the IT arena. It wasn't as visible before PC's, but now the bugs are widely publicized so everybody knows about them.

I don't like this practice but I understand it. There has to be a cutoff and the product shipped or it will never get into production. I've debugged 10 and 20 thousand line programs, but I can't imagine the hell these people go through with 29 million lines of code.


[This message has been edited by Roraycr (edited 03-29-2000).]

[Wiz]

Paul, i said the same thing! Isn't it amazing that a company can release something that buggy and charge $200? If i released software like that, i'd be drawn and quartered.