OSDev.org

@holypanl: I sympathize about UniMonkeys. However, in my 11 years in the software industry I haven't encountered very many. Those I did encounter usually got fired within six months to a year. I think most UniMonkeys end up doing internal development in the IT departments of big companies, where they can produce crap all day and no one notices.

The kinds of software most of us use every day tends to be written by people that actually know what they're doing. The problem is that despite the individuals' best efforts, the product can still suck because of bad management, deadlines that are too tight, lack of quality controls, etc.

Also, you'd be surprised about the real causes of performance issues like excess memory usage. The underlying cause is rarely what developers think it is. Example: Outlook is a memory pig because it uses too many threads. It uses a lot of threads (ostensibly) to keep the UI responsive when it makes requests to the Exchange server, etc. So they optimized for one thing, and ended up pessimizing for something else. These guys are not stupid -- just wrong. It's possible to be smart and hard working, and still be wrong.

I like your passion for quality though -- keep it up.

Colonel Kernel wrote:Also, you'd be surprised about the real causes of performance issues like excess memory usage. The underlying cause is rarely what developers think it is. Example: Outlook is a memory pig because it uses too many threads. It uses a lot of threads (ostensibly) to keep the UI responsive when it makes requests to the Exchange server, etc. So they optimized for one thing, and ended up pessimizing for something else. These guys are not stupid -- just wrong. It's possible to be smart and hard working, and still be wrong.

But the only reason they're wrong is because they didn't think enough about how much memory it would take. Those kinds of things aren't so hard to predict beforehand on a general scale. I think the problem there is probably bias for one thing, either by the management or by the programmers themselves. You can easily be smart on a small scale, but unwise on a large scale concurrently.

One solution I can see to a problem of balance like the one in Outlook is to have one guy on the team who absolutely *loves* threads and responsiveness, and another guy who *hates* memory leaks and excess. That way, they'll only be happy once a proper (and probably more clever) compromise has been reached.

NickJohnson wrote:But the only reason they're wrong is because they didn't think enough about how much memory it would take.

Or they thought about it, weighed it against the extra development cost of implementing everything with asynchronous callbacks, and decided that the trade-off was worth it. Once they established a precedent, it became too difficult to change as the years went on, new features were added, etc.

Fortunately there are new and better ways of implementing code that uses asynchronous I/O, but back then there weren't.

NickJohnson wrote:You can easily be smart on a small scale, but unwise on a large scale concurrently.

That is so true -- well said!

NickJohnson wrote:One solution I can see to a problem of balance like the one in Outlook is to have one guy on the team who absolutely *loves* threads and responsiveness, and another guy who *hates* memory leaks and excess. That way, they'll only be happy once a proper (and probably more clever) compromise has been reached.

You're forgetting about the third guy, who probably has pointy hair, yelling at both of them to "just ship the damn thing!".

NickJohnson wrote:One solution I can see to a problem of balance like the one in Outlook is to have one guy on the team who absolutely *loves* threads and responsiveness, and another guy who *hates* memory leaks and excess. That way, they'll only be happy once a proper (and probably more clever) compromise has been reached.

You're forgetting about the third guy, who probably has pointy hair, yelling at both of them to "just ship the damn thing!".

That is SO true. Employers expect a masterpiece, and think that somehow, since yelling at their Dev team seems to make them move a bit faster, it means that the software is being built faster. And yes, it is. But at what cost?

You could URGE that poor Graphical UI team to hurry the hell up with the menu, and who knows: they may finish in half the time, with all of your hounding. But then, if ANY conditions don't follow the norm in the working environment, the software just freezes, or generates some error, or just crashes, or some other mishap.

Then the same guy is like: "Why couldn't you just do it right the first time?!"

Colonel Kernel wrote: The kinds of software most of us use every day tends to be written by people that actually know what they're doing. The problem is that despite the individuals' best efforts, the product can still suck because of bad management, deadlines that are too tight, lack of quality controls, etc.

From my experience, I disagree. Take a look at the drivers that HP creates for their printers. The code is probably written in Bangalore, by people who have been taught how to cut and paste over a million lines of code a day. I make part of my living by rewriting their driver code in assembly.

I have an example right here of a driver that goes to a tremendous amount of effort to set up a pipeline (in c++ that has been hand-translated into c?) in order to calculate an rgb to compressed cmyk bitmap. Their code compiles to over 500K of binary, and uses 3 times the size of the bitmap in allocated memory -- ie. 100MB of ram, typically. My first pass on the translation to asm 1) replaced the entire pipeline with a mere 3 consecutive function calls, 2) reduced the size of the binary to below 20K, 3) reduced the memory required to below 64K. And I could easily make another pass through the code, and optimize it to half that size again.

So I think that holypanl is right -- we will continue to need paging and swapping in full measure, even on systems with multi-GB of RAM, to support ungodly lousy programming techniques.

Beside being an good programmer it might be usefull to knew a little bit about the area th programm is used in. For example if you writing an Score generator (something like band in a box for example), best programming praxis would help you only a litte bit if you don't knew at least the basics about music theorey.

MasterLee wrote:Beside being an good programmer it might be usefull to knew a little bit about the area th programm is used in. For example if you writing an Score generator (something like band in a box for example), best programming praxis would help you only a litte bit if you don't knew at least the basics about music theorey.

not entirely true. you could just as well be given a data sheet on musical constructs and you should be able to pick out what you need. everything should be explained in the datasheet, from note length to accents and beyond. but if you were developing as a 1 man team, then yes, you will need to know a bit of music theory to be able to do it.

It's all about the environment you develop in. Most (if not all) big companies have several departments for software development, including art, logic, HID, etc. so no single person has to know 100% of what's going into the next release. it's one of the reasons why the finished product is never exactly like the original idea. each team has their own ideas because they have the expertise in their field and no other (generally, anyway), and in the end it all comes down to the programmers. what the programmers want, the programmers get, well... most of the time.

if the programmers had to know the logic behind everything that is going into their programs off by heart, then programmers would be one of the most intelligent people in the world, but most aren't. i say most, because there are a few that slip through the net and do go out and learn more about what they're actually doing (like us! we didn't stop at windows, we went beyond and found linux. and then beyond that and made our own way in the world).

Cheers,
James.

I couldnt stop laughing when I read about the UniMonkeys. Ive actually heard two stories from a guy Im trying to get a job with who used to be a hiring manager about UniMonkeys.

One guy, who ended up getting the job because he was friends with the manager, and is actually still working there, was asked how to find a value in a binary tree. His answer was bubble sort. The manager almost fell out of the chair when he heard this.

The other guy, was a guy from Russia, who did real well on the interview, but after a few months, when the realized he wasnt getting anything done, his manager sat down with him to go through some code, and ended up realizing he didnt know what an if statement was.

the UniMonkeys are out there, beware.