Whas that an intentional flame bait?

I don't believe that the age of the developer matters much. Will and interest is far more important factors.

A company may hope for people who stay overtime to keep up with a tight schedule - especially since the scheduling problem is often not caused by the developers but by management and customer having run ahead a couple of steps. The important thing is that in many countries, the office would have to close if it tried to force the issue with overtime or vacation. In Sweden, it isn't just the union that would react, but the police could do a raid and request in reports evidence about working hours... We can't fight for the workers rights in development countries unless the society looks out for the same problems locally too.

I really, really do not think M$ has a problem with lack of documentation before starting to develop. On the contrary, they document, and document, and design, and decide and document and evaluate almost forever for features that a smaller company would quickly decide, implement and deliver. The problem is that a huge number of people involved in the decisions seems to have their heads screwed on backwards. They seem to have missed the fact that their customers are human beings. No fun for a developer to implement really stupid things just because there are 100 pages of documentation about exactly how the feature should work - but no documentation about how the end users will react. A large company has too long distance between product management and the end user - they do not spend time regularly solving customer problems. An example: At a telephone conference today one users laptop downloaded and installed a M$ update (I know - stupid to let M$ decide when!) and then constantly popped up a dialog that the computer needs to be restarted. Reach right. Just as if it should be allowed to be restarted while connected to the projector for synchronizing information between us and customer. M$ somewhere decided that "Remind me in an hour" would have given too much choice to an end user. That is a management problem, not a developer problem.

No problem that the M$ developers gets too much freedom with their tools. Most probably they do _not_ get the needed freedom. Not "make it work" but "make it work the politically correct way".

My old Pentium with 90MHz processor feels about similar to use with Word 2.0 than my current machine (3.4GHz multi-core with more instructions/clock cycle) does with the current Word release. Neither machine manages to feel snappy with Word. So we must talk about way more than a 10 times slowdown. And when the code is running faster, the new Word is instead making requests to a huge number of DLL and other support files making sure that processor efficiency gets hurt by disk seek speeds. Starting Word is a big and complex task compared to starting Win 3.11.

Assembler has its advantages, but in no significant way would it matter if M$ used assembler, C, C++ etc. It doesn't really matter if an application is 200kB or 400kB large or takes 100 or 130ms to run. The question is why it may be 10MB large and takes 5 seconds just to start.

A quick look in my task manager:
- Notepad with a 50kB large document loaded takes 4.5MB.
- WinAmp takes 9MB.
- FlashMagic, for programming NXP chips consumes 11MB.
- Excel needs 23MB.
- Acrobat 30MB.

The above doesn't happen just because people have selected a HLL instead of assembler. HLL languages manages quite well to produce small applications 20 years ago. But today all applications are using huge frameworks and then extending these frameworks with huge libraries. And all data is held at a very high abstraction level, resulting in the majority of memory being wasted with meta-data about the data. Maybe consuming houndreds of bytes of memory just to know where a single 4-byte integer or 10-character text string is stored. The memory management system is basically glowing a dull red from all the work constantly making micro-allocations and then garbage-collecting and merging.