The final words about software estimation - Pecha Kucha talk

Here are the slides of my Pecha Kucha lightining talk I gave at #ALE14 in Krakow. Kind of a quick reminder (or kick in the butt, in case one forgot...).

The intrinsic non repeatability of the change agent

After 3 really intense days of ALE2014 in Krakow, this morning my brain was busy connecting the many sparse dots and the many insights popping out from talks, open sessions and private conversations, including late night ones.

There’s a fundamental clash between the way change agents and organisational consultants act and the way the market is looking for their services. Let me explain it.

What the market is looking for

When selecting/interviewing a change agent the buyer company, most of the time ends up falling into two fundamentally flawed questions:

• Which results can you guarantee?
• Have you done this before?

Let me explain why they’re both fundamentally flawed and why you should try to challenge them from the start. Beware, I said flawed, but I didn’t mean they’re not legitimate questions: the buyer/customer company might be new to change initiatives and looking for some certainty. Statistics shows that 70% of change initiatives fail, and that those numbers are substantially flat from the eighties (thanks to Steven Parry for showing this data). So risk is inevitably there. But the way to manage risk is probably to hire a good consultant, with previous experience on the matter, in order to mitigate that risk, or to implement some just in case ‘cover my ass’ strategy.

 

This leads to a couple of weird problems: success in previous initiatives is no guarantee of success in the new one. More than anywhere else, context is king. And context is mostly out of the change agent scope, at least in the early days. A common trait of experienced change agents is the ability to detect critical, non removable impediments quickly (in the initial interview or in the early assessment) so that they end up having a better record, by avoiding customers with low success probability. Which sounds a lot like the old Sun Tzu’s advice: “battles are won before they’re ever fought”.

 

A more legitimate meaning of the ‘Have you done this before?’ question is to check previous references. This is probably the best thing to do, especially if it involves talking with somebody to know something more about the person, the style and the possible surprises that may arise.

What happens in reality

But the other implicit issue is that this often hides the tendency of thinking in terms of the wrong complexity context.  Of course we don’t expect our customers to be familiar with the Cynefin Framework, but guarantee and repeatability are thinking tools for complicated systems. While in a complex system there is no guarantee that repeating an action will lead to the same result.

 

If you hire Mourinho as a football coach, you’re sure you’re going to pay a lot of money, but there is no guarantee that he will deliver the expected result. This is what makes soccer still interesting, by the way.

 

But one other aspect gets too easily forgotten. In a change management initiative, or more specifically in an agile transformation, the system is not the only thing that changes. The change agent, changes as well. It’s not only experience, it’s scars. It’s emotions, and last but not least it’s learning.

The agent changes too

One thing that the customers rarely understand is that sometimes we do something really special, something that we’ve never done before. And this turns out special just because we’re doing it for the first time. It’s something probably similar to improvising in a jazz way. In Jazz music, it takes a lot of mastery to be able to improvise, but that performance is intrinsically non repeatable. And trying to repeat it will probably make it worse. The second time a band tries to jam on a given tune, the magic won’t be there.

 

The other thing that we often forget to consider is the emotional overload of such things. After a success, or a failure, or simply when the time has come, would you just ‘be ready to start over?’ I suspect the plain answer can be “no". Just like some people need some thinking time between a love story and another one, ending an initiative and starting a new one with a new customer right away might be a really bad idea. Without the initial curiosity, and freshness the new mission will risk to be ‘just a new job’, without the magic.

 

 

 

 

 

 

 

EventStorming Recipes

Just uploaded the slides of my talk at DDDeXchange London. Thanks to everybody for the great conversations.

Event storming recipes from Alberto Brandolini

Not Dead Yet

Like it or not, David Heinemeier Hanson did it. By starting the debate around the “Is TDD Dead” topic, he forced the whole agile community to re-think about many issues that were taken for granted. You may like his opinion or not, you may prefer to choose his side or Kent Beck side, or the more radical one from Robert C. Martin. Or you may also appreciate the way Martin Fowler proposed to sort out the issue, in a way that is a great example of “this is how we discuss things in the agile community”.

I personally liked the fact that many collateral discussion spread out on the topic, the best ones I had with Francesco Fullone and Matteo Vaccari. Here are some of the thoughts they helped shaping.

Who’s paying for what

I remember the old argument that 90% time on code is spent on maintenance, so it does make a lot of sense to write software that’s easier to read an maintain. This is what I normally do, or, better, this is what I relentlessly keep trying to do.

But the more I look around the more I realise that this statement leads to a quite naive approach. This is not how most developers are working right now.

Let me explain that.

It’s not about the code

Given 90% of time spent on code is in fact maintenance, it makes a lot of sense to try to improve this 90% instead of the 10% spent writing new stuff. Unless…

…unless we stop focusing about code and start looking at human beings surrounding it. Some call them developers, but I am really more concerned about the human being, not the role.

Humans move, evolve, grow, move to another team and another company. Humans will be far away the moment evolution will be needed on a given piece of code. They won’t be there to take the praise for well-written maintainable code as well as they won’t be there for talking the blame for horrible legacy code.

Even worse: once they’ve left, they might be blamed also for supposedly well-written code, if the new developer who’s now taking care of their beloved source code has a different programming style. Or simply doesn’t like their indentation style, or what was intended to be good coding practice at the time the code was written.

If I don’t plan to stay around a piece of software for a long time, writing maintainable code is dangerously close to an exercise of style. Many practices are said to repay themselves in the long term but no one stays around long enough to catch the benefit

Being short-term sustainable

Yep. In the long term.

That’s the thing I really don’t like. It sounded like reasonable first time I heard it, but now it has the sinister sound of I have no evidence to support it, just faith.

And in a world where software development workforce is made not only by internal developers, but also consultants, freelancers, contractors, offshore developers and part-time hackers (just to name a few) the implicit assumption that

if you don’t code right, technical debt will bite your back 

is flawed.

Well, technical debt is a bad thing. It’s probably worse than we think. Companies deliver horrible services due to technical debt, they struggle, collapse and ultimately sink for technical debt.

But well… who cares! Big companies will survive anyway. For small companies… it’s just darwinian selection. As a developer I’ll move somewhere else soon (disclaimer: I have a bias for not hiring developers who previously worked in companies that sunk).

So, I guess the real story with technical debt should be rephrased like

if you don’t code right, technical debt will bite somebody’s back

meaning …Not necessarily yours. Call me cynical, but by the time your crappy code will unleash its sinister powers you’ll probably be in another company complaining about a different yet stinky legacy codebase. Time for a soundtrack: try this.

A little tragedy of the commons

If code stays around longer than the expected lifespan of developers there’s not much that we can do to prevent technical debt to flourish. It’s just another version of the well known tragedy of the commons, that economists know very well: people acting in their own interest will ultimately harm a greater good.

A system view

Thinking of a codebase as a part of a larger system, if independent agents aren’t there to stay, they won’t improve the system. I remember my days when I was a university student. I hated it. I probably hated every single exam. The way it was led, taught, and the way students were evaluated. But the thing I hated most was that the whole system was hopeless: nobody liked it, but nobody really put any effort in changing the system. Students were not there to stay, the winning strategy was to keep your mouth shut and pass the exam. It will be somebody else’s business, not ours.

Does it sound familiar?

If the time needed to be rewarded for an effort is longer than the expected time in the system, well …who cares?

Enter the Boy Scout Rule

Interestingly, Uncle Bob proposed a solution for that: the so-called Boy Scout Rule, which goes as follows:

always leave the campground cleaner than you’ve found it

I love it, for many reasons. It creates a sense of ethics and belonging. It provides a little quick reward: “I am doing something good here”. But the most interesting thing is that it turns a rational argument into an ethical and moral one. Boy Scouts do not rationally believe that every forest will be cleaned up if everybody starts behaving the way they do. But the feeling of doing something good and right, is a good one. And moral - together with the fear that Uncle Bob in person will one day see my code and throw me in the flames of hell as a consequence - will probably do a better job.

A higher duty

Who should care for the system? Who should ‘enforce’ (I hate this term) the boy scout rule? It’s pretty clear that this is the job of somebody who’s going to stay around for a longer time. Somebody that cares about the ecosystem, and sees the whole. Or at least tries to do that. Be it a CTO a Technical Lead or the CEO, depending on your company.

For example, working for a sustainable work environment with as little turnover as possible might be a really good strategy in the long term. If developers feel the workplace as their own workplace, continuos improvement policies might flourish and people might stay around long enough to see them working, creating a virtuous cycle.

No hope in the short term?

Here we are. Now you’re probably thinking that - since the battle for maintainable code is very hard to win I - am depressed enough to give up and let the barbarian hordes commit whatever they want.

Not yet, guys.

The thing is, good practices like TDD and continuous refactoring should repay themselves in the short term too. And they do, …if you know them well enough. Which means that you’re correctly accounting costs and benefits, including the cost of learning TDD and keeping it distinct from the cost of doing TDD.

Personally, I would be lost without TDD. But I am a different beast: despite all of my efforts, coding is not my primary activity: booking hotels and flights is. So TDD is a way to keep a codebase manageable even in scenarios with no continuous work on a project. I guess this goes for many open source projects too.

But the most interesting thing is that the best developers I know are all doing TDD. Not for religion, but because they get benefits in return. Not potential benefits, just-in-case style. Real benefits, in the short term.

Safety, confidence and speed.

Very good developers can also recognise different needs in different contexts. There may be cases when TDD is overkill or bringing little value: if all you need right now is showing a prototype, show a damn rails prototype right now! It’s no religion, it’s a continuous evaluation of return on investment and evaluating options. Which means that you can also be wrong: you may be too conservative and pay an insurance for a disaster that would not happen, or be taking some risks, just to end up smashing your face against a wall with your colleagues staring at you with a I-told-you-so look on their faces. That’s life, dude.

But in the land of continuous choices, being able to code only in one way, means being weak. The only safe spot, is being so good in TDD to know when not to use TDD. Aren’t you there yet? Good luck. There’s still people that go to a Japanese restaurant and ask for fork and spoon. But, you don’t want to be the one.

So please, stop raising arguments like “Yes, but if one day somebody wants to change the codebase”  because I won’t buy it. If you can’t provide short term benefits for TDD and refactoring, then you probably don’t know them well enough, yet. And at the same time I don’t want to be the one trading a sure expense, for a potential gain in the distant future.

Some updates about EventStorming

Hi everybody. After a long silence I finally found some time to start writing again some content for this blog. Well, many things happened in the meanwhile in the EventStorming space, and I finally managed to find some time and discipline to start sharing our findings more effectively.

In the meanwhile, EventStorming found its way through word-of-mouth, twitter and conference workshops. But it’s looking like a web version of Fight Club: getting viral and secret at the same time. Maybe it’s time to make some change.

EventStorming Community/Mailing List

I’ve started a new public community on Google+: it’s called EventStormers. Here’s the link. I’ve chosen Google+ mostly for the look: our content is a lot more visual than other discussion groups, and I felt that Google+ was a good tool for that. I know there are some drawbacks too, but it’s working well, so far.

Some colleagues were already sharing content on the smaller private community called EventStorming Practitioners. Communities rules prevent me from turning the old one into a public one. So, members of the private community, which are ok with the idea of going public, will have to share their stuff again. That includes me too.

Writing some stuff

It’s no secret that I am planning to write something more than a blog post. EventStorming and Model Storming are tricky topics (and yes, I am aware that I haven’t published much about Model Storming and that many people are still confused about the two terms).

Telling the what might be relatively straightforward, but telling the why  and exploring the how can take ages. However, I finally acknowledged to focus on EventStorming for now, and I am working on readable content. Portions of it are actually making their own way to the blog.

But that’s the offer. I am writing about things I care and think that are worth sharing. But - as every blogger knows - I also write pushed by the urgency of a freshly learnt lesson. The drawback is that this is too much self-centred.

So I am asking your help.

If you are curious about EventStorming, please join the community and start asking questions, or maybe ask what you would like to know about EventStorming right here in the blog comments. I’ll do my best to share the answers I know, and find the ones I don’t.

Thanks everybody

 

 

Go personal to boost engagement.

Weird episode during today's EventStorming session. We had a meeting room with a big wall available, that we set up with a plotter paper roll. The room had a big table, that could not be moved away so we simply moved it aside, to provide more space in front of the Modelling Surface.

Unfortunately, it wasn't enough. Some participants showed up a little late, so we waited for them. When they came in, they saw other participants sitting (cause we've been waiting) and immediately grabbed their seats. Hrmpf! :-/

Well, I thought: "This isn't going to last much" and said politely: "You won't need your seat. We'll be standing most of the time, working by the paper roll". What I didn't consider was that many of the participants were ladies, and the answer was: "We don't have the right shoes for that!".

Ouch. Surprise. I've never thought about it. :-(

Add that to the fact that I couldn't adopt my usual I'll-kick-you-in-the-butt strategy that works perfectly with developers, (I am a gentleman, after all), and for the first time having people stand up became harder than usual, resulting in lower-than-average engagement and less observable body language, for a while.

Time for a Plan B

The surprise trick that really worked well was "could you please add Actors close to the corresponding event?" and since "actor" meant "me" for many of the participants, they all stood up and added information to the model, raising engagement at the same time. Wow!

Ok, lessons:

1. As Jef Claes reminded me, remove seats. I focused on the table and forgot the smaller enemies. Seats were still there, inviting and comfortable
2. Environment matters a lot. And preparing the meeting is really important. I did a survey on the room before the meeting (something which is hard if I travel to lead a workshop), but I focused on surfaces, and space. Maybe is time to set up a room preparation checklist (next post, maybe). As Sun Tzu said: "Every battle is won before it's ever fought"
3. personal involvement (actor == me) works pretty well as an engagement booster. I normally go to actors together with Command exploration, but in this case (small timeframe available) it was better to go straight to the actors.
4. shoes... maybe mention 'bring comfortable shoes' in the invitation.

EventStorming: invite the right people

Invite the right people

People are the primary ingredient for a successful party. You’ll need good music and drinks too, but if the girls won’t show up, the party will be lame

You’ve been reached by some buzz around EventStorming, you may even have experienced it in some evening event t the local user group. Now you fell like trying the experiment in your own company. But then a question pops up.

Who should be invited?

Ideally, one would like to have participants coming from two fields: people with questions and people with answers. They provide the perfect mix of curiosity and wisdom.

When exploring complex business domains (the scope of EventStorming is usually the whole business flow) this implies that a lot of people should be involved, and triggers a lot of warnings. Let's see some.

• They won't be available at the same time.
• The meeting will turn into a waste of time, at least for many of them.
• You'll end up nowhere due to conflicts that may arise.

All these worries are legitimate. But they lead us to do things in a way that doesn't work. The meaningful conversation with the Domain Expert that is at the core of Domain-Driven Design is often not that meaningful.

Should I look for specific roles?

I am somewhat reluctant to map those people to company roles for a couple of reasons: personal attitudes are more important than roles for the workshop to deliver, moreover I’ve seen so many different, somewhat dysfunctional company structures that tying myself to randomly assigned roles is not a wise choice.

So I won’t provide any answer like ‘every developer should attend the workshop’ or ‘only team leaders, business analysts and domain expert should be there’. Instead I’ll suggest to take a different path.

A somewhat zen answer

The best answer that comes to my mind is something that may disappoint you: “Just close your eyes and imagine the perfect meeting, where curious people with the right questions get answered by people who know the answers, or are honest enough to say that the answer is yet to be found”. Now name the people you saw, and invite them.

It’s no different from what you would do for organising a party. The party won’t be perfect if the right people won’t show up. Now, do you invite friends to the party according to their roles or attitudes?

A more cynical answer

If this sounds too mystical, or you feel that the key people won’t show up, you may run the opposite approach: “In a year from now, after the project has been a complete failure, burning a couple of million euros, your company will run a post-mortem meeting. Who do you think is going to be there?” And if they don’t look like interested in your unconventional type of meeting you might present the bargain: join the meeting now instead of the post-mortem, you might save some cash this way.

Conflicts are fine

The most common objection, albeit often implicit, is that if we bring all of those people together we won’t be able to handle the conflicts. This is very likely to happen in a traditional meeting, but remember: this is an EventStorming workshop: no tables, no boredom and an unlimited modelling surface on the wall.

The fact is conflict is there, and probably will be there tomorrow too, and it will probably be one of the most dangerous risk factors in your project, so why waiting?

In GOOS book, Freeman and Pryce introduce the notion of Walking Skeleton like the minimal piece of code that touches all the possible architectural pain point, as soon as possible, because you don’t want discover critical spots too late in the project.

I think this approach is really effective, and I also believe that most of the risk in large scale enterprise projects resides in people, so I'll try to reuse the idea and try to get in touch as soon as possible with the key people that could be the biggest source of risk in my project.

Managing conflicts

In EventStorming we’ll have many people discussing around a model they’ll be building collaboratively. For most of the time they’ll care about the area they’ll know more, and the workshop will achieve interesting speed allowing them to work in parallel (we have an unlimited modelling surface, space to walk, plenty of stickies and working markers, remember?).

You may discover something interesting in the way people group and act in front of the modelling surfaces. Some people will take explicit ownership of given portions of the modelling space (which later you may want to label as subdomains), others would be more reluctant, or dubious, maybe they’re not the real domain experts. Some would try to impose their own view over the system, others would try not to contradict their boss. Help them, provide enough markers and stickies to allow them to publish their view too and to let diverging perspectives emerge.

A place for hotspots

One of the things I love about EventStorming is that it provides a safe place for finger pointing. Given we’re building a modelling artefact, we actually can finger pointing at the stickies. When somebody says “it’s not exactly like that”, that’s the moment to listen to a story: “can you explain us why?”

The interesting thing is that, the physical model makes it easy to trigger the conflict - because you see what’s wrong -  but also helps in keeping the conflict at the model level, without turning into a personal issue. As I said, there’s a lot of value in discovering modelling issues and underlying conflicts, the earlier the better.

Solving some conflicts…

Many conflicts may in fact be solved using one of Domain-Driven Design secret weapons: Bounded Contexts. To put it in practice during the workshop, you just need to accept the fact that two diverging opinions by two domain experts may be both right …in their own place. In fact Bounded Contexts are like separate room with their own private model which is perfectly fit to the needs of their corresponding domain expert.

To put it in another way: you won’t solve conflicts by reaching an agreement, or - even worse - a trade-off. You can solve some conflicts just by assuming that the two views are equally valid, and that it would be your job, as a software architect, to find the best way for them to co-exist.

… and get along with some others

Bounded Contexts are great. But they’re not magic. Some conflicts would be resolved by deeper exploration, and that would need time. Time that you probably won’t have during the workshop. Some others, would never be solved (the I-hate-you-damn-bastard-and-I-always-will category, for example).

The best thing to do here is to mark the hotspot - possibly with a vivid coloured signal - advising that this is danger zone, and move on to the best area. This is already really valuable, and nobody is asking us miracles. Endless debating over a single issue might turn the workshop into a boring meeting, so keep the discussion short if there’s no easy way out. Other participants will appreciate it.

In general I am not trying to solve issues or to take decisions during an EventStorming session. My primary concern is to keep the workshop flow going, to have everybody engaged in what we’re building together.

What if we won’t have all the people?

Given a lot of the value resides in observing the interactions between participants, for every key person missing you’ll be losing the value of the interactions between him/her and everybody else. You can do your math, it’s not headcount, it’s counting relationships.

Beware of those folks who promise they’ll join you later. Especially if they are Italians. They’ll miss all the key information: one can not understand a movie from the ending titles, and being there is the most successful ingredient.

Just getting there

However, one might have to acknowledge what’s the real starting point (and I have an easy one: people invite me to run EventStorming sessions in their companies) and get along with that. Every organisation is different.

Sometimes getting the right people on board might be a long process. One may actually get there step by step, so even if I personally prefer to fight for my right to party there might be situation where a temporary trade-off is necessary. Here are some basic tips to get you started.

• Declare experiments: be honest, this might be the first time you run an EventStorming workshop, and even if you attended one, being on the facilitator side might be totally a different job.
• Manage risk: what is the worst thing that can happen during a meeting? It’s probably wasting time… oh, you’ve never wasted time in your company (sarcasm).
• Timebox: every open ended meeting might bloat. Keep it under control key people won’t be available for the whole day. Keep a visible agenda, or a timer. Just try to use participants’ time in the most effective way.
• Look at people’s faces: bored people tend to look bored. Just ask them why they’re not finding interest. And take some corrective action.
• It’s not a trap: some people will look like they shouldn’t really be there. Let them go if they don’t feel like. I normally try to take mobile phones and the like away to have full attention, at least for a limited amount of time, but some roles have different degrees  of machine slavery.
• Take breaks: engagement is good, but drains you energies a lot. You don’t want to be in low fuel status. Take a break, maybe every 45 minutes, and enjoy it.
• Retrospect: whatever the outcome is, just find some time to highlight achievements and problems of the meeting, to be sure next one will be even better.

In some organisations, key stakeholders won’t be available at the same time, or won’t free their time for just another meeting. It’s fine. You haven’t achieved anything yet.

Let your first EventStorming build some reputation in order to be attractive for key domain experts, in the next session.

Introducing Event Storming

Disclaimer: This is the seminal article about EventStorming. This is where everything started, so I think it's relevant to keep the original. At the same time, EventStorming has evolved a lot since I wrote this article, and the format described in this page is no longer my favorite one. In fact, there's not a single EventStorming format, the tool proved itself so versatile and powerful that I perfectioned a few different recipes. I also had to start writing a book about it, which is slowly progressing to completion. As of today, the better entry point to understanding EventStorming potential is probably my presentation 50.000 orange stickies later (which is also available in video) or reading the first chapter of the book, which is available for free. We are also working on a new version of the EventStorming.com website that should organize pointers to the interesting content about EventStorming that many practitioners published.

My perspective on the coding versus modeling balance

Root Cause Analysis stencil uploaded on Graffletopia Stencil

There are few OmniGraffle stencils which I use frequently during my consulting gigs, especially while gathering information for a change initiative, and in presentations also. One of my favorites is the one I just uploaded to Graffletopia for sharing.

Notation info

• Observable Facts are ellipses (or bubbles). 
• When using a tool for drawing like OmniGraffle, I take advantage of colors to display perceived severity. White is neutral, from yellow to red is bad. Black is disaster.
• Border thickness maps to our perception of our ability to affect/change a phenomenon. A fact with no border is under our control, a fact with a thick border is something we cannot influence easily. A company policy which is generating an undesirable effect might be mapped like a constrained fact (but later, you might be in the position to influence it).
• Unknown Areas are represented as clouds. There's something important there which we don't know yet.
• Question marks are part of the stencil as well. I never know everything, but mapping the things that I don't know is often a good idea.
• Since my primary use is to collect information for change at a system level, local solutions are part of the notation also.
• Direct dependencies are represented by arrows. 
• Dotted line arrows represent indirect dependencies. I'm less strict than some other more precise notation, I use the same dotted line for not-so-clearly-related facts and for relationships with delay. It's less precise, but at sketching time I probably don't have enough information to make a clear distinction anyway.

Some guidance

I have to admit I am driven by instinct more than a real formal process. However in drawing the map I have influences from Peter Senge ("The Fifth Discipline"), Craig Larman ("Scaling Lean & Agile Development" and from Eliyahu Goldratt (who described the Reality Tree in "It's not Luck!").

Collecting Data

I start collecting sparse data, from my observation. If I can draw direct links, I add them. If a fact has no clear explanation, I add a cloud or a question mark. Same goes of the causal effect link is no sufficient to imply the consequence. The fact that it's raining doesn't necessarily imply that I'll get wet. But if my car is broken, and I have no umbrella, and I have to go shopping for food, that's another story.

I don't need that much precision on the constraints. I like to capture the mood. If the team says there's nothing that it can be done about a policy, I'll draw it as a constrained fact. But I'll challenge that assumption later when it comes to use the drawing for collaborative problem solving,

Please feel free to share your comments. Hope you'll find it useful!

Setting up a DDD sample app

The guy who started it all is called Emanuele Del Bono. He’s a friend, a nice guy and a respected colleague. He participated in the first Domain-Driven Design class of my company, and also did a fantastic job in finding a suitable place for the class. He is also one of the guys that animated a discussion on the DDD-IT mailing list that urged me to write this posts, some time ago. So I should have been warned about the danger behind his simple request.
Some weeks ago, he complained about the lack of code example in the DDD-IT mailing list, and challenged the list to see if anybody dared to post the code of some aggregate. Innocent and legitimate request, ...or so it seemed. However, since he used the word “courage”, the one that kids use among themselves to do things they will regret, I accepted the challenge and started working on some code that could be shared, and found useful by the list.

Why should I regret it?

As I said, the request is both legitimate and innocent. What could be the drawbacks. I can point out two.

Time: I like to do things well, and sometimes I tend to get lost in meaningless details. So, for me, doing things right will take time. Given how busy I am, there’s a clear and present danger of never finishing the stuff.

Questions: there are many things that I don’t want to talk about when talking about Domain-Driven Design. Frameworks are one of these. I use some of them, but I can’t really say I love them. However, I don’t like questions like “how do you do this with Spring and Hibernate?” because you can probably do it in a smarter way that I can figure out. I think one of the values of DDD is to provide a conceptual background where these type of problems, decrease their importance to the point of being mere implementation details (even though they can make your time a hell if they don’t work exactly as expected). So my worry is to get too many questions focusing on the wrong side without really clarifying doubts on the part that matters most.

Choosing a domain

I definitely need something different from Cargos. Since I know the training domain a little, and used it also in the recent DDD school camp, I decided to choose this domain. However, as will be clearer later, we’ll need precision in defining what this is really about. Simply knowing how things work in the training domain won’t be enough.

Choosing a programming language

Since colleagues were eager for code, the first thing to do was choosing a programming language to actually show some code. The obvious choice was to choose my favorite language and get along with that. Problem number one: I don’t have a favorite language. Problem number two: there are too many things in the code that could divert both writer and readers attention from the actual scope of the task.

Java: this has been my first choice, a little conservative I have to admit. However, it’s bee a while since I wrote some java code, and I stopped following Java trends after Oracle’s takeover. Last but not least, all of my local configuration needed an update.

Groovy: a lot more pleasant to work with than Java, but to make it really pleasant I had to deconstruct Grails a little, in ways that might look obscure to most readers, carefully selecting only some of the available features. Good topics for a blog post, but not for this app.

C#: though I’ve been recently playing with the platform, and I appreciated some features, I still don’t feel like it’s mine. Still too hard for me to distinguish good and bad stuff.

Ruby: I am relatively new to the language, and probably missing some key tips on the technology stack and on the programming style (“You still think like a Java guy” Paolo Perrotta once said, I hope I improved a little since then…).

Given this starting point, I started with Java. I thought I could set up quickly a skeleton architecture with Spring, like the ones I was used to work with.

So I opened up the IDE and started coding.

Wrong choice.

After setting up an Aggregate an some satellite Services that did their dirty job, or faked it with a mock implementation, I finally realized that I was getting all wrong and was underestimating the task of writing a sample application. What was my problem?

Ambiguity.

The model I was building looked perfectly sound from a “modeling” perspective, but I was getting uncomfortable in the multiple roles of developer, analyst, and domain expert or product owner. Moreover, the “let’s show some code quickly” approach that I started with, didn’t really work. To define exactly what my aggregates were supposed to do, I needed a lot more precision, since a little business tweak in the underlying domain would have driven me in divergent modeling choices. I needed consistency and unity of vision in my domain, before I could implement it in my model.

Well, that was no surprise. That’s exactly what DDD is for. And a common, simplified development cycle is:

1. gather some information from the domain expert about features A, B and C;
2. quickly implement it as a domain model, using DDD patterns;
3. spot contradictions in the current understanding of the domain, that emerge from the model;
4. refine the model, asking to the domain expert what he precisely meant when he talked about features A, B, and C.

The only weird thing is that all the roles are in my head now. And to keep my sanity and stop swinging from one interpretation to another one of the same corner of the domain, I need to be a little more structured, and define exactly what I want from myself.

Providing a little structure

I want to model my aggregates around a problem, and I want this to be precisely defined. So, despite this being just an example, or maybe exactly for this reason, I can’t go for shortcuts. Let’s start with a user story and see where it lead us. 



My first problem was to find a good name for my role. I mean, my company is rather small, so there’s not much of a clean role separation. I could have put something like “as Me” and was probably going to be more correct, even if less portable.

However, that’s defining the starting point, and the scope for the first iteration. But it’s not precise enough. Let’s nail it down with an acceptance test.

Scenario: Publishing a new training
Given a Catalog
And a Training gourmet coding not yet published
When I publish Training gourmet coding on Catalog
Then Training gourmet coding is available on Catalog

And try to make it work. Of course this means setting up Cucumber in the development environment, something I thought it wasn’t strictly necessary, but I realized I am getting addicted to.

By the way, despite my previous experiences with Cucumber and Java, and the precious guidance by the secret ninjas cucumber scrolls, setting up again Cuke4Duke in my project didn’t work that smoothly. Looks like Maven got in the way. Again.

No, please. Not that again.

In a second, Maven destroyed my pleasure. And made me think that, even though I am still a rookie on Ruby, every second spent on solving problems on Ruby is a second spent learning, while the time spent on Java is probably wasted. So, after just a few minutes, I already dropped my platform and started again with Ruby, instead of Java. But this sample app is a sandbox, for learning and experimenting. Needs to be fun.

Modeling question number one

Do I really need a catalog? When thinking about managing trainings, a Catalog is the abstraction that naturally comes to mind. However when I started thinking about what I really wanted to do with this application, I couldn’t find any behavior for the catalog within the boundaries of my application. I said “boundaries” which means that I need to define scope more precisely. A little context map will do the job.

The ultra-basic context map, with my application and an Anti-Corruption Layer separating it from the external website model

 The main idea, for now, is to manage the trainings locally and trigger a publishing action on an external website. I have no idea about how to do that, but I need to make it clear that I am not directly working on the catalog that is visible to a potential customer. I have an external website for that. Maybe some hosting service exposing APIs would do the job. But I don’t want to know that. Right now I just need to know that I won’t publish directly on that. I’ll hide the details behind some domain service and hide all the little dirty things needed to complete the job behind the curtain of a neat interface. More likely, I’ll pretend to do that, and shamelessly fake everything, but behind the same interface.

Ruby, the architecture and me

I hereby state loud and clear my ignorance about the architectural patterns in Ruby. I don’t know much about it, so whenever you see something that doesn’t quite fit the picture or that seems awkward, feel free to comment and correct me. The only thing I am almost sure about is that I don’t want to use Rails. Can’t say it won’t fit in the picture (I am not looking for a 100% DDD application, and I can figure out portions of the application that could be implemented according to that paradigm) but definitely Active Record is not what I want to start with, and definitely I don’t want a full framework stack. I want to add things little by little.

Persistence framework

After exploring a little, I’ve chosen Sequel. A lightweight persistence framework that can be used at two different levels of abstraction. I started with the very low level approach, so my repositories now look a little vintage. :-)

Also DataMapper looked interesting. I’ll probably give it a try when trying to make the architecture a little more agnostic about persistence frameworks.

The trickiest part so far has been separating persistence instructions from transaction management. In a typical DDD architecture, transaction management is an application layer concern, but this seems to be at odd with most of the examples regarding ORMs and persistence frameworks in general.

What I like so far

I really like the Ruby testing stack. Cucumber and Rspec are incredibly well supported by RubyMine, and coding is a pleasure in this area. Getting to all green is always a pleasure.

What I don’t like so far

Of course the database had his revenge after that presentation. SQLite rebelled and I wanted to test the app also with some real DMBS, but installing MySQL has been a little pain (well, the actual installation run smoothly ...it just didn’t work with my Ruby version). I had to switch to a different Ruby version and to reinstall it before having it work with my stack.

There are also a few things that don’t feel right on the architecture. I missed some of the things Spring was doing behind the scenes, and that used to be my default paradigm so there is a high possibility that the whole stuff looks like a Spring based Java application in Ruby dress. Some patterns which are relevant in Java and C# (like Application Facade and Repository) probably have a more elegant alternative implementation in Ruby, and there are some Singletons around (forgive me) which are basically placeholder for a different implementation. In general wiring up is not as elegant as I would haver liked.

Ok, but where is the code?

I’ve started a project on GitHub. It’s called D3N. You can find it there. It's still naive, but I’ve tried to do things well and started to post also issues about the things I want to cover/experiment in the next weeks. At the end I am thinking more about a playground than a “sample app” (I hate this term).
So far, there's not so much to see, but I've been writing a hell of a long post. Let's try to get more use cases implemented and more coverage of the actual evolution. As I said before, there’s a lot more in doing a DDD application than just the resulting code.

As somebody once said: it’s the journey, not the destination.

Denial won't help you learning

While preparing my talk (video) for the last Italian Agile Day conference, I spent some time retrospecting on my past projects. As people who attended know, this retrospective step ended up completely thwarting the original purpose of the speech: looking back in the past I discovered more than I expected.

To be completely honest, some of the inspiration for the talk came from Alistair Cockburn closing keynote at JAOO 2007 , I rarely invent anything. Connecting the dots is my job.

My key factors for successful learning

(OMG, I wrote this title like I know this stuff... and I actually don’t) While retrospecting on my past projects, I didn’t focus on normal success conditions. I focused on the amount of relevant knowledge learnt during the project. This allowed me to look at the past with a different perspective, seeing things that I probably overlooked in the past. From the perspective of learning, the key factors that most influenced the outcome were:

1. Team attitude
2. Motivation
3. Context.

Team attitude is a tricky definition. Because it states 2 different things: that the attitude is relevant, and that I actually need a team. Of course I’ve learnt a lot also in projects where I was a lone consultant: I did some stuff, I solved some problems, I spent some time thinking about what I actually did. But the real massive amount of learning happened in projects where I had the chance to solve complex problems as a team.

Interestingly I couldn’t find any connection to the role I was playing at that time. Didn’t really made a difference if I was a junior developer or a project manager, or a senior architect. Didn’t really made a difference if I was supposed to be managed or managing (I hate this definition, but that used to be the past). Didn’t really made a difference if I was supposed to learn from the colleagues or to teach them something.

The one single thing that made a lot of difference was the attitude me and my colleagues shared in those difficult projects.

Learning attitude patterns

People made a lot of difference also in the business outcome of the project (yes, that boring on-time and on-budget part) but could give me from the very beginning a grasp about what I was going to expect. Let’s make some examples with somewhat stereotypical approaches.

“I know what I am talking about” that the kind of sentence often heard in organizations. To me, it means “I don’t feel any need to improve”. I’ve met some person like this, but luckily they were not in my team. Sometimes they were part of the organization we were supposed to work for, almost always they were part of the problem. I don’t want hem in my team. Plain and simple.

“That’s all clear to me” ... No. It isn’t. People that for some reasons pretend they’ve understood everything needed to solve the problem, are part of the problem as well. Quite often, under the surface they look for hints about what the boss said, and keep pretending that everything is fine. Walking timebombs.

“I have no clue about what we’re going to do” Now we’re talking! The most effective colleagues I’ve worked with always started the project with fear. They called me out for a one on one talk, and with fearful eyes told me “I know absolutely nothing about the topic of this project”, and - believe me - their faces were even better when I answered honestly “I have no idea about it either”. But that conversation was honest, we defined a common ground, and we started learning collaboratively assuming that we didn’t know all the things and that we needed to share information to solve a common problem.

Confront this profile with the previous two. Would you share information with those colleagues also? A lot less, ...they won’t need it anyway: they (pretended/assumed) that they already know the stuff. They basically shut themselves out from any possibility of collaborative learning. Ok, that’s basically Socrates statement: “The real wise man is the one that knows that he doesn’t know”. ...But not only.

Focusing efforts in the right direction

What’s striking me more and more, is that the attitude we had sometime towards learning new things as a team, was incredibly effective also because it was efficient. We din’t waste any time in pretending that we were better than we really were. We did have a massive amount of work to do, but we didn’t have any knowledge debt, and we didn’t spend a second studying things that people around me expect me to know but I don’t.

Don’t you smell something familiar here? It smells like your dirty little secret to me. Make me think about movies where one of the characters did something wrong in the past and lives in the fear of being blackmailed... Ignoring a key skill, it’s not as bad as committing a crime, but the mechanics in our mind are not that different. Our brain start working in “I can’t let them discover my secret" mode, which is a dangerous slope: it makes you feel like “I am not the person they expect”.

It doesn’t matter how bad is our secret, the mechanics are similar: shame and fear of humiliation (even if only at the coffee machine level) are powerful triggers, and would lead to the wrong behavior, and also to learn less in the long run. Because stress is preventing from effective learning, because one can’t enjoy collaborative learning, and because a lot of time won’t be dedicated to learning but just to cover-my-ass activities which are brain draining (how many brain cycles are you spending deleting compromising SMS from your phone or wondering if your girlfriend can actually see what you posted on that other girl's wall on Facebook?).

To be honest, in a software project, your fault (if we want to call it like that) is really little. Telling that you’ve actually never understood OOP, or that you’ve never actually shipped anything to production isn’t a fault, it’s just a honest starting point. Stating where you are exactly and honestly right now would save you and your team a lot of troubles in the future.

When is the moment of staffing the team for a new project. Now I know exactly what I want. I want people with the right learning attitude.

Only knowledge gap?

Not really. The more I look into the problem, the more I realize that the mechanics are the same whether it is knowledge or learning debt, technical debt or motivational debt. Failing to acknowledge where we really are only exacerbates the problem. But that’s a topic for a whole new post. I also didn’t say much about motivation and context... Stay tuned.

 

See the Forest and the trees with Kanban

I uploaded the slides of my presentation about Kanban that I gave at last UGI Alt.Net Conf in Milan.

Forest and trees with kanban

View more presentations from Alberto Brandolini.

Loosely Coupled Complexity - Unleash the power of your Domain Model with Command Query Responsibility Segregation and Event Sourcing

Here are the slides of my presentation about CQRS and Event Sourcing, that I gave at NHibernate Day in Bologna last week.

Loosely Coupled Complexity - Unleash the power of your Domain Model with Command Query Responsibility Segregation and Event Sourcing

View more presentations from Alberto Brandolini.

And if you're masochistic enough to stand my accent ...here is the video.

DDD Reference Links

Further references

Books

Domain Driven Design - Eric Evans (Addison Wesley)

The official starting point for Domain Driven Design, covering the topic form tactical to strategical.

Applying Domain-Driven Design and Patterns (Addison Wesley)

A more implementation related approach focusing on the mechanics of the implementation of tactical DDD with C# and .Net.

DDD Quickly

A free dowloadable smaller reference for Tactical DDD from InfoQ

http://www.infoq.com/minibooks/domain-driven-design-quickly

Domain Driven Design website

New official website for Domain Driven Design. Aggregator for further resources, informations, discussion and events

http://domaindrivendesign.org/

Domain Driven Design User Group

This is the place where the most interesting discussions are hosted

http://tech.groups.yahoo.com/group/domaindrivendesign/

Italian Domain Driven Design group

http://it.groups.yahoo.com/group/DDD-IT/

Eric Evans interviews and talks on InfoQ

http://www.infoq.com/interviews/domain-driven-design-eric-evans

http://www.infoq.com/presentations/model-to-work-evans

http://www.infoq.com/articles/eric-evans-ddd-matters-today

http://www.infoq.com/presentations/strategic-design-evans

http://www.infoq.com/presentations/ddd-dsl-evans

DDD sample Application

A working implementation of DDD principles in SpringMVC plus Hibernate, maintained by Swedish company Citerus.

http://dddsample.sourceforge.net/

CQRS & Event Sourcing

I needed a separate page for that:

http://ziobrando.blogspot.com/2010/10/cqrs-event-sourcing-reference-links.html

DDD, TDD & BDD

The three amigos: DDD, TDD & BDD Presentation by Gojko Adzic

http://skillsmatter.com/podcast/design-architecture/ddd-tdd-bdd

Gojko Adzic’s Blog: http://gojko.net/

Context mapping

Strategic Domain Driven Design with Context mapping (My article on InfoQ)

http://www.infoq.com/articles/ddd-contextmapping

Context Mapping in Action - Presentation by Alberto Brandolini

http://skillsmatter.com/podcast/design-architecture/context-mapping-in-action

Articles

About entities, aggregates and data duplication - Alberto Brandolini’s blog

http://ziobrando.blogspot.com/2010/06/about-entities-aggregates-and-data.html

Random Links

Kent Beck blog entry on why writing maintainable software matters.

http://www.threeriversinstitute.org/blog/?p=104

Some more related or interesting books

Patterns of Enterprise Application Architecture - Martin Fowler

Analysis Patterns - Martin Fowler

Growing Object Oriented Software, guided by tests - Steve Freeman & Nat Pryce

The Pragmatic Programmer - Dave Thomas and Andy Hunt

Clean Code - Robert C. Martin

Agile Software Development, Pattern Principles and Patterns

 

Lean Software Development - Mary and Tom Poppendieck

Test Driven Development by Example - Kent Beck

Collaboration Explained - Jean Tabaka

CQRS & Event Sourcing Reference Links

CQRS & Event Sourcing

DDD/CQRS Mailing list

The official CQRS Website

Interviews

Eric’s interview to Greg Younghttp://www.infoq.com/interviews/Architecture-Eric-Evans-Interviews-Greg-Young

Clarified CQRS - Article by Udi Dahan

Presentations

Command Query Responsibility Segregation - Presentation by Udi Dahan
http://www.infoq.com/presentations/Command-Query-Responsibility-SegregationAvoid a failed SOA - Presentation by Udi Dahan

http://www.infoq.com/presentations/SOA-Business-Autonomous-Components

Event Sourcing

Event Sourcing definition by Martin Fowler

http://martinfowler.com/eaaDev/EventSourcing.html

Innovation and Event Sourcing - Greg Young presentation

http://skillsmatter.com/podcast/design-architecture/architectural-innovation-eventing-event-sourcing

Code References

Super Simple CQRS Example

http://codebetter.com/blogs/gregyoung/archive/2010/08/31/super-simple-cqrs-example.aspx

Agile Testing UK meetup

While in England for DDD Exchange, I caught the opportunity to participate in a meetup of the UK Agile Testing community. Gojko Adzic led a very interesting workshop about how to write acceptance tests.

Neil McLaughlin, who happened to be in my team in the hands-on simulation wrote a nice report on the evening, and then Gojko himself posted about what he showed us. I'll try add something, from the participant perspective.

The developer mindset

Given we had quite a few people in the room, around 60, it was really interesting to note all different behaviors, but there were also some striking similarities. Most of the discussion we had were focused on

• Formal correctness of the test
• Splitting tests to be testing one concern at that time
• avoiding duplication in test fixture setup

When discussing the outcome, Gojko pointed out that the main concern for acceptance tests was readability, instead. Readability is a subjective evaluation criteria, and might lead to a not-so-precise definition about how to make it right. But that's the only way to write a useful acceptance test. But the developer's mindset really had a strong influence on us, it was really hard to give up.

Constrained by the tools

Despite Skills Matter (that was hosting the evening) doing a fantastic job in providing an impressive amount of whiteboards for all the team, some of the discussions were constrained by the amount of space available on the whiteboard, so we ended up pruning some concerns, thinking they were of little value to the discussion. It turned out we were wrong.

But, as I said, we had an amount of writable space that was a lot larger than what I normally found in a typical workplace... and still this was constraining us. Buying one more whiteboard is cheap, making wrong assumptions because of writable space constraints is a lot more costly.

We're problem solvers, after all

During the exercise, Gojko was wandering around from one team to another one, playing the role of the Domain Expert. However, most of the teams seemed more interested in his Teacher role and asked some questions about how to solve the exercise, but barely none about ambiguities in the domain. We preferred to use assumptions instead.

Even if I knew the trick, it worked on me as well. But it's scary to note that even when writing acceptance tests, which are a lot more translation than design, our built-in problem solving brain leads us so easily on the road of guessing instead of asking.

About Entities, Aggregates and Data Duplication.

There's been an interesting discussion about Aggregates on the Italian DDD mailing lists. When things become complex, a simple example might just turn too simple. So I came up with this medium-sized one. Hope it won't be too long. Ok, so let's start from our first User Story

User Story #1: Placing an order
As a Customer
I Want to place an order
In order to purchase some goods

The simplest implementation of the story is essentially stateless: every time a customer wants to order something, needs to re-enter the data. In the DDD perspective, the resulting model is based on a single aggregate (we're deliberately ignoring the catalog for now) whose root is the Order class.

The stateless nature of the service makes it really easy to implement: a Customer is just a Value Object, created and eventually dropped at needs. Also we took some shortcut: we've chosen to implement Address as a String. Item is sort of natural value object, while LineItem is somewhat in the middle: we can change quantities, while the order is in open state, but we can implement this also using droppable Value Objects, easing the integrity burden for the aggregate root.

Some businesses (like buying train tickets) might just work like this, but our marketing is more inclined to manage customers in a more long-term way, so here are two more user stories.

User Story #2: Returning customer
As a Customer
I Want to retrieve my profile
In order to place more orders

Story #2 breaks our assumption about the aggregate boundaries. If we stick to the aggregate rule-of-thumb, if we want to delete an Order, we probably don't want to delete also the corresponding Customer. So we need a separate aggregate for that. What would happen if we decide to delete a Customer? Should we delete all orders? We don't have enough information to answer that, yet, we'll mark it as an outstanding question for our next meeting with the domain expert. Let's try the model with two aggregates and see how does it perform.

We now have a relationship crossing the aggregate boundary. We have promoted Customer to become the root of the newly created aggregate, so there is no potential integrity violation. Still we have to watch it closely, because this is where problems related to lazy/eager loading will arise. We also added username and password to Customer.

User Story #3: Different shipping address
As a Customer
I Want to specify a valid shipping address
In order to ship to a different destination

Multiple addresses are a call for a separate type to manage Address. We don't have so many responsibilities so far, for this class, except validation (which as Udi Dahan would say, doesn't necessarily belong to the domain layer) but the smell of duplication is probably enough to go for a separate class. We try to keep the model as simple as possible, so we treat Address like a value object.

User Story #4: Editable customer profile
As a Customer
I Want to edit my profile
In order to update it if needed

Story #4 makes explicit what we've been suspecting: Customer needs to be an entity, because it has a nontrivial lifecycle. No revolutions at Domain Model level, but this triggers a question: "What happens if I have an outstanding order and the customer changes its data before the order is dispatched?" This is the type of questions you don't want to answer as software developer. So we walk up the stairs to have a talk with the Domain Expert. We come back with two fresh user stories:

User Story #5: Specify Billing and Shipping address
As a Customer
I Want to specify independent billing and shipping addresses
In order to deliver goods to different locations

This one is relatively easy: just reinforcing our design. We'll now have two references from Order to Address, which are managed by the Customer. We just store a default Address in the Customer aggregate (we could do better) but's ok for now.

Story #6 is a little trickier, it comes from the legal department and tell us what we probably expected.

User Story #6: Track past orders
As a Legal Department
I Want to track orders
In order to in order to manage litigations

The domain expert state it clear: once an order is placed, it can't be changed in any of its parts, be it the content or the Customer. In case of litigation, it must behave exactly like printed paper. But Customer does not, its lifecycle is different from our needs, we'd need a separate class for that. We're lacking fantasy and call it CustomerData.

Everything is looking a lot different from the beginning. The two aggregates are now largely decoupled: we can change or delete an order without affecting the customer or deleting or unregistering a customer without losing tracks of its past orders. On the other hand we have explicit duplication here. Customer and CustomerData look so similar we're feeling guilty. Did we violate DRY principle? At first look the data is the same, but if we think about behavior, or class lifecycle, Customer and CustomerData are clearly two different beasts. But more often than not, when the starting point is the data model, instead of the domain model we end up thinking that's the same data, hence the same class. I bet experienced data modelers do not fall into these pitfalls as well, but I've seen these problems recurring quite often.

Once we accept that little bit of data duplication we have a system which is a lot easier to evolve and maintain, with aggregate roots as integrity enforcers within their boundaries, and agnostic about the rest.

To add some salt, don't forget aggregates are also building blocks of distributed systems: suppose we'll need to send orders to a remote system. Sending just the single aggregate and the referenced value objects is probably the cleanest way.

Software ...e tutto ciò che comporta

Here are the slides from my presentation in Better Software 2010. I tuned it up a bit, changed the grey text, added comments (in italian) and a couple of slides. Hope you'll enjoy it.

Software ...e tutto ciò che comporta

View more presentations from Alberto Brandolini.

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.