Remember the SAT test and their ridiculous analogy questions? “Apple : Banana as Steak : ???”, where you have to figure out the relationship between the first pair in order to guess what the relationship in the second pair should be? (Of course, the SAT guys give you a multiple-choice answer, whereas I’m leaving it open to your interpretation.)

What triggers today’s blog post is this article that showed up in GeekWire, about how Firefox is accusing Microsoft of anti-competitive behaviors by claiming IE will have an unfair advantage on their new ARM-based machines.

Anderson says the situation has antitrust implications. Microsoft has agreed to abide by a set of principles to maintain a level playing field on Windows for competitors despite the expiration of its consent decree with the U.S. Justice Department.

OK, wait a second here. Last time I checked, there’s another operating system out there that completely and entirely prevents any kind of web browser from being deployed on it, which strikes me as grossly anticompetitive, and yet Mozilla chooses to fire their guns at Microsoft, who is attempting to take a shot at the ARM market?

Seems to me like somebody’s either not getting the point of “anticompetitive”, or else they’re just taking a potshot at the company that everybody loves to hate because it’s an easy shot. If Mozilla is really serious about anticompetitive concerns, they will ask DOJ to investigate Apple’s iOS (that owns, what, 2500% of the tablet market) and AppStore, not Microsoft IE on a market that doesn’t event exist yet.

Otherwise, I call bullshit.

Twitter led me to an interesting blog post—go read it before you continue. Or you can read the reproduction of it here, for those of you too lazy to click the link.

I was having coffee with my friend Simone the other day. We were sort of chatting about work stuff, and we’re both at the point now where we’re being put in charge of other people. She came up with a really good metaphor for explaining the various issues in tasking junior staff.

It’s like you’re asking them to hang a picture for you, but they’ve never done it before. You understand what you need done – the trick is getting them to do it. In fact, it’s so obvious to you that there are constraints and expectations that you don’t even think to explain. So you’ve got some junior guy working for you, and you say, “Go hang this picture over there. Let me know when you’re done.” It’s obvious, right? How could he screw that up? Truth is, there are a whole lot of things he doesn’t know that he’ll need to learn before he can hang that picture. There are also a surprising number of things that you can overlook.

First off, there’s the mechanics of how to do it. What tools does he need? You know that there’s a hammer and nails in the back of the supply closet. He doesn’t, and it’s fair of him to assume that you wouldn’t have asked him to do something he didn’t have the tools for. He looks around his desk, and he’s got a stapler and a tape dispenser.

There are two ways he can do this. He can make lots of little tape loops, so it’s effectively double-sided, and put them on the back of the picture. This is the solution that actually looks alright, and it’s not until the picture comes crashing down that you find out he did it wrong. The other possibility is that he takes big strips of tape and lashes them across the front of the picture, stapling them to the wall for reinforcement. This solution may be worse because it actually sorta fits the bill – the picture is up, and maybe not too badly obscured. With enough staples, it’ll hold. It’s just ugly, and not what you intended. And if you don’t put a stop to this now, he might keep hanging pictures this way.

There is also another way this can go wrong, particularly with a certain breed of eager young programmer. You find that he’s gone down this path when your boss comes by the next week to ask about this purchase order for a nail gun. So you talk to your guy and discover that he’s spent the last week Googling, reading reference works, and posting to news groups. He’s learned that you hang pictures on a nail driven into the wall, and that the right tool for driving nails into walls is a high-end, pneumatic nail gun. If you’re lucky, you can point out that there’s a difference between picture-hanging nails and structural nails, and that a small, lightweight hammer like you have in the supply closet is really the right tool for the job. If you’re not lucky, you have a fight on your hands that goes something like:

“Why can’t we get a nail gun?”
“We don’t have the budget for it.”
“So we can’t afford to do things right?”
“There’s nothing wrong with driving nails with a hammer.”
“But aren’t we trying to do things better and faster? Are we going to keep using hammers just because we’ve always used them? It’ll pay off in the long run.”
“We don’t spend enough time driving nails around here to justify buying a nail gun. We just don’t.”

And ends with him sulking.

Now you think you’ve pretty much got that tool issue sorted out. He’s got his hammer and nails, and he goes off. The trouble is, he still needs to know how to use them efficiently. Again, it’s obvious to you because you know how to use a hammer. To someone who has never seen one before, it probably looks like it’d be easier to hit something small like a nail using the broad, flat side of it. You could certainly do it with the butt of the handle. And you might even be able to wedge a nail into the claw part and just smack it into the wall, instead of having to hold it with your hand while you swing at it with something heavy.

This sounds pretty silly from a carpentry standpoint, but it’s a real issue with software tools. Software tends to be long on reference documentation and short on examples and customary use. You can buy a thousand page book telling you all the things you can do with a piece of software, but not the five-page explanation of how you should use it in your case. Even when you have examples, they don’t tend to explain why it was done a certain way. So you plow through all this documentation, and come out thinking that a nail gun is always the right tool for the job, or that it’s okay to hit things with the side of the hammer.

I ran into this when I started working with XML. I’ve seen all sorts of references that say, “Use a SAX parser for reading XML files, not a DOM parser. DOM parsers are slow and use too much memory.” I finally caught some guy saying that, and asked, “Why? Is the DOM parser just poorly implemented?”

And he said, “Well no, but why load a 10 megabyte document into memory when you just want to get the author and title info?”
“Ah, see, I have 20 kilobyte files, and I want to map the whole thing into a web page.”
“Oh yeah, you’d want to use DOM for that.”

There may also be tool-data interaction issues. Your guy knows how to drive nails now, and the first thing he does is pound one through the picture frame.
Ooooh.

“No, you see this wire on the back of the frame? You drive the nail into the wall, and then hook the wire over it.”
“Oh, I wondered what that was for. But you only put in one nail? Wouldn’t it be more secure with like, six?”
“It’s good enough with one, and it’s hard to adjust if you put more in.”
“Why would you need to adjust it?”
“To get it level.”
“Oh, it needs to be level?”

Ah, another unspoken requirement.

So now we get into higher-level design issues. Where should the picture go? At what height should it be hung? He has no way of judging any of this, and again, it’s not as obvious as you think.

You know it shouldn’t go over there because the door will cover it when open. And it can’t go there because that’s where your new bookcase will have to go. Maybe you have 14-foot ceilings, and the picture is some abstract thing you’re just using to fill space. Maybe it’s a photograph of you and Elvis, and you want it to be smack at eye level when someone is sitting at your desk. If it’s an old photograph, you’ll want to make sure it’s not in direct sunlight. These are all the “business rules”. You have to take them into account, but the way you go about actually hanging the picture is pretty much the same.

There are also business rules that affect your implementation. If the picture is valuable, you probably want to secure it a little better, or put it up out of reach. If it’s really valuable, you may want to set it into the wall, behind two inches of glass, with an alarm system around it. If the wall you’re mounting it on is concrete, you’re going to need a drill. If the wall itself is valuable, you may have to suspend the picture from the ceiling.

These rules may make sense, but they’re not obvious or intuitive. A solution that’s right in some cases will be wrong in others. It’s only through experience working in that room, that problem domain, that you learn them. You also have to take into account which rules will change. Are you really sure of where the picture’s going to go? Is this picture likely to move? Might it be replaced with a different picture in the same position? Will the new picture be the same size?

Your junior guy can’t be expected to judge any of this. Hell, you’re probably winging it a bit by this point. Your job is to explain his task in enough detail that he doesn’t have to know all this stuff, at least not ahead of time. If he’s smart and curious, he’ll ask questions and learn the whys and wherefores, but it’ll take time.

If you don’t give him enough detail, he may start guessing. The aforementioned eager young programmer can really go off the rails here. You tell him to hang the photo of your pet dog, and he comes back a week later, asking if you could “just double-check” his design for a drywall saw.

“Why are you designing a drywall saw?”
“Well, the wood saw in the office toolbox isn’t good for cutting drywall.”
“What, you think you’re the first person on earth to try and cut drywall? You can buy a saw for that at Home Depot.”
“Okay, cool, I’ll go get one.”
“Wait, why are you cutting drywall in the first place?”
“Well, I wasn’t sure what the best practices for hanging pictures were, so I went online and found a newsgroup for gallery designers. And they said that the right way to do it was to cut through the wall, and build the frame into it. That way, you put the picture in from the back, and you can make the glass much more secure since you don’t have to move it. It’s a much more elegant solution than that whole nail thing.”
“…”

This metaphor may be starting to sound particularly fuzzy, but trust me – there are very real parallels to draw here. If you haven’t seen them yet in your professional life, you will.

The key thing here is that there’s a lot of stuff, from the detailed technical level to the long-range business level, that you just have to know. Your junior guy can’t puzzle it out in advance, no matter how smart he is. It’s not about being smart; it’s just accumulating facts. You may have been working with them for so long that you’ve forgotten there ever was a time when you didn’t understand them. But you have to learn to spell things out in detail, and make sure your junior folks are comfortable asking questions.

(From http://www.bluegraybox.com/blog/2004/12/02/picture-hanging/)

Finished?

This led me to remember one of my favorite scenes from “The Empire Strikes Back”: Luke Skywalker, young farm boy suffering from tragic loss and discovering his secret heritage, is learning how to become a Jedi Knight from Yoda, the ancient Jedi Master. But Yoda is not teaching him what Luke thinks he should be learning, or in the way that Luke thinks he should be taught. In fact, to the adult viewer, Luke seems to have a lot of preconceptions about what a Jedi should be like, considering he’s had almost zero experience around Jedi, excepting of course for his time with Ben Kenobi, whom he clearly never identified as a Jedi until right before Kenobi sacrificed himself to his former apprentice, anyway.

In particular, one part of that scene always stands out in my mind:

LUKE: Master, moving stones around is one thing. This is totally different.

YODA: No! No different! Only different in your mind. You must unlearn what you have learned.

LUKE: (focusing, quietly) All right, I'll give it a try.

YODA: No! Try not. Do. Or do not. There is no try.

Where’s the connection between the picture-hanging post and Empire Strikes Back?

Young programmers need to unlearn what they think they know, and start learning what they need to know.

Programmers come out of college in one of two modes: either they are full of fire and initiative, ready to change the world with their “mad h@x0r skillz” and energy, or they are timid and tentative, completely afraid to take any chance or risk that might possibly lead them to getting fired from their job.

The first are the ones that scare me. They are the ones that think they know what needs to be done, and charge off to the Internet to Google the answers that they need—they are the ones that start looking for drywall saws to hang that picture. Or they will fight with you about the nail gun, because they’re right: the nail gun is a vastly faster, more efficient way to put a large number of nails into a large number of walls (or timbers, or support beams, or any soft, fleshy part of your body if you’re not careful). But they’re also wrong, because the nail gun is simply inappropriate for the task of partially-inserting a nail (as opposed to the nail gun’s habit of embedding the nail so deeply into the wall that it’s flush) such that a picture can hang from it.

The second are, unfortunately, the ones that the industry will chew up and spit out. Without a certain amount of initiative and drive, the chances that they will never actually learn anything and end up left behind doing simple spellcheck kinds of administrative-assistant work on HTML pages for the rest of their lives is high. Then they will get angry, blame the industry, and eventually go postal. Or go into Marketing. (Or, worse, Sales.)  Either way, it’s equally catastrophic to a young mind.

Which led me to a simple question: what’s the young programmer to do? How does one transition from a young programmer to an old, seasoned one? What process does the young developer need to go through to avoid those two outcomes?

Young programmers, you need to learn to ask questions. That’s it. Ask, and ye shall receive.

Consider the eager young programmer from the examples: if the young programmer has the moral fortitude to simply stand up and say, “Boss, I have never hung a picture before. How do I do that?”, then all of the problems—the nail-gun scenario, the adhesive-tape-and-staples scenario, the drywall-saw scenario—they all go away. You, the grizzled senior, realize that you are making assumptions about what he knows, and that you are probably making assumptions that are unwarranted for anyone that hasn’t been you and had your experience.

But the senior can’t know what the junior doesn’t know. It’s on the junior’s shoulders to make him aware of that. That’s what the Jedi Master/Padawan relationship is predicated upon, just as the Sith Lord/Sith Apprentice relationship is, and the thousands of years of Master/Apprentice guilds in human history operated.

And the kicker?

We are all young programmers in one thing or another. I don’t care if you have forty years of C++ across every platform and embedded system since the beginning of time, you are a young programmer when it comes to the relational database. Or NoSQL. Or Java and the JVM. Or C# and the CLR. Or the Force and how to become a Jedi Knight like your father and save the universe (and the pretty girl who turns out to be your sister but we don’t find that out until two episodes from now).

You get the idea.

Find yourself a Master (although today it’s probably more politically correct to call them “mentors”) and be useful to them while asking them questions and learning from them. Then, in turn, offer to be the same to another young programmer within your circle of coworkers or friends; they won’t always take you up on it, but think about it: when you were that age, did you want some old, wizened short little green dude teaching you stuff?

Do you really want to be Luke Skywalker, whiny wannabe, or Luke Skywalker, Jedi Knight? Luke had to lose a hand before he came to understand that Yoda was far wiser than he, and just asked him questions, rather than tried to tell Yoda “you’re doing it wrong!”.

How many projects will you have to fail before you accept that simple premise, that you don’t, in fact, know everything?

Two things conspire to bring you this blog post.

Of Contracts and Contracts

First, a few months ago, I was asked to participate in an architectural review for a project being done for one of the states here in the US. It was a project dealing with some sensitive information (Child Welfare Services), and I was required to sign a document basically promising not to do anything bad with the data. Not a problem to sign, since I was going to be more focused on the architecture and code anyway, and would stay away from the production servers and data as much as I possibly could. But then the state agency asked for my social security number, and when I pushed back asking why, they told me it was “mandatory” in order to work on the project. I suspect it was for a background check—but when I asked how long they were going to hold on to the number and what their privacy policy was regarding my data, they refused to answer, and I never heard from them again. Which, quite frankly, was something of a relief.

Second, just tonight there was a thread on the Seattle Tech Startup mailing list about SSNs again. This time, a contractor who participates on the list was being asked by the contracting agency for his SSN, not for any tax document form, but… just because. This sounded fishy. It turned out that the contract was going to be with AT&T, and that they commonly use a contractor’s SSN as a way of identifying the contractor in their vendor database. It was also noted that many companies do this, and that it was likely that many more would do so in the future. One poster pointed out that when the state’s attorney general’s office was contacted about this practice, it isn’t illegal.

Folks, this practice has to stop. For both your sake, and the company’s.

Of Data and Integrity

Using SSNs in your database is just a bad idea from top to bottom. For starters, it makes your otherwise-unassuming enterprise application a ripe target for hackers, who seek to gather legitimate SSNs as part of the digital fingerprinting of potential victims for identity theft. What’s worse, any time I’ve ever seen any company store the SSNs, they’re almost always stored in plaintext form (“These aren’t credit cards!”), and they’re often used as a primary key to uniquely identify individuals.

There’s so many things wrong with this idea from a data management perspective, it’s shameful.

• SSNs were never intended for identification purposes. Yeah, this is a weak argument now, given all the de facto uses to which they are put already, but when FDR passed the Social Security program back in the 30s, he promised the country that they would never be used for identification purposes. This is, in fact, why the card reads “This number not to be used for identification purposes” across the bottom. Granted, every financial institution with whom I’ve ever done business has ignored that promise for as long as I’ve been alive, but that doesn’t strike me as a reason to continue doing so.
• SSNs are not unique. There’s rumors of two different people being issued the same SSN, and while I can’t confirm or deny this based on personal experience, it doesn’t take a rocket scientist to figure out that if there are 300 million people living in the US, and the SSN is a nine-digit number, that means that there are 999,999,999 potential numbers in the best case (which isn’t possible, because the first three digits are a stratification mechanism—for example, California-issued numbers are generally in the 5xx range, while East Coast-issued numbers are in the 0xx range). What I can say for certain is that SSNs are, in fact, recycled—so your new baby may (and very likely will) end up with some recently-deceased individual’s SSN. As we start to see databases extending to a second and possibly even third generation of individuals, these kinds of conflicts are going to become even more common. As US population continues to rise, and immigration brings even more people into the country to work, how soon before we start seeing the US government sweat the problems associated with trying to go to a 10- or 11-digit SSN? It’s going to make the IPv4 and IPv6 problems look trivial by comparison. (Look for that to be the moment when the US government formally adopts a hexadecimal system for SSNs.)
• SSNs are sensitive data. You knew this already. But what you may not realize is that data not only has a tendency to escape the organization that gathered it (databases are often sold, acquired, or stolen), but that said data frequently lives far, far longer than it needs to. Look around in your own company—how many databases are still online, in use, even though the data isn’t really relevant anymore, just because “there’s no cost to keeping it”? More importantly, companies are increasingly being held accountable for sensitive information breaches, and it’s just a matter of time before a creative lawyer seeking to tap into the public’s sensitivities to things they don’t understand leads him/her takes a company to court, suing them for damages for such a breach. And there’s very likely more than a few sympathetic judges in the country to the idea. Do you really want to be hauled up on the witness stand to defend your use of the SSN in your database?

Given that SSNs aren’t unique, and therefore fail as their primary purpose in a data management scheme, and that they represent a huge liability because of their sensitive nature, why on earth would you want them in your database?

A Call

But more importantly, companies aren’t going to stop using them for these kinds of purposes until we make them stop. Any time a company asks you for your SSN, challenge them. Ask them why they need it, if the transaction can be completed without it, and if they insist on having it, a formal declaration of their sensitive information policy and what kind of notification and compensation you can expect when they suffer a sensitive data breach. It may take a while to find somebody within the company who can answer your questions at the places that legitimately need the information, but you’ll get there eventually. And for the rest of the companies that gather it “just in case”, well, if it starts turning into a huge PITA to get them, they’ll find other ways to figure out who you are.

This is a call to arms, folks: Just say NO to handing over your SSN.

This CNET report tells us what we’ve probably known for a few years now: in the hacker/securist cyberwar, the hackers are winning. Or at the very least, making it pretty apparent that the cybersecurity companies aren’t making much headway.

Notable quotes from the article:

Art Coviello, executive chairman of RSA, at least had the presence of mind to be humble, acknowledging in his keynote that current "security models" are inadequate. Yet he couldn't help but lapse into rah-rah boosterism by the end of his speech. "Never have so many companies been under attack, including RSA," he said. "Together we can learn from these experiences and emerge from this hell, smarter and stronger than we were before."
Really? History would suggest otherwise. Instead of finally locking down our data and fencing out the shadowy forces who want to steal our identities, the security industry is almost certain to present us with more warnings of newer and scarier threats and bigger, more dangerous break-ins and data compromises and new products that are quickly outdated. Lather, rinse, repeat.

The industry's sluggishness is enough to breed pervasive cynicism in some quarters. Critics like [Josh Corman, director of security intelligence at Akamai] are quick to note that if security vendors really could do what they promise, they'd simply put themselves out of business. "The security industry is not about securing you; it's about making money," Corman says. "Minimum investment to get maximum revenue."

Getting companies to devote time and money to adequately address their security issues is particularly difficult because they often don't think there's a problem until they've been compromised. And for some, too much knowledge can be a bad thing. "Part of the problem might be plausible deniability, that if the company finds something, there will be an SEC filing requirement," Landesman said.

The most important quote in the whole piece?

Of course, it would help if software in general was less buggy. Some security experts are pushing for a more proactive approach to security much like preventative medicine can help keep you healthy. The more secure the software code, the fewer bugs and the less chance of attackers getting in.

"Most of RSA, especially on the trade show floor, is reactive security and the idea behind that is protect broken stuff from the bad people," said Gary McGraw, chief technology officer at Cigital. "But that hasn't been working very well. It's like a hamster wheel."

(Fair disclosure in the interests of journalistic integrity: Gary is something of a friend; we’ve exchanged emails, met at SDWest many years ago, and Gary tried to recruit me to write a book in his Software Security book series with Addison-Wesley. His voice is one of the few that I trust implicitly when it comes to software security.)

Next time the company director, CEO/CTO or VP wants you to choose “faster” and “cheaper” and leave out “better” in the “better, faster, cheaper” triad, point out to them that “worse” (the opposite of “better”) often translates into “insecure”, and that in turn puts the company in a hugely vulnerable spot. Remember, even if the application under question, or its data, aren’t obvious targets for hackers, you’re still a target—getting access to the server can act as a springboard to attack other servers, and/or use the data stored in your database as a springboard to attack other servers. Remember, it’s very common for users to reuse passwords across systems—obtaining the passwords to your app can in turn lead to easy access to the more sensitive data.

And folks, let’s not kid ourselves. That quote back there about “SEC filing requirement”s? If CEOs and CTOs are required to file with the SEC, it’s only a matter of time before one of them gets the bright idea to point the finger at the people who built the system as the culprits. (Don’t think it’s possible? All it takes is one case, one jury, in one highly business-friendly judicial arena, and suddenly precedent is set and it becomes vastly easier to pursue all over the country.)

Anybody interested in creating an anonymous cybersecurity whisteblowing service?

Eric Evans, a number of years ago, wrote a book on “Domain Driven Design”.

Around the same time, Martin Fowler coined the “Rich Domain Model” pattern.

Ever since then, people have been going bat-shit nutso over building these large domain object models, then twisting and contorting them in all these various ways to make them work across different contexts—across tiers, for example, and into databases, and so on. It created a cottage industry of infrastructure tools, toolkits, libraries and frameworks, all designed somehow to make your objects less twisted and more usable and less tightly-coupled to infrastructure (I’ll pause for a moment to let you think about the absurdity of that—infrastructure designed to reduce coupling to other infrastructure—before we go on), and so on.

All the time, though, we were shying away from really taking the plunge, and thinking about domain entities in domain terms.

Jessica Kerr nails it, on the head. Her post is in the context of Java (with, ironically, some F# thrown in for clarity), but the fact is, the Java parts could’ve been written in C# or C++ and the discussion would be the exact same.

To think about building domain objects, if you are really looking to build a domain model, means to think beyond the implementation language you’re building them in. That means you have to stop thinking in terms of “Strings” and “ints”, but in terms of “FirstName” and “Age” types. Ironically, Java is ill-suited as a language to support this. C# is not great about this, but it is easier than Java. C++, ironically, may be best suited for this, given the ease with which we can set up “aliased” types, via either the typedef or even the lowly preprocessor macro (though it hurts me to say that).

I disagree with her when she says that it’s a problem that FirstName can’t inherit from String—frankly, I hold the position that doing so would be putting too much implementation detail into FirstName then, and would hurt FirstName’s chances for evolution and enhancement—but the rest of the post is so spot-on, it’s scary.

And the really ironic thing? I remember having this conversation nearly twenty years ago, in the context of C++ at the time.

Want another mind-warping discussion around DDD and how to think about domain objects correctly? Read Allen Holub’s “Getters and Setters Considered Harmful” article of nine (!) years ago.

Read those two entries, think on them for a bit, then give it a whirl in your own projects. Or as a research spike. I think you’ll start to find a lot of that infrastructure code starting to drop away and become unnecessary. And that will let you get back to the essence of objects, and level up your DDD.

(Unfortunately, I don’t know what leveled-up DDD is called. DDD++, maybe?)

Do you ever long for the days when they just called them “Betas” and only a select few could get at them?

Anyway, like most of the Microsoft Geek world, I pulled down the Windows 8 Consumer Preview that became available yesterday, and since I had one of those spiffy Samsung Slates that Microsoft handed out at the //build conference last year, I decided to update my Win8 build there with the new one.

Frankly, although I admit that I read my buddy Brian Randell’s post on how to update the //build tablet with Win8 first, I probably didn’t need to—it was incredibly trivial to do. Pulling down Visual Studio 11 was also pretty easy to do, though I’m still (about 90 minutes later) still waiting for all the help file indexes to merge. (I like having documentation offline, because I spend so much time on a plane and it’s so frustrating to not be able to figure out why something’s not working because I can’t get F1 to tell me what the expected ins-and-outs of a given method are, or the name of that stupid class that I just can’t remember.)

DevExpress captured my thoughts on Windows 8 while we were all down there in LA for the //build conference last year, and I can summarize them thusly:

• Microsoft needs to hit a base hit with this release. They need to show the world that they are, in fact, capable of innovating and changing the rules of the game back to favor their team, rather than just letting Apple continue to churn out consumer devices without viable competition and complete their domination of that market.
• Clearly the consumer market world is all about tablets and slates (or oversized phones, whatever you want to call them). Touch-ready devices are pretty obviously a big thing for the consumer world, over and above the traditional keyboard-and-mouse device, at least all the way up until you have somebody who has to type for a living (such as *ahem* all those authors and programmers out there).
• Having said that, though, despite what Microsoft said in their keynote (“Any monitor out there that isn’t touch-capable is broken”), very very few consumers own touch-based monitors, and won’t, for a long time, particularly if the touch-capable tablet/slate continues to make such strong inroads into the traditional PC market. Think about it this way: aside from the traditional hard-core gamer, what does the average American need a keyboard/mouse/mini-tower/monitor for? More specifically, what do they need that setup for that can’t be done using a tablet/slate? Frankly, I’m at a loss. I consider my mother, a grade-school principal, a pretty average consumer of technical devices (no offense, Mom!), and honestly I can’t see that there’s anything she does that isn’t well-served by a tablet/slate.

So here’s my litmus test for Microsoft, if Windows is going to remain relevant into the next decade:

• They must continue to have a worthy successor to Windows for all those keyboard/mouse/monitor PCs out there, and…
• They must release a great touch-capable OS for all the tablet/slate devices that are going to eventually replace those keyboard/mouse/monitor PCs out there.

Notice that I didn’t say this had to be the same operating system. Therein lies my concern: I’m not sure it can be one operating system that covers both niches. There is an old saying that says that “No one can serve two masters. Either he will hate the one and love the other, or he will be devoted to the one and despise the other.” (Matthew 6:24, for anybody who’s trying to keep me intellectually honest here.) This is where I think Windows 8 is primed to fail: I think by trying to serve both the keyboard/mouse/monitor master, their existing consumer base, at the same time they try to serve the tablet/slate market that they hope will become their new consumer base, they run the risk of sacrificing one in favor of the other.

At //build, they seemed to favor the Metro look over the “classic” desktop look, and certainly a lot of the negative reviews I heard about Win8 during that time seemed to come from the folks that tried to use Metro on a keyboard/mouse/monitor setup. Those of us who had the tablets/slates seemed to find Metro pretty intuitive. But then we flip the situation around, and trying to use “classic” desktop mode on the tablet/slate is a royal PITA, where of course the keyboard/mouse/monitor set is completely comfortable with it (particularly since it looks exactly like Windows 7 does).

This most recent release doesn’t really change my opinions much one way or another: trying to use the Bluetooth keyboard to write code is awkward. Using the stylus is necessary, because the icons and buttons and scrollbars and such in classic desktop applications are just too small for my fat fingertips. Not a lot of Metro-ized applications are out there besides the “easy” ones to build (like Twitter clients and such), so it’s hard to feel what Metro would be like on a tablet. (Metro on a phone works out pretty well, so I hold out hope.)

Microsoft, if you’re listening, I *really* urge you to consider a simple Windows split: WIndows 8 Desktop Edition, and Windows 8 Slate Edition. Optimize each in terms of how people will use it. There’s too much riding on this release for you to gamble on the dual goals.

Yesterday, Feb 29th, the leap day in a leap year, saw not only the third day in Microsoft’s MVP 2012 Summit, not to mention the fifth iteration of my personal MVP Summit party, #ChezNeward, but also one of the most embarrassing outages in cloud history. Specifically, Microsoft’s Azure cloud service went down, and it went down hard. My understanding (entirely anecdotal descriptions, I have no insider information here) was that the security certificates were the source of the problem: specifically, they were set to expire on Feb 28th, and not to renew until March 1st. (I don’t know more details than that, so please don’t ask me for the details as to how this situation came to be.)

For those of you playing the home game, this means (IIRC) that each of the major cloud providers has had a major outage within the last two years: Azure’s yesterday, Amazon’s of a few months ago, and of course Gmail goes down every half-year or so, to tremendous fanfare and finger-pointing. (You can hear the entire Internet scream when it does.)

Can we please stop with the hype that somehow “The Cloud” is the solution to all your reliability problems?

I’m not even going to argue that the cloud services hosted by “the big boys” (Microsoft, Google, Amazon) aren’t somehow more reliable; in fact, I’ll even be the first to point out that by any statistical measure I’ve seen examined, the cloud providers stay up far more often than what a private data center achieves. Part of this is because of the IT equivalent of economies of scale: if you’re hosting five servers, you’re not going to put as much money and time into keeping the data center running as if you’re hosting five thousand servers. HVAC and multiple Internet connections and all are expensive, and for a lot of companies, remain entirely out of their IT budget’s reach.

What companies need to realize is that moving to the cloud isn’t just moving your software out of the data center and into somebody else’s data center—it’s also a complete loss of control over what happens when an outage occurs.

When a company builds a business that puts technology at the front and center of its operations, and then puts that technology into the hands of a third party for safe-keeping and management, that company loses a degree of control over when and how the emergency response happens. If the data center is inside your building, managed by your people, you (the CEO or CTO) have a say in how things come back online—do you restore email first, or do you restore the web site? Is the directory service the most critical aspect of your system? And so on.

More importantly, your people are on it. They may not be as technically gifted as the people that manage the cloud centers (or so at least the cloud providers would have you believe), but your people are focused on your servers. Inside the cloud centers, their people are focused on their servers—and restoring service to the cloud center as a whole, not taking whatever means are necessary, including potentially some jury-rigging of servers and networking infrastructure, to get your most critical piece of your IT story up and running again.

Readers may think I’m spinning some kind of conspiracy theory here, that somehow Microsoft is looking to sacrifice its Azure customers in favor of its own systems, but the theory is much more basic than that: Microsoft’s Azure technicians are trying to restore service to their customers, but they don’t really have much preference over which customers get service first, whether that’s you or the guy next to you in the rack. Frankly, for a lot of businesses, you’re the same way: one customer isn’t really different from another. Yes, we’d like to treat them all “special”, but when the stress ratchets up through the roof, you’re not going to quibble over which one gets service first—you’re going to break your neck trying to get them all up ASAP, rather than just a few up first.

Some businesses are OK with this kind of triage on the part of their hosting provider. Some, like the now-infamous cardiac monitoring startup that was based on AWS and as a result lost connections to their patients (a potentially life-threatening outage for them) when AWS went down… yeah, some businesses aren’t OK with that.

Cloud will never replace on-premise hosting. It will supplement it in places, it will complement it in others. The sooner the CTOs and CIOs of the world realize that, the better.

While going through some spam email (well, technically not spam, since I willingly signed up for the ads/product-centric-newsletters, but that is just a mouthful to say), I ran across the App Design Vault 32 Top Resources Mobile App Developers Should Know About list, and had a look. I was somewhat disappointed at the fact that they were all iOS resources, leaving the Android and Windows Phone crowd out in the cold, not to mention Java, .NET, Ruby, and others shivering on the back porch as well.

So, I figured, why not build one that seeks to be a tad more all-encompassing? And rather than try and impose my own sense of order upon the world, and limit it to my own experiences, I choose instead to crowdsource the thing, and let you tell me what you think the top developer resources are.

Because these things have to have some kind of structure, in order to effectively collate all the resources that will be thrown at me, I’m going to ask that you

• Limit your list to five resources. The final list will likely (I hope) contain a lot more, but if you just give me the top five resources you think are invaluable to you as a developer, it’ll make the list more well-considered and pare it down to just the essential stuff you think about.
• Keep the lists somewhat tech-focused. Not in the sense that I don’t want to know about agile resources and what-not, but that I want to hear what your top .NET five are, your top Java five, and so on. Of course, if you really want to just come up with one list across several platforms or categories, go for it. Yours is the comment box, after all. :-)

And if you work for a company or you own a product, please feel free to nominate your tool of choice… so long as there are four others that go along with your baby. Fair is fair, after all. ;-)

And yes, for those who are curious, I will of course inject my own into the list, but I just had this thought latch into my head a few minutes ago, and haven’t compiled my own list yet, so I need a little time to think about it, too.

Roughly speaking, categories that come to mind are: .NET, Java (which I’m assuming to mean mostly enterprise/Java-web kinds of things, but hey, if Swing is your thing, go for it…), Ruby, Web, Game development (any platform), Android, iOS, MacOS, C++ (by which I really mean “any language that compiles to native code”, a la Haskell, C, Delphi, …), and what the hell, PHP. (Perl guys, I’m going to automatically put “Any book teaching some other language” at #1 on your list, just to tweak your nose a bit.) If you have some other categorization, sure, throw that at me, too.

The App Design Vault broke their resources down into a few categories too: Books, Tutorials, Tools, Sites, Forums, Marketing, and Design. Obviously there’s a pretty strong website bias in there (Tutorials, Sites, Forums, Marketing and Design all usually involve websites of one form or another), but feel free to toss in Conferences, Magazines, and whatever else seems useful to you.

Think of it like this: if a programmer writing an app for you were to be stuck on a deserted island with nothing but a laptop and an extremely limited Internet connection, what five things would you want him/her to have with them or access to? (Perhaps more accurately, “a fully-available Internet connection but a very limited amount of time to do anything other than work on your app” is the better way to phrase that...)

And please, no flames or criticism of anybody else’s list. Email ‘em to me, if you’d prefer. (And if you’re reading this through one of the post portals—a la Reddit or DZone—please comment on the original site, tedneward.com, or I probably won’t see your comments.)

Once I have what feels like a sizable list and the suggestions are tapering off, I’ll update this post with the results. No points or awards or endorsements intended—I just want to compile something I think would be useful.

In his Dr Dobb’s overview, Andrew Binstock talks about the prevalence of low-cost, low-powers and suggest in the title of the piece that they have begun their steady ascent over more traditional servers. His concluding statement, in fact, suggests that they will replace the “pizza box” servers we have come to know and love.

Ironically, to me, the notion of a “server” still conjures up images of row upon row of full-tower machines, whirring away. In fact, I have one of those under my work desk at home, doing… nothing. Right now I have it more or less permanently switched off.

Andrew and I have disagreed on things before, but on this score, he’s right: the machines we commonly call “servers” are, step by step, slowly but surely, becoming smaller, quieter, lighter, better power-friendly, and all the other things we have traditionally associated with the client side of the client/server equation. It’s not new: I have a couple of friends who, in order to do “cloud” or “cluster” presentations, carry around with them a small private cloud. One of them carries around (as in, with them to conferences and such) about a half-dozen laptops, the other, a custom-made rack of Mac Minis, a router, and other accoutrements. Yes, if you attend TechEd, you probably know exactly whom I mean.

But this raises some interesting questions. If servers are becoming smaller and lighter and are still fast enough to be considered servers, what does this have to say about infrastructure? Andrew touches on it briefly,

This model of low-cost, low-power devices is the way of the future. What I am describing here is not terribly different than building your own personal cloud from inexpensive machines. If you had chosen to keep the $300, you could have gotten this much from Rackspace's cloud server: 512MB RAM and 20GB HDD running Linux. That's not close to as much horsepower as my machine delivers However, it gives you two advantages: You have no additional ongoing costs (power consumption, parts replacement), and because it's off site, you have an instant off-site backup of your code base. Other companies, such as IntoVPS.com, give you about twice Rackspace's resources for the same price. Eventually, the pricing of cloud options will drop to close to the low-power, on-site devices, I expect. (Source: http://drdobbs.com/tools/232500406?cid=DDJ_nl_mdev_2012-01-25_h&elq=5c23117c5cff4d06820726bd0294693a)

… but putting the discussion of “on-premise” vs “cloud” off to one side for a moment, it raises a more interesting question: if servers are small enough to carry around with us, are they still servers? Historically, the server has always been the machine in the data center, but if we have tools that allow servers to synchronize data between them easily (such as we see going on in tools like Dropbox or Evernote), and the servers are small and portable enough to fit in our pockets, then are they still servers?

Think about this for a moment: the servers that Andrew describes (“a 1.8GHz dual-core Intel Atom chip, 2GB RAM, 250 GB SATA, HDMI, 6 ea. USB, Wifi, and GbE” and “a dual-core 1GHz ARM-based Tegra chip from Nvidia, had robust Nvidia graphics (HDMI), 1GB RAM, a 32GB SSD or a large capacity HDD, and all the USB and other ports you could possibly want”) are hardly the heavy-metal monsters we used to think about when discussing “servers”, and yet still serve the purpose. If we don’t need the server for its processing power, and if we don’t need it for its central location (as a rendezvous point for clients to discover each other and/or centralize data), then what purpose does the server serve?

Maybe it’s time to take a really hard look again into those peer-to-peer ideas from about a half-decade ago.

As discriminatory as this is going to sound, this one is for the old-timers. If you started programming after the turn of the milennium, I don’t know if you’re going to be able to follow the trend of this post—not out of any serious deficiency on your part, hardly that. But I think this is something only the old-timers are going to identify with. (And thus, do I alienate probably 80% of my readership, but so be it.)

Is it me, or is programming just less interesting today than it was two decades ago?

By all means, shake your smartphones and other mobile devices at me and say, “Dude, how can you say that?”, but in many ways programming for Android and iOS reminds me of programming for Windows and Mac OS two decades ago. HTML 5 and JavaScript remind me of ten years ago, the first time HTML and JavaScript came around. The discussions around programming languages remind me of the discussions around C++. The discussions around NoSQL remind me of the arguments both for and against relational databases. It all feels like we’ve been here before, with only the names having changed.

Don’t get me wrong—if any of you comment on the differences between HTML 5 now and HTML 3.2 then, or the degree of the various browser companies agreeing to the standard today against the “browser wars” of a decade ago, I’ll agree with you. This isn’t so much of a rational and logical discussion as it is an emotive and intuitive one. It just feels similar.

To be honest, I get this sense that across the entire industry right now, there’s a sort of malaise, a general sort of “Bah, nothing really all that new is going on anymore”. NoSQL is re-introducing storage ideas that had been around before but were discarded (perhaps injudiciously and too quickly) in favor of the relational model. Functional languages have obviously been in place since the 50’s (in Lisp). And so on.

More importantly, look at the Java community: what truly innovative ideas have emerged here in the last five years? Every new open-source project or commercial endeavor either seems to be a refinement of an idea before it (how many different times are we going to create a new Web framework, guys?) or an attempt to leverage an idea coming from somewhere else (be it from .NET or from Ruby or from JavaScript or….). With the upcoming .NET 4.5 release and Windows 8, Microsoft is holding out very little “new and exciting” bits for the community to invest emotionally in: we hear about “async” in C# 5 (something that F# has had already, thank you), and of course there is WinRT (another platform or virtual machine… sort of), and… well, honestly, didn’t we just do this a decade ago? Where is the WCFs, the WPFs, the Silverlights, the things that would get us fired up? Hell, even a new approach to data access might stir some excitement. Node.js feels like an attempt to reinvent the app server, but if you look back far enough you see that the app server itself was reinvented once (in the Java world) in Spring and other lightweight frameworks, and before that by people who actually thought to write their own web servers in straight Java. (And, for the record, the whole event-driven I/O thing is something that’s been done in both Java and .NET a long time before now.)

And as much as this is going to probably just throw fat on the fire, all the excitement around JavaScript as a language reminds me of the excitement about Ruby as a language. Does nobody remember that Sun did this once already, with Phobos? Or that Netscape did this with LiveScript? JavaScript on the server end is not new, folks. It’s just new to the people who’d never seen it before.

In years past, there has always seemed to be something deeper, something more exciting and more innovative that drives the industry in strange ways. Artificial Intelligence was one such thing: the search to try and bring computers to a state of human-like sentience drove a lot of interesting ideas and concepts forward, but over the last decade or two, AI seems to have lost almost all of its luster and momentum. User interfaces—specifically, GUIs—were another force for a while, until GUIs got to the point where they were so common and so deeply rooted in their chosen pasts (the single-button of the Mac, the menubar-per-window of Windows, etc) that they left themselves so little room for maneuver. At least this is one area where Microsoft is (maybe) putting the fatted sacred cow to the butcher’s knife, with their Metro UI moves in Windows 8… but only up to a point.

Maybe I’m just old and tired and should hang up my keyboard and go take up farming, then go retire to my front porch’s rocking chair and practice my Hey you kids! Getoffamylawn! or something. But before you dismiss me entirely, do me a favor and tell me: what gets you excited these days? If you’ve been programming for twenty years, what about the industry today gets your blood moving and your mind sharpened?

Well, friends, another year has come and gone, and it's time for me to put my crystal ball into place and see what the upcoming year has for us. But, of course, in the long-standing tradition of these predictions, I also need to put my spectacles on (I did turn 40 last year, after all) and have a look at how well I did in this same activity twelve months ago.

Let's see what unbelievable gobs of hooey I slung last year came even remotely to pass. For 2011, I said....

• THEN: Android’s penetration into the mobile space is going to rise, then plateau around the middle of the year. Android phones, collectively, have outpaced iPhone sales. That’s a pretty significant statistic—and it means that there’s fewer customers buying smartphones in the coming year. More importantly, the first generation of Android slates (including the Galaxy Tab, which I own), are less-than-sublime, and not really an “iPad Killer” device by any stretch of the imagination. And I think that will slow down people buying Android slates and phones, particularly since Google has all but promised that Android releases will start slowing down.
  • NOW: Well, I think I get a point for saying that Android's penetration will rise... but then I lose it for suggesting that it would slow down. Wow, was I wrong on that. Once Amazon put the Kindle Fire out, suddenly for the first time Android tablets began to appear in peoples' hands in record numbers. The drawback here is that most people using the Fire don't realize it's an Android tablet, which certainly hurts Google's brand-awareness (not that Amazon really seems to mind), but the upshot is simple: people are still buying devices, even though they may already own one. Which amazes me.
• THEN: Windows Phone 7 penetration into the mobile space will appear huge, then slow down towards the middle of the year. Microsoft is getting some pretty decent numbers now, from what I can piece together, and I think that’s largely the “I love Microsoft” crowd buying in. But it’s a pretty crowded place right now with Android and iPhone, and I’m not sure if the much-easier Office and/or Exchange integration is enough to woo consumers (who care about Office) or business types (who care about Exchange) away from their Androids and iPhones.
  • NOW: Despite the catastrophic implosion of RIM (thus creating a huge market of people looking to trade their Blackberrys in for other mobile phones, ones which won't all go down when a RIM server implodes), WP7 has definitely not emerged as the "third player" in the mobile space; or, perhaps more precisely, they feel like a distant third, rather than a creditable alternative to the other two. In fact, more and more it just feels like this is a two-horse race and Microsoft is in it still because they're willing to throw loss after loss to stay in it. (For what reason, I'm not sure--it's not clear to me that they can ever reach a point of profitability here, even once Nokia makes the transition to WP7, which is supposedly going to take years. On the order of a half-decade or so.) Even living here in Redmon, where I would expect the WP7 concentration to be much, much higher than anywhere else in the world, it's still more common to see iPhones and 'droids in peoples' hands than it is to see WP7 phones.
• THEN: Android, iOS and/or Windows Phone 7 becomes a developer requirement. Developers, if you haven’t taken the time to learn how to program one of these three platforms, you are electing to remove yourself from a growing market that desperately wants people with these skills. I see the “mobile native app development” space as every bit as hot as the “Internet/Web development” space was back in 2000. If you don’t have a device, buy one. If you have a device, get the tools—in all three cases they’re free downloads—and start writing stupid little apps that nobody cares about, so you can have some skills on the platform when somebody cares about it.
  • NOW: Wow, yes. Right now, if you are a developer and you haven't spent at least a little time learning mobile development, you are excluding yourself from a development "boom" that rivals the one around Web sites in the mid-90's. Seriously: remember when everybody had to have a website? That's the mentality right now with a ton of different companies--"we have to have a mobile app!" "But we sell condom lubricant!" "Doesn't matter! We need a mobile app! Build us something! Go go go go go!"
• THEN: The Windows 7 slates will suck. This isn’t a prediction, this is established fact. I played with an “ExoPC” 10” form factor slate running Windows 7 (Dell I think was the manufacturer), and it was a horrible experience. Windows 7, like most OSes, really expects a keyboard to be present, and a slate doesn’t have one—so the OS was hacked to put a “keyboard” button at the top of the screen that would slide out to let you touch-type on the slate. I tried to fire up Notepad and type out a haiku, and it was an unbelievably awkward process. Android and iOS clearly own the slate market for the forseeable future, and if Dell has any brains in its corporate head, it will phone up Google tomorrow and start talking about putting Android on that hardware.
  • NOW: Yeah, that was something of a "gimme" point (but I'll take it). Windows7 on a slate was a Bad Idea, and I'm pretty sure the sales reflect that. Conduct your own anecdotal poll: see if you can find a store somewhere in your town or city that will actually sell you a Windows7 slate. Can't find one? I can--it's the Microsoft store in town, and I'm not entirely sure they still stock them. Certainly our local Best Buy doesn't.
• THEN: DSLs mostly disappear from the buzz. I still see no strawman (no “pet store” equivalent), and none of the traditional builders-of-strawmen (Microsoft, Oracle, etc) appear interested in DSLs much anymore, so I think 2010 will mark the last year that we spent any time talking about the concept.
  • NOW: I'm going to claim a point here, too. DSLs have pretty much left us hanging. Without a strawman for developers to "get", the DSL movement has more or less largely died out. I still sometimes hear people refer to something that isn't a programming language but does something technical as a "DSL" ("That shipping label? That's a DSL!"), and that just tells me that the concept never really took root.
• THEN: Facebook becomes more of a developer requirement than before. I don’t like Mark Zuckerburg. I don’t like Facebook’s privacy policies. I don’t particularly like the way Facebook approaches the Facebook Connect experience. But Facebook owns enough people to be the fourth-largest nation on the planet, and probably commands an economy of roughly that size to boot. If your app is aimed at the Facebook demographic (that is, everybody who’s not on Twitter), you have to know how to reach these people, and that means developing at least some part of your system to integrate with it.
  • NOW: Facebook, if anything, has become more important through 2011, particularly for startups looking to get some exposure and recognition. Facebook continues to screw with their user experience, though, and they keep screwing with their security policies, and as "big" a presence as they have, it's not invulnerable, and if they're not careful, they're going to find themselves on the other side of the relevance curve.
• THEN: Twitter becomes more of a developer requirement, too. Anybody who’s not on Facebook is on Twitter. Or dead. So to reach the other half of the online community, you have to know how to connect out with Twitter.
  • NOW: Twitter's impact has become deeper, but more muted in some ways--people don't think of Twitter as a "new" channel, but one that they've come to expect and get used to. At the same time, how Twitter is supposed to factor into different applications isn't always clear, which hinders Twitter's acceptance and "must-have"-ness. Of course, Twitter could care less, it seems, though it still confuses me how they actually make money.
• THEN: XMPP becomes more of a developer requirement. XMPP hasn’t crossed a lot of people’s radar screen before, but Facebook decided to adopt it as their chat system communication protocol, and Google’s already been using it, and suddenly there’s a whole lotta traffic going over XMPP. More importantly, it offers a two-way communication experience that is in some scenarios vastly better than what HTTP offers, yet running in a very “Internet-friendly” way just as HTTP does. I suspect that XMPP is going to start cropping up in a number of places as a useful alternative and/or complement to using HTTP.
  • NOW: Well, unfortunately, XMPP still hides underneath other names and still doesn't come to mind when people are thinking about communication, leaving this one way unfulfilled. *sigh* Maybe someday we will learn that not everything has to go over HTTP, but it didn't happen in 2011.
• THEN: “Gamification” starts making serious inroads into non-gaming systems. Maybe it’s just because I’ve been talking more about gaming, game design, and game implementation last year, but all of a sudden “gamification”—the process of putting game-like concepts into non-game applications—is cresting in a big way. FourSquare, Yelp, Gowalla, suddenly all these systems are offering achievement badges and scoring systems for people who want to play in their worlds. How long is it before a developer is pulled into a meeting and told that “we need to put achievement badges into the call-center support application”? Or the online e-commerce portal? It’ll start either this year or next.
  • NOW: Gamification is emerging, but slowly and under the radar. It's certainly not as strong as I thought it would be, but gamification concepts are sneaking their way into a variety of different scenarios (beyond games themselves). Probably can't claim a point here, no.
• THEN: Functional languages will hit a make-or-break point. I know, I said it last year. But the buzz keeps growing, and when that happens, it usually means that it’s either going to reach a critical mass and explode, or it’s going to implode—and the longer the buzz grows, the faster it explodes or implodes, accordingly. My personal guess is that the “F/O hybrids”—F#, Scala, etc—will continue to grow until they explode, particularly since the suggested v.Next changes to both Java and C# have to be done as language changes, whereas futures for F# frequently are either built as libraries masquerading as syntax (such as asynchronous workflows, introduced in 2.0) or as back-end library hooks that anybody can plug in (such as type providers, introduced at PDC a few months ago), neither of which require any language revs—and no concerns about backwards compatibility with existing code. This makes the F/O hybrids vastly more flexible and stable. In fact, I suspect that within five years or so, we’ll start seeing a gradual shift away from pure O-O systems, into systems that use a lot more functional concepts—and that will propel the F/O languages into the center of the developer mindshare.
  • NOW: More than any of my other predictions (or subjects of interest), functional languages stump me the most. On the one hand, there doesn't seem to be a drop-off of interest in the subject, based on a variety of anecdotal evidence (books, articles, etc), but on the other hand, they don't seem to be crossing over into the "mainstream" programming worlds, either. At best, we can say that they are entering the mindset of senior programmers and/or project leads and/or architects, but certainly they don't seem to be turning in to the "go-to" language for projects being done in 2011.
• THEN: The Microsoft Kinect will lose its shine. I hate to say it, but I just don’t see where the excitement is coming from. Remember when the Wii nunchucks were the most amazing thing anybody had ever seen? Frankly, after a slew of initial releases for the Wii that made use of them in interesting ways, the buzz has dropped off, and more importantly, the nunchucks turned out to be just another way to move an arrow around on the screen—in other words, we haven’t found particularly novel and interesting/game-changing ways to use the things. That’s what I think will happen with the Kinect. Sure, it’s really freakin’ cool that you can use your body as the controller—but how precise is it, how quickly can it react to my body movements, and most of all, what new user interface metaphors are people going to have to come up with in order to avoid the “me-too” dancing-game clones that are charging down the pipeline right now?
  • NOW: Kinect still makes for a great Christmas or birthday present, but nobody seems to be all that amazed by the idea anymore. Certainly we aren't seeing a huge surge in using Kinect as a general user interface device, at least not yet. Maybe it needed more time for people to develop those new metaphors, but at the same time, I would've expected at least a few more games to make use of it, and I haven't seen any this past year.
• THEN: There will be no clear victor in the Silverlight-vs-HTML5 war. And make no mistake about it, a war is brewing. Microsoft, I think, finds itself in the inenviable position of having two very clearly useful technologies, each one’s “sphere of utility” (meaning, the range of answers to the “where would I use it?” question) very clearly overlapping. It’s sort of like being a football team with both Brett Favre and Tom Brady on your roster—both of them are superstars, but you know, deep down, that you have to cut one, because you can’t devote the same degree of time and energy to both. Microsoft is going to take most of 2011 and probably part of 2012 trying to support both, making a mess of it, offering up conflicting rationale and reasoning, in the end achieving nothing but confusing developers and harming their relationship with the Microsoft developer community in the process. Personally, I think Microsoft has no choice but to get behind HTML 5, but I like a lot of the features of Silverlight and think that it has a lot of mojo that HTML 5 lacks, and would actually be in favor of Microsoft keeping both—so long as they make it very clear to the developer community when and where each should be used. In other words, the executives in charge of each should be locked into a room and not allowed out until they’ve hammered out a business strategy that is then printed and handed out to every developer within a 3-continent radius of Redmond. (Chances of this happening: .01%)
  • NOW: Well, this was accurate all the way up until the last couple of months, when Microsoft made it fairly clear that Silverlight was being effectively "put behind" HTML 5, despite shipping another version of Silverlight. In the meantime, though, they've tried to support both (and some Silverlighters tell me that the Silverlight team is still looking forward to continuing supporting it, though I'm not sure at this point what is rumor and what is fact anymore), and yes, they confused the hell out of everybody. I'm surprised they pulled the trigger on it in 2011, though--I expected it to go a version or two more before they finally pulled the rug out.
• THEN: Apple starts feeling the pressure to deliver a developer experience that isn’t mired in mid-90’s metaphor. Don’t look now, Apple, but a lot of software developers are coming to your platform from Java and .NET, and they’re bringing their expectations for what and how a developer IDE should look like, perform, and do, with them. Xcode is not a modern IDE, all the Apple fan-boy love for it notwithstanding, and this means that a few things will happen:
  • Eclipse gets an iOS plugin. Yes, I know, it wouldn’t work (for the most part) on a Windows-based Eclipse installation, but if Eclipse can have a native C/C++ developer experience, then there’s no reason why a Mac Eclipse install couldn’t have an Objective-C plugin, and that opens up the idea of using Eclipse to write iOS and/or native Mac apps (which will be critical when the Mac App Store debuts somewhere in 2011 or 2012).
  • Rumors will abound about Microsoft bringing Visual Studio to the Mac. Silverlight already runs on the Mac; why not bring the native development experience there? I’m not saying they’ll actually do it, and certainly not in 2011, but the rumors, they will be flyin….
  • Other third-party alternatives to Xcode will emerge and/or grow. MonoTouch is just one example. There’s opportunity here, just as the fledgling Java IDE market looked back in ‘96, and people will come to fill it.
  • NOW: Xcode 4 is "better", but it's still not what I would call comparable to the Microsoft Visual Studio or JetBrains IDEA experience. LLVM is definitely a better platform for the company's development efforts, long-term, and it's encouraging that they're investing so heavily into it, but I still wish the overall development experience was stronger. Meanwhile, though, no Eclipse plugin has emerged (that I'm aware of), which surprised me, and neither did we see Microsoft trying to step into that world, which doesn't surprise me, but disappoints me just a little. I realize that Microsoft's developer tools are generally designed to support the Windows operating system first, but Microsoft has to cut loose from that perspective if they're going to survive as a company. More on that later.
• THEN: NoSQL buzz grows. The NoSQL movement, which sort of got started last year, will reach significant states of buzz this year. NoSQL databases have a lot to offer, particularly in areas that relational databases are weak, such as hierarchical kinds of storage requirements, for example. That buzz will reach a fever pitch this year, and the relational database moguls (Microsoft, Oracle, IBM) will start to fight back.
  • NOW: Well, the buzz certainly grew, and it surprised me that the big storage guys (Microsoft, IBM, Oracle) didn't do more to address it; I was expecting features to emerge in their database products to address some of the features present in MongoDB or CouchDB or some of the others, such as "schemaless" or map/reduce-style queries. Even just incorporating JavaScript into the engine somewhere would've generated a reaction.

Overall, it appears I'm running at about my usual 50/50 levels of prognostication. So be it. Let's see what the ol' crystal ball has in mind for 2012:

• Lisps will be the languages to watch. With Clojure leading the way, Lisps (that is, languages that are more or less loosely based on Common Lisp or one of its variants) are slowly clawing their way back into the limelight. Lisps are both functional languages as well as dynamic languages, which gives them a significant reason for interest. Clojure runs on top of the JVM, which makes it highly interoperable with other JVM languages/systems, and Clojure/CLR is the version of Clojure for the CLR platform, though there seems to be less interest in it in the .NET world (which is a mistake, if you ask me).
• Functional languages will.... I have no idea. As I said above, I'm kind of stymied on the whole functional-language thing and their future. I keep thinking they will either "take off" or "drop off", and they keep tacking to the middle, doing neither, just sort of hanging in there as a concept for programmers to take and run with. Mind you, I like functional languages, and I want to see them become mainstream, or at least more so, but I keep wondering if the mainstream programming public is ready to accept the ideas and concepts hiding therein. So this year, let's try something different: I predict that they will remain exactly where they are, neither "done" nor "accepted", but continue next year to sort of hang out in the middle.
• F#'s type providers will show up in C# v.Next. This one is actually a "gimme", if you look across the history of F# and C#: for almost every version of F# v."N", features from that version show up in C# v."N+1". More importantly, F# 3.0's type provider feature is an amazing idea, and one that I think will open up language research in some very interesting ways. (Not sure what F#'s type providers are or what they'll do for you? Check out Don Syme's talk on it at BUILD last year.)
• Windows8 will generate a lot of chatter. As 2012 progresses, Microsoft will try to force a lot of buzz around it by keeping things under wraps until various points in the year that feel strategic (TechEd, BUILD, etc). In doing so, though, they will annoy a number of people by not talking about them more openly or transparently. What's more....
• Windows8 ("Metro")-style apps won't impress at first. The more I think about it, the more I'm becoming convinced that Metro-style apps on a desktop machine are going to collectively underwhelm. The UI simply isn't designed for keyboard-and-mouse kinds of interaction, and that's going to be the hardware setup that most people first experience Windows8 on--contrary to what (I think) Microsoft thinks, people do not just have tablets laying around waiting for Windows 8 to be installed on it, nor are they going to buy a Windows8 tablet just to try it out, at least not until it's gathered some mojo behind it. Microsoft is going to have to finesse the messaging here very, very finely, and that's not something they've shown themselves to be particularly good at over the last half-decade.
• Scala will get bigger, thanks to Heroku. With the adoption of Scala and Play for their Java apps, Heroku is going to make Scala look attractive as a development platform, and the adoption of Play by Typesafe (the same people who brought you Akka) means that these four--Heroku, Scala, Play and Akka--will combine into a very compelling and interesting platform. I'm looking forward to seeing what comes of that.
• Cloud will continue to whip up a lot of air. For all the hype and money spent on it, it doesn't really seem like cloud is gathering commensurate amounts of traction, across all the various cloud providers with the possible exception of Amazon's cloud system. But, as the different cloud platforms start to diversify their platform technology (Microsoft seems to be leading the way here, ironically, with the introduction of Java, Hadoop and some limited NoSQL bits into their Azure offerings), and as we start to get more experience with the pricing and costs of cloud, 2012 might be the year that we start to see mainstream cloud adoption, beyond "just" the usage patterns we've seen so far (as a backing server for mobile apps and as an easy way to spin up startups).
• Android tablets will start to gain momentum. Amazon's Kindle Fire has hit the market strong, definitely better than any other Android-based tablet before it. The Nooq (the Kindle's principal competitor, at least in the e-reader world) is also an Android tablet, which means that right now, consumers can get into the Android tablet world for far, far less than what an iPad costs. Apple rumors suggest that they may have a 7" form factor tablet that will price competitively (in the $200/$300 range), but that's just rumor right now, and Apple has never shown an interest in that form factor, which means the 7" world will remain exclusively Android's (at least for now), and that's a nice form factor for a lot of things. This translates well into more sales of Android tablets in general, I think.
• Apple will release an iPad 3, and it will be "more of the same". Trying to predict Apple is generally a lost cause, particularly when it comes to their vaunted iOS lines, but somewhere around the middle of the year would be ripe for a new iPad, at the very least. (With the iPhone 4S out a few months ago, it's hard to imagine they'd cannibalize those sales by releasing a new iPhone, until the end of the year at the earliest.) Frankly, though, I don't expect the iPad 3 to be all that big of a boost, just a faster processor, more storage, and probably about the same size. Probably the only thing I'd want added to the iPad would be a USB port, but that conflicts with the Apple desire to present the iPad as a "device", rather than as a "computer". (USB ports smack of "computers", not self-contained "devices".)
• Apple will get hauled in front of the US government for... something. Apple's recent foray in the legal world, effectively informing Samsung that they can't make square phones and offering advice as to what will avoid future litigation, smacks of such hubris and arrogance, it makes Microsoft look like a Pollyanna Pushover by comparison. It is pretty much a given, it seems to me, that a confrontation in the legal halls is not far removed, either with the US or with the EU, over anti-cometitive behavior. (And if this kind of behavior continues, and there is no legal action, it'll be pretty apparent that Apple has a pretty good set of US Congressmen and Senators in their pocket, something they probably learned from watching Microsoft and IBM slug it out rather than just buy them off.)
• IBM will be entirely irrelevant again. Look, IBM's main contribution to the Java world is/was Eclipse, and to a much lesser degree, Harmony. With Eclipse more or less "done" (aside from all the work on plugins being done by third parties), and with IBM abandoning Harmony in favor of OpenJDK, IBM more or less removes themselves from the game, as far as developers are concerned. Which shouldn't really be surprising--they've been more or less irrelevant pretty much ever since the mid-2000s or so.
• Oracle will "screw it up" at least once. Right now, the Java community is poised, like a starving vulture, waiting for Oracle to do something else that demonstrates and befits their Evil Emperor status. The community has already been quick (far too quick, if you ask me) to highlight Oracle's supposed missteps, such as the JVM-crashing bug (which has already been fixed in the _u1 release of Java7, which garnered no attention from the various Java news sites) and the debacle around Hudson/Jenkins/whatever-the-heck-we-need-to-call-it-this-week. I'll grant you, the Hudson/Jenkins debacle was deserving of ire, but Oracle is hardly the Evil Emperor the community makes them out to be--at least, so far. (I'll admit it, though, I'm a touch biased, both because Brian Goetz is a friend of mine and because Oracle TechNet has asked me to write a column for them next year. Still, in the spirit of "innocent until proven guilty"....)
• VMWare/SpringSource will start pushing their cloud solution in a major way. Companies like Microsoft and Google are pushing cloud solutions because Software-as-a-Service is a reoccurring revenue model, generating revenue even in years when the product hasn't incremented. VMWare, being a product company, is in the same boat--the only time they make money is when they sell a new copy of their product, unless they can start pushing their virtualization story onto hardware on behalf of clients--a.k.a. "the cloud". With SpringSource as the software stack, VMWare has a more-or-less complete cloud play, so it's surprising that they didn't push it harder in 2011; I suspect they'll start cramming it down everybody's throats in 2012. Expect to see Rod Johnson talking a lot about the cloud as a result.
• JavaScript hype will continue to grow, and by years' end will be at near-backlash levels. JavaScript (more properly known as ECMAScript, not that anyone seems to care but me) is gaining all kinds of steam as a mainstream development language (as opposed to just-a-browser language), particularly with the release of NodeJS. That hype will continue to escalate, and by the end of the year we may start to see a backlash against it. (Speaking personally, NodeJS is an interesting solution, but suggesting that it will replace your Tomcat or IIS server is a bit far-fetched; event-driven I/O is something both of those servers have been doing for years, and the rest of it is "just" a language discussion. We could pretty easily use JavaScript as the development language inside both servers, as Sun demonstrated years ago with their "Phobos" project--not that anybody really cared back then.)
• NoSQL buzz will continue to grow, and by years' end will start to generate a backlash. More and more companies are jumping into NoSQL-based solutions, and this trend will continue to accelerate, until some extremely public failure will start to generate a backlash against it. (This seems to be a pattern that shows up with a lot of technologies, so it seems entirely realistic that it'll happen here, too.) Mind you, I don't mean to suggest that the backlash will be factual or correct--usually these sorts of things come from misuing the tool, not from any intrinsic failure in it--but it'll generate some bad press.
• Ted will thoroughly rock the house during his CodeMash keynote. Yeah, OK, that's more of a fervent wish than a prediction, but hey, keep a positive attitude and all that, right?
• Ted will continue to enjoy his time working for Neudesic. So far, it's been great working for these guys, and I'm looking forward to a great 2012 with them. (Hopefully this will be a prediction I get to tack on for many years to come, too.)

I hope that all of you have enjoyed reading these, and I wish you and yours a very merry, happy, profitable and fulfilling 2012. Thanks for reading.

As has already been announced, CodeMash 2012 has selected me to give a keynote there this January. The keynote will be my “Rethinking Enterprise” keynote, which I’ve given before, most recently in Krakow, Poland, at the 33rd Degrees conference, where it was pretty well-received. (Actually, if it’s not too rude to brag a little, I watched an attendee fall out of his chair laughing. That was fun.)

For those of you who’ve not seen it (and I hope that includes all or at least most of the 1200 of you attending CodeMash), the talk is an attempt to offer some advice about how to re-think the design and architecture of applications in this new, NoSQL/REST/1-tier/agile/mobile/etc era that we seem to be facing, particularly since some of the “old rules” (app servers, transactions, etc) seem to be fading fast. But it’s not a traditional path we take to get there, and along the way we find out a little bit about history, mathematics, and psychology.

Since I’m there for the full week, but don’t have any speaking responsibilities beyond the keynote and one session on Android Persistence (with Jessica Kerr), I figured it’d be a good time to reach out to the community and offer up some time for consultation and meetings and such. We have a landing page on the Neudesic website that you can use to set something up. (Worst case, you can reach me through the usual channels, but I’m just going to point you towards Kelli Piepkow, who’s coordinating all that, so you’re best off going through the landing page. Besides, we’re giving away what sounds to be a pretty nice digital camera as part of the whole thing—don’t miss that.) So if you’ve got some technical questions (“What is MongoDB good for?” “How does Ruby/Rails stack up against ASP.NET MVC?” or things of that nature), or if you’re interested in finding out about getting us to do some work for you, let’s set something up.

And, of course, if you’re planning to be at CodeMash, remember that it’s being held at the (newly expanded!) Kalahari Resort, which includes an indoor waterslide park, so bring your swimsuit.

Hmm…. Maybe we can schedule some of those meetings in the Wave Cove.

See you there!

Many of you have undoubtedly noticed that my blogging has dropped off precipitously over the last half-year. The reason for that is multifold, ranging from the usual “I just don’t seem to have the time for it” rationale, up through the realization that I have a couple of regular (paid) columns (one with CoDe Magazine, one with MSDN) that consume a lot of my ideas that would otherwise go into the blog.

But most of all, the main reason I’m finding it harder these days to blog is that as of July of this year, I have joined forces with Neudesic, LLC, as a full-time employee, working as an Architectural Consultant for them.

Neudesic is a Microsoft partner (as a matter of fact, as I understand it we were Microsoft’s Partner of the Year not too long ago), with several different technology practices, including a Mobile practice, a User Experience practice, a Connected Systems practice, and a Custom Application Development practice, among others. The company is (as of this writing) about 400 consultants strong, with a number of Microsoft MVPs and Regional Directors on staff, including a personal friend of mine, Simon Guest, who heads up the Mobile Practice, and another friend, Rick Garibay, who is the Practice Director for Connected Systems. And that doesn’t include the other friends I have within the company, as well as the people within the company who are quickly becoming new friends. I’m even more tickled that I was instrumental in bringing Steven “Doc” List in, to bring his agile experience and perspective to our projects nationwide. (Plus I just like working with Doc.)

It’s been a great partnership so far: they ask me to continue doing the speaking and writing that I love to do, bringing fame and glory (I hope!) to the Neudesic name, and in turn I get to jump in on a variety of different projects as an architect and mentor. The people I’m working with are great, top-notch technology experts and just some of the nicest people I’ve met. Plus, yes, it’s nice to draw a regular bimonthly paycheck and benefits after being an independent for a decade or so.

The fact that they’re principally a .NET shop may lead some to conclude that this is my farewell letter to the Java community, but in fact the opposite is the case. I’m actively engaged with our Mobile practice around Android (and iOS) development, and I’m subtly and covertly (sssh! Don’t tell the partners!) trying to subvert the company into expanding our technology practices into the Java (and Ruby/Rails) space.

With the coming new year, I think one of my upcoming responsibilities will be to blog more, so don’t be too surprised if you start to see more activity on a more regular basis here. But in the meantime, I’m working on my end-of-year predictions and retrospective, so keep an eye out for that in the next few days.

(Oh, and that link that appears across the bottom of my blog posts? Someday I’m going to remember how to change the text for that in the blog engine and modify it to read something more Neudesic-centric. But for now, it’ll work.)