Juval Löwy is a Microsoft "Software Legend" and RD, and architect for IDesign, a consulting and architectural services company. In an exclusive interview with .NET Developer's Journal editor-in-chief Derek Ferguson, Löwy discusses the need for an inherently extensible architecture, the importance of a commitment to quality, and the bright future of .NET.

-Interviewed by Derek Ferguson, editor-in-chief of .NETDJ

.NETDJ: Juval, I know that you are a Microsoft RD - what does that mean?
JL: An RD is a Regional Director. I don't work for Microsoft, I work with Microsoft. Specifically, I am RD for Silicon Valley, which means that I keep Microsoft educated about the industry, the industry educated about Microsoft, and even sometimes Microsoft educated about Microsoft.

One way I do this is by participating in the strategic design review sessions for future generations of .NET. I also do this through a different channel by sitting on the .NET advisory council, which is a collection of customers that Microsoft consults to find out what people think about the direction of .NET.

.NETDJ: What about your interactions with the general public?
JL: In terms of my interaction with the public, my most recent book - Programming .NET Components - was published by O'Reilly in April, and I have also published numerous articles. I was one of the founders of Bay.NET, the Silicon Valley .NET user group, and I am responsible for the monthly program. I speak at major developer conferences and I've been recognized by Microsoft as one of its "Software Legends," a title reserved for the top 10 or so experts in Microsoft technology.

.NETDJ: What do you do for a day job?
JL: I was previously corporate architect for a large company. Now I am the principal architect and president of IDesign.

.NETDJ: What does IDesign do?
JL: We provide high-end consulting and architectural services to client companies. Typically we consult on architecture for two days to a week, and also conduct some very intense training, including advanced topics.

.NETDJ: Your involvement in training is interesting - is that primarily focused on ensuring that the systems are properly maintained?
JL: Well, besides technology (which we cover in the training), there are really two key factors involved in maintainability: commitment to quality and getting a good architect. A manager has to understand that you have to perform all the right steps: gathering the requirements, top-level design, design reviews, code reviews, testing, installation, and documentation. If a manager doesn't understand that you need to do all of those things - if the management mentality is just "code like hell" - nothing is going to help.

.NETDJ: When you say "commitment to quality" - what does "quality" really mean?
JL: Quality is creating the most productive code you can. Because if you don't spend time debugging, then you spend more time adding features and you are much more productive. Quality means no defects - your components should be rock solid. If your atoms themselves are not stable, then because of the complexity at the system level, you will never be able to debug the system.

.NETDJ: What do you see as the number one obstacle to high quality, besides not having rock-solid components?
JL: If we assume that you compose applications according to requirements, then faulty requirements require faulty behavior. I believe that 85% of all defects in mature organizations can be traced to defects in the requirements.

Of course, that's the kind of thing where a good architect can help minimize the effect of faulty requirements by designing extensible systems.

.NETDJ: How much of a demand do you see, then, for great architects?
JL: Well, it is impossible for most organizations to hire a great architect. Only 1 in 10 good developers (meaning 1 in 100 of all developers) is even capable of being an architect. Architects in most companies are perceived as just super-smart developers, so no one is paying three times the developer rate for architects. With today's short budgets what we've found companies are doing (or trying to do) is saying "we can't keep chasing our tails to try to master every new technology or methodology. Instead we have a core competency - we have some domain knowledge that no one else has. This is what we'll focus on."

Now traditionally, you spend 5% of your time programming product features and everything else is programming the infrastructure, the glue, the plumbing, issues such as threading, remote calls, security - that's where if you make a mistake, you're doomed. Smart organizations recognize they need world-class architects, but they can't hire them. For one thing, they don't know where they are and for another, they can't pay them what they deserve, or retain them as architects, resisting the temptation to use them as developers once the design is over. So, instead, they are deciding to have their own small teams that understand the problem inside and out, and just getting somebody to come in and help with the architecture once every few years.

.NETDJ: What makes a world-class architect?
JL: One thing is having critical thinking skills. Another is the ability to abstract. Finally, very important is the ability to understand priorities. You have to really understand the core - a good architect may not even care what the product actually does - the ability to abstract beyond the specifics of the current product is important.

The main reason for this is that we're seeing a shift in software life cycles in the industry. In the early '90s, everyone was trying to do waterfall development, ending with a complete product. It turns out that this model doesn't work too well in today's environment; it assumes that you know everything up front. It also assumes that the requirements are fixed and you understand the requirements.

Today, it is sometimes better to ship something first than to wait for your competitors to put you out of business. In addition, the rate of change of technology is accelerating; I wrote an article that suggested that the length of a technology generation (DOS to Windows, Windows to .NET, etc.) is about 6-7 years today, as opposed to 10-12 years a decade ago. Developers are constantly not good at what they do, because they need to keep relearning.

So, to get around this, you want to come up with an architecture that is inherently extensibleScomposed of a set of interacting components. The system can be extended by combining the components differently or by adding new components. You focus on creating the right set of building blocks, and then you just add new features as you go along. It requires a great deal of abstraction because the individual components by themselves cannot be mapped directly to features, and are often general-purpose components that could be used in other products. The product is basically just a model for how to put the components together.

It's really a lot like Agile Development.

.NETDJ: Does that mean that Extreme Programming (XP) is best for creating .NET systems?
JL: Pick the process that works for you! If you are doing .NET, you should really be using something component oriented, though. XP is for priests, not the real world. Most developers and organizations can't apply everything that XP says you must do. The Component-Oriented Development process is my choice.

.NETDJ: What's that?
JL: It is a process that I defined myself, actually. The basic premise is that because you're using components, this affects every key process area. If you have multiple developers creating infrastructure, for example, how do you track progress and quality? How do you do version management? I took every key area and adjusted it to the fact that you are using components. I invested enough time to come up with a unique model for this, which I have applied successfully myself, and which I help my customers adopt.

.NETDJ: Getting back to what makes a world-class architect, are technical skills or people skills more important for an architect?
JL: Being an architect requires having good technical skills and good personal skills. You have to understand the requirements and then be able to sell them to management and developers. For example, if the board asks you "Is your proposal the best architecture?", then you have to be a bit of a salesman to convince them that your plan is definitely the best - even though there may be other possibilities out there that you don't know about.

This requires being a bit of an extrovert, really. I mean, when you present a design to management and other developers, you are kind of standing naked in front of them - your design is very much an expression of your own personality and thinking. A good architect can not only do that, but will enjoy doing it! The best thing that can happen to an architect is to be told that he is wrong and then be given an opportunity to improve the design.

.NETDJ: When you talk about presenting a design to management and defending it, I'm thinking strictly in terms of really big projects. Is that correct?
JL: Well, what do you mean by "big projects" - code size or team size? Let's assume that the size of the team and the size of the code are analogous. I don't think that there should necessarily be a difference in the way that you architect your solution. I think that the real determining factor is the intended life cycle of your application. What are your plans for it? Is it something that you plan on maintaining for many years or is it something where you just need to be first to market, regardless? The bigger the size, the more likely it is that you are going to push maintainability, to get a longer return on the larger investment. Large applications tend to be written for a longer life span. Smaller applications tend to have more of a rapid application development life cycle.

.NETDJ: How does all of this tie in to .NET?
JL: .NET is a clean slate - Microsoft did a lot of soul-searching about the issues that developers are facing and they took the best of all worlds and combined them in a very consistent manner. When you have this level of maturity in a development platform, it's not a hodgepodge of organically evolved APIs - it's all very consistent. I like the fact that many of the things that I had to do manually in COM are taken care of for me in .NET.

.NETDJ: Does that make .NET the best choice for building enterprise applications?
JL: .NET gives you all of the tools you need to create great software - but it doesn't force you to use them. For example, it supports the separation of interfaces from implementation, but it doesn't enforce this.

COM, on the other hand, was all about interfaces. However, most developers have a hard time dealing with interfaces. So .NET really is the best all-around platform for letting programmers code at their appropriate levels of expertise. I call the CLR the "Common Skills Runtime"!

.NETDJ: Where do you see the greatest interest in .NET today?
JL: I see interest in .NET coming from anywhere people used to use the old Microsoft DNA technologies. Everywhere that this is currently in use, people are moving to .NET when they begin new projects.

.NETDJ: When do you think .NET will reach "critical mass" and everyone will be using it?
JL: .NET will reach critical mass whenever the economy turns the corner!

.NETDJ: Interesting! Do you think that the depressed tech economy has helped or hindered .NET's adoption, then?
JL: In general, it is much better to introduce a new technology in a down economy like this one. After all, who wants to change a wheel at 60 miles an hour? In a way, it has been a blessing in disguise, because everyone has been introduced to .NET during this period, when only a fraction are doing new projects. Now, when the economy picks up, everyone will be doing .NET!

.NETDJ: And do you think that Microsoft's new focus on "trustworthy computing" will be important to this?
JL: Microsoft's bad rap for security is unwarranted really - just look at the number of alerts. Linux gets far more of them than Windows nowadays.

If you want absolute security, turn off your machine! Security is a compromise between usability and security. A highly secure system is very difficult to use. Microsoft traditionally opted to make technologies usable by the layman. You didn't need years of training and a PhD in order to use them.

However, by making them very easy to use, it also made it possible for laymen to deploy systems that were insecure. Does this mean that Windows is insecure? No, it just means that Microsoft Windows is ubiquitous - and therefore a much larger target than competing systems. I can configure a Windows box so that it is the most secure box in the world. It's all a matter of understanding the issues.

.NETDJ: So what exactly is "good programming?"
JL: Good programming is whatever code gets the job done! You have to set your priorities. If your goal is to be first to market, then good programming is whatever gets the job done the quickest. But if you're designing a system to be maintained over a long time, you had better factor the interfaces really well.