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!

Weekends are for fun and relaxation. As I was pulling up some music to listen to via my Xbox 360 last Saturday morning, it occurred to me that I've been running Windows Home Server for quite awhile now. In fact, last Saturday was the 100th day I'd had Home Server running on my home network. So I thought I'd share some of the ups and downs I've had over that time with Home Server.

What I Dig

Hardware Requirements: I have a decent PC that I build about four years ago in my home office. By "decent" I mean that it is adequate for accessing and storing data, being a print server and some gaming. Very solids, but nothing spectacular, but let's face it, it's freaking four years old.

The basic specs are:

• P4 2.4 GHz
• 512 MB SD RAM
• Basic, non-brand name 64MB display card

I had a 20 GB hard drive already installed serving as the system partition and I bought and installed a 220 GB ATA drive (yeah, the system board is too old for SATA) for content. And that's it. Pretty basic.

The OS absolutely screams on this hardware. As it is mainly managing content and backups on your home network, Home Server doesn't need a lot of horsepower to provide reasonable performance. I know that several PC vendors are selling preconfigured machines for Home Server, which is cool, but you can just as easily build yourself a machine for very little money and get comparable performance. Just be sure to get yourself a big and fast drive for storing content. Disc space is cheap and you'll be glad you have the extra room once you start doing backups of the other machines on your network.

Reliability: Home Server just runs and runs and runs. I've only had to shut it down a couple of times and that was because I was heading out of town for a week or so with the family and I usually power everything down if it's not going to be used for an extended period of time. As it's built on top of Windows 2003 Server, the reliability isn't surprising, but welcome just the same.

Remote Management Console: Home Server comes with a client-side application that does a few things. For one, it registers your machine with the Home Server automatically, facilitating automated back-ups primarily. It also provides you with a handy management console application that will let you manage the machines on your home network, configure automated back-ups, setup and manage user accounts on the Home Server, configure shared directories for music, videos, etc. and check the current status of your server drives and your network as a whole.

While those of us who work with servers all the time could do this any number of ways. One of the risks of creating a home server is that non-technical consumers who still struggle to print Word 2007 documents with the new tool ribbon will be completely lost when it comes to server configuration. The Home Server management console makes this very easy and, for those of us who could manage it from the command line, it provides a very efficient means of making necessary changes and then getting out, all without having to log directly into the console. Nice!

What's more, you can configure Home Server to be accessible from outside your home network as well, providing you with access to your files and data ever when you're away from home. Nice nice!

What I Don't Dig So Much

No Support Media Center Extender: This just made me sad. As Media Center ships standard with Vista Home and up now, it seems like bundling some flavor of the Media Center management interface into Home Server would have been a no-brainer. But alas, it is no where to be found. It is easy enough to connect my Xbox to the shared content directories on the Home Server, but I have really come to like the Media Center user interface as it appears in Vista. It was so simple, my six-year-old could cycle through available movies and pick something out. Now I have to do it for her because the files names can be a little cryptic to someone her age.

I guess I'm not looking for full-blown Media Center on Home Server, just the ability for other Media Center PCs and devices to interact with it like Media Center. Is that so much to ask? Honestly, this is my only complaint, but it's a significant one.

Better Off Than a Hundred Days Ago?

My hope when I installed Home Server was that I would get all the benefits I'd come to enjoy from Media Center with the added bonuses of network and backup management in Home Server. As it turns out, the latter set of features are what I've benefited from the most. What would make Home Server a grand slam instead of a double would be to provide me with the means of not only storing my media files, but to manage and access them much the way Media Center does. If this were there, I'd be hard pressed to think of anything else you'd have to do to this product to make it better.

The International Organization for Standardization, or ISO (yeah, I can't figure out that acronym either), posted a press release on their web site Tuesday  announcing that ISO/IES DIS 29500, or Office Open XML, received well more than the minimum number of votes by the international community to become an official ISO standard. While ISO has not officially approved Open XML as an international standard, it received 86% approval, well above the 66.6% needed for approval.

Open XML may very well be one of the most significant recent technical standards that you haven't heard much about. For a starter course with links out to important resources, check out this post I did a couple of weeks ago on this very subject.

The official Microsoft statement on the ratification comes from Tom Robertson, General Manager of Interoperability and Standards:

With 86 percent of voting national bodies supporting ratification, there is overwhelming support for Open XML. This outcome is a clear win for customers, technology providers and governments that want to choose the format that best meets their needs and have a voice in the evolution of this widely adopted standard. The input from the technical experts, customers and governments around the world has greatly improved the Open XML specification and will make it even more useful to developers and customers. Once it is formally approved, we are committed to supporting this specification in our products, and we will continue to work with standards bodies, governments and the industry to promote greater interoperability and innovation.

Open XML has been an open standard for years. In fact, a slew of software vendors already support it their products. These products include Microsoft Office (2007, 2003, XP, 2000), OpenOffice Novel Edition, Gnumeric, Neo-Office 2.1, WordPerfect 2007 and the PalmOS.

This ratification is important to developers and architects worldwide. The standardization of word processing, spreadsheet and presentation documents will:

1. Provides customers with much more choice -- they can make software purchasing solutions based not on existing file formats, but which office productivity software has the best features for the best price.
2. Allow developers can create applications on the desktop, the server and mobile devices that generate documents that they know, with confidence, will be readily consumed by their information workers' software.

In very much the same way we look to standards-based technologies like web services to allow us to interoperate between systems built to run on different platforms, developers and architects must begin to think the same way about business documents. Adoption of Open XML allows technology providers to focus on building the best software solution possible without having to worry about the formatting minutia of multiple different consuming applications.

And how can that be a bad thing?

At both the Kansas City and Minneapolis Windows Server/Visual Studio/SQL Server product launches, I've presented a breakout session called Creating Instantly Recognizable Application with the Microsoft Office System. It has given me a really good opportunity to dig into developing custom applications in the Office client applications as well as customizing SharePoint Server and, ultimately, tying the two systems together to create a true "software plus service" solution. I have to say, this stuff absolutely rocks!

One thing I've learned in the past several weeks is that is has never been easier to develop, test and deploy MOSS applications. There are several reasons for this:

• Visual Studio Tools for Office (VSTO) is integrated into Visual Studio 2008 and offers a very rich set of project types for all the Office products
• VSTO provides a SharePoint workflow project type -- this is the same as a typical Workflow Foundation project (SharePoint uses WF as its workflow engine) except that it has all the SharePoint specific hooks built in that allows for one-click deployment and debugging
• For Office 2007 applications, VSTO now provides a visual design tool for ribbon add-in applications
• The developer experience for building Office Business Applications (OBAs) is exactly the same as building any other WinForm or ASP.NET application in Visual Studio

If you've developed an application in Visual Studio before, you can have an OBA application up and running in virtually no time. If you want to get some hands-on experience from the professionals, I'm glad to let you know that there will be a MOSS Camp in St. Louis this coming Saturday, April 5th. To get all the details, including the topics for the day, check out the announcement post on Clint Edmonson's web site. This is a community driven event being given my the St. Louis SharePoint User Group.