tag:blogger.com,1999:blog-205768452024-03-15T16:44:45.435+01:00Ziobrando's LairAn independent blog on Software DevelopmentAnonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.comBlogger168125tag:blogger.com,1999:blog-20576845.post-79892928937874288612014-09-04T09:57:00.002+02:002014-09-04T09:57:58.867+02:00The final words about software estimation - Pecha Kucha talkHere 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...).
<iframe src="//www.slideshare.net/slideshow/embed_code/38682005" width="476" height="400" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe>Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com0tag:blogger.com,1999:blog-20576845.post-58182282445910857532014-08-23T16:17:00.001+02:002014-08-23T16:17:07.748+02:00The intrinsic non repeatability of the change agent<p>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.</p>
<p>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.</p>
<h2>What the market is looking for</h2>
<p>When selecting/interviewing a change agent the buyer company, most of the time ends up falling into two fundamentally flawed questions:</p>
<ul>
<li><em>Which results can you guarantee?</em></li>
<li><em>Have you done this before?</em></li>
</ul>
<div>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 <em>risk</em> is inevitably there. But the way to manage risk is probably to hire a <em>good </em>consultant, with <em>previous experience</em> on the matter, in order to mitigate that risk, or to implement some just in case ‘cover my ass’ strategy.</div>
<div> </div>
<div>This leads to a couple of weird problems: <strong>success in previous initiatives is no guarantee of success in the new one</strong>. More than anywhere else, <em>context is king</em>. 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 <em>avoiding customers with low success probability</em>. Which sounds a lot like the old Sun Tzu’s advice: <em>“battles are won before they’re ever fought”</em>.</div>
<div> </div>
<div>A more legitimate meaning of the <em>‘Have you done this before?’</em> 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.</div>
<div>
<h2>What happens in reality</h2>
</div>
<div>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 <em>guarantee </em>and <em>repeatability </em>are thinking tools for complicated systems. While <strong>in a complex system there is no guarantee that repeating an action will lead to the same result</strong>.</div>
<div> </div>
<div>If you hire Mourinho as a football coach, you’re <em>sure</em> you’re going to pay a lot of money, but there is no <em>guarantee</em> that he will deliver the expected result. This is what makes soccer still interesting, by the way.</div>
<div> </div>
<div>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 <em>experience</em>, it’s scars. It’s emotions, and last but not least it’s <em>learning</em>.</div>
<h3>The agent changes too</h3>
<div>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 <em>just because we’re doing it for the first time</em>. It’s something probably similar to <em>improvising </em>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<p> </p>
<p> </p>
<h2> </h2>Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com0tag:blogger.com,1999:blog-20576845.post-37798385936471498552014-06-21T16:15:00.003+02:002014-06-21T16:16:23.848+02:00EventStorming RecipesJust uploaded the slides of my talk at DDDeXchange London. Thanks to everybody for the great conversations.
<iframe src="//www.slideshare.net/slideshow/embed_code/36135704?rel=0" width="427" height="356" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px 1px 0; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="https://www.slideshare.net/ziobrando/event-storming-recipes" title="Event storming recipes" target="_blank">Event storming recipes</a> </strong> from <strong><a href="http://www.slideshare.net/ziobrando" target="_blank">Alberto Brandolini</a></strong> </div>Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com0tag:blogger.com,1999:blog-20576845.post-82891032746795445552014-06-16T16:04:00.001+02:002014-06-16T17:59:35.858+02:00Not Dead Yet<p>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 <em>“this is how we discuss things in the agile community”</em>.</p>
<p>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.</p>
<h2>Who’s paying for what</h2>
<p>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 <em>trying</em> to do.</p>
<p>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.</p>
<p>Let me explain that.</p>
<h3>It’s not about the code</h3>
<p>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…</p>
<p>…unless we stop focusing about code and start looking at <em>human beings</em> surrounding it. Some call them developers, but I am really more concerned about the human being, not the role.</p>
<p>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.</p>
<p>Even <em>worse</em>: 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.</p>
<p>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 <em>in the long term</em> but no one stays around long enough to catch the benefit</p>
<h2>Being short-term sustainable</h2>
<p>Yep. <em>In the long term</em>.</p>
<p>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 <em>I have no evidence to support it, just faith</em>.</p>
<p>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</p>
<p style="text-align: center;"><em>if you don’t code right, technical debt will bite your back </em></p>
<p>is flawed.</p>
<p>Well, technical debt <em>is</em> 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.</p>
<p>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).</p>
<p>So, I guess the real story with technical debt should be rephrased like</p>
<p style="text-align: center;"><em>if you don’t code right, technical debt will bite </em><strong><em>somebody’s</em></strong><em> back</em></p>
<p>meaning<em> …Not necessarily yours. </em>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: <a href="https://www.youtube.com/watch?v=sTUIHK7gHRE&feature=kp"><em>try this</em></a>.</p>
<h2>A little tragedy of the commons</h2>
<p>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 <a href="http://en.wikipedia.org/wiki/Tragedy_of_the_commons">tragedy of the commons</a>, that economists know very well: people acting in their own interest will ultimately harm a greater good.</p>
<h3>A system view</h3>
<p>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.</p>
<p>Does it sound familiar?</p>
<p>If the time needed to be rewarded for an effort is longer than the expected time in the system, well …who cares?</p>
<h3>Enter the Boy Scout Rule</h3>
<p>Interestingly, Uncle Bob proposed a solution for that: the so-called <a href="http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule">Boy Scout Rule</a>, which goes as follows:</p>
<p style="text-align: center;"><em>always leave the campground cleaner than you’ve found it</em></p>
<p>I love it, for many reasons. It creates a sense of ethics and belonging. It provides a little quick reward: <em>“I am doing something good here”.</em> 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.</p>
<h2>A higher duty</h2>
<p>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.</p>
<p>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.</p>
<h2>No hope in the short term?</h2>
<p>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.</p>
<p><iframe src="//www.youtube.com/embed/V4UfAL9f74I" width="420" height="315" frameborder="0"></iframe></p>
<p>Not yet, guys.</p>
<p>The thing is, good practices like TDD and continuous refactoring should repay themselves in the short term too. And they do, <em>…if you know them well enough</em>. Which means that you’re correctly accounting costs and benefits, including the cost of <em>learning TDD</em> and keeping it distinct from the cost of <em>doing TDD</em>.</p>
<p>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.</p>
<p>But the most interesting thing is that the best developers I know are <em>all </em>doing TDD. Not for religion, but because they get benefits in return. Not potential benefits, <em>just-in-case</em> style. Real benefits, in the short term.</p>
<p>Safety, confidence and <em>speed</em>.</p>
<p>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, <em>show a damn rails prototype right now!</em> It’s no religion, it’s a continuous evaluation of return on investment and evaluating <em>options</em>. 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 <em>I-told-you-so</em> look on their faces. That’s life, dude.</p>
<p>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.</p>
<p>So please, stop raising arguments like <em>“Yes, but if one day somebody wants to change the codebase”</em> 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.</p>Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com0tag:blogger.com,1999:blog-20576845.post-6397340758614996372014-05-19T10:47:00.001+02:002014-05-19T11:26:22.400+02:00Some updates about EventStorming<p>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.</p>
<p>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.</p>
<h2>EventStorming Community/Mailing List</h2>
<p>I’ve started a new public community on Google+: it’s called <strong>EventStormers</strong>. Here’s the <a href="https://plus.google.com/communities/113258571348605620818">link</a>. 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.</p>
<p>Some colleagues were already sharing content on the smaller private community called <strong>EventStorming Practitioners</strong>. 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 <em>going public, </em>will have to share their stuff again. That includes me too.</p>
<h2>Writing some stuff</h2>
<p>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).</p>
<p>Telling the <em>what</em> might be relatively straightforward, but telling the <em>why</em> and exploring the <em>how</em> 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.</p>
<p>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.</p>
<p>So I am asking your help.</p>
<p>If you are curious about EventStorming, please <a href="https://plus.google.com/communities/113258571348605620818">join the community</a> 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.</p>
<p>Thanks everybody</p>
<p> </p>
<h2> </h2>Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com0tag:blogger.com,1999:blog-20576845.post-28383355489737857082014-05-15T18:02:00.001+02:002014-05-19T11:25:57.621+02:00Go personal to boost engagement.<p>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.</p>
<p>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! :-/ </p>
<p>Well, I thought: <em>"This isn't going to last much"</em> 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: <em>"We don't have the right shoes for that!"</em>.</p>
<p>Ouch. Surprise. I've never thought about it. :-(</p>
<p>Add that to the fact that I couldn't adopt my usual <em>I'll-kick-you-in-the-butt</em> 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.</p>
<h2>Time for a Plan B</h2>
<p>The surprise trick that really worked well was "could you please add <strong><em>Actors</em></strong> close to the corresponding event?" and since "actor" meant <em>"me"</em> for many of the participants, they all stood up and added information to the model, raising engagement at the same time. Wow!</p>
<p>Ok, lessons:</p>
<ol>
<li>As Jef Claes reminded me, <strong>remove seats</strong>. I focused on the table and forgot the smaller enemies. Seats were still there, inviting and comfortable</li>
<li>Environment matters <em>a lot</em>. 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 <strong>room preparation checklist</strong> (next post, maybe). As Sun Tzu said: <em>"Every battle is won before it's ever fought"</em></li>
<li> 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.</li>
<li>shoes... maybe mention 'bring comfortable shoes' in the invitation.
</ol>
Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com0tag:blogger.com,1999:blog-20576845.post-34062001188467624502014-05-06T16:42:00.001+02:002014-05-19T11:24:56.102+02:00EventStorming: invite the right people<h1>Invite the right people</h1>
<p style="margin: 0px 0px 12px; text-align: right;" ><em>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</em></p>
<p>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.</p>
<h2>Who should be invited?</h2>
<p>Ideally, one would like to have participants coming from two fields: people with <strong><em>questions</em></strong> and people with <strong><em>answers</em></strong>. They provide the perfect mix of curiosity and wisdom.</p>
<p>When exploring complex business domains (the scope of EventStorming is usually the whole business flow) this implies that <em>a lot of people should be involved</em>, and triggers a lot of warnings. Let's see some.</p>
<ul>
<li>They won't be <strong>available</strong> at the same time.</li>
<li>The meeting will turn into a <strong>waste of time</strong>, at least for many of them.</li>
<li>You'll end up nowhere due to <strong>conflicts</strong> that may arise.</li>
</ul>
<p>All these worries are legitimate. But they lead us to do things in a way that doesn't work. The <em>meaningful conversation with the Domain Expert</em> that is at the core of Domain-Driven Design is often <em>not that meaningful</em>.</p>
<h3>Should I look for specific roles?</h3>
<p>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.</p>
<p>So I won’t provide any answer like <em>‘every developer should attend the workshop’</em> or <em>‘only team leaders, business analysts and domain expert should be there’</em>. Instead I’ll suggest to take a different path.</p>
<h3>A somewhat zen answer</h3>
<p>The best answer that comes to my mind is something that may disappoint you: <em>“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”</em>. Now name the people you saw, and invite them.</p>
<p>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 <em>roles</em> or <em>attitudes</em>?</p>
<h3>A more cynical answer</h3>
<p>If this sounds too mystical, or you feel that the key people won’t show up, you may run the opposite approach: <em>“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?” </em>And if they don’t look like interested in your unconventional type of meeting you might present the bargain: <em>join the meeting now instead of the post-mortem, you might save some cash this way</em>.</p>
<h2>Conflicts are fine</h2>
<p>The most common objection, albeit often implicit, is that <em>if we bring all of those people together we won’t be able to handle the conflicts.</em> 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.</p>
<p>The fact is <em>conflict is there, and probably will be there tomorrow too</em>, and it will probably be one of the most dangerous risk factors in your project, so why waiting?</p>
<p>In <a href="http://www.growing-object-oriented-software.com/">GOOS</a> book, Freeman and Pryce introduce the notion of <em>Walking Skeleton</em> 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.</p>
<p>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.</p>
<h3>Managing conflicts</h3>
<p>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?).</p>
<p>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 <em>subdomains</em>), 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.</p>
<h4>A place for hotspots</h4>
<p>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 <em>“it’s not exactly like that”</em>, that’s the moment to listen to a <strong>story</strong>: <em>“can you explain us why?”</em></p>
<p>The interesting thing is that, the physical model makes it easy to trigger the conflict - because you <em>see</em> 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.</p>
<h4>Solving some conflicts…</h4>
<p>Many conflicts may in fact be solved using one of Domain-Driven Design secret weapons: <strong>Bounded Contexts</strong>. 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.</p>
<p>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.</p>
<h4>… and get along with some others</h4>
<p>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 <em>during the workshop</em>. Some others, would never be solved (the <em>I-hate-you-damn-bastard-and-I-always-will</em> category, for example).</p>
<p>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.</p>
<p>In general I am not trying to <em>solve issues </em>or to <em>take decisions</em> during an EventStorming session. My primary concern is to keep the workshop flow going, to have everybody engaged in what we’re building together.</p>
<h2>What if we won’t have all the people?</h2>
<p>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 <em>relationships</em>.</p>
<p>Beware of those folks who promise <em>they’ll join you later</em>. Especially if they are <em>Italians</em>. They’ll miss all the key information: one can not understand a movie from the ending titles, and <em>being there</em> is the most successful ingredient.</p>
<h3>Just getting there</h3>
<p>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.</p>
<p>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 <em>fight for my right to party</em> there might be situation where a temporary trade-off is necessary. Here are some basic tips to get you started.</p>
<ul>
<li><strong>Declare experiments</strong>: 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.</li>
<li><strong>Manage risk</strong>: 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).</li>
<li><strong>Timebox</strong>: 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.</li>
<li><strong>Look at people’s faces</strong>: bored people tend to <em>look</em> bored. Just ask them why they’re not finding interest. And take some corrective action.</li>
<li><strong>It’s not a trap</strong>: 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.</li>
<li><strong>Take breaks</strong>: 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.</li>
<li><strong>Retrospect</strong>: 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.</li>
</ul>
<p>In some organisations, key stakeholders won’t be available at the same time, or won’t free their time for <em>just another meeting</em>. It’s fine. You haven’t achieved anything yet.</p>
<p>Let your first EventStorming build some reputation in order to be attractive for key domain experts, in the next session.</p>
Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com0tag:blogger.com,1999:blog-20576845.post-61806499406402935402013-11-18T18:29:00.001+01:002018-09-05T15:09:19.445+02:00Introducing Event Storming<b>Disclaimer: </b><i>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 <b>a lot</b> 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 <a href="https://leanpub.com/introducing_eventstorming" target="_blank">writing a book about it</a>, which is slowly progressing to completion. As of today, the better entry point to understanding EventStorming potential is probably my presentation <a href="https://www.slideshare.net/ziobrando/50000-orange-stickies-later" target="_blank">50.000 orange stickies later</a> (which is also available in <a href="https://www.youtube.com/watch?v=1i6QYvYhlYQ" target="_blank">video</a>) or reading the first chapter of the book, which is available for free. We are also working on a new version of the <a href="http://eventstorming.com/">EventStorming.com</a> website that should organize pointers to the interesting content about EventStorming that many practitioners published.</i><br />
<br />
<br />
<a name='more'></a><br />
In the past months I’ve spent some time experimenting with this weird thing. It started like an <em>“Ouch I have no time to draw a precise UML diagram, let’s do this instead” </em>then became a thing called Event-Based modelling workshop that I presented at Italian Agile Day 2012, I later had the chance to do more experiments in Belgium and Poland during Vaughn Vernon’s IDDD tour, and I gathered incredibly valuable feedback and insights. I managed to find a cooler name - <strong>EventStorming</strong> - just before the whole thing exploded in summer 2013. While I realized there was a lot of value in it, other practitioners (<a href="http://verraes.net/2013/09/dddbe-modellathon/">Mathias Verraes</a>, <a href="http://tojans.me/blog/2013/09/04/the-very-first-dddbe-event-the-modellathon/">Tom Janssen</a>, <a href="http://www.heimeshoff.de/wordpress/?p=276">Marco Heimeshoff</a>, Yves Reynhout,<a href="http://www.meetup.com/DDD-Paris/events/142503812/"> Tomas Jaskula</a>, <a href="http://bettercoderwannabe.blogspot.it/2013/09/first-event-storming-experiment.html">Alessandro Colla</a>, Andrea Balducci,<a href="http://www.jefclaes.be/2013/11/event-storming-workshop-slides.html"> Jef Claes</a>, just to name a few) started exploring and playing with the format with amazing results, leading me to the conclusion that this is something more than “just another workshop format”.<br />
<h1>
What is EventStorming</h1>
EventStorming is a workshop format for quickly exploring complex business domains.<br />
It is <strong>powerful</strong>: it has allowed me and many practitioners to come up with a comprehensive model of a complete business flow in hours instead of weeks.<br />
It is <strong>engaging</strong>: the whole idea is to bring people with the questions and people who know the answer in the same room and to build a model together.<br />
It is <strong>efficient</strong>: the resulting model is perfectly aligned with a Domain-Driven Design implementation style (particularly fitting an Event Sourcing approach) and allows for a quick determination of Context and Aggregate boundaries.<br />
It is <strong>easy</strong>: the notation is ultra-simple. No complex UML that might cut off participants from the heart of the discussion.<br />
It is <strong>fun</strong>: I always had a great time leading the workshops, people are energized and deliver more than they expected. The right questions arise, and the atmosphere is the right one.<br />
<h1>
How does it work</h1>
Here are the basic steps:<br />
<ul>
<li><strong>Invite the right people</strong> to the workshop. Ideally you’ll want a large meeting room with 6..8 people, with the right mixture of the ones who know the questions to ask (and which are curious to listen to the answer) and the ones who know the answers.</li>
<li><strong>Provide unlimited modeling space</strong>. Too often complex problems are not properly analyzed because there’s not enough space available to <em>see</em> the problem. Your problem is bigger than your whiteboard, so what? My solution is to <em>hack the modeling space</em> using whatever available (my favorite tool is an Ikea paper roll) to get rid of the space limitation.</li>
<li><strong>Explore the domain starting from <em>Domain Events</em></strong>. A <em><strong>Domain Event</strong></em> is something meaningful happened in the domain. It can be easily translated into <em>software</em>, but the real value here is that it could be quickly grasped from non-technical people. An event might be the predecessor of the follower of another one. Place all of them on your modeling surface (the convention is to use <em>orange</em> stickies for this purpose) according to a timeline.</li>
<li><strong>Explore the origin of Domain Events</strong>. Some events are the direct consequence of a user action —> represent it as a <em style="font-weight: bold;">Command</em> using a <em>blue</em> sticky note. Others are the consequence of something happening in external systems or of the time passing, we’ll use a <em>purple</em> sticky note for them. In some other cases, we’ll have events that will be the direct consequence of some other events. We’ll simply place the two events close together.</li>
<li><strong>Look for Aggregates</strong>. Instead of defining aggregates starting from the code, we’re taking an outside-in approach: the <strong><em>Aggregate</em></strong> is the portion of the system that receives commands and decides whether to execute them or not, thus producing a <em>domain event</em>.</li>
</ul>
<div>
<h2>
Bonus targets</h2>
These are the basic steps of the original EventStorming format. However, you might spot some bonus goals along the way, if the discussion becomes hot. Here’s a list of the possible bonus targets which are worth considering as a rewarding detour from the standard route.<br />
<ul>
<li><strong>Exploring Subdomains</strong>: some domain experts will show more expertise in an area, leaving other portions of the domain to others. Different areas of responsibility map pretty well to different subdomains or <em>portions of the pork</em> if you’ve been exposed to my presentations in the past.</li>
<li><strong>Exploring Bounded Contexts</strong>: during the discussion, some conflict areas might emerge. Developers and facilitators with a DDD mindset will spot different interpretations of terms, as a trigger for discussion around the meaning. This might be a good moment to draw the boundaries between the multiple consistent models that will coexist in your domain.</li>
<li><strong>Sketching User Personas</strong>: when talking about commands, conversation tends to steer towards the context where the command is issued and the goals of the person triggering the action. This is valuable information, don’t blow it! You may expand the notation to include little yellow sticky notes as personas.</li>
<li><strong>Sketching Key Acceptance Tests</strong>: if the discussion starts revolving around corner cases or ambiguous scenarios, there’s no better way to remove ambiguity than to define a clear acceptance test. Not all scenarios will need to be documented in such a way (I mean <em>not in this workshop</em>, mostly for time reasons) but if they’re a tiebreaker in some areas there’s no reason not capture the emerging knowledge right now.</li>
<li><strong>Sketching Key Read Model Artefacts</strong>: for some scenarios what the users see if far more important than what the system does. If a screen, table or graph particularly valuable to a given user, just sketch it in a sticky and place it close to the command it is associated to.</li>
</ul>
<div>
<div>
Below an overview of all the possible the workshop steps, so far:</div>
<div align="center" margin="20" padding="20">
<img alt="All the possible workshop steps" border="0" height="400" src="https://lh3.googleusercontent.com/-2x4VNk-s32g/UouhUvPHbWI/AAAAAAAAAi8/oicOlEmD7i4/w1405-h1123-no/Event+Storming+Cards+-+all.jpg" title="Event Storming Cards - all.jpg" width="500" />
</div>
<div align="center">
<em>A better quality image could be seen <a href="https://lh3.googleusercontent.com/-2x4VNk-s32g/UouhUvPHbWI/AAAAAAAAAi8/oicOlEmD7i4/w1405-h1123-no/Event+Storming+Cards+-+all.jpg">here</a></em> <!-- <img alt="IMG 2297" border="0" height="479" src="http://lh4.ggpht.com/-Dvaoa2b12Go/UopOfgSH9HI/AAAAAAAAAhU/7nO1Voigl70/IMG_2297.jpg?imgmax=800" title="IMG_2297.jpg" width="600" /> -->
</div>
</div>
<br />
<div>
Putting everything together is a lot of stuff. Just keep in mind that the goal of the workshop is to learn as much as possible in the shorts possible time. We invited key people to the workshop, and we don’t want to waste their time.</div>
<div>
So, when it comes to these bonus goals, be ready to use time in the most efficient way: you get a valuable hint, just sketch it and place the corresponding sticky in the hotspot. Don’t drive the discussion towards model completeness: the model is going to be huge, completing it might be of little value or even sound scary for some participants.</div>
</div>
<div>
</div>
<div>
Embracing incompleteness will make the workshop less boring and more fruitful.</div>
<div>
<h2>
Choosing the right format</h2>
</div>
<div>
As you noticed, there isn’t a single format for the workshop. In fact, the first steps are more or less the same, but the format may vary according to the roles of the participants, and the project scope.</div>
<h3>
Minimal Scope</h3>
<div>
I’ve found the results really valuable even when stopping with Domain Events, i.e. we did an EventStorming session in my company exploring the business flow of training classes we are running. Participants were not developers, so the goal was simply <em>understanding the system by asking the right questions</em>. And we did it in a couple of hours. At the end of the workshop, every new hire had a clear idea of what our company was supposed to do.</div>
<div align="center" margin="20" padding="20">
<img align="center" alt="IMG 2171" border="0" src="https://lh6.ggpht.com/-eXxJSf8ebJw/UopOdSSWrnI/AAAAAAAAAhE/Q0Wc62lFS3A/IMG_2171.JPG?imgmax=800" title="IMG_2171.JPG" width="500" />
</div>
<div align="center">
<em>(In this scenario we used a slightly different notation, that was more meaningful for the participants: Orange —> Events, Purple —> external systems, Blue —> external organizations or communities, Green —> Artefacts).</em> </div>
<br />
<div>
When exploring for software development the result is even more powerful. Aggregates, Commands and Domain Events, all map pretty well into software artifacts. You might run the workshop to grasp the big picture really quickly and to provide a physical space where discussion around the flow happen.</div>
<div>
<h2>
Turning the model into code</h2>
</div>
<div>
DDD practitioners like this approach not only because it’s fun but also because the resulting model is a lot closer to what they need: <strong>this ain’t no data model</strong>. The resulting model is fully behavioral: there is no underlying data model that constraints the implementation against its very nature. If you’re oriented towards Command-Query Responsibility Segregation chances are that after trying the workshop you’ll be experiencing the urgency of offering me a beer.</div>
<div>
<br /></div>
<div>
You can also start coding almost immediately and validate the result of your exploration in code in a very short time. This is what most productive teams do, and the combination of discussion-based discovery with a Domain-Driven oriented implementation can deliver massive improvements.</div>
<div>
<br />
You’ll be basically implementing the right thing faster.</div>
<div>
<h2>
How do I start doing EventStorming?</h2>
Running an experiment isn’t that difficult. All you need is:<br />
<ul>
<li>a <strong>suitable room</strong>, quiet and large enough to contain the modeling surface (if the weather permits, outdoor modeling might be an option too, but the wind might be a major blocker);</li>
<li>a <strong>writable surface</strong>, most likely an Ikea paper roll (codename Måla, you can find it in the kids' area).</li>
<li>a LOT of <strong>sticky notes</strong>, in different flavors (the basic set is pale yellow rectangular stickies, plus orange, blue, and purple squared ones);</li>
<li>working <strong>markers</strong>, ideally one per participants plus backup;</li>
<li>some <strong>masking tape</strong>, just in case;</li>
<li>the right <strong>people</strong>.</li>
<li>a <strong>facilitator</strong>.</li>
</ul>
<div>
You might want to prototype the execution in a sandbox (some User Groups are perfect for that, they love experiments) before involving your Darth Vader-like boss. You might also want to join the growing community of practitioners and experimenters.</div>
<div>
Or you might want to <a href="http://www.avanscoperta.it/en/training/event-storming-workshop-2/">hire a facilitator</a>, for a day or two, to run the workshop in your company, while providing guidance about the workshop itself and the further possible steps.</div>
<div>
<h1>
What’s next…</h1>
While practicing and experimenting with EventStorming, I realized that I’ve stumbled upon something bigger. I tried to tell the story of what happened in the past month in <a href="http://www.slideshare.net/ziobrando/model-storming">this presentation</a>. I called <strong>Model Storming</strong> the more general approach I am now applying, with EventStorming being just the most notable implementation.<br />
More about it will come soon. This stuff is too cool to keep it only for me! ;-)</div>
<div>
</div>
</div>
Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com4tag:blogger.com,1999:blog-20576845.post-32083212209465037552012-10-25T23:44:00.001+02:002012-10-25T23:44:28.747+02:00My perspective on the coding versus modeling balance<div class="separator"style="clear: both; text-align: center;"><a href="https://lh4.googleusercontent.com/-2N-oWxJSWHk/UImyuKjW0JI/AAAAAAAAAWk/sE21tM5NEvY/s640/blogger-image--1949023086.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://lh4.googleusercontent.com/-2N-oWxJSWHk/UImyuKjW0JI/AAAAAAAAAWk/sE21tM5NEvY/s640/blogger-image--1949023086.jpg" /></a></div>Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com2tag:blogger.com,1999:blog-20576845.post-42810686644623346912012-10-12T18:02:00.000+02:002012-10-12T18:02:44.311+02:00Root Cause Analysis stencil uploaded on Graffletopia StencilThere 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 <a href="http://graffletopia.com/stencils/928">I just uploaded to Graffletopia</a> for sharing.<br />
<br />
<h3>
Notation info</h3>
<div>
<ul>
<li><b>Observable Facts</b> are ellipses (or bubbles). </li>
<li>When using a tool for drawing like OmniGraffle, I take advantage of <b>colors</b> to display <i><b>perceived severity</b></i>. White is <i>neutral</i>, from yellow to red is <i>bad</i>. Black is <i>disaster</i>.</li>
<li><b>Border thickness </b>maps to our <b><i>perception of our ability to affect/change a phenomenon</i></b>. 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).</li>
<li><b>Unknown Areas</b> are represented as clouds. There's something important there which we don't know yet.</li>
<li><b>Question marks</b> 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.</li>
<li>Since my primary use is to collect information for change at a system level, <b>local solutions </b>are part of the notation also.</li>
<li><b>Direct dependencies </b>are represented by arrows. </li>
<li>Dotted line arrows represent <b>indirect dependencies</b>. 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.<i> </i>It's less precise, but at sketching time I probably don't have enough information to make a clear distinction anyway.</li>
</ul>
</div>
<h3>
Some guidance</h3>
<div>
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 ("<a href="http://www.amazon.com/The-Fifth-Discipline-Practice-Organization/dp/0385260954" target="_blank">The Fifth Discipline</a>"), Craig Larman ("<a href="http://www.craiglarman.com/wiki/index.php?title=Book_-_Scaling_Lean_and_Agile_-_Thinking_and_Organizational_Tools" target="_blank">Scaling Lean & Agile Developmen</a>t" and from Eliyahu Goldratt (who described the <i>Reality Tree </i>in "<a href="http://www.amazon.com/Its-Not-Luck-Eliyahu-Goldratt/dp/0884271153" target="_blank">It's not Luck!</a>").</div>
<div>
<br /></div>
<h4>
Collecting Data</h4>
<div>
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.</div>
<div>
<br /></div>
<div>
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,</div>
<div>
<br /></div>
<div>
Please feel free to share your comments. Hope you'll find it useful!</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com2tag:blogger.com,1999:blog-20576845.post-3091030707189373372012-01-02T16:56:00.001+01:002012-01-02T16:56:56.472+01:00Setting up a DDD sample app<p>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.<br /> 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.</p><h2>Why should I regret it?</h2><p>As I said, the request is both legitimate and innocent. What could be the drawbacks. I can point out two.</p><li><strong>Time</strong>: 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.</li><li><strong>Questions</strong>: 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 <em>“how do you do this with Spring and Hibernate?”</em> 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.</li><h1>Choosing a domain</h1><p>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 <strong><em>precision</em></strong> in defining what this is really about. Simply knowing how things work in the training domain won’t be enough.</p><h1>Choosing a programming language</h1><p>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.</p><li><strong>Java</strong>: 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.</li><li><strong>Groovy</strong>: 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.</li><li><strong>C#</strong>: 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.</li><li><strong>Ruby</strong>: I am relatively new to the language, and probably missing some key tips on the technology stack and on the programming style (<em>“You still think like a Java guy”</em> Paolo Perrotta once said, I hope I improved a little since then…).</li><p>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.</p><p>So I opened up the IDE and started coding.</p><p>Wrong choice.</p><p>After setting up an <strong>Aggregate</strong> an some satellite <strong>Services</strong> 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?</p><p>Ambiguity.</p><p>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 <em>“let’s show some code quickly”</em> approach that I started with, didn’t really work. To define exactly what my aggregates were supposed to do, I needed a lot more <em>precision</em>, 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.</p><p>Well, that was no surprise. <em>That’s exactly what DDD is for</em>. And a common, simplified development cycle is:</p><ol><li>gather some information from the domain expert about features A, B and C; </li><li>quickly implement it as a domain model, using DDD patterns; </li><li>spot contradictions in the current understanding of the domain, that emerge from the model; </li><li>refine the model, asking to the domain expert <em>what he precisely meant</em> when he talked about features A, B, and C. </li></ol><br />The only weird thing is that <em>all the roles are in my head now</em>. 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. <br /><h1>Providing a little structure</h1><br />I want to model my aggregates around a problem, and I want this to be precisely defined. So, despite this being <em>just an example</em>, 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. <br /><br /><img style="display:block; margin-left:auto; margin-right:auto;" src="http://lh6.ggpht.com/-5lsueuISnho/TwHTvwHBYDI/AAAAAAAAAS0/yxtBT-xwnPE/DDD%252520Sample%252520User%252520Story.jpg?imgmax=800" alt="DDD Sample User Story" title="DDD Sample User Story.jpg" border="0" width="405" height="268" /><br /><br />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.</br><br />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.<br /><div><strong>Scenario</strong>: <em>Publishing a new training</em></br><strong>Given</strong> a Catalog</br><strong>And</strong> a Training <em>gourmet coding</em> not yet published</br><strong>When</strong> I publish Training <em>gourmet coding</em> on Catalog</br><strong>Then</strong> Training <em>gourmet coding</em> is available on Catalog</br></div><br /><br />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. <br /><br />By the way, despite my previous experiences with Cucumber and Java, and the precious guidance by <a href="http://cuke4ninja.com/">the secret ninjas cucumber scrolls</a>, setting up again Cuke4Duke in my project didn’t work that smoothly. Looks like Maven got in the way. Again. <br /><br />No, please. Not <em>that</em> again. <br /><br />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. <br /><br /><h1>Modeling question number one </h1><br />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 <em>within the boundaries</em> of my application. I said <em>“boundaries</em>” which means that I need to define scope more precisely. A little <strong>context map</strong> will do the job.<br /><div text-align="center"><img style="display:block; margin-left:auto; margin-right:auto;" src="http://lh6.ggpht.com/-4Rm77-Bk9u4/TwHTxbEbYPI/AAAAAAAAAS8/Y-9MQnLaioc/Bounded%252520Contexts%252520plus%252520ACL.jpg?imgmax=800" alt="Bounded Contexts plus ACL" title="Bounded Contexts plus ACL.jpg" border="0" width="515" height="392" /><em>The ultra-basic context map, with my application and an Anti-Corruption Layer separating it from the external website model</em></div><br /><br /> 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 <strong>domain service</strong> 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 <em>shamelessly fake everything</em>, but behind the same interface.<br /><br /><h1>Ruby, the architecture and me </h1><br />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. <br /><h2>Persistence framework</h2> <br />After exploring a little, I’ve chosen <a href="http://sequel.rubyforge.org/">Sequel</a>. A lightweight persistence framework that can be used at two different levels of abstraction. I started with the very low level approach, so my <strong>repositories</strong> now look a little <em>vintage</em>. :-) <br /><br />Also <a href="http://datamapper.org/">DataMapper</a> looked interesting. I’ll probably give it a try when trying to make the architecture a little more agnostic about persistence frameworks. <br /><br />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. <br /><h2>What I like so far</h2><br />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. <br /><br /><h2>What I don’t like so far </h2><br />Of course the database had his revenge after <a href="http://www.slideshare.net/ziobrando/drive-your-dba-crazy-in-3-easy-steps">that presentation</a>. 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. <br /><br />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 <strong>Application Facade</strong> and <strong>Repository</strong>) probably have a more elegant alternative implementation in Ruby, and there are some <strong>Singletons</strong> around (forgive me) which are basically placeholder for a different implementation. In general wiring up is not as elegant as I would haver liked. <br /><h1>Ok, but where is the code? </h1><br />I’ve started a project on GitHub. It’s called D3N. You can find it <a href="https://github.com/ziobrando/D3n">there</a>. 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). <br />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. <br /><br />As somebody once said: <em>it’s the journey, not the destination</em>.<br /><br />Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com3tag:blogger.com,1999:blog-20576845.post-31583472209244044322011-11-30T12:01:00.001+01:002011-11-30T12:42:01.740+01:00Denial won't help you learning<p>While preparing my talk (<a href="http://www.agilemovement.it/video/volevo-solo-scrivere-codice">video</a>) 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.</p><p>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.</p><h2>My key factors for successful learning</h2><p>(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 <em>the amount of relevant <strong>knowledge</strong> learnt during the project</em>. 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:</p><ol><li>Team attitude</li><li>Motivation</li><li>Context.</li></ol><p>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 <em>also</em> 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 <em>as a team</em>.</p><p>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 <em>learn</em> from the colleagues or to <em>teach</em> them something.</p><p>The one single thing that made a lot of difference was the attitude me and my colleagues shared in those difficult projects.</p><h2>Learning attitude patterns</h2><p>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.</p><p><strong>“I know what I am talking about” </strong>that the kind of sentence often heard in organizations. To me, it means <em>“I don’t feel any need to improve”</em>. 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.</p><p><strong>“That’s all clear to me”</strong> ... No. It isn’t. People that for some reasons <em>pretend</em> 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.</p><p><strong>“I have no clue about what we’re going to do”</strong> 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 <em>“I know absolutely nothing about the topic of this project”</em>, and - believe me - their faces were even better when I answered honestly <em>“I have no idea about it either”</em>. But that conversation was <strong>honest</strong>, 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.</p><p>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: <em>“The real wise man is the one that knows that he doesn’t know”</em>. <em>...But not only. </em></p><h2>Focusing efforts in the right direction</h2><p>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 <em>waste</em> 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 <strong><em>knowledge debt</em></strong>, and we didn’t spend a second studying <em>things that people around me expect me to know but I don’t</em>.</p><p>Don’t you smell something familiar here? It smells like <em>your dirty little secret</em> 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 <em>“I can’t let them discover my secret" </em>mode<em>, </em>which is a dangerous slope: it makes you feel like “I am not the person they expect”.</p><p>It doesn’t matter how bad is our secret, the mechanics are similar: <em>shame</em> and <em>fear of humiliation</em> (even if only at the coffee machine level) are powerful triggers, and would lead to the wrong behavior, and also to<em> learn less</em> 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 <em>cover-my-ass</em> 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 <em>that other girl'</em>s wall on Facebook?).</p><p>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 <em>fault</em>, 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.</p><p>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.</p><h2>Only knowledge gap?</h2><p>Not really. The more I look into the problem, the more I realize that the mechanics are the same whether it is <em>knowledge</em> or <em>learning debt</em>, <em>technical debt</em> or <em>motivational debt</em>. 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 <em>motivation</em> and <em>context</em>... Stay tuned.</p><p> </p>Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com3tag:blogger.com,1999:blog-20576845.post-4732153974192848822011-03-07T23:22:00.001+01:002011-03-07T23:22:42.190+01:00See the Forest and the trees with KanbanI uploaded the slides of my presentation about Kanban that I gave at last UGI Alt.Net Conf in Milan.<div style="width:425px" id="__ss_7169759"><strong style="display:block;margin:12px 0 4px"><a href="http://www.slideshare.net/ziobrando/forest-and-trees-with-kanban" title="Forest and trees with kanban">Forest and trees with kanban</a></strong><object id="__sse7169759" width="425" height="355"><param name="movie" value="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=forestandtreeswithkanban-110306155156-phpapp01&stripped_title=forest-and-trees-with-kanban&userName=ziobrando" /><param name="allowFullScreen" value="true"/><param name="allowScriptAccess" value="always"/><embed name="__sse7169759" src="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=forestandtreeswithkanban-110306155156-phpapp01&stripped_title=forest-and-trees-with-kanban&userName=ziobrando" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="355"></embed></object><div style="padding:5px 0 12px">View more <a href="http://www.slideshare.net/">presentations</a> from <a href="http://www.slideshare.net/ziobrando">Alberto Brandolini</a>.</div></div>Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com0tag:blogger.com,1999:blog-20576845.post-29102124968763233012010-10-17T10:13:00.001+02:002010-10-26T15:25:14.680+02:00Loosely Coupled Complexity - Unleash the power of your Domain Model with Command Query Responsibility Segregation and Event SourcingHere are the slides of my presentation about CQRS and Event Sourcing, that I gave at NHibernate Day in Bologna last week.<div style="width:425px" id="__ss_5459541"><strong style="display:block;margin:12px 0 4px"><a href="http://www.slideshare.net/ziobrando/loosely-coupled-complexity-unleash-the-power-of-your-domain-model-with-command-query-responsibility-segregation-and-event-sourcing" title="Loosely Coupled Complexity - Unleash the power of your Domain Model with Command Query Responsibility Segregation and Event Sourcing">Loosely Coupled Complexity - Unleash the power of your Domain Model with Command Query Responsibility Segregation and Event Sourcing</a></strong><object id="__sse5459541" width="425" height="355"><param name="movie" value="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=cqrseventsourcing-101016055756-phpapp02&stripped_title=loosely-coupled-complexity-unleash-the-power-of-your-domain-model-with-command-query-responsibility-segregation-and-event-sourcing&userName=ziobrando" /><param name="allowFullScreen" value="true"/><param name="allowScriptAccess" value="always"/><embed name="__sse5459541" src="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=cqrseventsourcing-101016055756-phpapp02&stripped_title=loosely-coupled-complexity-unleash-the-power-of-your-domain-model-with-command-query-responsibility-segregation-and-event-sourcing&userName=ziobrando" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="355"></embed></object><div style="padding:5px 0 12px">View more <a href="http://www.slideshare.net/">presentations</a> from <a href="http://www.slideshare.net/ziobrando">Alberto Brandolini</a>.</div></div><br />And if you're masochistic enough to stand my accent ...here is the <a href="http://vimeo.com/16054927">video</a>.Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com2tag:blogger.com,1999:blog-20576845.post-33551500029947319862010-10-12T14:23:00.001+02:002010-10-12T14:23:16.764+02:00DDD Reference Links<p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 28.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Further references</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 18.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Books</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Domain Driven Design - Eric Evans (Addison Wesley)</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;">The official starting point for Domain Driven Design, covering the topic form tactical to strategical.</span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Applying Domain-Driven Design and Patterns (Addison Wesley)</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;">A more implementation related approach focusing on the mechanics of the implementation of tactical DDD with C# and .Net. </span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>DDD Quickly</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;">A free dowloadable smaller reference for Tactical DDD from InfoQ</span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #0e1f99;"><span style="text-decoration: underline; letter-spacing: 0.0px;"><a href="http://www.infoq.com/minibooks/domain-driven-design-quickly">http://www.infoq.com/minibooks/domain-driven-design-quickly</a></span><span style="letter-spacing: 0.0px color;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 18.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Domain Driven Design website</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;">New official website for Domain Driven Design. Aggregator for further resources, informations, discussion and events</span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #0e1f99;"><span style="text-decoration: underline; letter-spacing: 0.0px;"><a href="http://domaindrivendesign.org">http://domaindrivendesign.org</a></span><span style="letter-spacing: 0.0px color;">/</span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 18.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Domain Driven Design User Group</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;">This is the place where the most interesting discussions are hosted</span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #0e1f99;"><span style="text-decoration: underline; letter-spacing: 0.0px;"><a href="http://tech.groups.yahoo.com/group/domaindrivendesign/">http://tech.groups.yahoo.com/group/domaindrivendesign/</a></span><span style="letter-spacing: 0.0px color;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Italian Domain Driven Design group</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #0e1f99;"><span style="text-decoration: underline; letter-spacing: 0.0px;"><a href="http://it.groups.yahoo.com/group/DDD-IT/">http://it.groups.yahoo.com/group/DDD-IT/</a></span><span style="letter-spacing: 0.0px color;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 18.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Eric Evans interviews and talks on InfoQ</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #0e1f99;"><span style="text-decoration: underline; letter-spacing: 0.0px;"><a href="http://www.infoq.com/interviews/domain-driven-design-eric-evans">http://www.infoq.com/interviews/domain-driven-design-eric-evans</a></span><span style="letter-spacing: 0.0px color;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #0e1f99;"><span style="text-decoration: underline; letter-spacing: 0.0px;"><a href="http://www.infoq.com/presentations/model-to-work-evans">http://www.infoq.com/presentations/model-to-work-evans</a></span><span style="letter-spacing: 0.0px color;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #0e1f99;"><span style="text-decoration: underline; letter-spacing: 0.0px;"><a href="http://www.infoq.com/articles/eric-evans-ddd-matters-today">http://www.infoq.com/articles/eric-evans-ddd-matters-today</a></span><span style="letter-spacing: 0.0px color;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #0e1f99;"><span style="text-decoration: underline; letter-spacing: 0.0px;"><a href="http://www.infoq.com/presentations/strategic-design-evans">http://www.infoq.com/presentations/strategic-design-evans</a></span><span style="letter-spacing: 0.0px color;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #0e1f99;"><span style="text-decoration: underline; letter-spacing: 0.0px;"><a href="http://www.infoq.com/presentations/ddd-dsl-evans">http://www.infoq.com/presentations/ddd-dsl-evans</a></span><span style="letter-spacing: 0.0px color;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>DDD sample Application</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;">A working implementation of DDD principles in SpringMVC plus Hibernate, maintained by Swedish company Citerus.</span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #0e1f99;"><span style="text-decoration: underline; letter-spacing: 0.0px;"><a href="http://dddsample.sourceforge.net">http://dddsample.sourceforge.net</a></span><span style="letter-spacing: 0.0px color;">/ </span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><h3 style="margin: 0.0px 0.0px 0.0px 0.0px; font: 18.0px Helvetica;"><span style="font-size: small;"><span style="font-size: 12px;"><span style="font-size: large;"><span style="font-size: 18px;"><strong>CQRS & Event Sourcing</strong></span></span></span></span></h3><p>I needed a separate page for that:</p><p><a href="http://ziobrando.blogspot.com/2010/10/cqrs-event-sourcing-reference-links.html">http://ziobrando.blogspot.com/2010/10/cqrs-event-sourcing-reference-links.html</a></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 18.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>DDD, TDD & BDD</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;">The three amigos: DDD, TDD & BDD Presentation by Gojko Adzic</span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #1022a3;"><span style="text-decoration: underline; letter-spacing: 0.0px;"><a href="http://skillsmatter.com/podcast/design-architecture/ddd-tdd-bdd">http://skillsmatter.com/podcast/design-architecture/ddd-tdd-bdd<span style="text-decoration: underline; letter-spacing: 0.0px color;"></span></a></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;">Gojko Adzic’s Blog: <a href="http://gojko.net/"><span style="font: 12.0px Helvetica; text-decoration: underline; letter-spacing: 0.0px color;">http://gojko.net/</span></a></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 18.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Context mapping</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Strategic Domain Driven Design with Context mapping</strong> (My article on InfoQ)</span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #1022a3;"><span style="text-decoration: underline; letter-spacing: 0.0px;"><a href="http://www.infoq.com/articles/ddd-contextmapping">http://www.infoq.com/articles/ddd-contextmapping<span style="text-decoration: underline; letter-spacing: 0.0px color;"></span></a></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Context Mapping in Action</strong> - Presentation by Alberto Brandolini</span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #1022a3;"><span style="text-decoration: underline; letter-spacing: 0.0px;"><a href="http://skillsmatter.com/podcast/design-architecture/context-mapping-in-action">http://skillsmatter.com/podcast/design-architecture/context-mapping-in-action<span style="text-decoration: underline; letter-spacing: 0.0px color;"></span></a></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 18.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Articles</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;">About entities, aggregates and data duplication - Alberto Brandolini’s blog</span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #1022a3;"><span style="text-decoration: underline; letter-spacing: 0.0px;"><a href="http://ziobrando.blogspot.com/2010/06/about-entities-aggregates-and-data.html">http://ziobrando.blogspot.com/2010/06/about-entities-aggregates-and-data.html<span style="text-decoration: underline; letter-spacing: 0.0px color;"></span></a></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 18.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Random Links</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;">Kent Beck blog entry on why writing maintainable software matters.</span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #0e1f99;"><span style="text-decoration: underline; letter-spacing: 0.0px;"><a href="http://www.threeriversinstitute.org/blog/?p=104">http://www.threeriversinstitute.org/blog/?p=104</a></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 18.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Some more related or interesting books</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Patterns of Enterprise Application Architecture - Martin Fowler</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Analysis Patterns - Martin Fowler</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Growing Object Oriented Software, guided by tests - Steve Freeman & Nat Pryce</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"><strong></strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>The Pragmatic Programmer - Dave Thomas and Andy Hunt</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Clean Code - Robert C. Martin</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Agile Software Development, Pattern Principles and Patterns</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"> </p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Lean Software Development - Mary and Tom Poppendieck</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"><strong></strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Test Driven Development by Example - Kent Beck</strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;"><span style="letter-spacing: 0.0px;"><strong></strong></span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><span style="letter-spacing: 0.0px;"><strong>Collaboration Explained - Jean Tabaka</strong></span></p><div><span style="letter-spacing: 0.0px;"><strong><br /></strong></span></div></p>Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com0tag:blogger.com,1999:blog-20576845.post-68046069104459994732010-10-12T14:21:00.001+02:002010-10-19T17:30:55.825+02:00CQRS & Event Sourcing Reference Links<h2>CQRS & Event Sourcing</h2><h3><a href="http://groups.google.com/group/dddcqrs">DDD/CQRS Mailing list</a></h3><p><a href="http://cqrs.wordpress.com/"><strong>The official CQRS Website</strong></a></p><h4>Interviews</h4><strong>Eric’s interview to Greg Young</strong><a href="http://www.infoq.com/interviews/Architecture-Eric-Evans-Interviews-Greg-Young">http://www.infoq.com/interviews/Architecture-Eric-Evans-Interviews-Greg-Young</a><p><a href="http://www.udidahan.com/2009/12/09/clarified-cqrs/"><strong>Clarified CQRS</strong></a> - Article by Udi Dahan</p><h4>Presentations</h4><strong>Command Query Responsibility Segregation</strong> - Presentation by Udi Dahan<br /><a href="http://www.infoq.com/presentations/Command-Query-Responsibility-Segregation">http://www.infoq.com/presentations/Command-Query-Responsibility-Segregation</a><strong>Avoid a failed SOA</strong> - Presentation by Udi Dahan<br /><br /><a href="http://www.infoq.com/presentations/SOA-Business-Autonomous-Components">http://www.infoq.com/presentations/SOA-Business-Autonomous-Components</a><h3>Event Sourcing</h3><p><strong>Event Sourcing definition</strong> by Martin Fowler </p><a href="http://martinfowler.com/eaaDev/EventSourcing.html">http://martinfowler.com/eaaDev/EventSourcing.html</a><p><strong>Innovation and Event Sourcing</strong> - Greg Young presentation</p><a href="http://skillsmatter.com/podcast/design-architecture/architectural-innovation-eventing-event-sourcing">http://skillsmatter.com/podcast/design-architecture/architectural-innovation-eventing-event-sourcing</a><h3>Code References</h3><p><strong>Super Simple CQRS Example</strong></p><a href="http://codebetter.com/blogs/gregyoung/archive/2010/08/31/super-simple-cqrs-example.aspx">http://codebetter.com/blogs/gregyoung/archive/2010/08/31/super-simple-cqrs-example.aspx</a>Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com2tag:blogger.com,1999:blog-20576845.post-33220980389376450802010-06-16T09:35:00.002+02:002010-06-16T12:48:18.576+02:00Agile Testing UK meetup<p>While in England for DDD Exchange, I caught the opportunity to participate in a meetup of the UK Agile Testing community. <a href="http://gojko.net/">Gojko Adzic</a> led a very interesting workshop about how to write acceptance tests.</p><p>Neil McLaughlin, who happened to be in my team in the hands-on simulation wrote a <a href="http://blog.mittenview.co.uk/2010/06/reflections-on-tonights-agile-testing.html">nice report</a> on the evening, and then Gojko himself <a href="http://gojko.net/2010/06/16/anatomy-of-a-good-acceptance-test/">posted about what he showed us</a>. I'll try add something, from the participant perspective.<br /></p><h2>The developer mindset</h2><p>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</p><ul><li>Formal correctness of the test</li><li>Splitting tests to be testing one concern at that time</li><li>avoiding duplication in test fixture setup</li></ul><p>When discussing the outcome, Gojko pointed out that the main concern for acceptance tests was <em>readability</em>, instead. Readability is a subjective evaluation criteria, and might lead to a not-so-precise definition about how to make it <em>right</em>. But that's the only way to write a <em>useful</em> acceptance test. But the developer's mindset really had a strong influence on us, it was really hard to give up.</p><h2>Constrained by the tools</h2><p>Despite <a href="http://skillsmatter.com/">Skills Matter</a> (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.</p><p>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 <em>still this was constraining us</em>. Buying one more whiteboard is cheap, making wrong assumptions because of writable space constraints is a lot more costly.</p><h2>We're problem solvers, after all</h2><p>During the exercise, Gojko was wandering around from one team to another one, playing the role of the <em>Domain Expert</em>. However, most of the teams seemed more interested in his <em>Teacher</em> role and asked some questions about <em>how to solve the exercise</em>, but barely none about ambiguities in the domain. We preferred to use <em>assumptions</em> instead.</p><p>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 <em>guessing</em> instead of <em>asking</em>.</p>Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com0tag:blogger.com,1999:blog-20576845.post-49764403520064897922010-06-15T18:41:00.006+02:002010-06-16T11:15:02.920+02:00About Entities, Aggregates and Data Duplication.<p>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</p><p><cite><strong>User Story #1: Placing an order</strong><br /><strong>As a</strong> Customer<br /><strong>I Want to</strong> place an order<br /><strong>In order to</strong> purchase some goods<br /></cite></p><p>The simplest implementation of the story is essentially <em>stateless</em>: 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 <em>aggregate</em> (we're deliberately ignoring the catalog for now) whose <em>root</em> is the <strong>Order</strong> class.</p><div style="text-align: center;"><img style="display: block; margin-left: auto; margin-right: auto;" src="http://lh6.ggpht.com/_miciPvwKRf0/TBetMNAOK5I/AAAAAAAAAPY/BRaQPx-Fyp0/DDD%20order%20story%201.1.jpg?imgmax=800" border="0" alt="DDD order story 1.1.jpg" width="447" height="419" /></div><br /><br /><p>The stateless nature of the service makes it really easy to implement: a <strong>Customer</strong> is just a <em>Value Object</em>, created and eventually dropped at needs. Also we took some shortcut: we've chosen to implement Address as a String. <strong>Item</strong> is sort of <em>natural value object</em>, while <strong>LineItem</strong> is somewhat in the middle: we can change quantities, while the order is in open state, but we can implement this also using droppable <em>Value Objects</em>, easing the integrity burden for the aggregate root.</p><p>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.</p><p><cite><strong>User Story #2: Returning customer</strong><br /><strong>As a</strong> Customer<br /><strong>I Want to</strong> retrieve my profile<br /><strong>In order to</strong> place more orders</cite></p><p>Story <em><strong>#2</strong></em> breaks our assumption about the aggregate boundaries. If we stick to the aggregate <em>rule-of-thumb</em>, if we want to delete an <strong>Order</strong>, we probably don't want to delete also the corresponding <strong>Customer</strong>. 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.</p><p><br /></p><p> </p><p><cite><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh4.ggpht.com/_miciPvwKRf0/TBetOT5HeKI/AAAAAAAAAPc/NcFUS-uAbxo/DDD%20order%20story%202.2.jpg?imgmax=800"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 450px;" src="http://lh4.ggpht.com/_miciPvwKRf0/TBetOT5HeKI/AAAAAAAAAPc/NcFUS-uAbxo/DDD%20order%20story%202.2.jpg?imgmax=800" border="0" alt="" /></a><br /><br /></cite><cite><strong></strong></cite></p><p>We now have a relationship crossing the <em>aggregate boundary</em>. We have promoted <strong>Customer</strong> to become the <em>root</em> of the newly created <em>aggregate</em>, 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 <strong>Customer.</strong></p><p><span style="font-style: italic;"><strong>User Story #3: Different shipping address</strong><br /><strong>As a</strong> Customer<br /><strong>I Want to</strong> specify a valid shipping address<br /><strong>In order to</strong> ship to a different destination</span></p><p>Multiple addresses are a call for a separate type to manage <strong>Address.</strong> 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 <strong>Address</strong> like a <em>value object</em>.</p><p><img style="display: block; margin-left: auto; margin-right: auto;" src="http://lh4.ggpht.com/_miciPvwKRf0/TBes_-pt2JI/AAAAAAAAAPI/7Nj0vOIlXTM/DDD%20order%20story%203.jpg?imgmax=800" border="0" alt="DDD order story 3.jpg" width="450" /></p><p><cite><strong>User Story #4: Editable customer profile</strong><br /><strong>As a</strong> Customer<br /><strong>I Want to</strong> edit my profile<br /><strong>In order to</strong> update it if needed<br /></cite></p><p>Story #4 makes explicit what we've been suspecting: <strong>Customer</strong> needs to be an <em>entity</em>, because it has a nontrivial lifecycle. No revolutions at Domain Model level, but this triggers a question: <em>"What happens if I have an outstanding order and the customer changes its data before the order is dispatched?"</em> 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:</p><p><span style="font-style: italic;"><strong>User Story #5: Specify Billing and Shipping address</strong><br /><strong>As a</strong> Customer<br /><strong>I Want to</strong> specify independent billing and shipping addresses<br /><strong>In order to</strong> deliver goods to different locations</span></p><p>This one is relatively easy: just reinforcing our design. We'll now have two references from <strong>Order</strong> to <strong>Address</strong>, which are managed by the <strong>Customer</strong>. We just store a default <strong>Address </strong>in the <strong>Customer</strong> aggregate (we could do better) but's ok for now.</p><p> </p><p><img style="display: block; margin-left: auto; margin-right: auto;" src="http://lh3.ggpht.com/_miciPvwKRf0/TBetESP-2hI/AAAAAAAAAPM/jxQ2zU9OTOQ/DDD%20order%20story%205.jpg?imgmax=800" border="0" alt="DDD order story 5.jpg" width="450" /></p><p>Story #6 is a little trickier, it comes from the legal department and tell us what we probably expected.</p><p><span style="font-style: italic;"><strong>User Story #6: Track past orders</strong><br /><strong>As a</strong> Legal Department<br /><strong>I Want to</strong> track orders<br /><strong>In order to</strong> in order to manage litigations</span></p><p>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 <strong>Customer</strong>. In case of litigation, it must behave <em>exactly like printed paper</em>. But <strong>Customer</strong> does not, its <em>lifecycle</em> is different from our needs, we'd need a separate class for that. We're lacking fantasy and call it <strong>CustomerData</strong>.</p><p><img style="display: block; margin-left: auto; margin-right: auto;" src="http://lh5.ggpht.com/_miciPvwKRf0/TBetJyayyLI/AAAAAAAAAPU/Ajzh8HtSq4s/DDD%20order%20story%206.jpg?imgmax=800" border="0" alt="DDD order story 6.jpg" width="450" /></p><br /><p>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. <strong>Customer</strong> 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 <em>behavior</em>, or class lifecycle, <strong>Customer</strong> and <strong>CustomerData</strong> 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.</p><p>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.</p><p>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 <em>aggregate</em> and the referenced value objects is probably the cleanest way.</p>Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com11tag:blogger.com,1999:blog-20576845.post-26657222178107344672010-05-07T18:32:00.001+02:002010-05-07T18:32:29.064+02:00Software ...e tutto ciò che comportaHere 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.<br /><div style="width:425px" id="__ss_4007768"><strong style="display:block;margin:12px 0 4px"><a href="http://www.slideshare.net/ziobrando/software-e-tutto-ci-che-comporta" title="Software ...e tutto ciò che comporta">Software ...e tutto ciò che comporta</a></strong><object id="__sse4007768" width="425" height="355"><param name="movie" value="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=softwareetuttocichecomportaafterbsw2010-100507110008-phpapp01&stripped_title=software-e-tutto-ci-che-comporta" /><param name="allowFullScreen" value="true"/><param name="allowScriptAccess" value="always"/><embed name="__sse4007768" src="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=softwareetuttocichecomportaafterbsw2010-100507110008-phpapp01&stripped_title=software-e-tutto-ci-che-comporta" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="355"></embed></object><div style="padding:5px 0 12px">View more <a href="http://www.slideshare.net/">presentations</a> from <a href="http://www.slideshare.net/ziobrando">Alberto Brandolini</a>.</div></div>Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com0tag:blogger.com,1999:blog-20576845.post-33548147675601995112010-02-02T09:50:00.001+01:002010-02-02T09:50:42.292+01:00Some thoughts on the iPadLast 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.<br /><br />Only time and revenues will tell who's right: but I think a few things that emerged from recent discussions are worth thinking about.<br /><br /><h1>It's all about being sexy</h1><br />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 <em>vanity</em>. The best way to satisfy vanity is to make the iPad an <strong>essentially wireless device</strong>. Cables are for losers, they're necessary, but only when nobody's watching.<br /><br />However, if you still feel like you need to upload pictures, <em>connect</em> to external devices... you'll maybe end up buying another device like the AirPort.<br /><br /><h2>Gestures matters</h2><br />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 <em>natural</em>. Things or actions that wouldn't fit the device were simply not included.<br />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.<br /><br /><h2>A pleasant experience</h2><br />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.<br /><br /><h2>No multitasking</h2><br />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. <br />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 <em>without being interrupted</em> that often, could be loved by some. <br /><br /><h2>It's not for the geeks</h2><br />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 <em>you don't see the whole picture there</em>. More generally, geeks feel comfortable with complexity and multitasking. Many folks don't.<br /><br />I have to admit i bought the iPhone for 2 reasons: <em>learning</em> and <em>vanity</em>. 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.<br /><br />Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com0tag:blogger.com,1999:blog-20576845.post-15746997325061553272010-01-12T15:52:00.002+01:002010-01-12T15:55:17.401+01:00We can do better than this... ReloadedIn 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 <a href="http://ziobrando.blogspot.com/2009/11/crowdsourcing-experiment.html">here</a>, but there are still many things that are bouncing in my head...<br /><br />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 <em>surrounded by crap</em>. Just to make it clear what I am talking about: here is an excerpt of what a home banking service is asking me <em>every single operation I do</em>.<br /><br /><div style="text-align: center;"><strong>Choose the desired account:</strong><br /><br /><select name="menu" size="2"> <option value="1">My Company Account</option> <option value="2">(all the accounts)</option></select><br /></div><br />And every time I think: <em>"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..."</em>.<br /><br />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.<br /><br /><h2>There is still a lot to do</h2><br />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: <strong>many companies are looking towards agile methodologies as a way to improve their <em>development processes</em>, in order to <em>deliver software on time and on budget</em></strong>.<br /><br />Doesn't sound that bad isn't it?<br /><br />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 <strong>better products</strong>. 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.<br /><br />The most neglected areas at the moment - at least from my point of observation - are:<br /><ol><li>user's involvment,</li><li>understanding the domain complexity,</li><li>lack of an overall perspective,</li><li>inefficient learning during the product development lifecycle.</li></ol>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.<br /><br />In the next posts I'll dig deeper in these topics.Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com2tag:blogger.com,1999:blog-20576845.post-80773277276781927732010-01-04T17:28:00.004+01:002010-01-04T17:39:13.444+01:00New DDD training events in BolognaThe first dates for Domain Driven Design classes in Bologna are finally published!<br /><div class="entry"><div class="snap_preview"><ul><li>1 introduction day, targeted to who want's to know what DDD is, on <strong>February 8th </strong>(<a href="http://avanscopertadddprimer08022010.eventbrite.com/">info & registration</a>)</li><li>4 days of workshop <strong>from February 9th to 12th </strong> for practitioners that want to dig deeper and discuss (<a href="http://avanscopertadddworkshop09022010.eventbrite.com/">info & registration</a>)</li></ul> <p>The events will take place in Savoia Regency Hotel (well known to participants of last Italian Agile Day). Early bird till January 15th, and special discounts for Bologna XPUG menbers.<br /></p> </div> </div>Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com0tag:blogger.com,1999:blog-20576845.post-87998315738558650582009-12-16T18:56:00.003+01:002009-12-16T19:02:53.044+01:00DDD patterns as “elegant support”I've got quite a challenging response to <a href="http://www.infoq.com/articles/ddd-contextmapping">my article about context mapping on InfoQ</a>, that forced me to re-think about the article, and re-express some concepts, because some statements could have been misleading. I quickly mentioned the “classical” or “tactical” DDD patterns, such as <span style="font-weight: bold;">Aggregates</span> and <span style="font-weight: bold;">Repositories</span> and it looked like they’re the key to successful design. Well, they do help a lot, but the key to successfully implement a domain model is to understand the domain, achieving a <span style="font-style: italic;">creative collaboration</span> with the domain expert. Practically this produces a small, but sophisticated, domain model that deeply reflects our understanding of the domain and supports our future, business-driven, changes. It’s impressive to see how a well designed model can accommodate changes.<br /><br />So, the whole point is to keep your model tidy, small and clean. Most of the tactical DDD patterns serve the goal of keeping the domain model clean. Classes like <span style="font-weight: bold;">Factories</span> or <span style="font-weight: bold;">Repositories</span>, <span style="font-style: italic;">belong</span> in the domain layer, have a well defined responsibility, but I think their overall purpose is to allow for the <span style="font-style: italic;">cleanest possible programming style</span> in <span style="font-weight: bold;">Entities</span> and <span style="font-weight: bold;">Value</span> <span style="font-weight: bold;">Objects</span>, where most of the domain behavior is coded. In a certain way, the whole system of patterns is a sort of <span style="font-style: italic;">necessary scaffolding</span> to allow the domain model to thrive. Patterns are not part of discussion with users and domain experts (this is pretty obvious, but ...zealots are zealots), they’re just part of the implementation. They allow the model to be <span style="font-style: italic;">technology independent</span>, or <span style="font-style: italic;">decoupled</span> from other portions of the application, they allow the model to be <span style="font-style: italic;">easily tested</span>. They allow for complexity to be managed in an <span style="font-style: italic;">elegant and scalable way</span>.<br /><span style="font-size:130%;"><br /><span style="font-weight: bold;">Sometimes elegance might be a problem</span></span><br />There is some aesthetic quality in a well crafted domain model. Some developers really like what a DDD model will look like. Guess what? I like it too. But that might deviate our attention to what really matters. Sometimes elegance has no business value, or better, is perceived to have none, by non-developers.<br /><ul style="font-style: italic;"><li>“We’re refactoring this architecture to make it more elegant”</li><li>“I don’t pay you to write Armani-dressed code! I want code that works and I want it fast!”</li></ul>Has any of us developers being seduced by <span style="font-style: italic;">the beauty of numbers</span> in an Excel balance sheet from the finance department? I guess not. It’s just a different language. So, sometimes it’s better to express<span style="font-style: italic;"> “elegance”</span> as <span style="font-style: italic;">“reducing the cost of change”</span>. Sounds a lot more like business, and a lot less like a disconnected geek spending the time tidying up the code (by the way also <span style="font-style: italic;">cleanup</span> doesn’t really work). We’ll still implement elegantly, but that’s our job.<br /><br />So if you’re enthusiastically embracing DDD and try to apply what you’ve read in the book, be careful not to transform yourself in a DDD pattern zealot. Their elegance might distract attention from the real goal: they’re helpful and often indispensable, but the real target is in the domain itself, and in it’s business value.Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com0tag:blogger.com,1999:blog-20576845.post-43185876812808434222009-12-01T12:34:00.002+01:002009-12-01T12:36:53.762+01:00Video of my "Possiamo fare di meglio" speech is out.Big thanks to Yuri Valentini and all the friends from the Bologna XP User Group, for editing and posting the video. Here's the <a href="http://blip.tv/file/2905907">link</a>.Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com0tag:blogger.com,1999:blog-20576845.post-79689831100532512082009-11-26T17:02:00.002+01:002009-11-26T17:04:43.165+01:00Shared the Agile Day PresentationThe Slideshare version of my "Possiamo fare di meglio" (we can do better than this) presentation, is now available (in Italian) <a href="http://www.slideshare.net/ziobrando/possiamo-fare-di-meglio">here</a>.<br /><br />I did my best to add comments to the many pictures, sooner or later also the video version will be available.Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.com0