Some thoughts on the iPad

Last week the Net was in "full hype mode" for the launch of the latest Apple device. The outcome anyway is rather controversial, maybe expectations were set too high, leaving somebody down.

Only time and revenues will tell who's right: but I think a few things that emerged from recent discussions are worth thinking about.

It's all about being sexy

What's the ugliest part of an electronic device? Cables. They're messy, and despite every effort to make them look pleasant ...they are ugly, and probably always will. I suspect that the lack of connectors is a way to discourage users from plugging in many devices: famous actresses look a lot more ordinary without the make up. And they hate showing up in public if they have some imperfections on the skin. It's called vanity. The best way to satisfy vanity is to make the iPad an essentially wireless device. Cables are for losers, they're necessary, but only when nobody's watching.

However, if you still feel like you need to upload pictures, connect to external devices... you'll maybe end up buying another device like the AirPort.

Gestures matters

Some folks complained it's less than an iPhone. Wow ...it's big! Do you really would like to phone with a big device like this? It doesn't feel natural. Our body learned to associate gestures with situations, and we phone with small objects (like ...phones) and we read with bigger ones (like magazines, books and newspapers). I think the whole idea is to make the device feel natural. Things or actions that wouldn't fit the device were simply not included.
Looks like the whole idea is to be a device do be used on the couch. Relaxed, and quiet. Like ...reading a book, but not necessarily so.

A pleasant experience

iBook and the relative store, are more than a hint that Apple is engaging Amazon in the book battle. Some friends noted that reading a book requires a different display, to be a pleasant experience for the eye. I think they're right on this. Sill the iPad is not a device to do one thing (as it is for Kindle) but to do many. And not all of them are necessarily known from the beginning.

No multitasking

Some people consider the lack of multitasking capabilities as a key missing feature on the iPad. I think the opposite. Frequent interruptions are stressing, and to me the iPad looks like a thing to do one thing at a time (which by the way is the basic mantra of GTD, Kanban and so on). If you want to torture yourself by being continuously interrupted, a phone or a PC are the tools for you, and this is what you probably use for working. But if you want to please yourself, relaxing on the couch, the only other thing to do while using the iPad is probably having a glass of good wine. Or maybe that's the picture of you that will stick in your brain to make you buy that thing.
I suspect that also the lack of a camera has something to do with that. I mean ...Apple put cameras in MacBooks ages ago: they know how to build devices with cameras. But the stressing feeling of being continuously reachable is what makes people hate cell phones. A device that allows you to surf/read without being interrupted that often, could be loved by some.

It's not for the geeks

Maybe I am a little bit too far on this, but I think the iPad is targeted to a part of the market that had been partially untouched from other Apple products. Think about the agenda: it really feels like a real agenda, with all the potential of an application. There are quite a few users that still prefer planning on paper rather than on a blackberry or an iPhone, cause you don't see the whole picture there. More generally, geeks feel comfortable with complexity and multitasking. Many folks don't.

I have to admit i bought the iPhone for 2 reasons: learning and vanity. The reasons I use it now are completely different, and I discovered them while using it. So I think it's still early to have a precise idea of the potential, and of the marketing success, but really looks like "less is more" has been a design driver this time.

We can do better than this... Reloaded

In the last Italian Agile Day I delivered an open presentation called "Possiamo fare di meglio" (this post's title is just the translation), where I raised some questions about the way we develop software. I then tried to summarize some of the things that emerged in the discussion here, but there are still many things that are bouncing in my head...

One thing that really disappoints me is the low quality of many software applications I have to deal with in my everyday life. Some days I really feel like I am surrounded by crap. Just to make it clear what I am talking about: here is an excerpt of what a home banking service is asking me every single operation I do.

Choose the desired account:

My Company Account (all the accounts)

And every time I think: "It's one account, it's just one account, it's always been just one account, so why on Earth you keep asking me this question every time! Couldn't you just take me straight to the account...".

Some days I just feel like surrender, some other I see how some application are doing a fantastic job, on platforms like iPhone or on the web, and I feel like there's still some hope for us.

There is still a lot to do

Despite all of our efforts, to introduce TDD and continuous integration, velocity based estimations and the like. There's a lot to do in other fields as well. Let me say it in another way: many companies are looking towards agile methodologies as a way to improve their development processes, in order to deliver software on time and on budget.

Doesn't sound that bad isn't it?

It does. It doesn't mention the quality of the product. ...Oh, yes, we forgot, we need also tests to reduce our defect ratio. Tests are good, software quality is good, but still doesn't address the whole point. We should deliver better products. Emphasis on the process itself would satisfy the managers' ancient need for schedules and predictable outcome, allowing teams to produce crap more efficiently, but would not produce better products unless some key points are specifically addressed.

The most neglected areas at the moment - at least from my point of observation - are:

1. user's involvment,
2. understanding the domain complexity,
3. lack of an overall perspective,
4. inefficient learning during the product development lifecycle.

The items are not completely separated, in fact they're slightly overlapping, but I think these are the areas where as software developers we can (and must) improve a lot.

In the next posts I'll dig deeper in these topics.

Shared the Agile Day Presentation

The Slideshare version of my "Possiamo fare di meglio" (we can do better than this) presentation, is now available (in Italian) here.

I did my best to add comments to the many pictures, sooner or later also the video version will be available.

A crowdsourcing experiment

Like one year ago, I decided to give my talk at Italian Agile Day as an open session with roughly the same schema: 15-20 minutes of impact talk, and 30 minutes of open discussion. I like this type of sessions because it’s not a “I know the truth” approach (I don't), but rather a way to make a small portion of a possible truth emerge from anyone in the room. So, even if I had some answers in mind, I preferred to focus on the questions, leaving the answers eventually open. I’ve seen some open sessions, but it’s not the kind of things that you practice every week (unless you’re leading a talk show), so please forgive me if it anything went wrong. Personally, I think it went a lot better than the year before: the discussion flew naturally and touched many of the topics I wanted to touch.

See it in another way
Ok, now think of me like Dr.Evil, with a “masterplan”: I’ve managed to hire about 200 among the best IT professionals I know as consultants for one hour. Basically for free. That’s my crowdsourcing experiment. And I had the feeling of so many little things emerged. Maybe not so clearly, maybe not so well formed or well expressed, but enough to make me think a lot in the following days.

On the way home, and later in the weekend some thoughts were a little clearer. I guess my personal follow up is worth sharing: at least ...I owe it to the participants. :-)

We’re making products, not software
Software is what we know, what we like to write, what we learned to produce. Some of us are really good in writing software, or in making their team write good software. That’s only half of the story: from the user perspective we see a product, not code. In the discussion, many mentioned user interface or the user experience. Which is right. But it’s still trees, not the forest. If we start thinking about the overall product we might realize that we need to see the whole a lot better than we usually do. Scrum has a good shoot on this by emphasizing the role of the Product Owner, meaning that we have a single responsible person (which is a gift from the gods in many organizations) for the whole product. There’s a problem up there, because so many times the whole idea of product is flawed, and we’re just writing software. Guess what... with a high probability of being completely useless.

I’ve seen so many projects missing their goals or their potential, just because the responsible organization didn’t have a clear idea of the whole product not to see a pattern here.

Non technical integration is not so easy
Ok, so we should try to have an all-round view to our product. Including also non developers roles within our project scope. Interesting but tricky. Especially if the team boundaries do not match with the company boundaries, which might happen quite often in a cross-functional team. But software-only teams can control continuous integration to a very high degree of efficiency using TDD, Continuous Integration and SCM tools. But this is only a portion of the product. Other professional might follow a different approach, that has nothing to do with TDD (or maybe it has... only on a different time scale), and the perfection we strived to achieve becomes frustratingly fragile. I guess there’s no easy recipe here, we’ve got to fall back on mantras like “inspect and adapt”: solutions might be a lot different from team to team. After all we’re humans. But it’s funny to realize that we sometimes we want to “integrate early and often” but “only software artifacts, please”. Postponing integration with non-software components of your project is even riskier.

This is definitely a hot topic, especially if you approach it from an enterprise management perspective: enterprise 2.0 folks are talking about more flexible approaches to collaboration, and this might be at odds with the benefit of a jelled team.