-
What are the most important features of debugging managed code with Visual Studio .NET 2005?
I almost don’t even know where to begin because from a debugging perspective, there’s so much that’s new.
My favorite feature is the new Data Visualizers. Instead of looking at a ton of raw data in the Watch window,
we can now look at the different data types exactly as you would expect them to appear. Once you see your
returned data sets in a grid control or a bitmap in its graphical form, you’ll wonder how we ever were able to get
anything debugged before. While graphical representation of data while debugging has been around for a while
(back in the 16-bit Windows days a third party debugger displayed self referential structures graphically), it’s only
now that we have self describing objects from .NET that we can apply it to generic technologies. Just with the
Data Visualizers alone I’ll have somewhere around two years of Bugslayer columns for MSDN Magazine!
Another feature I find myself using quite a bit is the new Data Tips. The fact that they allow full editing and changing
of the data right inside the Data Tip means you stay focused on your code, instead of bouncing in various windows.
It’s one of those features that will make you debug faster. Speaking of faster, one of the other great features is something
that Microsoft hasn’t been touting at all: debugging managed code has sped up considerably, especially mixed (both managed and
native) mode debugging. Even in the untuned beta you’ll see just how much faster it is.
A few features that folks are just now able to start playing with are going to make the whole debugging process much easier for developers.
The Enterprise Developer Tools folks at Microsoft will be delivering profiling, code coverage, and unit testing tools with Visual Studio .NET 2005.
I’ve got some columns on these tools coming up in MSDN Magazine and I’m extremely impressed with what they have for a first version.
These tools are really third or fourth version based on their feature breadth and depth.
- In your book "Debugging Applications for Microsoft .NET and Microsoft Windows" (DANW) you recommend
that developers should be evaluated based on the number of bugs they have found in their code. This sounds like a great idea because a
developer can find some serious bugs if encouraged to do so regularly. How can this policy be implemented from the management perspective?
The whole idea here is to get a real picture of where the bugs are. The folks writing the code know where they have issues and problems
in the application, but they almost never get them in the bug tracking system on their own. With those issues in the heads of the developers,
that means that others on the team spend a huge amount of time tracking them down or reproducing them. How many times have you been struggling for
days on a problem only to have someone else on the team say something like “Yeah that could be a problem because of the way I store the data and I
had planned on fixing that later.”
My idea is to incentivize the developers to get all those issues into the bug tracking system so you’ve got a complete as possible picture to where potential
problems are in the product. That way, when you do run into a problem, a quick search of the bug tracking database will let you know who’s responsible
for the problem, and how much thought has gone into the problem. A great side benefit for getting any and all potential problem thoughts into the bug
tracking system, you’ve immediately got a chance to start applying appropriate code reinvestment for future versions.
To make sure the developers do what you want, it all comes down to using the data in a review. If you tell everyone that they need to be putting in all
problems they know about, make darn sure that data shows up on their reviews. I’ve found that if you make it clear to people what exactly they will be
reviewed on, they respond appropriately because pay and promotions are riding on it. Of course, having multiple reviews through the year make this much
easier to implement because you can give those mid course corrections.
- John, in DANW you talk quite a bit about Performance monitor (Perfmon).
Perfmon functionality did not change since Windows 2000. What extensions of Perfmon would you recommend for Longhorn?
On the Performance Logs and Alerts side, I’m pretty happy with all the data it collects and exports. I’ve gotten really good at all the command line tools and
Excel to look at all the data. Where it falls down is on the System Monitor and the corresponding Microsoft Management Console (MMC) side. That’s partly
because while I understand what problem they were trying to solve with the MMC solution, that of a consistent way to access system management
information, its implementation leaves a lot to be desired.
For example, I am constantly hitting the File Save menu expecting to save my data in System Monitor, because every other Windows application in the
universe works that way, yet with MMC, I’m saving the actual console, not my data. Also, I think its nuts that you have to save System Monitor counters
sets as a separate MMC snap in. Why can’t it save counter lists in a format where you can load the counters inside the same view?
I’ve often been tempted to write a wrapper around the System Monitor ActiveX control that’s more geared towards developers. (I don’t know if it’s
possible to reuse the ActiveX control as I haven’t looked too hard). My dream replacement would have the following features:
- The ability to save and load just the current counters so you can easily bulk add counters to a view.
- You can save all the data collected in the view into a CSV or XML file, not just the current snap.
- The ability to compare two data sets.
- The Add Counters dialog would remember the last selected performance object instead of always going back to Processor.
- Mono's implementation of .NET is becoming increasingly popular. What is your experience with Mono's .NET debugger?
What improvements would you recommend?
Other than reading about Mono on their web site, I haven’t used it. I have enough trouble just keeping up with what Microsoft is doing, let alone work
with another runtime.
However, I am very excited to see what they are doing. Anything that pushes .NET development is cool with me, especially to other platforms.
- For unmanaged C++ you wrote a tool that would rearrange C++ during linking so that methods that are more frequently called are near the top in the PE file.
Is there a preferred design of a managed class that would minimize page faults in the managed executable?
Smooth Working Set (SWS) was my answer to the disappearance of the old Working Set Tuner tool from Microsoft. I was quite happy to see how many really
large commercial applications have been tuned with SWS. When it comes to .NET, we get the benefit of SWS for free so there’s no need for a tool.
Because the code necessary to execute the application is jitted as needed, only the called methods are actually in memory. If you’ve got dead code,
it’s never brought in. Even better is that if there is a memory constraint on the system, the CLR can resort to code pitching and will throw out jitted
methods that haven’t been accessed in a while. Therefore, we’ve got an automatic tuning system that keeps only the most called stuff in memory
automatically.
- You’ve recommended that developers should have a stint management, why?
That sounds counterproductive to being a good engineer.
A little management time won’t hurt anyone! :) The best career move I ever made as an engineer was to have a good stint as a manager.
As an engineer, I used to wonder what drugs my manager was on asking me about certain things. Once I became a manager,
I was the one asking for those things and I realized how important they are. After I went back to engineering, I had walked the
proverbial mile in my manager’s shoes. My horizons were broadened and I attribute that time to making me a much more contentious and
stronger engineer. You don’t have to go into a full Program Manager role to get a taste for how life works; simply being a Development Lead for
scheduling will make a huge difference in your life.
What really bothers me about this business is how many people tell me that while my idea of being some sort of manager is a good idea, they can’t do it
in their company because once they go down the management track, they are stuck there forever. That’s a sure sign of a dysfunctional development
shop (and one you may want to leave for a good one). If a company can’t realize that there are engineering, management, and quality assurance tracts
that are interchangeable, they have no hope of shipping quality software. The best thing you can do in an organization is get people cycling through roles
so they understand the other sides. You’ll get much better code and much smoother development cycles because developers understand the other two
thirds of development.
- What is a typical career path for a Bugslayer? What has changed in the last decade?
Ideally, everyone who wants to fix bugs for a living will be a fully qualified Green Beret, as I am. By understanding the ramifications of airborne infiltration
and the ability to work for months at a time in covert hostile environments is mandatory to solving the toughest debugging challenges.
Of course, I’m kidding, but for the 20-30 of us former Special Forces guys now in the software business, our salaries would be fantastic!
One can always dream, right?
Seriously, when we are hiring for our consulting division at Wintellect, we are very interested in folks who have extraordinary track records of completing projects.
While pretty much anyone can write numerous oceans full of code, the real learning comes into play when you have to make those tough compromises at the end
of the project to finish it as well as the real testing and debugging to make the code as good as possible.
I’ve always told folks that the most important thing you can do for your career is to come up with a couple of projects on your own, plan them, and finish them.
When you show up for an interview, bring your code samples with you and give them to the interviewers. We always ask for code samples at Wintellect because
we want to see how folks work and determine if the code is tight enough that we could seamlessly transition onto a project this person was working on..
If you show up with good code samples, you are immediately bumped into the top 20% of developers. One final note about code samples: just because you
wrote it at work does not make it yours. If someone else holds the copyright on the sample you bring in, don’t be surprised if they kick you out the door for
violating trade secrets. Make sure the code totally belongs to you.
In the last decade the change follows the market: Win32 to .NET. Instead of asking about all sorts of convoluted Windows messaging problems, now we ask
all sorts of convoluted .NET assembly and app domain problems. One thing that I’ve found interesting interviewing recently is that folks know a lot about .NET,
but are missing some of the foundation in Win32. We debug a lot of .NET applications these days, but with those weird performance or execution problems we
see still come down to the operating system. You don’t have to know how to write a device driver, but you should definitely know things like what constitutes a
handle, how to see file accesses by a process, and the like. Reading Dave Solomon and Mark Russinovich’s Windows Internals/Inside Windows is a great help.
- Are we ever going to get to the point, where we could in a reasonable time find and fix bugs in third party binaries without source code?
With .NET assemblies, simply pull up the assembly with Lutz Roerder’s outstanding Reflector and you’ve got the source code! Of course, if it’s obfuscated with
Brent Rector’s great Demeanor, that’s not going to help, so we’re back to the native days. In the big scheme of things, I doubt that any time soon we will be
fixing and patching binaries. It’s just the nature of the beast.
- Last few years have been tough for technology companies. You, guys from Wintellect, made it through. What is your secret?
At Wintellect we say that the best time to start a company is the month that the stock market hits it all time high right before a recession! It has been tough
over the last four and a half years, but by having to scratch and work hard for every deal we learned to run a lean company and not to take anything for granted.
We’ve been able to grow to over 20 people by paying hyper attention to what our clients want.
As for a secret, I’d say that’s Lewis Frazer, our President. When Jeff Prosise, Jeffrey Richter, and I were starting to form the company, we realized that we
were idiots when it came to business. Fortunately, Jeff knew of this great business guy who’d grown companies from startups to taking them public.
Lewis was looking to run another startup so the four of us started the company. If it wasn’t for Lewis, we’d have died by now.
My advice to any engineers looking to start a company is to make sure you get hooked up with a real business person. Code is only about 5%, if even
that, of what it takes to be a real business. The other 95% is getting the word out and closing sales. If you can’t handle that (and I know of very
few engineers that can), you’re in trouble.
- What are your professional plans for the next few years?
Our long term plans are to buy Microsoft. :)
In the short term, I’m working on some very interesting projects between Wintellect and Microsoft to bring advanced training to higher end developers.
I’ve always maintained that there’s a ton of introductory classes out there but nothing for serious developers who’ve already done the basics. These new
plans we have will address that and offer a path for growing developers as well. I’m really excited about it so keep an eye on Wintellect’s web site for more
information.
As Visual Studio .NET 2005 starts getting closer, I’ll start seriously working on an update to my book to cover it. While books are a pain to do, there are a lot
of things I want to say about debugging and performance tuning in the .NET world that takes a book to say. For the next edition I will break it into two books,
one for the managed and one for native. That way I can concentrate on the respective environments without trying to combine them in a single book. Also, I
was already up to 850+ pages and if I add all the stuff I want to add, you physically won’t be able to open the book if I kept covered both in one book.
As always, my first priority will be growing Wintellect. We’re doing a lot of
interesting consulting work and I want to expand that work because there is a
need for a high end .NET and Windows consulting and education firm. With the
phenomenal people we have in our consulting business, we’ve been mapping out
some strategies on meeting our goals. As I mentioned earlier, training is still
a big part of our business and we are looking at a lot of creative ways to grow
that market as well. It’s going to be a heck of a fun ride!
|
|
