Archives

Consider this the opening volley in our campaign for Lean Branding, the argument that branding has to follow the same course as customer and product development. More on this later. First a good argument on why you shouldn’t just plaster your brand over any and every aspect of your app or webapp.

Jonathan Anderson has a great post over at UX Magazine entitled Your Logo Is Making Me Sick. In it he argues that using a company’s logo or brand as the most striking part of a critical failure or error message is a common self inflicted wound and should be avoided.

Years ago, my mother got a nasty case of food poisoning from an order of chicken tikka at a restaurant. For years after that, if I’d sneak up behind her and say, “Chicken tikka!” she’d crumple into a bout of dry heaves.

Funny and informative. Give it a read.

photo credit: codepo8

RIM is putting the remaining stock of it’s BlackBerry Playbooks on clearance for $299. This is after HP engaged in a rummage sale of both it’s new and refurbished WebOS tablets. What are buyers running on the hacked devices? That’s right, Android.

That’s now two major players who have thrown up their hands rather than compete. For Microsoft it means a long uphill climb against two established competitors. Nokia won’t help MS much here, once Android squishes their existing phones out of the developing world marketplace.

So what will MS have to do to establish a toehold? One or both of two things:

1. Hope that their aspirationally dubbed phones really are "super" and have something that people really can’t live without. Teleportation?
2. Are able to run Android apps out of the box but offer some better functionality or experience than the Android devices.

Given that MS hasn’t set the world on fire with it’s previous mobile product development efforts (is anyone doing real customer research over there?), I wouldn’t hold my breath.

photo credit: Daquella manera

I’m always on the search for examples that illustrate the difference between problem and solution in product design. Recently, I’ve found a really sweet one.

In our various processes — whether it’s customer development, product design, or usability analysis — we end up asking people about their problems. What works for them; what doesn’t  work for them; what takes too long; what seems unnecessary? We asks lots of leading questions and play lots of little games to get at the underlying question of problem. Only then do we propose solutions to that problem and vet them with customers.

If you misunderstand the difference between problem and solution, you’ll end up launching a SaaS product for travel agents rather than Expedia or Orbitz.

My favorite example illustrating this problem up until recently was the automated scanning of license plate numbers at places like toll booths. It turns out that with dirt, lighting conditions, blur from movement, and different angles of the plate, this is a really hard problem. But it isn’t the real problem. You want to identify cars, not scan letters. Adding some sort of bar code that is much easier to scan than letters would solve the real problem.

My new favorite example is the beat-less artificial heart. If the problem is constructing an artificial version of the human heart, then we have mechanical versions of that. They have quite a few moving pieces and the unfortunate tendency to fail more often than we would like. If we look at the problem more closely, however, we see that the only reason a heart has to beat is that it is a muscle. Muscles need to expand and contract in order to keep working. But the problem really isn’t about that. It’s about circulating blood around the body. A highly reliable rotary pump with only one moving part and no beat will do just as well. The rest of the body doesn’t care that the blood pressure is constant and there is no pulse.

If you are an entrepreneur or product manager, realize that good problem analysis isn’t a luxury, but a critical step before you stumble toward a solution nobody may want.

We are big believers in hiring fresh graduates into our apprenticeship program. Get good people young and mentor them into outstanding agile developers.

We recruit graduates nationwide, but we do see a large proportion from the Midwest — Depaul, UIC, IIT, Loyola, Perdue, Indiana, Champagne-Urbana. As a result, we have good familiarity with the curriculum of those schools. For the most part they focus on Java in the classroom. At the same time they neglect OOAD (Object Oriented Analysis and Design) and OOP (Object Oriented Programming). It may see odd to teach an OO language and not give students the tools to do so effectively. It more than seems; it is odd.

Usually the folks we hire have shown a lot of personal initiative and done a fair amount of outside work on OO and things like unit testing. But a formal foundation in the classroom would make finding qualified candidates so much easier.

Now comes the news that CMU (Carnegie Mellon University) is dropping mandatory OO classes from it’s undergrad CS curriculum.

Object-oriented programming is eliminated entirely from the introductory curriculum, because it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum. A proposed new course on object-oriented design methodology will be offered at the sophomore level for those students who wish to study this topic.

photo credit: mel_rowling

Steve Blank writes a thought provoking article about the folly of the complete software rewrite. He envisions a scenario where an agile team builds a product and that product gradually accumulates technical debt until it is difficult to maintain and, I assume, add new features.

The benefits of customer and agile development and minimum features set are continuous customer feedback, rapid iteration and little wasted code. But over time if developers aren’t careful, code written to find early customers can become unwieldy, difficult to maintain and incapable of scaling. Ironically it becomes the antithesis of agile. And the magnitude of the problem increases exponentially with the success of the company. The logical solution? “Re-architect and re-write” the product.

For a company in a rapidly changing market, that’s usually the beginning of the end.

First, you should be careful to avoid the unnecessary accumulation of technical debt. You need to refactor with each iteration. You can’t avoid all technical debt, but can keep it small enough so it doesn’t snowball into a problem.

Second, you need to keep the user experience design debt under control as well. Your information architects have to keep an eye on the actors/personas and the overall arc of a feature as user stories are added and modified. Not only does design debt adversely affect maintainability, it also results in technical debt, as the code is contorted into supporting disjointed workflows and features.

Still, these agile projects usually have something going for them: they have good and lean documentation on functional and non-functional requirements. If you do have the original development team, you may be able to pull off a rewrite, but if you can, it’s clearly less risky to try to refactor the code.

photo credit: 3liz4

Depending on who you ask, IE’s market share hovers either just above or just below 50%. While other browsers have made inroads, it’s still the big dog on the block. If you look at IE6, however, there are good arguments that we shouldn’t be counting them when calculate percentage share.

1. CTO’s force IE6 as a standard to prevent employees from using the latest and greatest sites. Whether that means that company policy discourages conducting private business at work or preventing AJAX security exploits, these are likely not your best customers.
2. IE6 usage peaks during business hours and falls off dramatically outside of that. This supports the hypotheses that visitors are using IE6 for work and using a more modern browser for personal activities.
3. Visitors with IE6 tend to be technologically backward and have somewhat lower conversion rates than those with newer browsers.

If we discount IE6 users and just focus on those with newish to newer browsers, we get a somewhat different picture. Taking the Net Apps browser market share stats for December 2010, the raw market share for IE is 57.08%. Subtracting and adjusting for removal of the 13.06% share for IE6, the market share for IE is now 50.63%. And that’s for the most optimistic of all of the market share reports. With some of the other reports, fully 60% of all visitors don’t use IE.

So, while the argument for not focusing exclusively on IE was already strong, this makes it stronger. Given the downward trend with IE, and the upward trend with mobile browsers, focusing your precious resources on mobile makes a lot of sense.

That’s all we needed, really, a new logo. Does anyone else feel the need to have this stitched onto a leotard with a cape?

photo credit: geoftheref

OK, so maybe it isn’t really news. But Robert Cringley has eulogized email quite nicely. As someone who still remembers the thrill of sending his first email via BITNET, I feel it deserves a good eulogy if nothing else.

I have in my computer every e-mail message I have sent or received since 1992. Minus the obvious spam, this database comes to about half a million messages from people as varied (or similar, if you think about it) as Larry Ellison and Larry Flynt. But lately my e-mail seems to be dying. Yours is, too.

Many of the new and competing channels that Cringley discusses are currently just a smokescreen for the same old stuff, i.e. blog posts all pushed and re-pushed via different media – Facebook, twitter, etc.. Just see Cringley’s tweets as an example.

photo credit: mbiebusch

I first learned about the indie video game Minecraft when Paypal froze the developers account with 600,000 Euros in it. The game, a kind of retro low res but addicting game has since gone on to sell over 500,000 copies. Doing a quick calculation at the current price of 9.95 Euros, that about $7.5 million dollars in revenue.

This indie game phenomenon — Marcus “Notch” Persson isn’t the only indie game developer, just the most successful — reminds me a little bit of the indie movie world. There’s a few things that are similar, but there are differences that makes this sort of success possible in the online software world.

The Similarities

• There are tools now, the open source Lightweight Java Game Library for instance, that allow amateurs on a low budget to achieve professional results. In contrast, big game and film studios pump in huge amounts of dollars to try and guarantee success.
• There is an entrepreneurial culture — a willingness to quit your job and bootstrap something.
• Marketing. Indie films and software rely on word of mouth for their early success.

The Differences

• Distribution. It’s cheap on the internet. Once you get so successful that it requires some investment, it’s still comparatively cheap. By comparison, you can’t really do it yourself in the film biz. Someone has to help with the distribution (though that may change with streaming Netflix).
• Payment (as long as Paypal doesn’t act like a**holes) is pretty easy for online sales.

I think it may be too soon to predict the death of big studio games, but the indie software phenomenon is an important part of the competitive landscape and is here to stay.

photo credit: Center for
American Progress Action Fund

Harry Reid hung on to beat Sharron Angle this past election day. It wasn’t that the voters of Nevada loved him, it was just that the other candidate was so much worse. Much the same can be said of Java for enterprise applications: meh, but the alternatives are worse.

That’s not surprising, as most of the alternatives to Java have focused on the things that made Java such a poor solution for webapps — over engineered, thousands of different ways to roll your own application architecture, slow dev/compile/test cycles because of the JVM. But those same alternative left the back-end enterprise space alone.

Back in 2005 or so, the rise of Ruby on Rails hit Java like a gut shot. Java book sales started a free fall. But when it comes to the enterprise, i.e. highly scalable, high performance backends, Java is hanging tough. Over the last two years we’ve seen lots of hybrid Rails front-end, Java back-end solutions. The Rails part gives you the highly productive web development, the Java back-end gives you the highly scalable architecture.

This story should be familiar to anyone who has followed the first big Rails success story: Twitter. They moved to a Scala back-end for a variety of reasons. And of course Scala runs on top of the JVM (much like Groovy, it is a mutant cousin of Java). The other big competitor to Java in the enterprise space — C# — is still trying to have it both ways, competing with Java for the back-end services, and with Rails for the front-end webapps. I think MS is going to have to commit one way or the other rather than sitting between all chairs.