This past week, I’ve been pointedly avoiding a few of my favorite tech sites and blogs, just because the iPad had put a noticeable negative spike in their SNRs.  The covetous cries of Mac-Fans everywhere are as annoying as they are unsurprising.  These people are clamoring for the chance to lay down $500+ of their own cash for an oversized iPhone with fewer features.  (Though there will be bonus Awesome Points for the first person to load Skype on the iPad and use it as a hilariously oversized phone.)

I basically see the iPad as an answer in desperate want of a question.  Netbooks are cheaper and more useful.  An iPhone is more portable and is, you know, a phone to boot.  My Motorola Droid does even the iPhone one better by being able to multitask.  There’s literally nothing that the iPad does that other products don’t already done better.  In fact, there’s nothing the iPad does that isn’t already done better by an existing Apple product.

Herein lies a beautiful object lesson about both Capitalism writ large and the tech market in particular.  It’s not about what I want or you want or any other one person wants.  It’s about what the Market wants.  The Market is a messy, emergent force caused by the desires and information of millions of actors.  And enough of those actors want this thing (and want it with a fierceness) that this underpowered hunk of white, round-edged plastic is going to make a killing.  The odds are significantly non-zero that people will be waiting in line for days to get their hands on one.

Simply put, Apple is going to make a killing on these.  They’re going to make money hand over fist.  The profits from the iPad are going to bankroll Steve Jobs’ hyperbole and black turtleneck habits for years to come.  So no matter what you or I or anyone in particular thinks of the iPad, the Market has spoken.  We may judge the iPad to be lame, but the Market will undoubtedly judge it to be awesome.

And from a business standpoint, that’s all that matters.

I’m currently working my way through Rohit Khare’s dissertation on using using REST methods in Decentralized Systems.  The main work of the paper is interesting, but I wanted to comment briefly on the methodology.  Khare takes the interesting approach of articulating several known problems with decentralized systems and then designing an architure which enforces graceful solutions to those problems.

“The basic organizational pattern of this dissertation is the pairing of a desired property and the architectural constraints that induce it. We design several new styles using this pattern of alternating subsections: specification of the required properties, a definition of the new style, validation that the new style correctly implements the abstract specification, and implementation issues encountered in practice.”

This architectural approach to solving difficult problems is an interesting one.  Architecture’s often given lip service, but it’s rarely treated well.  It’s often treated (by both suits and hackers) as the annoying middle step between defining what a system does and building that system.  It’s the irritating goody-two-shoes at the party that says “wait, before we pound this third round of tequila shooters, we should really figure out how we’re getting home.”

…Okay, so that analogy went kind of a weird place, but my point is that architecture is often seen as a necessary evil.  Business folks see it as yet another task in the Gantt chart that pushes back the delivery date.  Programmers see it as the busy work necessary to divy up the project amongst themselves.

(Interestingly, programmers tend to approach architecting personal projects with the same glee one might expect of a kid designing the treehouse of their dreams.  Put a bunch of coders together on a business project, however, and that joy for architecting disappears.  I imagine this indicates that how a coder feels about architecture may serve as a litmus for how they feel about the project as a whole.  I can’t decide whether this qualifies as an interesting insight or as crashingly obvious.)

I think that Khare’s approach is an elegant demonstration of the way software professionals should approach architecture.  What Khare is doing in his dissertation is articulating the desired behaviors of the system, and then designing it so that the system cannot behave in any other way. In this way, architecture becomes an integral part of specification enforcement.  (In more applied contexts, it also simplifies programming and testing the system as well.  After all, if every possible behavior that can be taken care of at the architecture level has been, then those are behaviors that you don’t have to worry about in implementation or testing.)

If you approach architecture as a way to satisfy some parts of a specification, then it becomes more obvious way software professionals should care about it.  Suits should care about architecture because, since it enforces some parts of the spec before any code is even written, it will make subsequent tasks (implementation and QA) faster.  It will also create a better and more reliable end product.

Coders should care about architecture because it makes their jobs easier and more enjoyable.  It helps them deliver a stronger product, with less risk and effort on their part.  It also helps them do all that more quickly and more consistently.

Personally, I think that both should care about architecture because it’s really damned interesting and can lead to some amazingly elegant solutions.  But I guess I can’t really demand that other people be as interested in good design as I am.  To paraphrase the amazing Randall Munroe: “Architecture: It Works, Bitches!”

I suppose the first post should be all introspective and shit, but I’m honestly not feeling it.  All I have to say is that this blog will always strive to choose Win over Fail and to engage in random acts of Awesome.  As its proprietor I make no other promises.

Let’s get hacking.