|
News from National -- Current
Articles
5/14/2002 3:32:46 PM
CLR
Expert: Kevin Burton
Interview by S.
Ibaraki, I.S.P.
This week, Stephen Ibaraki, I.S.P., has an
exclusive interview with Kevin Burton. Kevin is a widely known and respected
senior software design engineer, C++ veteran, and an international expert in
COM development, who has authored many articles and edited books on C# [C
sharp]. His most recent book, “.NET Common Language Runtime Unleashed,” [CLR]
by SAMS is unique in that it focuses on the CLR which is the heart of .NET
[dot NET].
Discussion:
Q: Kevin, it’s a real privilege to have you with us. Thank you for agreeing
to this interview and sharing your incredible 20 years of experiences, and
considerable skills with our audience.
A: You are very generous in your introduction and I thank you for this
interview opportunity. I hope my comments are helpful.
Q: You have a most interesting career. Can you highlight the key decisions
you made in your career, and how did you got into programming?
A: Actually I got into programming quite by accident. I have enjoyed
programming ever since my high school days when I would write programs in
BASIC or Z80 assembly on my dad’s TRS-80. I took some courses in numerical
analysis that I thoroughly enjoyed but at that time computer science was a
field that attracted the students that could not handle the math in
electrical engineering so I was not interested in a degree in computer
science. My first job involved designing a complex communications assembly
which depended on a real-time executive written by a consultant. Towards the
end of the project and before the actual integration of the software and the
hardware the consultant in charge of the software (firmware) was let go. Of
course the integration failed and I was charged with figuring out the code
and making it work. My next job with the flight controls group and Northrop
was more software development and from then on I exclusively had jobs doing
software development.
I guess some of the key decisions that lead me into programming were the
classes that I took while in college, the decision to take over the project
from a software (firmware) consultant, and the decision to stay in that line
of work.
Q: Describe your relationship with Microsoft’s .NET CLR team and what
development tips/pointers you can pass on from this interaction?
A: After acting as a technical editor for Sam’s Publishing I was asked at
first to co-author then to author a book on the CLR. Although I had a good
deal of experience with beta versions of the .NET Framework I felt that I did
not have the requisite “insider” knowledge required to author a book on the
subject, so Sam’s arranged for me to spend two weeks on the Microsoft campus
interviewing members of the CLR team. Microsoft arranged for me to have an
office and with great cooperation from the members of the CLR team I was able
to come away with a much better idea of the inner workings of the CLR than I
had before.
Every part of the CLR has a champion. Each area security, interop,
reflection, performance, networking, exceptions, threading, remoting, etc.
has a person responsible for that feature in the CLR. After that initial
contact I continually received support and tips from the CLR team members.
They were very willing to help and more than willing to offer tips and
suggestions regarding their particular area of expertise. And all of this help
was essentially on their own time, and believe me, with a major release of
the product that you have been working on for two plus years looming, that
time was not very abundant.
This is an extremely bright and dedicated group of developers. Within the .NET
CLR development team there are some of the brightest and most dedicated
software engineers certainly that I have ever met. Not only that they were
just nice people. If there was one tip that I could offer from my interaction
with them is that the .NET CLR has been developed by some of the brightest
minds and with some of the best resources available. Any time that I started
to wonder why was something done the way it was, there was always a very good
reason.
Q: What prompted you to write your most recent book on the CLR, what did you
learn from the experience, and what would you do differently?
A: I was first drawn to the .NET Framework because I could see from the first
beta that I installed that this was a new way to develop software. I spent a
good deal of time coming up to speed on the whole .NET initiative. To add
fuel to my interest I was asked to be a technical editor for C# Unleashed.
After a few months working as a technical editor I was asked if I would
consider authoring a book. I jumped at the chance because I could see a great
opportunity to learn more about the CLR and .NET. I found that the company
that I work for (Avid Broadcast) became very interested in .NET and my
efforts on the book and “work” dovetailed very nicely.
What did I learn from the experience? I have gained a very solid
understanding of the CLR and the .NET Framework. I have also built some
relationships with some very key people at Microsoft that have been very
helpful in my climb up the learning curve.
What would I do different? In hindsight I would have tried to keep a more
steady pace during the writing process. There was so much work to do that I
would sometimes “rest”. Or I would be stumped on a particular topic and I
would be waiting for a response. Overall it would have been better to switch
gears to a different topic during these “lull” periods. This amounts to not
much more than better time management.
Q: Can you provide us with five or more tips from your book and why Dennis
Angeline, Lead Program Manager for Microsoft, says, “…Regardless of the
language you use or the type of application you’re building, this book offers
a rare insight into how your application and the CLR operate. It offers a
perspective that nearly every developer using the CLR will find invaluable.”
A: I think you are really asking what I consider to be the most important
services that the CLR offers. It would be hard to prioritize these because
the level of importance of any given service depends on the application using
it, but here are what I consider the key services of the CLR and how you can
get the most out of each:
1. Resource management. Because of the type-safety inherent in most .NET
applications along with the garbage collection provided by the CLR a whole
class of memory management problems has disappeared. .NET. Programmers no
longer need to spend inordinate amount of time checking for buffer overflow,
memory leaks, using memory after it has been freed, etc. Handling non-memory
resources and unmanaged resources are a little bit more complicated but there
is a recommended pattern to handle these situations that I outline in my book
using IDispose.
2. Interop. It does not matter how great the new development environment is
if it requires the old to be discarded it will not be adopted very readily.
There is a huge installed based of COM applications and arguably even a
bigger base of Win32 DLL’s. The interop layer that has been built into the
.NET Framework allows for a very seamless integration between COM and Win32
DLL’s. The important point here is that the interop layer maintains model
consistency. For example the COM programmers are used to receiving error
information in the form of HRESULTs, .NET on the other hand exclusively
handles errors with exceptions. The interop layer automatically transforms
exceptions into HRESULTs and HRESULTs into exceptions. There are many more
examples but the overriding theme is model consistency. The .NET programmer
can treat the COM component as a .NET object and the COM programmer sees the
.NET object as either another COM object or interface.
3. Types and Values. I spend the first five chapters of the book describing
the type information, the intermediate language instructions, the assembly
format, and how the CLR manages each of these. The organization and
infrastructure of the CLR is fascinating and yields great dividends in
understanding how your application is executed. In my mind this is a step
above (in terms of abstraction) traditional object-oriented programming and
hence requires some “getting used to”. But, as you will see much of what the
CLR provides (language independence, security, resource management, meta
data, etc.) is in large part due to the Common Type System (CTS) and the
Common Language Specification (CLS).
4. Security. A managed program has the unique position to regulate security
within an application. The CLR has the chance to check for security
violations with each function call. This is a tremendous service for an
application to take advantage of.
5. Reflection. From remoting to simple serialization to debugging the
metadata that is associated with a program can be used so many ways to ease
the development cycle and make a program more understandable and
maintainable.
Q: What future book titles and articles can we expect from you?
A: I am currently working as a co-author on a book on .NET performance with a
member of the Microsoft CLR team.
Q: You have a long computing history filled with considerable and valuable
experiences. Can you describe some of the projects that you have worked on
and what tips you can pass on?
A: I am sure that I am dating myself but I started out in the computing field
with programs written on cards and was fascinated by the advances to teletype
printers and VT100’s. My first programming job was with the Bureau of
Reclamation overseeing a number of hydroelectric power generation plants. The
bureau used a CYBER computer located in Denver and we connected to it via a
1200 baud modem. The main language that we developed programs with was
FORTRAN. After I graduated I worked with Hughes Aircraft on a spread spectrum
communications system for the Navy. After that was canceled I worked with
Northup on the Stealth Bomber in the flight controls group. From there I move
into the commercial arena to develop CAD applications for printed circuit
design. It was with this job that I started to use ‘C’ extensively in
developing programs. Virtual memory was still not really part of main stream
applications so I spent a good deal of time worrying about the memory used by
my application. ‘C’ became more and more popular as I worked on inspection
systems for printed circuit boards and applications tied to a scanning
electron microscope. My first exposure to C++ was as I was developing image
processing algorithms for various applications for an image processing
consultation firm. I continued to firm up my knowledge of object-oriented
design and C++ as I assisted in the development of a TV news broadcast
automation system. And it was here that I am spear-heading the effort to
build the next generation news room automation system using the .NET
Framework.
So this does not really describe one or two projects but it describes how I
arrived at where I am now. And that is the tip that I would like to pass on.
It hasn’t been that long and I have seen at least three major shifts in the
way software is developed. It started with the crude methods of punch cards
and VT100 terminals. You had all the control that you wanted and just enough
rope to hang yourself. Then I saw a move to larger and larger disks and
memory getting cheaper and cheaper. Virtual memory, paging, and swapping
became everyday terms in a programmers dialog. Then came object-oriented
design which at first was rather faddish but soon reached the main stream as
the preferred way to develop software. Now there is .NET. Each successive
development improves the quality of the software and the productivity of the
programmer. But with each new shift it required an adjustment by the
programmer that wanted to keep up. .NET requires such an adjustment but based
on experience it will not be the last change. I can’t predict what the next
shift will be but I can almost guarantee there will be another. In a very
popular book “Who Moved My Cheese” the author uses the allegory of two little
people and two mice who come one day to find that the cheese that they
depended on to be there day to day was moved. It was gone. The mice almost
instinctively immediately started the search for new cheese, while the little
people bemoaned the fact that they were being “picked” on and insisted on
spending unproductive time asking questions like “Why me?” I think with each
shift that I mentioned above the cheese was moved. .NET has definitely moved
the “cheese”. The response will be how the good programmers are
differentiated. And the good programmers need to be aware that the “cheese”
will be moved again. You can count on it.
Q: What are the ten top traps or pitfalls that developers should be wary of
and avoid?
A: Again I have not taken the time to order these but here are some pitfalls
that come to mind:
1. Don’t rely on intuition to tune an application. Instead devise specific
tests, measure, tune and re-measure. I can’t tell you how many times I have
tried to optimize a function only to find that the changes that I made only
accounted for a small percentage of the performance.
2. Up front, seek to use good tools. Learn how to get the most out of these
tools. It is so expensive to develop software; it is well worth the cost for
a good editor, compiler, debugger, etc. to provide the best development
environment possible. Similarly it is important that you learn to use the
tools available to the maximum benefit. For example, spend time learning how
you can automate some of your routine tasks with the development tools,
program so that the compiler works with you to help detect problems, use the
tools available to characterize the software what you are building
(complexity, line count, etc.).
3. Be careful that what you develop is what you are expected to develop.
While there is reward for innovation if it takes the place of what you are
paid to develop it loses its luster.
4. As a corollary to the above point make sure that you understand and your
customers (it may be your boss, marketing, etc.) what the software you are
developing will and won’t do. No body likes surprises. If it is unclear what
you are doing make sure that all concerned know that it is unclear.
5. Avoid the temptation to go off in a corner, develop something and “unveil”
it. Network with your co-workers and interact with customers. If you are the
local expert make sure that you take some time to mentor.
6. Try not to become too specialized. Talk to your boss about rotating the
types of work you do.
7. Keep you eyes open and your ears to the ground. Stay abreast of the
current technology. Invest in good books and magazines.
8. Be prepared to swallow your pride and “buy” a solution if needs be. Any
good developer can implement just about anything but at certain points it is
better to use a canned solution than spending the time developing your own.
Avoid the “not invented here” syndrome.
9. Remember that the software that you develop will more than likely outlast
you. In other words it is highly likely that someone else will inherit your
code. Make sure the code is well documented, well commented, and modularized
so that its functionality can be easily grasped.
10. Have fun. Software development can be demanding at times but the sense of
accomplishment when a piece of software functions as it should is what has
kept me in the business. I enjoy developing good software.
Q: Can you share your 10 leading career tips for those thinking of getting
into the computing field?
A: I don’t know if I can come up with 10 but here are some tips that I hope
will be useful. No order but these are some tips that I might pass on:
1. Each job that I have had involved an initial period of doing tasks that I
was not that excited about. But following that period I found I niche in the
company that I enjoyed and was beneficial to the company and me. I think that
it is essential that each person find that spot in what ever job they are in.
2. Stay focused. Work smart and be prepared to work long hours every so
often. That is just the nature of the software development business. But at
the same time continually look for signs that you are getting burned out.
3. Be aware of industry trends.
4. Make sure that your company is keeping up. Companies rarely just shut
their doors overnight without some warning signs. Listen to the heartbeat of
your company. I have been in big companies and small companies. When it comes
to a layoff or downsizing the size of the company does not seem to matter.
5. Make sure you regularly invest in yourself. If your company cannot turn
itself on a dime (and most can’t) you may need to bide your time by becoming
familiar with leading edge technology on your own. Then when the company is
ready to invest in new development you will be there to assist in the effort.
6. Insist on who you work for to regularly invest in training. This shows
that the company is interested in you. The company should realize that this
will instill greater loyalty and greatly reduce “burn out”.
7. Avoid specialization. This is not good for you or the company. Often one
person becomes the expert in a particular area of the company. It is easier
and short term less costly for the company to maintain one expert, as tasks
that pertain to that area are most easily and quickly done by that person.
Also the transfer of knowledge is not cheap or quick. It is not good for you
because if the company should be downsized, sold, or simply go bankrupt (it
does happen) you may possess a lot of knowledge about an area that no one is
interested in (Where would someone go who has experience in the fine art of
reading paper tape?). It is not good for the company because even though a
person seems diligent and very much involved in their area they could be
becoming burned out and up and leave. A reliable feature now becomes a single
point of failure and may force the company to remove or redevelop that
feature.
8. If it does not exist already then start a grassroots effort to build some
methodology to your teams development efforts. Set up some sort of source
control, insist on requirements documents, do what you can to strengthen QA
and testing, automate your build process, start a process to review software
design, etc. Doing these kinds of things though frustrating at first, will
help improve the software that you develop [and] the software quality of your
team.
Q: You have a reputation for staying on top of the latest technologies. What
are the hottest topics that all IT professionals must know to be successful
in the short term and long term?
A: I am partial to .NET right now but I would think that it is crucial for
all IT professionals to become familiar with the whole idea of a managed code
environment. Java, VB, and various functional languages have had the vision
of a managed code environment for some time now. I think that the .NET
Framework manages code better that most any other environment but I think it
is still too soon to see who is the dominant player. IT professionals need to
understand the issues involved with managed code as far as garbage
collection, security, meta-data, interoperability, etc. Don Box made the
statement that he could foresee the day when all code either ran under the
JVM or the CLR. If that is even partially true then I think you can see that
it is pretty important to understand each of the managed environments.
Next in importance are the concepts behind SOAP, XML, and Web services.
XPath, XQuery, XLink, and XSLT associated with XML are key technologies in
their infancy. It is very important that IT professionals become familiar
with the standards and the tools available to implement the standards. I feel
that we will see the move from traditional relational databases to
relational-object databases that recognize XML as a first class data type.
Already the big three (SQL Server, DB2, and Oracle) have announced plans to
introduce an XML database of sorts. For the foreseeable future standard
relational databases will dominate as FORTRAN dominated the programming
world, particularly in numerical software, but eventually we will see more
and more XML databases.
Q: What would be your recommended top ten references for the serious
developer?
A: I would go to the following Web sites:
• http://msdn.microsoft.com
• http://www.gotdotnet.com
• http://csharptoday.com
• http://www.asptoday.com
• http://www.dotnetjunkies.com
Also, I would recommend the DOTNET newsgroup sponsored by DevelopMentor.
Whenever possible try to listen to Don Box’s various keynote addresses.
Subscribe to MSDN, C++ Journal, and Dr. Dobbs as well as “free” magazines to
professionals such as eWeek. Unfortunately the shelf life of books is not
very long. Currently I seem to be referring to the following:
.NET Common Language Runtime Unleashed, Kevin Burton (mine)
Applied Microsoft .NET Framework Programming, Jeffrey Richter
A Programmer's Introduction to C#, Eric Gunnerson
XSLT Programmer's Reference, Michael Kay
ASP.NET Unleashed, Stephen Walther
.NET and COM: The Complete Interoperability Guide, Adam Nathan
Q: You have so many accomplishments. What do you do to relax?
A: Actually far too few accomplishments. It might be more appropriate to ask,
what takes up my “free” time. Well I am married and have children so my
family takes up a good bit of my time. We have a dog that loves to go on
walks. I like to run. I have completed six marathons, two being the Boston
Marathon. My PR is 3:10 and I hope to break 3 hours next year. So between
work, a book, and my free time activities I really don’t “relax” a lot, but I
do enjoy life.
Q: If you were doing this interview, what two questions would you ask of
someone in your position and what would be your answers?
A: I think that you have already asked what I would ask. I would try to gain
some insight as to where they saw the software industry going and how they
planned to keep up. I think you have asked those questions already.
Q: It’s a blank slate, what added comments would you like to give to
enterprise corporations and organizations?
A: It is important to realize that your employees are your most valuable
asset. Every dollar spent in training and educating each employee is well
spent. Even if the training for some reason cannot be applied your employee
will long remember the investment that the company made in them. Good
employees are smart employees and smart employees are good employees.
Q: Kevin, thank you for sharing your valuable insights with us today and we
look forward to reading your books, and articles.
A: Again, thank you for this opportunity.
|
|
