Eric Sink claims to be the ”.NET Redneck,” complete with cardboard cutout:

Shawn Morrissey [shawnmor @ microsoft.com]
Taken at Gnomedex
July 15th, 2003

Here. "Windows Forms Programming in C# by Chris Sells This book is written to help experienced programmers who already possess a basic understanding of Visual C# .NET and the .NET Framework to master the Windows Forms toolkit. Contents include discussion of the core elements of Windows Forms (with concise examples and graphic depictions of user interface features in action), as well as pitfalls to avoid and solutions to common problems. Windows Forms Programming in C# is the seventh book to publish in Addison-Wesley's Microsoft .NET Development Series. Chris Sells has been touring the U.S. as one of Microsoft's Software Legends. (Publishing August 2003)"

Here. As a frustrated fiction author myself, I find this very cool: "He rented a modern typewriter, secluded himself in his apartment and started to type. Soon a problem appeared: the typewriter had a modern plastic ribbon. The plastic mellowed and became sticky: it was July in Iowa City, and the apartment was hot. The only way to prevent the ribbon from getting stuck is to keep the ribbon moving. And the only way to keep the ribbon moving is to keep pressing the keys. That discovery did wonders for his productivity." This is *so* different from how I write, but it makes a really good story. : ) Plus, he adopted another technique later. "For instance, many stories of Charles Dickens were first published in a magazine, over a course of several months. It is not often emphasized that Dickens didn't have time to distill his novels and to write draft after draft. He had to write in monthly installments, with barely a time for one draft." This is how I like to write. I write up articles, post them various places, get feedback and then use those as draft material for the chapters in my books. It works really well, I think, both because it produces better material and because my hardcore audience doesn't have to write for the book publishing process for a lot of the material.

Here. Veritest shows that Windows Server 2003/IIS6 creams Linux/Apache by up to 300% vs. Apache 1.3.23 and up to 58% vs. Apache 2.0.4.

In addition to bending my head back during my flight lesson, Alan Cooper always manages to bend my brain back, too. Here’s a guy that invented drag-n-drop UI development umpteen years ago and he’s been in the business ever since, mostly doing interaction design, but lately trying to tackle the problem of software management. His main thesis is that “web designers are called programmers, programmers are called engineers, engineers are called architects and architects are never called.” He justifies this statement by comparing architecture to real-world architecture, which is very different from what the IT industry has co-opted the term mean.

For example, in the world of physical buildings, an architect meets with the clients to understand their needs and listens to their ideas. He then designs a building via a series of increasingly specific sessions with the clients to understand what they need and with engineers to understand what can be done. He uses these interactions to produce blueprints to hand off to the engineer. The engineer decides how to build the building, e.g. what materials to use, what to build or buy, what labor is needed, etc. Before we had mass-produced parts and giant spec books describing every material under the sun, this often required experimentation, which would also feed into the production of a more detailed set of plans to hand off to the construction workers, who do the actual building of the structure. While the structure is built, the engineer and the architect checks in to make sure that things are meeting their requirements and, in fact, it’s the engineer’s job to sign off when it does. Likewise, there are inspectors that check to make sure things are up to code at certain phases of the project.

In the world of software, we’ve got inspectors, they’re called QA staff. We’ve got construction workers, they’re called programmers. We’ve got engineers, they’re called software engineers, even though we have yet to decide what being a “software engineer” means (often it’s just another fancy word for “programmer”). We sometimes have architects, but we tend to rely on the combination of engineering and usability folks, most often skipping the usability and most of the contact with the customer altogether.

Alan’s view of the world of software is that, because we don’t have this very interactive role that really corresponds to the architect very often, non-technical management really has no idea what’s going on in the software construction process. Instead, they have to rely on engineers and programmers to tell them things, when they feel like it, and those guys lie (or plain don’t know). Likewise, because there is so little architecture, what comes out the other side is often not what the users want anyway.

In Alan’s world, architects fill the role between engineers and customers and non-technical management, designing software that users want and communicating what’s going on with management. Likewise, engineers design software to spec that works under stress; programmers build software that doesn’t crash; QA checks to make sure that this all happens the way it should.

One of the benefits of Alan’s view is that before engineering happens, architects figure out in a detailed and thorough way what needs building, handing complete specs to the engineers. Likewise, before programming happens, engineers run the experiments and make the technology and resource decisions before any code is written, passing off details specs to the programmers. These details specs also flow to the QA folks, which uses them along with their own quality standards to make sure that the software is right before it ships.

If this seems silly, think about an inspector signing off on a house before the foundation is poured, a construction worker pouring the concrete before the plans are done or the engineer deciding on the materials of a building before he knows if it’s a house or a mall. Software is certainly more fluid than concrete, but it’s not so fluid as we like to believe, as evidenced by the number of failed software projects and the cost overruns associated with them.

We think we’re doing architect/engineer/programmer now, but Alan disagrees. What we have is software being hand-made by craftsman from the iron age, but reproduced like appliances from the industrial age. What we need is real engineering for the information age. Alan puts it nicely, “We’re standing at the front edge of the information age with really sharp tools from the industrial age.”

Of course, what Alan’s talking about is the standard waterfall method of software design, which is what I learned in software engineering school. So why don’t we do it? Because we don’t like drawing up blueprints. We like to make the lights go blinky, blinky on the monitor. Building a shed in your backyard is quicker and easier without an architect or an engineer involved, but is that how you want your house built?

Another benefit of this model of architect/engineer/programmer is that it gives non-technical management much more visibility into and control of the process. You may not think so, but this is good. Right now, the only control they have over the process is the schedule. We say, “That’ll take two years,” and they say, “You’ve got four months.” Why? Because they’ve been down the “two year” software process before and gotten burned ~100% of the time, whether the software ships late or it doesn’t ship at all. At least if they say “four months,” they’ve only lost 1/6th of the money when/if things go bad. If we want to take the giant hammer of schedule out of their hands, we’ve got to give them something else so that we have the time we know we need to build quality software that we can be proud of.

I don’t know if Alan’s right or not, but I sure want him to be. As an architect, I want the tools and the opportunity to design something that the customer will want (I’ve been down the other road before and it never ends well). As an engineer and as a programmer, I want to build something that will be loved and used when I’m done. Isn’t that what we all want?

Here. Rich Salz explains in a clear, calm manner the problems with RSS and what Necho/Echo/Pie brings to the table. Thanks, Rich!

Here. The one where the Father of VB turns off the autopilot, giving me control of his airplane and causing me to nearly lose control of my bowels.

Here. If you didn't get to come to the Applied XML Developer's Conference, you missed a fun show. The conference page (linked to this item) has the materials and a list of blogs that I know of that posted conference commentary.