| Title: | former Microsoft employee replies... |
| From: | fred langa |
| Email: | fred_iwk@langa.com |
| Date: | 17-Dec-01 8:34 PM GMT |
Subject: Code Bloat
Hi Fred,
I have a few comments for you on the issue of code bloat.
If you reference any of these comments, please keep my
identity anonymous. I worked as a developer at Microsoft
from 1985 to 1993 and therefore know a bit about how
things happened at MS during that time, but I have gotten
quite tired of people taking out on me all their anger
and frustration at the company and its products so I like
to lay low, as it were....
In your Information Week article you wrote:
> Some of the bloat we commonly see in today's software is, no
> doubt, due to the tools used to create it. For example, a
> decade ago, low-level assembly-language programming was
> far more common. Assembly-language code is compact and
> blazingly fast, but is hard to produce, is tightly tied to specific
> platforms, is difficult to debug, and isn't well suited for very
> large projects. All those factors contribute to the reason why
> assembly language programs--and programmers--are
> relatively scarce these days.
> Instead, most of today's software is produced with high-level
> programming languages that often include code-automation
> tools, debugging routines, the ability to support projects of
> arbitrary scale, and so on. These tools can add an astonishing
> amount of baggage to the final code.
I spent my entire tenure at MS working on the BASIC
language products, from GWBASIC & BASCOM to the last
version of QuickBASIC, to the one-version-only VisualBASIC
for DOS, and then on to the first versions of VisualBASIC
for Windows. I was an assembly language programmer the
whole time, so I'm intimately familiar with what you're
saying about the difference between assembly language
and high level languages.
What you say is true but fails to mention what I believe,
through my own observations of how development changed
at Microsoft, to be the biggest reason for code bloat:
a conscious decision to trade developement efficiency
for code efficiency, with object oriented programming
being the culmination of that trend.
Here's an example:
In the early QuickBASIC days, when we were first
adding a real user interface to the BASIC development
tools, the UI code of text mode (non-Windows) products
was written by the developers of the product and built
into the product. It was clean and tight because it
did only what it had to do for that one product, and
was well integrated with that product.
Then it became clear that we, as a company, had several
developers scattered around the different product groups
all writing UI code that was doing essentially the same
job. So a UI group was created, and they built up a set
of shared library routines that each product would then
include and call. Of course, these library routines had
to provide all the features that all the products needed,
as well as doing so through a well-defined API instead
of tight integration with the main product code. This
led to a more efficient development process while also
leading to less efficient code size and speed.
Now extrapolate that concept from UI's to other aspects
of the products that could be shared: memory management,
graphics routines, help systems, network support, etc.
Each time a function got removed from tight integration
with the product and replaced with a general purpose
library routine, the development process got cleaner
and the resulting product got bigger and slower.
Note that this is not just a slide into big fat sloppy
code; it was a conscious decision made for business
reasons. It was not a universally popular decision
within the walls of the company, and I was one of those
who was not happy with it. I hated the fact that *my*
products, which I had worked so hard to keep lean and
clean, were being cluttered up with big fat code that
IMO we didn't need. But now I can look back and see
that it was a business decision that made sense. The
proponents of the decision to move development in that
direction always said things like, "don't worry that
it's fatter and slower, the hardware will catch up and
this method lets us get the products out the door and
to the customers sooner". They were right.
The eventual move into object oriented programming
magnified the situation because the development process
of building a product from object libraries was even
more efficient, but the resulting code was even more
fat and slow.
To answer some of your other questions:
> Are any companies producing lean, tight code anymore?
The Palm OS is my favorite example of lean tight code.
The writers of that were constrained by the weakness
of the hardware and so had to write tight code to make
it useful.
> Do you think code bloat is simply the result of
> institutional sloppiness on the part of Microsoft
> and other software vendors, or is there more to it?
I hope I have explained above that it is most definitely
not "simply [...] institutional sloppiness". I'm sure
that there is plenty of sloppy code in Windows, but to
put the whole issue of code bloat down to sloppiness is
much too simplistic. If it was just a matter of being
sloppy, Windows would have already been knocked off its
throne by a product which provides the same functionality
with unquestionably greater efficiency.
> Do you think code bloat will reach a plateau, or will
> it continue indefinitely?
I think it has already reached a plateau of sorts.
The move from single purpose assembly code to high level
languages and object libraries has already been made, and
I don't see on the horizon any similarly large leap left
to make. But I do expect every future version of Windows
to have more features and more help files and more
templates and more examples, so as long as you count
all those megabytes as "code bloat" then yes we'll see
a neverending increase.
Well, that's my 2 cents.
Keep up the good work,
[name withheld]