I'm a bit disappointed with Charles regarding this article. It seems he may
be suffering from a slight case of Future Shock. For anyone who has not
heard that term before, Google "Alvin Toffler" and/or "Future Shock."
I am nearly 50 years old. However, I still prefer to remain on the cutting
edge of technology, "riding the curl" as it were. I only have a limited time
on this planet. I'd like to see as much as possible during my tenure.
In this case, I believe Charles' analysis of Microsoft's software philosophy
and architecture is bass-ackwards. That is, Microsoft is the most successful
software company in the world, employing some of the brightest minds of our
generation to create the most successful software in the world. To begin
with the assumption that, because one has difficulty adapting to it,
therefore Microsoft may be at fault, is to begin with a faulty assumption.
When I analyse new software technologies developed by Microsoft, my initial
approach is, what can I learn from the masters? In other words, by looking
at the result, I can derive the line of logical thought process that led to
the design of the software that we are looking at. Of course, this is not
possible in a vacuum. I do not study Microsoft alone. I try to keep current
with the latest products of various standards organizations like the W3C,
ISO, and ECMA at the same time, to put things into their proper context. In
addition, I keep my peripheral eye on the most successful of Microsoft's
competition, to see how it all fits together. This provides what I consider
to be a useful context for my analysis.
The design of software is predicated upon a set of requirements. Of course,
we cannot know all of the requirements that contribute to the design of
Microsoft software, but we may certainly be able to derive some of them from
the final product, and the context in which it is created, with some degree
of accuracy.
Charles complains that Visual Studio does not readily afford the developer a
great deal of freedom with the way that code is organized, and that claim is
certainly true, exactly as I have stated it. First, Visual Studio tends to
coerce the developer to a certain set of "best practices" that Microsoft has
developed. Second, while it is certainly possible to configure Visual Studio
to a different methodology, it requires a certain level of expertise and/or
research in order to do so. While Charles questions this, I feel that he has
missed an important step in his analysis: Understanding the logic behind it.
Let me elaborate.
Charles is a couple of years older than I. He ought to be able to remember
the "frontier days" of X86 programming, using DOS, command-line compilers,
various flavors of Kernigan&Ritchey C, and having to write software that
provided its own peripheral drivers, etc. I can certainly remember using a
variety of software packages for different types of things like Word
Processing, Database access, etc. One of the things I fondly recall (only
fondly because I no longer have to put up with it) is having a number of
cardboard "Cheat Sheets" with the various shortcut keys of the various
software packages, laid out or taped somewhere near the computer, since the
Mouse was not yet invented, and every software manufacturer had their own
set of proprietary shortcut keys for their software. This was
anti-productivity.
Competition relies heavily on productivity. Henry Ford was successful
because of his assembly line. The assembly line was a concept that created a
set of standards, a standard process for creating cars, with a number of
positions at which certain types of operations were performed in exactly the
same way repeatedly during the manufacture process. This made the Ford
company more productive. They were able to sell their cars for less money
because it cost them less money to build them.
Microsoft has always made productivity the central pillar of their software
development philosophy. Software which promotes productivity will sell
better than software which does not, because productivity increases the
ability to compete. Productivity is almost always centered around the
establishment of a set of more or less arbitrary standardized methods for
performing certain tasks, and, in the area of computing, automating those
tasks as much as possible, which frees the user to take on the more
difficult tasks that require creativity and intelligence.
Personally, I am only enjoying myself when I am employing creativity and
intelligence. Therefore, where I declare variables in my code, what rules of
capitalization I employ, whether my IDE promotes a top-down or a bottom-up
approach to organizing my code, none of these things interest me. What DOES
interest me is creating software that does way-cool stuff, makes my ideas
into reality, and enables me to crank out the software I design quickly, so
that I can go back to the drawing board and dream up the next way-cool
software.
Software development has become complex, requiring teams of developers to
create. Productivity demands that these developers adhere to a set of more
or less arbitrary standards, in order to interact more smoothly. What
Microsoft has done is to make these arbitrary decisions *by default* and
allow the developers more time to do what they do best: make software
happen.
Now, as to the reason why these things are not readily changeable: There are
many levels of software developers in the world. A combination of the
advanced tool sets available, demand for software developers, and pure lazy
human nature has created a segment of the software development community
that has very little ability to think and reason for themselves. I have come
to accept this, begrudgingly. There is actually a use for these "useless"
people in the world. However, if left to their own devices, they would
become a support nightmare for companies like Microsoft. They know just
enough to get themselves into a great deal of trouble if allowed to do so.
Therefore, while Visual Studio is incredibly configurable, much of that
configurability is hidden from the easy-access level, and documented in
hard-to-reach places, in much the same manner as child-proof caps on
medicine bottles. If one can find them, and use them, one has a certain
necessary skill level to do so.
So, what makes Charles Petzold, who admittedly writes some very good
instructional books about programming technologies, get his attitude from?
My theory is that his vocation dictates it. Charles has a very specific use
for software like Visual Studio, and other programming tools. He writes
about things like the C# language. In order for him to do so, he admittedly
tells readers to start with an empty project, and type their code in by
hand. This is an excellent idea for teaching people how to program, how
languages and programming technologies work. Charles is teaching in the way
that any good teacher does. He does not want the budding developer to simply
let the IDE write his software for him, without understanding the whys and
wherefores of that code. I applaud that. I have seen far too many developers
of the sort that Charles wants to prevent. That is what makes Charles a good
author and teacher.
But there is a difference between learning how to program, and programming
for a living. And there is a difference between using software to teach
programming, and using it to write programs. Charles works in a
highly-specialized realm. He is not, at this point, a programmer, but a
teacher. And Visual Studio.Net, and other software development tools
manufactured by Microsoft, are created with the professional developer in
mind.
I am only disappointed that Charles doesn't seem to realize this.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.
