Careers: Interviews
CLR Expert: Kevin Burton
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 |
|
|
