Category: Uncategorized

I've always been a proponent of right-sized process; that is, enough process to do the job, but no more than necessary. Though most development efforts fail on the side of too little process, it's reasonable to be nervous about too much process just for the sake of process. Fortunately, there's an effective minimum that's easy to implement. Read on and make sure you're doing at least the minimum to keep yourself on track.
Over the years, I've seen a surprising number of development efforts that put themselves at unreasonable risk of failure simply by skipping on some simple pieces of infrastructure. Often, this is done in the name of speeding development; as in, "if we skip this bit of process here, we can get this done faster." That makes sense in the same way that skipping an outline will help you get a research paper done more quickly.

In fact, the right amount of process or infrastructure is right because it helps you get the job done as quickly as possible. Some things, like source code control, save time by eliminating those catastrophes that inevitably crop up during the course of a development project. Others, like bug tracking, simply reduce overhead needed to keep track of what's going on. The items I've listed here have made a real difference in my teams' ability to deliver software over the years -- they should be considered minimum requirements if you're building software for internal or external clients.

Source Code Control. This should be pretty obvious, but it's staggering how much software development happens without source code control of any kind. If you're a one-man wrecking crew, you may be able to get away with burning a CD every day, but there are plenty of commercial-quality SCC systems out there that are free for single developers or non-profit development -- check them out. If you're part of a team, this is simply not optional. Pick a system and start using it.

Build Machine. Some may be surprised to see this show up on a list of "must-haves", but it's been a key for me over the years. Simply put, this innoculates you against "it works on my machine". By setting up a build machine that is connected to the team via your SCC system only, you guarantee that you have one and only one system configuration that produces your "official" builds.

Note that there's nothing here that says developers can't do builds on their local machines; on the contrary, that can help boost individual productivity. If your build system is able to handle this, that's fantastic. Under no circumstances, however, can you ever consider a build done anywhere other than your build machine to be considered "real".

A related but separate issue is build frequency. I'm a fan of daily builds, but I've used build machines for weekly or ad-hoc build schedules, and the concept is just as valid in these other settings, too.

Bug Tracking. This can be an excel spreadsheet if you're really compelled to go minimalist, but again, there are so many great options out there that don't cost a thing, that I think you'd be foolish not to set up a "real" system. Use it to track bugs, and be religious about it -- it it's not in the system, it never happened. Don't let this be an excuse to be abusive to customers who don't have access or knowledge to use the system; you may end up entering some bugs for them. Just be sure they're in the system.

You may find that you want to track feature requests, support incidents, or other to-do items in your bug tracking system. Once everyone's in there on a regular basis, this can make a lot of sense, and can take the place of "big process" for things like requirements management and help desk support. Go ahead and exceed the minimum if that makes sense.

Automated Testing. If there's an optional item on the list, this is it. There's often a fair bit of work involved in setting up effective automated testing, but once it's in place, it's a powerful tool. Find some small amount of unit testing to start with and give this a try. You should be able to see results quickly and convince yourself that futher work is worthwhile.

Good luck with these -- I'm sure you'll need to exceed these minimum guidelines for many projects, but if you ever stumble into one where you're not meeting these minimums, get them in place as quickly and as carefully as possible.

Ok - I've got a new theory to explain some of Microsoft's more inexplicable behavior. After all the anti-trust muckety-muck they've been through, they're a little gun-shy about taking over the world all at once, so they're hitting a few short flies to the infield to keep everyone off guard. That's my theory, anyway. It's the only thing I can come up with that would explain why they're not swooping in and simply scooping up market share with a big bucket.
There are three big areas where Microsoft is just whiffing right now, and I can't believe that this isn't abundantly obvious to them.

1. App server integration
2. Low-end development tools
3. Workflow / business rules

Ok, one at a time now. App server integration. I've remarked in the past that someone could make a big dent in the market by integrating .Net support into a recognized J2EE app server. Gotta be one that's already acknowledged in the market. We've got enough app servers out there already, after all. Build .Net support (via Mono) into an App server such that JNDI and app management work similarly no matter what the app was written in.

Speaking of Mono, for Pete's sake, get behind these guys, already. They've just released Mono 1.1.10, and they're starting on .Net 2.0 support. They're funded largely by Novell right now, and they're doing the best they can to keep up, but there obviously are some things falling by the wayside due to lack of funds / bandwidth (Novell had apparently told them they're not going to fund development of VB.Net support in Mono, for example).

So there's this group of developers sitting in the open-source camp growing a list of followers - throw 'em a bone. Make a public announcement endorsing the guys, and toss them a few bills. You kill two birds with one stone: Mono is going to attract developers who would otherwise be using Java or LAMP on a non-Microsoft platform, so you're eroding someone else's market share, plus you get to point to this great open-source showcase the next time someone starts griping that Microsoft is big and mean and closed and anti-competitive.

My final observation on this point is that I've personally experienced the horror of not being able to sell .Net as a development platform simply because it implies platform lock-in. I ended up having to architect in Java for a shrinkwrapped software product simply because I couldn't get over that point. At that time, Mono was very young, and even alternatives like Mainsoft were just beginning to surface. I don't know how many other people out there are falling victim to exactly the same circumstances that got me, but Microsoft could end all that by just coming out and endorsing / supporting something that offers the promise of open platform support. Compete on the basis that Windows is the best place to run your app -- not the only place it can run.

Next point: low-end development tools. First, when I say low-end, what I mean is low learning curve, not inferior. Microsoft once had a pretty broad spectrum of development tools in Visual C++ and Visual Basic. These tools essentially merged with the introduction of VS.Net. Granted, there are different languages to ease adoption from the various camps, but the biggest learning curve in .Net is the framework itself, and that's the same no matter what language you're writing in. The .Net framework in general, and C# in specific are widely acknowledged to be Microsoft's response to Java, and in general, I think that's a good thing. Hit the mark pretty well, if you ask me.

What's missing, though, is the tool support for everybody else. The original concept behind Visual Basic was to enable Windows development for the masses. Though "the masses" turned out to be a subset of developers, this was still an huge score for Microsoft. You've no doubt seen references to the VB developers who feel scorned an abandoned by Microsoft now that they're ending support for VB6. If you ask me, I think an awful lot of the real hurt those people are feeling is not over the death of VB6, but over the death of the original idea behind Visual Basic.

When a group of customers asks for something that appears not to make sense, you've got to look past the points on the surface to understand what's really irking them. In the case of the abandoned VB developers, the thing they really miss is the simplicity and elegance of early VB. There's a hole in Microsoft's product line, and it's not going to be filled merely by giving away VS.Net "Express" editions.

There's growing support for simplified platforms like Ruby-on-Rails -- largely among Java developers, but the appeal for any developer is obvious (here's an excellent example from the point of view of a J2EE developer). Development platform like ROR have the simplicity and productivity of early VB while offering the ability to run on open platforms -- important for an app you may want to host on someone else's server for $9 / month.

I covered the open platform point already, so I'll stick to the simplicity point here. Lots of people have tried to hit the sweet spot where business analyst meets developer. From the analyst side, we've (nominally) seen UML, which missed badly. We've also seen Microsoft try to extend office with Access and Frontpage and VBA with limited success. The original VB tried to his this spot from the development side, and the "express" products are targeted there right now.

Nice tries, all of them, but not quite enough. Current direction calls for Office to keep pounding away with tools like Infopath and Sharepoint, but we need more. There needs to be a real "less is more" product that knows what its limitations are and is ok with that. Maybe it can't be a whole other product, for fear of fragmenting the product lines too badly. Maybe it's something you insert into word doc or an excel sheet like you'd insert a table or a chart (insert new Application...).

All of this transitions nicely into my last point - workflow and business rules. I've already written about my initial reaction to Microsoft Workflow. By targeting Workflow squarely at developers, Microsoft is missing again that confluence of business users and IT groups. Yes, I know that this is just the beginning of a strategy that's supposed to play out as Vista and Office 12 are released. In the mean time, the business user is left wanting.

This will remain the case even after Office 12 if programming languages are the only way to express business rules. Business Rules Engine (BRE) products are poised for growth soon in the same way that Business Process Management (BPM) apps have grown over the last couple years. Among these BREs are products that can express business rules graphically - no coding required. Most of the BRE's out there lack the scope needed to effectively integrate into the enterprise out-of-the-box, making integrators essential to deployment.

If Microsoft could learn from some of these vendors (or possibly snap up one or three), I'd bet they could produce a fully Office-integrated application that a business person could use to produce solutions that were really enabled from front-office to back-office.

The good news for everyone who isn't Microsoft is that as long as they leave these holes unfilled, there's room for other vendors. The part I don't get is why nobody's seen the holes yet.

On occasion, I've had to do some real simple image editing to support technical documentation, design docs, powerpoints, and so on. Here's a technique I used to take a desktop-wide screen shot and highlight one window by fading the rest of the desktop to near-grayscale. You could use this same technique to highlight part of an application screen to draw the viewer's eyes to the part of the picture you want them to pay attention to.
(1) Take a screenshot. Alt-prntscrn works as well as anything else, IMO.

(2) Paste into an image editor. I use PhotoImpact, but virtualy anything should do. You could try Gimp or Paint.net (http://www.eecs.wsu.edu/paint.net/index.html) if you want something free.

(3) Make a copy of the image ("highlight").

(4) You should be able to find a "Hue / Saturation" control in whatever you're using. Use that to dial down the saturation to achieve the effect you want. This can be more subtle than going all the way to greyscale if you want.

(5) Take your "highlight" copy and select the window you want to highlight -- you may be able to use an "edge find" tool, though I seldom have good luck w/ this.

(6) Copy the highlight window and paste into the base that you dimmed earlier.

This should get you pretty close. I don't, btw, know of any tools that make this any more automatic than this, but this shouldn't take more than 1-2 mins per screen shot.

If you read Clash of the Titans on this site earlier, you saw my opinion that Microsoft and BEA should get to be closer friends. So I read with obvious interest the announcement that Microsoft and JBoss are forming an alliance.
The MS-JBoss partnership strikes most people as a headscratcher, but on deeper examination, it looks like a pretty shallow marketing deal. No great product innovations seem imminent here.

Watch for the type of integration I predicted before, though. It could come out of the JBoss partnership, or it could yet come from BEA. As I wrote earlier, an independent BEA or JBoss pushing .Net has a unique appeal that wouldn't be matched should Microsoft just snap up one of these vendors.

Nevertheless, every once in a while, you see people ask things like "Who will buy BEA?"

Ok, so no predictions have come true to the letter yet, but if you squint, you can see shapes coming into focus. Keep watching this space....

Last week, Microsoft unveiled Microsoft Workflow Foundation (Google 'microsoft workflow foundation' for lots of press coverage). This product had a chance to really change the landscape of BPM vendors, but it missed its mark.Looking at the press releases, screen shots, and Microsoft's own web page, you can see that MS Workflow bears a strong resemblance to lots of existing BPM products -- including Oracle's BPEL editor for Eclipse. This is a direct result of Microsoft's decision to build Workflow on top of Visual Studio. Microsoft is declaring that Workflow is the domain of the programmer, not the business user.

I understand the argument to do this; I just don't agree with it. It's too easy to fall into the trap of declaring business people incapable of designing and maintaining an integrated workflow. It would have been much harder to find a way to put this power in the hands of a business user, and still maintain the solid technical underpinnings that an enterprise IT department requires.

But that's what's needed.

Microsoft has left the door open. There will be BPM vendors that rush in to fill this hole -- at least until Microsoft realizes their mistake.

Simplicity is good. Simplicity is the source of understanding and effectiveness. Lack of simplicity drives misunderstanding and errors.

This shouldn’t be a big surprise to too many people, but I see lots of people forget about simplicity all the time. That’s really too bad, since there’s such a strong correlation between simplicity and success. Let’s look at some areas where simplicity pays off.

Simplicity in Communication

Speak clearly. Write clearly. Watch for fluffy words that sneak into your writing and obscure your ideas. This is very common advice, but too rarely followed. We’ve all seen the effects of overly complex communication: eyes glaze over, drool dribbles out of the corners of mouths, and ideas fall on deaf ears.

Everyone knows someone who speaks or writes much too verbosely. Entire paragraphs are used where a few words would do nicely. When you find yourself unwinding sentences to figure out where you missed a left turn, you’re a victim of unneeded complexity. When this happens to you, pay attention to your ability to keep up with a conversation and actually get anything out of it. It’s a ton more work as a listener, and when you do that to your listeners, you’re decreasing your effectiveness.

Simplicity in writing doesn’t mean lack of color or imagination. Color drives interest, and interest drives understanding. When you read something from an excellent writer, you’ll see both color and simplicity. Each word seems chosen to achieve a specific intent. It’s as if the writer has a limited budget, and is careful not to exhaust his supply, but in reality, the limited budget it the reader’s patience and attention.

Simplicity in Design

There’s a feeling I get when designing software. Designs often start out or pass through a complex period where things seem like they’ll probably work, but there’s a lot of “noise” in the design. It feels like the design is tough to communicate because it’s incredibly intricate or complicated.

On the other hand, sometimes a design is just dead-on. It’s right – there’s no other way of doing something that could possibly be more right. It’s boiled down to a perfect formula, and everything about it gets easier. It’s easy to understand, easy to talk about, easy to advance through development, easy to test, and easy to document.

I believe that almost all complex designs could somehow be refined to be simple. Often, this is hard work that takes a long time and requires intense analysis. Sometimes it’s not worth it. Marginal complexity doesn’t hurt too badly, so strive to simplify when you need to, and leave well enough alone when you don’t.

Simplicity in Coding

It’s a rare case when less code is worse than more code. Most developers have seen mind-bending recursive code that breaks this principle, but it’s uncommon. Far too often, we see page after page of spaghetti code that’s difficult to debug, maintain, and extend.

If you or any of your developers isn’t familiar with Steve McConnell’s Code Complete, I highly recommend you pick it up and give it a read. A recurring theme in this book is the need for deliberate intent in design and code. Each module, each subroutine, needs to have a purpose and a cohesion. This approach yields simple, efficient, maintainable code.

Refactoring is the process of deriving simplicity out of a pile of spaghetti. If you truly end up with simple code as a result, this is a good thing, but watch out for refactoring being used as a substitute for correct understanding and design up-front. It’s all too easy to dive straight into coding without really understanding what you’re building, and end up having to refactor a couple of times because there’s no design to support your work. Simplicity by design beats simplicity by refactoring ten times out of ten.

Simplicity in Marketing

Quick – what does your company do? If you can’t rattle off an elevator pitch without stopping to think about it first, you are suffering from lack of simplicity in Marketing. If you have a hard time communicating what you do, your customers will have a hard time understanding what you do, and that tends to be bad for business.

The concept of “sound bites” in marketing has a questionable stigma, but truth is that when you don’t have this sort of simplicity of message, you don’t have control over your product and your company. Be sure you can tell the difference between a short message and a meaningful message, though. Short is only good if it means something. Watch out for words like “quality”, “usability”, and “scalability” that are completely hollow unless they’re made specific.

Seek simplicity of understanding above all, and then express this with the fewest words possible.

Simplicity in Vision

Vision is a special form of Marketing. Vision is about imparting understanding of something that you usually can’t lay your hands on. Vision is about seeing a future that you can never quite attain, but will always strive for.

People talk about “shared vision” as if there was any other kind. In fact, a vision that can’t be effectively communicated to others is pretty close to a wasted effort. I’ve seen people ranting about how they’ve got a vision for something and it’s up to an audience to figure out what the vision is. Words fail me in expressing my distain for this position.

Vision, much like Marketing, is about leading a group of people to share a common way of thinking about something. This is tricky under the best circumstances, and damned near impossible if you can’t communicate your vision with clarity. The more complex the idea, the more likely someone will be to get it wrong.

Again, seek meaning, not just low word count. “World peace” doesn’t convey as much meaning as “no nuclear weapons anywhere on the face of the earth.” While Marketing is about driving understanding of something that exists, vision is about driving understanding of something intangible, so it’s more difficult to find meaning. Nevertheless, that’s what you have to do in order for vision to be worthwhile.

What to do when you lack simplicity

Many things aren’t, in fact, simple. Fear not, faithful student – half the battle here is just detecting lack of simplicity.

Knowing that something is complex – maybe even a little too complex – enables you to deal with this deterministically. You can deal with the complexity. You can plan for it. You can decide whether to expend effort to make the thing simple or whether to just let it be.

Knowing that there’s an area of complexity in something, allow for more effort whenever working with it. Communicating design, performing maintenance, and so on will take longer and be less reliable. If you have a complex message, you’ll probably have to repeat it a few times before it sinks in. If you don’t like this, simplify. If you can’t simplify, deal with it. In any event, don’t be surprised by the results, because I warned you.

Once you start paying attention to simplicity and complexity, you’ll find that you can predict and/or prevent a lot of problems. It’s definitely worth consideration if there’s a problem you can’t explain otherwise.

The power went out last night. Several times. In what should have been a fortunate stroke of luck, the outages began at 11:00pm, so I should have been able to just go to sleep and slumber the problem away in ignorance.

Instead, I had a couple of opportunities to observe some usability that wasn't too usable. Keep reading to see how we can learn some design lessons just by looking around.
The first design lesson was courtesy of our Electric Company. As soon as the power went out, my wife felt compelled to call them up and let them know that we were without power. I didn't have the heart to tell her that when the entire west side of town drops off the grid, it's gonna make a noise somewhere. She felt some satisfaction in calling to report the outage because she was Doing Something about the problem.

Lesson One:   Users want to feel in-control, even if they're not. They're driving - not the computer. If you're one of those people (like me) who can't stand riding in a car -- you've got to be driving -- then you understand this idea. Make sure your users feel that they're controlling the experience.

Ok, so my wife's on the phone with the Electric Company, and I can hear them gathering information. Name, address, address again (spelled), address again (spelled as it appears on our bill from them), name again... My wife glowered accusingly at me when I started laughing. It occurred to me that they might be trying to guard against someone fraudulently reporting a power outage , but I think the real issue was that they had a rigid process that wasn't able to absorb unexpected conditions. It would have been a whole lot more efficient to break protocol and get to the point: "Yeah, west side? Right - we've got it. Thanks for your help." Click. Meanwhile, the management center is lit up like a Christmas tree showing faults all over town and they're validating billing information.

Lesson Two:  Expect the unexpected. Sorry, that's a cliche, but it's true. S**t is gonna happen. Design enough flexibility into the system so that the people who are running it can apply their infinite capacity for adaptability and deal with the problem. Do Not become part of the problem.

The lights are out now, and the thunder rumbles soothingly into the distance. BEEEEEEEEP. There's a candle on the nightstand beside our bed, and the cats are settling into their normal spots. BEEEEEEEEP. I lean over and kiss my wife, and think that this might not be all that big an inconvenience. BEEEEEEEEP.

WHAT THE HELL IS STILL BEEPING ??!!!?? ##&;@%$!

Culprit #1 - the UPS on my wife's computer. Easily dismissed by shutting off the load. Culprit #2 - our alarm system. This one stymies me for a bit, but the Cancel button seems to do the trick.

An hour later, the power came back on. Lights come on, fans whir to life. I wake up and start turning off the lights, and then the power goes off again.

BEEEEEEEEP.

Stomp, stomp, stomp. . %^%#@*&!##@. Stomp, stomp, stomp.

This happens three more times during the night. Each time, the cursed alarm system screeches at me, proclaiming that it alone has a reserve of power -- enough, in fact, for it to squander its power by piercing the midnight silence. Thank God the alarm system told me I had no power, because that little fact might very well have escaped me otherwise.

Lesson Three:  Forcing users to acknowledge your "help" is a perilous move - use it sparingly. Consider "Clippy" the paper clip. A good portion of peoples' animosity toward the clip is not the fact that it's smugly offering advice, but that it doesn't know when to leave you alone. When you offer feedback to your users, endeavor to do so without requiring the user to stop what they're doing, deal with your interruption, and then try to figure out what they were doing before you butted in.

It's morning again. Lights are on, and everything's back to normal. And I'm tired.

Last week, Forbes.com ran a great article where they interview Mark Fleury about IBM's recent Gluecode purchase. Mark is a bit miffed that IBM is trying to out-JBoss him. He thinks IBM is trying to put him out of business. In fact, the thought of IBM putting an open source company in harm's way is pretty amusing, but we haven't seen the last of this trend.

Read on for my $0.02 ...Ok, here's the backstory.
There are enough players in this conflagration to make a Tom Clancy novel,
but we can focus on a couple at a time and get a pretty good feel for the
situation. Let's start with Fleury. Here's a guy who started JBoss to
compete with the big boys by giving their software away and charging for
services. Fair enough. He's had some success, including a
>$10m Intel-backed VC round.. Along the way, he's vowed revenge on a group of developers who left to form their own company, and gotten himself and his company in a fair bit of a mess
by faking identities on some online forums.
I get the impression that this is a guy who pounds a couple too many Red
Bulls every day.
But let's take another look. JBoss showed up as a software release in 1999,
and the JBoss organization became real in 2001. They grew via a
professional services model, and incorporated in 2004. Now you have a
company of some 150+ employees that's bringing in real revenue and hiring
real employees. They no more resemble the code-for-free open-source
stereotype than IBM does. In fact, they have promoted the term "Professional Open Source" to reflect their for-profit stance.
Now, IBM wants in, so they pick up Gluecode. They go on to announce that
they're going to undercut JBoss on services, and JBoss is a little nervous.
So, prediction time. Does IBM drive JBoss out of business? No. But I
think they may drive them into the arms of a white knight.
There are still a couple of gorillas in the mist.
Oracle is one possibility. They haven't made any big moves since picking
up Peoplesoft, and they wouldn't mind extending their position in J2EE by
getting on the hip open-source bandwagon.
A move that would make more sense would be for HP to acquire JBoss. This
would not only boost their professional services image, but would open the
door for some very interesting integrations. Consider JBoss extended to
run .Net software via Mono, and managed by HP management software (see
my earlier predition about .Net and J2EE integration in an app
server).
You'd have a real heavyweight company getting behind J2EE and .
Net on the same application server via open source, with management that's
ready for real enterprises. All running on HP equipment and serviced by HP
experts. This would squarely hit the need that IBM is targeting: customers
want to get everything from a single vendor, but know that they could
switch if they needed to without disrupting their entire infrastructure.
For a bonus, consider HP picking up EMC and getting VMWare along with it.
Virtualization is getting hot, and HP could manage it along with everything
else.
In the mean time, it's priceless to watch Fleury squirm.

Related Reading
JBoss secures $
10m financing

Mark Fleury
accused of Astroturfing

Open Source Smack-Down

JBoss moves up to business processes

Update: IBM's Gluecode Deal Adds A New Wrinkle To Its Open-Source Strategy

Forum
discussion: Joel on Software on JBoss / IBM

Most of us have had to choose whether we want to work in a big company or a small company. There are clearly benefits of each, as evidenced by the number of small companies trying to get big and the number of big companies trying to act small. But who's right? Who's best? Given the choice, do you want to work for a small company or a big company?A couple of well-known bloggers I follow chimed in and responded on this topic this week. Joel Spolsky started the volley with a post about recruiting, claiming that the environment and resources at his company greatly exceeded those available to your typical Microsoft employee.

In fairness, it's impossible to portray Fog Creek as representative of all small companies everywhere. In fact, one of the great things about small companies is that they tend to be a whole lot more unique from case to case than large companies. Joel does represent the successful small entrepeneur who's able to do some nice things to take care of his employees.

In my experience, these small companies can be extremely exciting places to be when they're working well. In general, they've started with a culture of having to succeed in order to survive, so they understand excellence and they understand execution. A young employee can learn a lot in a place like this.

Same thing goes for hiring. It's important everywhere, but it's vitally important in a small company. One bad apple can really hurt you because every part of the organization plays a critical role in the success of the company. In a bigger company, there are just more resources to deal with marginal cases -- better training facillities to make mediocre employees into good ones, counseling resources to handle problems, and so on. These things just don't exist formally in a small company, so individuals have to either sink or swim.

Availability of resources can be a mixed bag. As both Joel and Robert pointed out, there can be great resources in either environment. I've worked in some small companies, though, that were just a step or two above the stereotypical "garage and a bare light bulb." In general, if you're in a small company and you need something for your work, you get it as long as you can afford it. In a big company, you may find yourself wading through paperwork and months-long waiting lists in order to get something pretty trivial. On the other hand, when the things you need cost real money, there's nothing like the deep pockets of a big company to reach down and pony up the kind of real money it takes to buy serious hardware.

What's my preference?

I really like the energy and environment of excellence found in a small company on the rise. I also really like the resources available in a larger company. Once, I experienced a place where the small-company environment existed (to a degree) in a mid- to large-sized company. Only now do I recognize what a rare thing that was. The company's gone now, but if I ever find something like that again, I'll know enough not to take it for granted.

I've been looking at XML serialization / deserialization in VS.Net, and I'm really beginning to like working with the XSD.exe tool that ships with VS.Net. I've found that this is a great way to work from example data and end up with code that can serialize and deserialize directly from that data structure.The XSD.exe tool is found in the Visual Studio install directory in the SDK folder, and it's a command-line tool. It lets you take an XML document and generate an XSD (XML schema) document from it. You can then run XSD.exe again and generate code that works with XML that conforms to that XSD. Of course, you can perform one or the other of these steps if you want (skip generating the XSD if you already have one, for instance).

When I started playing with this tool, I knew very little about XSD schema documents, but the prototyping I've been doing has gotten me up to speed pretty quickly, and I think I'm sold on them now. These docs do an amazing job of defining the "low-hanging" business rules that seem to trip up so many applications. The final proof for me will be to see if I can use these without imparting a "sorry, try again" feel to an application (I'd like to guide users, not slap them down).

So far, I've found that I've been bouncing back and forth from XML to XSD to code trying to get things sorted out the way I want. In my case, I control the XML and the XSD, so I'm adjusting both of them to get a combination I like. It's also been very helpful to load the XML up with the generated code and browse the object structure at runtime. It's helped me see a few structural things that I've been able to clean up. Working through all of this, there are a lot of features in XSD that really help tighten up the definition of the XML, and being able to see the serializable code and browse the runtime objects really helps my understanding of the overall project.

As with any such generation technology, there's a round-trip problem here, so I expect that this is mainly a one-time prototype / jump-start tool. I also found it pretty awkward to use VS.Net to look as XSD files, because it launches a designer that doesn't really give you access to the XSD itself. Despite these small problems, it's definitely worth a look if you haven't seen this before!

Related links:
Learn about XSD on w3schools.com
Online XSD schema validator
MSDN documentation for Xsd.exe
Appdev: Generate web service stubs from WSDL