Tuesday, March 20, 2012
Unlearn, young programmer

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.

“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.



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?

Tuesday, March 20, 2012 11:44:21 PM (Pacific Standard Time, UTC-08:00)
Comments [12]  | 
 Friday, March 16, 2012
Just Say No to SSNs

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.

.NET | Android | Azure | C# | C++ | Conferences | Development Processes | F# | Flash | Industry | iPhone | Java/J2EE | Languages | LLVM | Mac OS | Objective-C | Parrot | Personal | Python | Reading | Review | Ruby | Scala | Security | Social | Solaris | Visual Basic | VMWare | WCF | Windows | XML Services | XNA

Friday, March 16, 2012 10:10:49 PM (Pacific Standard Time, UTC-08:00)
Comments [1]  | 
 Saturday, March 3, 2012
Want Security? Get Quality

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?

.NET | Android | Azure | C# | C++ | F# | Flash | Industry | iPhone | Java/J2EE | LLVM | Mac OS | Objective-C | Parrot | Python | Ruby | Scala | Security | Solaris | Visual Basic | WCF | Windows | XML Services

Saturday, March 3, 2012 10:53:08 PM (Pacific Standard Time, UTC-08:00)
Comments [0]  | 
 Friday, March 2, 2012
Leveling up “DDD”

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?)

.NET | Android | Azure | C# | C++ | F# | iPhone | Java/J2EE | Languages | Mac OS | Objective-C | Parrot | Python | Ruby | Scala | Visual Basic

Friday, March 2, 2012 4:08:57 PM (Pacific Standard Time, UTC-08:00)
Comments [8]  | 
Windows 8 Consumer Preview

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.

Friday, March 2, 2012 1:03:40 AM (Pacific Standard Time, UTC-08:00)
Comments [1]  | 
 Thursday, March 1, 2012
Can we pronounce “The Cloud” hype over yet?

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.

Thursday, March 1, 2012 11:00:51 PM (Pacific Standard Time, UTC-08:00)
Comments [2]  |