For those of you who didn't get the memo, Ron Jacobs is no longer hosting the very popular Channel 9 show, ARCast. After spending a couple of years traveling the world talking to hundreds of practicing architects, Ron decided he needed a change and is now a Technical Evangelist in Redmond working with the WCF and WF teams.

Because of the popularity of ARCast worldwide, I and a small team of fellow architects from across the country have been working over the past several months to bring into being what we're calling, "ARCast 2.0." Instead of having one regular host on the show, any architect evangelist in the world that has a story to tell and is willing to sit down and record it can be the host of an ARCast episode.

We published the first official episode of ARCast 2.0 last week. My colleague and good friend Bob Familiar sat down with Simon Guest, Senior Director of the Platform Architecture Team at Microsoft, and had a great conversation about what his team does and what types of content and activities his team will have for the community in the future. If you haven't had a chance to watch the interview yet, you can watch it here.

And this week it's my turn.

A few weeks ago at TechEd Developer 2008, I had an opportunity to sit down in the TechEd Online "fishbowl" and have a conversation with Juval Lowy about his ideas concerning interface-based design in software. Any conversation that starts with, "Object-orientation has completely failed us," is going to be a good one.

You can watch the full ARCast video here:

ARCast.tv - Juval Lowy on Interface Based Design

If you never want to miss an episode of ARCast, then be sure to subscribe to the show's feed here. Please let me know what you think of the interview.

Code reviews should be built into every project timeline. What I find most of the time is that they are overlooked, excluded in lieu of functional testing only, or worst of all, performed by the wrong person. This is shame because a code review can significantly enhance a team's chance of delivering a quality piece of software that the customer will actually use.

There are several ways of conducting an effective code review, some very laize faire and some very hands-on. The key is combining the power of review tools with an architect's personal and professional experience to yield the most effective review possible without taking inordinate amounts of time away from the project itself.

The following are three tips I'd like to offer to help you get the most out of your code reviews.

1. Do Reviews Early, Do Reviews Often
The first three weeks of a project are the most crucial. It is during this early time that the foundational parts of the application are being developed. This will be the first and best opportunity for issues in this vital part of your application to be identified and fixed inexpensively. Every day that goes by without identifying a critical defect in the code will cost you exponentially down the road in lost time and money.

The first key to a successful code review is to start reviewing the first day of the project. Look at code written by all the members of the development team and make sure that they are heading in the right direction. Some important things to look for in these early reviews include:

• Are they correctly implementing classes, interfaces and layers per the system design?
• Are they leveraging any reusable utility components in your organization?
• Are they using established naming conventions, either industry or organization specific?
• Are they implementing proper exception handling, i.e. not swallowing exceptions?
• Are they properly closing database connections, streams, etc.?
• Is there any redundant code that can be consolidated?
• Are they properly addressing tier requirements for the system?

With a focus on these specific items, I recommend that you do daily code reviews for the first three weeks of the project, providing feedback to the team the same day. By identifying these fundamental structural issues before thousands of more lines of code are written on top of them allow your team to address them while they are still easy and inexpensive to fix.

This process also provides the architect a great opportunity to mentor your development team. Looking at their code will be a great indicator of how experienced they are and sharing your feedback will help make them better developers down the road.

After the first three weeks of the project, you should be able to back off the daily code reviews and start doing them every couple of days instead. By this time, your team should have firm expectations what they need to do and solid direction going forward. Ideally, within a month, you should be able to move to weekly reviews with minimal risk of missing something important. Of course, every project and development team is different, so use your best judgement as to the effectiveness this approach offers at the start of each new project.

2. Tools: Trust, but Verify
Any software vendor that you talk to will tell you that their static analysis tools will catch most of the bad stuff in your code, and the only ones you should be considering should allow you customize the rules that the tool applies in its analysis.

However, analysis tools are just like any other piece of software: They're limited by the number and quality of rules provided them to do their job. Most static analysis tools I've worked with in my career provide good starting points for a more in-depth, manual review.

Think about a code analysis tool like Cliff's Notes. Cliff's Notes were meant to be a study assistant while reading a particular book, not a replacement for the book itself. However, ask any group of high school English students and I'm sure you find them enjoying the Cliff's Notes for Huckleberry Finn without a copy of the novel anywhere in site. While this will give you a high level overview of the plot and the major themes, nothing can replace the level of detail you'll only get from reading the book itself.

Also, Cliff's Notes are not always correct. I remember using Cliff's in college for some 18th century British novel I was struggling to get through (I wish I could remember wish -- it was dry as hell). I got through the novel, but depended almost solely on the Cliff's Notes to arm me with the information I needed to discuss it in class. As it turns out, we were using an alternative version of the original text and I was missing several details which made me look like an idiot in front of my classmates.

If anyone out there used FxCop before it was (arguably) improved and integrated into Visual Studio Team System, you know that tools can't always be trusted to return an accurate representation of reality. I once wrote a "Hello World" console application in C# and FxCop told me I had over 1,200 defects in my code.

The point of this is to use code analysis tools as a means of "sniffing" your code for potential problems. Look at them as sign posts to something you should investigate further. Sadly, I don't think we'll ever see a tool that will deliver the same, high-quality results as actual human eyeballs on the source code. "Trust" that the tool is pointing you in the right direction, but "verify" that there is really some fire to go with that smoke.

3. Actually Read the Code
Building on the previous section, nothing can replace actually looking at source code. This is definitely time consuming, but will yield the best results. While code analysis tools will catch naming convention violations and orphan variables, actually looking at the code will provide you the context of those issues, especially in the structural integrity of the application as a whole.

The other benefit is that it gives you more visibility to what your developers know how to do. In my first bibliography class as an undergraduate, I was fascinated to learn that literary scientists had been able to identify individual typesetters of Shakespeare's first folio by the grammatical and spelling errors they made setting type on the printing press. The same principle can be applied to reviewing developers' code. It will help you identify strengths and weakness in individuals' coding and allow you act accordingly.

Reading raw code isn't necessarily to most exciting or desirable work in the world. In fact, it can be downright tedious and tiring. However, it is the most sure way to make sure that your project is proceeding the way it should be in development, so budget time to sit and just read and understand the code being written for your project. If you do, I can guarantee you'll reap the benefits later.

Just Do It
Hopefully you'll find these tips useful in getting better quality results from your development projects. I absolutely recommend trying these techniques out on your next project, but also encourage you to try them out on your current project, even if it is well underway. You may not get all the benefits, especially from the early and often reviews, but doing some level of review is better than doing none at all.

I welcome your input, experiences and additional best practices. Please leave a comment if you have something to add to the conversation.

While there is still a lot of conversation going on about what it means to be a software architect, there are a few things that are true among all of us who wear the title "Architect":

• Architects are thought leaders, pushing the envelope on what's possible
• Architects provide the vision, guidance and experience that enable others to make that vision a reality
• Architects need to understand the technical and the business (practical) side of any project to provide the best proposed solution

Now, watch the following Monty Python "Architect Sketch" with these points in mind. It's not only entertaining (one of my very favorites from the Python troupe), but required viewing for anyone who purports to have a sense of humor:

Monty Python's "Architect Sketch"

Though John Cleese and Eric Idle are pitching "a block of flats," there are certainly many things that should resonate and seem familiar to those of us working in the software industry today.

Understanding the Project Requirements
This is one of the most obvious and most missed parts of working as an architect. There are several reasons for this:

• The architect doesn't understand what the customer wants, but doesn't know it
• The customer doesn't know what he/she wants, but doesn't know it
• The architect makes certain assumptions about the customer's intent, goals and technical maturity
• The customer makes certain assumptions about the architect's experience and level of knowledge
• The customer and the architect don't ask questions or challenge ideas for fear of looking unknowledgeable

Any one of these common situations can send a project off the rails before it even gets started, and usually there are two or three in play at the same time.

As architects, we need to understand the business drivers of the project in order to present the "right" solution to the customer. There's an old joke that says, "The only answer an architect needs to any question is, 'It depends.'" Well, to a certain degree, that's true. There are always going to be many different ways to solve a problem. Our job is to understand our customers' motivations by asking pointed questions and challenging them on things that don't seem to make sense, thereby enabling us to provide the best solution to meet their needs and avoid pitching an abattoir when a block of flats is what the customer really wants.

In addition, the architect needs to be self aware and not push a customer into a solution because he/she is afraid to admit they've missed something during the discovery phase of the project. I've never heard tell of someone being removed from a project because he/she was honest and said, "I must have misunderstood what you were looking for here -- let me work on an alternative solution," at the beginning of the project. I can imagine it would be very easy to get thrown off a team for spending several weeks developing only then to find out that the solution you convinced your customer was the "right" one is not going to get them what they need.

Thought leadership becomes a reality by taking your collective experience, diving deep into the customer's needs by asking the right questions and challenging the ideas that don't make sense and by listening as much as you talk. Self-criticality and honesty build trust and credibility.

Compromising the "Right" Solution
No one who has worked on even one project in their careers is unfamiliar with the multitude of external forces that can negatively impact a project's outcome. The customer wants the most business value from a piece of software for the least amount of money. Developers don't tend to care about cost as much as putting together solid code that works.

In the middle sits the architect.

It's not unusual for a customer to look to cut corners to save money on a project, especially if there isn't a real, tangible ROI attached to the final product. As an architect, we need to make sure we communicate the probable consequences of these cuts and make sure that we adjust the technical roadmap as a result. The fact is that the customer is not always right, and we need to make sure that they have all the facts about a decision before they make it.

At the end of the day, the customer is one paying for the project and we need to attentively listen to their ideas, but we must not passively let the make erroneous decisions. Our passion for building solid, secure and performant solutions has to be asserted in a way that serves our customer's best interests. This sometimes means pushing back on cutting corners, especially if they involve a "central pillar system," "recessed magnilium phalange groups" or "fire suppressant materials," i.e scalability, performance and security.

Politics and Technological Religion
It's been said that if you put more more than two people in a room together, politics becomes part of the decision making process. OK, I've always said that, but it seems too obvious for someone else to not have said it already -- I just don't know who.

Political struggles within companies are right up there with death and taxes on the "Things You'll Eventually Have to Deal With" list. More times than not, politics drives the decisions made concerning technology, the one area where it should be easy to purge political influence. I say that because it is very easy to quantify technical decisions. You can easily apply hard numbers to:

• Development resources required to deliver the solution
• Cost of new software and hardware to support the proposed solution
• Cost to integrate the new system with existing systems
• Cost of training to ramp developers' skill sets
• Projected cost of maintaining the solution over its life span

All this being said, I still see decisions made all the time based on political and technologically "religious" grounds instead of hard-core numbers. I was once talking to an architect who was working on performance problems with a JSP-based line-of-business application. He had the idea to build a WinForm application with .NET and see if he could improve on the 57 seconds it was taking for the JSP page to render a grid of data from a local database.

He got it down to 2 1/2 seconds.

When he presented the solution "bake off" to his management team, the conversation went a little bit like this:

Management: "How many records could be returned in the web app so that it would match the performance of the client-side 'test' you wrote?"
Architect: "About 250."
Management: "OK, change the web app so it only returns 250 records."

Clearly, politics and technological religion are so prevalent in that organization, management is willing to dramatically alter user requirements to stay on one technological stack and avoid the other completely, regardless of the hard facts in front of them.

As architects, we need to be aware of the these forces at work all around us. Ultimately, we have to consider the existing technology landscape within an organization and weigh the potential advantages and disadvantages of our proposed solution. As much as possible, we need to consider ourselves "technology agnostic" and truly consider what is the "right" architectural approach to meet the customer's needs.

Put simply, the architect should expect to deal with politics, but not participate in them.

"Free Masonry Opens Doors"
In the end game, being an effective architect is about integrity as much as it is technical skill. I've known many people over the course of my career that were my technical superior, but always struggled to fill the role of the architect on projects, due primarily to their overly focusing on implementation details.

Success is largely dependant on being able to take a macroscopic view of the project and the overall ecosystem in which it will need to fit. Having a detailed understanding of the requirements, being your customer's biggest advocate (sometimes in spite of their best efforts) and distancing yourself as much as possible from internal politics and technological "religious wars" will go a long way to letting you apply your technical expertise and be a successful architect.

Then you'll learn the secret handshake.

Industry thought-leader David Chappell will be visiting four cities in the central part of the country throughout the month of May to present Undestanding Software + Services: A Perspective. David's talk will provide a clear explanation of what an S+S approach to architecture really looks like, an overview of building software with hosted "services in the cloud," as well as the tools and guidance Microsoft is providing to help development teams be successful in developing S+S oriented solutions.

David will be speaking from 1:00 PM to 4:00 PM in the following cities on the following dates:

David is Principal of Chappell & Associates in San Francisco, California. David has been the keynote speaker for dozens of conferences and events in the U.S., Europe, Asia, Latin America, and Australia. His popular seminars have been attended by tens of thousands of developers, architects, and decision makers in forty countries. David’s books have been translated into ten languages and used regularly in courses at MIT, ETH Zurich, and many other universities. In his consulting practice, he has helped clients such as Hewlett-Packard, IBM, Microsoft, Stanford University, and Target Corporation adopt new technologies, market new products, train their sales staffs, and create business plans.

I am coordinating David's tour through this part of the country. If you have any questions about the event or have any problems registering, please drop me an email or leave me a comment below.

If you've never seen David Chappell speak, you won't want to miss this opportunity to see one of great luminaries in the industry talk about one of the most exciting topics in software architecture today.