"The Next Web." "The Next Generation Web."

What the hell is that, anyway? Just another buzzword? More "marketing techno-babble?"

I like to think of it as "Web 2.5." It ameliorates the technical innovations that drove the Web 2.0 movement and really takes them to the next level. If you consider the impact that AJAX has had on the way web applications are built, essentially making them behave more like desktop applications, next generation Web applications look and feel like desktop applications as well. In the Microsoft world, the technologies that are driving this evolution are Windows Presentation Foundation, Silverlight and the incredible advances in ASP.NET.

If you live in or near St. Louis, I encourage you to register for a great seminar we're going to be holding on Wednesday, June 11th at the Microsoft offices to talk about the next generation of the Web and how these technologies will play into it. You will take part in a technical exploration of the latest technologies Microsoft has to offer, and how you can take advantage of those technologies to provide a truly next-generation user experience in you Windows and web client applications. During the seminar, Mike Henderson from Pluralsight will guide you on a technical walkthrough of each technology, demonstrate the technologies' capabilities, and show the tools and techniques used to provide those capabilities.

Seating will be limited for this event, so I highly encourage you to register today if you would like to attend.

I try to avoid doing posts that simply announce upcoming events without providing some kind of value to the message. This is a blogging tip I got from my buddy Josh Holmes and it's really proven to work well.

But this time, I'm going to make an exception...

If you haven't heard already, Microsoft launched the Professional Developers Conference 2008 (PDC) web site. The conference will take place in Los Angeles from October 27th through October 30th. The registration site is now open and, if you possibly can, you should make every effort to attend this conference.

For those who aren't familiar with the PDC, this is not a conference that happens every year, like Microsoft TechEd that is taking place over the next couple of weeks in Orlando. The PDC only happens when Microsoft has something big coming that they want the development community to learn about.

What might you learn about at the PDC this year? Well, Ray Ozzie spent a lot of time at MIX last March talking about Software + Services and, not long after that, the Live Mesh CTP as released. S+S is surely going to be a big topic at PDC this year, but I'm also betting that we're going to see a lot great information about the future of the Windows Mobile platform, Silverlight and .NET as well.

If you're a senior developer, architect or technical decision maker responsible for helping determine the technical roadmap for your organization, you will want to be in Los Angeles this October for the conference. I'm definitely going to be there, and hope to see you there too.

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.

In a post yesterday, Eli Feldblum makes the assertion that Microsoft seems to prefer to use Flash over Silverlight. He argues this fact is obvious since most of the rich, interactive parts of Microsoft's public sites are using Flash. In fact, he even states that "the software giant seems to be not even trying" to move to Silverlight and goes on to say:

A quick check through Microsoft properties reveals that only the Microsoft Home Page  and the Microsoft Developer Network use Silverlight; MSN Video, Zune.net and the new WWTelescope all use Flash.

The idea that Microsoft isn't interested in using Silverlight on its sites is, of course, completely wrong. However, in Mr. Feldblum's defense, it could certainly seem that way if you make the assumption that any company, including Microsoft, could implement massive technical and creative changes across an incredibly wide swatch of high traffic sites like the ones cited above in a month or two.

I felt compelled to respond to Mr. Feldblum's post not necessarily to defend Microsoft, but because I have very similar conversations with people all the time about adopting new technology in general. There is a natural human reaction when something new and revolutionary is laid before them. They need to strike a balance between all the new possibilities this new technology offers with the tangible business value of replacing what they already have in place. In this case, the question is, "What do I gain from paying a development team to replace the considerable Flash presence on my sites with Silverlight?"

To assume that a project team with any company would simply throw out a project plan already in motion, ramp their developers and designers in a new technology and start over for the simple fact that there is a new way of accomplishing their goal is ridiculous. You wouldn't do that and I wouldn't do that, unless there was a real ROI as a result.

However, when I talk to people about adopting Silverlight, they always make the comment, "I already have so much Flash built into my web site, I don't know where to start with Silverlight." Well, the good news is you don't have to throw out the baby with the bath water. The fact of the matter is that you can begin to implement Silverlight where it makes sense in your web site without modifying or removing any of the Flash assets you already have in place. Silverlight will run just fine in a web page with Flash, so you can iteratively begin the process if implementing Silverlight and, if prudent, replacing Flash to take advantage of XAML, developer/designer collaboration, developing in managed code and all the other benefits Silverlight has to offer. No expensive and painful "big bang" replacement is necessary. Find a requirement for which Silverlight is a good fit and implement it. It's as simple as that.

The truth is, while the rest of the world would hold Microsoft to a higher standard than any other company, at the end of the day Microsoft works very much like the IT shops you probably work in. Each Microsoft product and web site has a team of developers and product managers that have a finite budget, timeline and resource pool in which to work. Believe me, if Silverlight could be deployed as a replacement to Flash across all Microsoft web sites next week, it would certainly make my job a hell of a lot easier, but that's not possible and difficult decisions have to be made in order to deliver a multitude of solutions currently underway on time and on budget.

I can all but guarantee you that there are roadmaps in place to adopt Silverlight across most or all of the Microsoft web assets. That adoption will be rolled-out in a manner that delivers value to the business and as it makes sense. You're seeing that adoption begin on Microsoft.com and MSDN, and should see it on more Microsoft sites in the coming months and years, a very timely example being the new Expression Suite web site, all built in Silverlight.

In fact, if you're still of the mindset that Microsoft isn't using Silverlight because they don't believe in it, it will probably interest you to know that NBC will be broadcasting all 17 days and 34 sports of the 2008 Summer Olympic Games this year, at total of 2,200 hours of streaming HD video with multiple views and control gadgets, all in Silverlight. For an early review, have a look at Adam Kinney's post.

Rather than shame Microsoft for not dropping everything else that they're working on to replace Flash with Silverlight, we should learn from their example of implementing Silverlight iteratively as it makes sense. That just good project management and good business.

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.

Late last year, I shot a podcast with a local developer/architect/IT manager named Tim Higgins. I was intrigued by a device he built called The Water Hobo. It's essentially a water cannon with a motion sensor that detects when people are cutting through his yard and it shoots a stream of water at them. What's more, the software that controls the motion detector and the actual firing of the weapon (including a setting called "The Holy Hand Grenade") was written in C# and hosted on a PC in Tim's garage. For all the social and technical details behind the invention of The Water Hobo, please have a look at the podcast. It's not only informative, but entertaining (hopefully).

Today, I got a note from Tim that he'd made a few updates to the Water Hobo recently. While I didn't have time to run out and run film on it, I thought I'd share the photos with you. If you watch the podcast, you see the cannon is clearly visible over the fence line. The Water Hobo III was obviously built for stealth and power:

Noooo, that's not a high-pressure, .NET controlled water cannon. It's just a harmless creeping vine on an innocent looking fence in just another suburban neighborhood.

During the podcast, Tim said he was looking to implement the ability to activate and fire The Water Hobo with his Xbox 360 using the XNA Studio. I haven't heard back as to whether or not this phase is complete, but I'll be sure to keep you up to date. If he has, please don't cut though Tim's yard!

Well done, Tim. Looking forward to the The Water Hobo IV!

And by the way, if you've built something interesting or just plain weird using .NET or some other Microsoft technology, please drop me an email or leave a comment below and let me know about it. I'd love to shoot an episode of Weird Code with you and show off your work!

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.

I got the following question several times after my presentation at the St. Louis Heroes Happen Here launch event yesterday:

"What utility were you using to zoom in on your code? That was freakin' cool!"

That utility is ZoomIt, and it is a free tool available on Microsoft's TechNet site. You can download it here.

To install ZoomIt, open the Zip file you downloaded and simply extract the file content to a directory somewhere on your computer. You can then add a shortcut for the executable file in your Startup folder so it fires up every time you start Windows, or, if you're like me and trying to limit how much background processes are running on your machine, just add the shortcut to your Quick Launch bar. That way, you can start it up any 'ol time you need it.

ZoomIt has a couple of other features as well, including the ability to draw and type text directly on your screen while zoomed. When you fire up the application for the first time, you'll be presented with a dialog box where you can set the keystroke preferences for activating these ZoomIt features and, of course, to turn ZoomIt off. Full directions for setting-up ZoomIt are on its main product page.

I discovered this tool for the first time at the launch event in Minneapolis back on April 1st. I delivered the "next web" demo during the keynote and ZoomIt really helped me show some of the code and especially the toolbar details in a hall that sat 3,000 people.

If you do a lot of presenting, you should definitely go grab ZoomIt and use it in your presentations. It really works and the price is right!

I finished up my speaking tour for the Heroes Happen Here product launch of Windows Server, Visual Studio and SQL Server 2008 about 25 minutes ago here in my home town of St. Louis. The audience was great. I hope you enjoyed the talk and thanks to you all for your attention and the great questions. I hope you enjoy the t-shirts!

I'm actually sitting in the front row at the launch as I write this watching Clint Edmonson talk about occasionally connected applications (OCAs) and the synch framework. As promised, you can download the deck that I showed you today here.

Also, just to make things easy, here are the links from my resource slide at the end of my presentation:

• Install of Visual Studio 2008 Trial Edition
• Visit the Office Developer Forum
• Visit the Office Developer Center
• Download the Evaluation Materials

As a follow-up to the gentleman who asked me a question about downloading Visual Studio Tools for Office (VSTO) and installing it in Visual Studio 2008, unfortunately, that isn't currently possible. I know everyone who attended the launch received a copy of VS2008 Standard which doesn't support VSTO at this time. Hopefully, you'll have access to the Professional version of VS2008 so you can try out some of the techniques we talked about this afternoon.

Again, please feel free to leave any questions in the comment section below or send me an email!