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].

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:

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


Suggestions for this page?
Email NPA Web Services: click here

NPA      facebook      LinkedIN logo
© Copyright Network Professional Association® 1994-2024 All Rights Reserved.
NPA Privacy Statement