Sometimes, only one member of a band gets the attention, and the rest of the musicans serve as backup. How many people can name the members of The Doors besides Jim Morrison? But other times, the entire band become stars — like the Rolling Stones.

With the Wintellect crew, it's hard to pick out a top contender. All three of its founders — Jeffery Richter, Jeff Prosise, and John Robbins — are star performers in their own rights. Each brings top-notch software development expertise to Wintellect, a training, debugging, and consulting firm dedicated to helping companies build better software, faster. For example, Jeff Prosise's most recent book, Programming Microsoft .NET, was published by Microsoft Press in 2002, and his writings appear regularly in MSDN Magazine and other developer magazines. Although I first knew him, back in the early 90s, as a general programming author, today his life revolves totally around ASP.NET.

John Robbins heads up the consulting and debugging services side of the business. He also travels the world teaching his Debugging .NET Applications and Debugging Windows Applications course so that developers everywhere can learn the techniques he uses to solve the nastiest software problems known to man. As one of the world's recognized authorities on debugging, John takes an evil delight in finding and fixing impossible bugs in other people's programs. Prior to founding Wintellect, John was one of the early engineers at NuMega Technologies (now Compuware NuMega), where he played key roles in designing, developing, and acting as project manager for some of the coolest C/C++, Visual Basic, and Java developers' tools on the market, such as BoundsChecker, TrueTime, and TrueCoverage. He was also the only developer at NuMega with a couch in his office.

The third member of the crew, Jeffery Richter, is the author of several best selling .NET and Win32 programming books, including Applied Microsoft .NET Framework Programming (Microsoft Press), and a contributing editor to MSDN Magazine where he authors the .NET column. Jeff has been consulting with Microsoft's .NET Framework team since October 1999; he's also been consulting on Microsoft's XML Web Services and Messaging Team ("Indigo") since January 2003.

DevSource: First: why do other people think you're so cool? Everybody talks about you as though you know everything. What do you guys think that you do right, or differently?

Jeff Prosise: John and Jeffrey are cool, but I'm not very cool. Just ask my teenage son and my (almost) teenage daughter!

I guess we're somewhat unique in that instead of spending all day every day in the trenches developing product, we dedicate a significant part of our lives to understanding a platform or technology deeply and then sharing that knowledge by writing books and articles, teaching classes, and speaking in public forums. I feel exceedingly fortunate that I can make a living doing something I love, but I could do without a lot of the travel. Travel is not cool when you have a family back home.

Jeffrey Richter: I think the reason why we seem so informed is because of our close ties with Microsoft, its employees, and products. Personally, I've been contracting on and off at Microsoft in various groups for the past 13 years or so. This has given me phenomenal contacts and insight into the motivations for why things were done the way they were.

A lot of times, people can look at Microsoft technologies and ask "Why did they do that?" or "Why did they do it that way?" or "what could they possibly have been thinking?" In some cases, Microsoft had perfectly good reasons for doing something a way that it is. And, in some cases, something was done a certain way just because they wanted to ship and enough time wasn't spent really thinking about the problem. Or, sometimes, the Microsoft employee responsible for a particular feature didn't have the right knowledge or experience and so an inferior implementation or design is ultimately what ships. Having this knowledge lets you make good judgments about technologies; you can decide to ignore a technology, or know that Technology A doesn't fit well when used with Technology B or that a particular technology has performance or security problems.

Today, I look at a lot of MS technologies and see that things are not as good as they could be because it was originally developed years ago when there were significant memory and CPU restraints and these things can't be redesigned today due to backward compatibility constraints. Developers that are new to Microsoft's technologies won't have this insight.

I think that this insight and knowledge gives us an edge over our competition. I've been following Microsoft technologies since the MS-DOS days back in 1980. That's almost 25 years now. There are many things in Windows that are the way they are because of the MS-DOS lineage. The whole file system with its directory structure is a great example. And, one reason why Microsoft is having a hard time shipping a new file system (like WinFS) is because of backward compatibility.

John: Only Jeff and Jeffrey know everything. I learned how to develop from their books and articles. They've both been in this business a lot longer than I so that makes me the dumb guy of the group.

Seriously, I certainly don't know everything, but one lesson I've learned in this business is that half the developers out there are way smarter than I am. I know a little bit about debugging applications and how Windows and .NET work. There's so much to know that there's no way you can even claim to know one third of .NET or Windows.

Probably what sets us apart from most folks is that we seem to have the ability to communicate the concepts and ideas developers are interested in. We all slave like crazy on finding the best way to tell the story about how to use the technology or solve a particular problem. Since most developer-types slept through their English and Communications classes because they found it boring, they missed out on probably the most important tool in this business.

DevSource: Between the three of you, you've been specializing in developer issues for, what, 20 years? 30? What's changed most in that time? (Or, rather: what's gotten better and what's gotten worse?) Also, what important changes do you see coming?

Jeff Prosise: Well, software development is definitely very different today than it was 20 years ago. You used to live pretty close to the machine, writing machine code that talked directly to the processor. Today, software benefits from multiple layers of abstraction, and the layers get thicker every day. Mostly, the high level of abstraction is a solution to the problem that software is growing too complex for the human mind to comprehend. Imagine writing an application like Microsoft Word in 1980s Assembly language. You'd never finish. But because of operating systems such as Windows and frameworks such as .NET, we can write increasingly complex applications and have reasonable confidence that they'll work (most of the time).

I think the issue of software complexity is like a big rock hanging over us, ready to drop at any time. Look at Windows, for example. One reason Microsoft continually finds and fixes bugs in it — and one reason that Longhorn seems to get pushed farther and farther out — is that Windows has so many tens of millions of lines of code in it that no one person can get his or her arms around it all. No single person at Microsoft knows the entire Windows source code base. Fix something over here, and you're liable to break something over there. With Windows, we've just reached about the limit of human capacity when it comes to software. That's a little bit scary.

John: I've only been in this business since the early 90s, but I did get to start with DOS, which I consider a huge blessing. Back in those days, you were close to the metal. As PC development has evolved, I had that knowledge of how a computer really works from the lowest levels up. Today's developers are coming in at higher and higher levels of abstractions, so they don't have the underpinnings of how the machine and OS works so when they have problems, they are sometimes at a loss to solve them.

While the abstraction levels have caused problems, I do think they are the biggest and best change I've seen. In a couple of days, an IT developer can sit down and write a Web site that accesses routines on multiple machines (Web services) and databases with billions of records. That blows me away. When I started in the business, the first application I worked on dialed the phone to connect to a server and exchanged data through a rudimentary protocol. We were thrilled to get it working, and it was a living hell to get debugged.

While I don't have any specific data to back it up, one thing that I've seen getting worse over the years is the level of testing. Maybe it was the company I started with, but the level of testing both by the developer and QA seemed to be on average much higher than they are today. The type of development I was taught years ago is now recycled as Test Driven Development. Hopefully, that will bring the level of testing up considerably.

As far as important changes coming up, the idea of "always on anywhere you are IP-tone" is something that I think hasn't yet been explored, but will have a huge ramification to all aspects of development. As I type this, I am in the Red Carpet club in Chicago's O'Hare Airport accessing the Internet through a GPRS connection on my Bluetooth phone. I've got my laptop set up so that, if it doesn't have a network connection, it automatically uses the phone connection. It's now almost disconcerting if I can't download my mail. While few people need the always-connected computer, when you debug people's impossible problems for a living, being responsive to their calls for help is a key business objective.

Right now, all the applications and Web sites assume that everyone has a minimum of a 10 MB direct pipe into their machine. On this GPRS connection, I'm lucky to get 21KBps/second, so checking e-mail and accessing the Web takes forever. A very smart developer would work to ensure that their applications and Web sites take into account connection speed and respond accordingly. My SmartPhone does that already, but I want the same ability on my laptop.

Jeffrey Richter: Today, we hardly ever think about CPU performance and memory size. This, of course, is great, as it allows developers to focus on the actual business problem. Of course, the down side is that occasionally, memory and CPU performance becomes a problem and if addressed too late in the development cycle, these things can be quite difficult to fix. So, I think what has gotten worse is people's desire to really think through a problem and understand it before implementing a solution. New hardware and software technology advances allow us to get a little lazy with this but I've seen some examples where almost no thought has gone into a solution at all.

Also, developers really need to better understand the technologies that they are using. It is so convenient in .NET to open an XML document and read the whole thing into a DOM. But how many developers really know the performance of doing this? Or how much memory it will take? What impact will all of the DOM's objects have on the garbage collector? How long will these objects stay in memory?

Developers should take a technology that they are considering using out for a test drive before making the technology the cornerstone of their application. Build an application that just opens a file and reads XML into it. Test the performance, memory usage, etc. I'd also like to see more incubation projects, where theories are tested out with small programs before the company bets the whole farm on something.

As for the future, hardware improvements will keep coming and this will allow developers to get lazier about design. Platform improvements will also keep coming and this will allow developers to do more while writing less code. Long ago, programs consisted of a set of instructions. Then, we discovered how to put common functionality into a subroutine and call it from various locations. This made us more productive. Then object-oriented programming came making us even more productive. Managed environments like .NET and Java took object-oriented programming to a new level where lots of common programmer tasks were done by the platform (like memory management and serialization).

What's next? I think attribute-based programming is next. This is where the programmer designs an application's user-interface layout or behaviors based on attributes. HTML is a great example of this. ASP.NET 2.0 is another great example. In fact, in these cases, the developer can even drag and drop using a designer to build most of the application. The designer applies most of the attributes automatically forming most of the "code."

Also, software is getting bigger and bigger as well as more and more complex. In addition, end-user machines vary substantially. ... Testing really complex applications on all these kinds of machines is near impossible, which is why software gets a bad reputation for reliability. I think that we will see improvements here. More code will be placed in to the platform (by Microsoft and others) and these companies will be responsible for the majority of the testing. The platform abstraction level will move farther up, away from the hardware, so more developers will be using components created and tested by others. More than ever, you'll have to trust the platform (and company that stands behind it) that you choose to develop your software with.

DevSource: With all the training you've delivered, and the books/articles you've written, you've seen a lot of programmer mistakes and confusion. (That is, you know what questions are asked most often, which questions are most likely to be answered wrong on the quiz.) What are the most common errors, misconceptions, the stuff that's never quite clear? What's the source of those "huh?!" expressions — and who ought to be addressing them?

Jeff Prosise: I see a lot of mistakes made when it comes to managing the software development process. John Robbins could probably offer some lucid comments on this, because he's one of the world's experts in managing development projects properly.

Something else that I see a lot is developers who have so little time to build a deep understanding of the platform they're working on that they build code that works but that does so suboptimally. The average application produced today has lots of room for improvement. If an expert gets a chance to review the code, he or she usually has no trouble identifying ways to make it work faster and better.

John: As I mentioned earlier, I was so lucky over the years to learn from the bottom up. From a developer perspective, I'm seeing that developers are missing how the computer works. Many of the architectural and performance problems we've helped debug come down to bad assumptions on what goes on order the hood. If developers would take the time to read books on how .NET, Windows, and Visual Studio worked, they would be much better off.

Another problem — that's remained constant the whole time I've been in this business — is development managers who are still not doing one very important aspect of their jobs: getting rid of developers who are not performing up to team standards. Nothing is a worse motivation killer for a developer to be slaving away and getting the same raise as the developer in the next office over [who] is doing nothing productive and, in many cases, actually hindering development. In some companies I've visited, I've had the developers begging me to talk to their managers about getting rid of some folks so they can do their jobs better.

There is certainly no joy in getting rid of someone, but it's what you have to do to keep hot teams on the right side of the bell curve. The manager needs to work hard at counseling and working with their team members to anticipate problems and nip them in the bud. What I'm talking about is a problem in all businesses, but is one that I think that is even worse in development shops because the managers have moved up from technical positions and very few technically inclined people are actually "people people."

I've worked at companies where managers did their very hard duty and those teams were massively more productive and happier than normal teams. While there seems to be a "new" development philosophy making the rounds every six months or so now, none of them address the fundamental people problems that will undermine any spiffy new way to write and test code. Maybe I should patent this, call it "Reality Development," and sell really expensive training for it.

Jeffrey Richter:I see developers spending way too much time and effort writing error handling code. They are not using exception handling correctly in their code, and they are making life so difficult for themselves. It is typical to see a gazillion catch blocks in code that are swallowing exceptions hiding real errors in the code so that developers don't know when errors arise. This is also popular within Microsoft's own code, unfortunately. People really need to get Zen with exception/error handling more.

DevSource: The real danger, in any "learning experience," is being unaware of what you don't know. You fix the bugs that you know about, but you're much more vulnerable to problems you never considered. Surely, a few years ago, the prominent example of "I don't know that I don't know" was app security. What is it today? What's the issue that developers don't realize they really have to address?

Jeffrey Richter: Security will be an issue for a very long time. Thankfully, the CLR helps a lot with that because of type-safety checks, array index checks, code access security, no memory leaks, and no memory corruption.

Thread synchronization issues are also quite problematic and will probably get worse as time goes on. Today, on a single-CPU machine, it's hard to discover thread synchronization issue; but with hyper-threaded and multi-core CPUs becoming more and more mainstream, the chance of data corruption due to a thread synchronization hole is more likely.

And, as I said before, error handling is a big issue. Developers and their company need to complete the application life-cycle in a robust and solid way. The life-cycle is code, debug/test, deploy, capture bugs in the deployed code, update the software, deploy a new version, etc. Microsoft is a great example of a company doing this mostly right. When a Microsoft application crashes in the field, it sends information about the bug to a Microsoft server on the Web. Microsoft takes this data and fixes the application and then offers updates to the application.

I'd like to see Microsoft get more responsive. Today, a lot of people believe that when an application crashes, Microsoft sends the information to a garbage can on the Web. It would be nice if customers could get feedback when then send data. Something that indicates that the bug has already been found or Microsoft could send them an e-mail when an update to the application that crashed fixes the bug. It's important that the customer feel attended to.

Jeff Prosise: Who was it that said 'the more things change, the more they stay the same'? The big issue today (and tomorrow) is security — especially Web security. It's easy to hack into a lot of prominent Web sites. Many developers have only recently moved into the Web programming space, and platforms such as ASP.NET are lowering the bar and attracting even more developers.

Trouble is, a single unchecked text input field in a Web form can serve as an entry point for all sorts of debilitating attacks, allowing unscrupulous people to compromise and corrupt back-end databases, steal administrator passwords, and take over other machines on the network. Many developers don't realize this. Every day, new Web apps are deployed that are eminently hackable. Publishing a Web page written by a person (or team) who is unaware of the dangers can literally put your company's entire IT infrastructure at risk.

John: Another "have to address" issue is server development. Many of the developers that are now running when wizards to deploy ASP.NET applications have only done straight client applications. They are not familiar at all with concurrency, server performance, or scalability. The applications these developers deploy work fine for small data sets, but the instant they have to move to even a medium sized set they fall over.

DevSource: What's going to be the most mis- or not-understood feature in the next version of Visual Studio and .NET?

John: Based on the number of people clamoring to write about Visual Studio .NET 2005, I wonder if there will be any. My guess is that it will be the usual story of the average developer not taking the time to know their tools so they will be missing much of the real power and capabilities of the editing and debugging environment.

Jeff Prosise: In ASP.NET, that would have to be the client callback manager (CCM). The CCM permits Web pages to make lightweight XML-HTTP callbacks to Web servers, and it presents all sort of interesting possibilities for making Web apps faster, more responsive, and more efficient. However, I suspect that it isn't going to be documented very well, and that a lot of otherwise savvy ASP.NET developers won't even realize that it exists.

Jeffrey Richter: I think some of the new features in C# 2.0 will raise some eyebrows. First, iterators is an easy way to write code that returns elements within a collection. While, with C# 2.0, it is really easy to write this code now, one should avoid doing so. Using iterators in an application causes objects to be created on the heap and requires 2 methods be called for each item. This is very bad performance-wise. I'm surprised the C# team added this feature when, in my opinion, it should not be used.

C# 2.0 also adds anonymous methods. This is the ability to pass code as a method's parameter. Looking at code written using this feature definitely takes some getting used to and writing code that uses this feature takes even more getting used to. It definitely needs to be used with care. I have a person rule: I will only use an anonymous method if I pass 3 lines of code or less.

DevSource: What's the oldest development tool installed on your hard drive?

Jeffrey Richter: I have a GUI WinTouch.exe utility that I use periodically to update the timestamps of files. I wrote this utility myself, and published it in my Windows 95: A Developer's Guide book which came out in 1995.

John: A quick check showed that MASM6 is still there. You never know when you'll need to drop to assembler from VB.NET.

Jeff Prosise: Visual C++ 6.0. Although I do keep an old copy of MASM (the Microsoft Macro Assembler) around — just in case. :-)

DevSource: What was the last app you wrote for your own pleasure (i.e. not for someone else or for a deadline)?

Jeff Prosise: An ASP.NET app for cataloging my comic book collection.

Jeffrey Richter: I have this little application, called PushPin.exe. It starts up when I boot my machine and it stays running all the time. It has become a dumping group for features I wish Windows had built-in. PushPin allows me to set any window to "always on top;" this is useful when teaching because I can make the application's window on top of the debugger as I step through the code. PushPin also lets me set any window's opacity so that I can see some of the window behind it.

PushPin also remembers my desktop icon positions and whenever I change screen resolution, it restores the icons back to my desired location. This is really useful when lowering resolution when I connect to a projector or when I use Remote Desktop or when I rotate my Tablet PC's screen 90 degrees. PushPin also looks for certain windows popping up on the screen and when they do it fills in various controls and presses enter. I added this feature because I got sick and tired of Yes, No, or Cancel every time for certain dialog boxes. I've had many friends and colleagues ask me for a copy of PushPin over the years. It probably has a customer base of about 30 people by now.

John: There have been two. Toggling Bluetooth on and off on my Windows SmartPhone is far too many keystrokes, so I wrote a small app to do that. The other application was a Windows Client that cleared out all the items in my Internet Explorer cache, temporary files, and recycle Bin. I did that to speed up my network backups — and it's just fun to write code.

DevSource: If you had time to learn something completely new, what would it be? Why?

Jeffrey Richter: Oh my gosh! I can think of so many things to say here. I wish I knew more about computer hardware and how it worked. It's just amazing to me to think that there are electrons making all this stuff happen. If we broaden the question beyond computers, then I'd like to learn more about the law. I've often thought that I'd be a lawyer if computers didn't pan out. I'd like to learn more about aerodynamics too. I have an airplane and a helicopter license and I wish I had more time to spend flying and learning how these machine work. Understanding more about the space station would also be interesting to me.

Jeff Prosise: How to program a Mac. I've always been curious about the Mac programming model, and once, in the mid-1980s, considered diving into it. Problem was, at that time, it was hard to make a living as a freelance Mac programmer. Maybe it still is — I don't know.

John: Probably Macintosh development. OS X is fantastic on my PowerBook and the great iLife applications make digital photography more fun than I ever imagined. I think of would be a blast to work on add-on tools for iLife.

Some people may be surprised that a heavy Windows guy would say OS X, or even use it. To me, computers and operating systems are not religious or political statements. They are simply tools that I use to help our clients and help our employees pay for their kid's college education. If we could see a great opportunity to grow the company and have fun using OS X, Linux, or punch card based OS-360, we'd do it.