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.

Share/Bookmark

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.

Share/Bookmark

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.

CMU is one of the premier Computer Science programs in the country. I find it disappointing that they are moving away from OO toward functional. I can’t argue with them about the advantages of functional programming. I like functional programming for two reasons.

1. Functional programming requires a lot of cleverness. Everything is a little logic puzzle. For a mathematician, it’s a ton of fun.
2. Functional programming is hard. Not everyone can do it and it reinforces my notion that I am cleverer than most folks.

As an entrepreneur delivering software every day, however, I’m not enamored of functional programming for those same reasons. You need truly exceptional developers to be able to cary off a project in a functional language. Also, simple things can be surprisingly difficult in a functional language (think of the amazing productivity of XSLT ).

Even OO can be difficult. The hill from Procedural to OO is not as steep as that to Functional, but not everyone can do it and they do need some training.

I think that what will likely happen with CMU students is that they will take the OO course anyway, or they will learn OO outside of school on open source or personal projects.

Share/Bookmark

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.

A Thought Experiment on Rewrites

It is possible to do complete rewrites. It happens all the time, only it’s usually competing companies that are “rewriting” their competitors products and launching them. Think Apple and the iPhone versus the old crop of smart phones. Obviously having a single company launch a competing product to an existing one is a bit more complicated. But there the problem is not one of code or software product development, but rather of channels, marketing, brand, existing customers, etc. In short, it is a business problem, not a technical problem.

Other times the technical debt is just so large that rewriting is the only choice. In these cases — usually not developed with an agile or really any sort of method (pet peeve: methodology is the study of methods) — there’s the additional issue of poor or non-existent requirements. In this case you are essentially forced to define the product all over again. Risky? You betcha. Something to be avoided? Without a doubt. Avoidable? Not at that late a date.

The Cadaver in the Boardroom

While Steve gets the risk of rewrites right, I think rewriting versus not rewriting is a false choice. By that I mean that if you’ve arrived at that choice, you’re already dead; rewriting versus trying to resuscitate a troubled code base is a no-win decision. They’re both expensive, they’re both risky, and neither one of them is likely to succeed.

At fault is that the perceived risk of not doing the right thing in a single iteration seems so low. Let’s not refactor now, we don’t have the time. We have too much to do to pair. Let’s skip TDD for just a few stories while we get the next release out. Let’s not fix the broken continuous integration system for now.

All of these little simple shortcuts result in bad development habits (and, after all, a large part of agile is an accumulation of good habits) and a vicious cycle of increasing technical debt.

Then it’s not the CEO or VP of Development’s fault for making a “wrong” decision. It really doesn’t matter at that point. The company is already a corpse, stinking up the boardroom.

Share/Bookmark

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.

Share/Bookmark

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?

Share/Bookmark

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.

Share/Bookmark

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.

Share/Bookmark

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.

Share/Bookmark

photo credit: wolfsavard

So I’ve been working on a number of geolocation enabled iPhone apps recently. In the latest SDK, the simulator supports geolocation, so I don’t have to push the apps to the device all the time. Great.

Now as it happens, I have both wireless and wired on at the office, so I can easily move from place to place but also get better bandwidth when I plug in. The other day I had to turn off wireless (wired and wireless are on separate subnets). Within a few minutes, the geolocation on the simulator crapped out.

As it turns out, wireless has to be on in order for the simulator to perform geolocation. It’ll cache the results for some minutes, but no updates, and then, poof! So, be aware of this constraint in the simulator when developing geolocation enabled apps.

Share/Bookmark