tag:blogger.com,1999:blog-79289858784027400882024-03-13T17:15:39.061+01:00Dear Junior - Letters to a Junior ProgrammerThoughts on Programming; what we do, and how we do itAnonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comBlogger93125tag:blogger.com,1999:blog-7928985878402740088.post-70311231661820216852017-09-18T11:11:00.000+02:002017-09-18T11:11:14.728+02:00It is not just an Integer, it is a Domain Primitive<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Dear Junior</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Right now I am sitting on train number 928, travelling from home on my way to Arlanda airport and onwards to <a href="http://exploreddd.com/speakers/dan-bergh-johnsson.html">Explore DDD Conference</a> to present on Domain Primitives together with my friend and colleague Daniel Deogun. Train numer 928 … if I would write a program handling trains I would probably come up with a class named TrainNumber somewhere sooner or later.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Some people might object ”come on Dan, that’s overdoing it, 928 is just an integer” and suggest representing it as a simple int. Me forming a separate class - am I doing it more complex that it is?</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">For a moment, let us dive into ”it is just an integer”. What does it mean to be ”just an integer” anyway?</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Obviously integers are not just a bunch of numbers in a pile. One of the first intellectual things we teach our kids is to count stuff ”one, two, three, four …” pedagogically moving our adult index finger from one toy car to the next. Clearly the fact that ”three” comes immediately after ”four” is something very fundamental for us.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Does that hold for train numbers as well?</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Another important property of integers are that we can add them to each other: 4+5=9. This is a really useful property that enable us to take some new-bought apples (five of them) and put them in the fruit bowl where there were some apples since before (four of them). We now know there are nine apples in the bowl. And it neither matters how many apples there were in the bowl, nor how many apples we put in, the result will always be a integer amount of apples.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Of course, integers can be negative. Negatives denote a shortcoming, a lack, or a debt. According to the bank, I own an impressing number of negative Swedish kronor related to my house loan. And when I add Swedish kronor to that negative pile, at time of mortgage, that negative number increase towards zero. Hopefully it will be zero some day.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Does that hold for train numbers as well?</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">We can also multiply integers: collecting four piles of plates, each six plates high, yields a pile of twenty-four plates. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Does that hold for train numbers as well?</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Zooming out, using mathematical notation: the integers form ”an <a href="https://en.m.wikipedia.org/wiki/Abelian_group">abelian group</a> under addition”. This means for example that there exists an ”identity element” (denoted 0) such that it doesn’t matter if you add it to another integer: 0+a = a. It also means that for every other element (not 0) there exists an ”inverse” which is the ”opposite”; so as 4 is an integer which is not not 0, there must exist an integer (which we name -4) such that 4 + (-4) = 0.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Does that hold for train numbers as well?</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Being ”just an integer” does not seem so simple any longer, doesn’t it? It turns out that integers is a very rich type with a lot of properties (and we have not even started talking about prime numbers yet).</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Does really train numbers have all these complex properties?</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Of course not: There isn’t necessarily any specific meaning in that train number 928 is ”adjacent to” train number 929. Adding train number 928 and 356 does not necessarily yield a train number. Train numbers are very seldom negativ. Multiplying two train numbers doesn’t make sense at all (a train-square?). Train numbers does certainly not form an abelian group.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Train numbers are much simper than integers. It’s basically just a set of distinct elements, without any operations or relations apart from comparing two of them.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Train numbers are simply something that is a primitive in our domain. It’s one of the fundamental concepts that the train domain stand on, its parts carry no meaning. In that regard it fulfils the same kind of role that ”language primitives” fulfil in programming languages, but in the train domain. It is a ”train primitive”.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Turing our heads toward programming, think about all the things you can do with an int - just have a look in the Math-class for inspiration. This means that whenever someone think ”train numbers are just integers” they have to take care not to do any of these things that can be done. The TrainNumber class on the other hand can only be used for what it is intended for, nothing else.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Saying that train numbers is a domain primitive, and giving it a class TrainNumber, is not to make things complex. It’s to make things simple.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Yours</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"> Dan</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-42336292434878324062017-02-07T18:08:00.000+01:002017-02-07T18:08:18.359+01:00Impressions from Jfokus 2017: Internet of Things (IoT)<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Dear Junior</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">The annual developer conference Jfokus is always an almost overwhelming source of impressions. There is always lots of interesting presentations, and today was no exception. It's impossible to cover all of them, but today I attended three presentations that together formed a nice whole as they covered different aspects of IoT - Internet of Things.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">During the IoT keynote Kevin Hoyt went very down to earth. He covered the state of IoT devices today using different means of connectivity as his starting point. My main take-away was his very thorough coverage of each "typical" device for Bluetooth-, WiFi-, and GSM-connectivity. For each type he demoed the device, showed the development environment, and discussed programming concerns: for example the importance of entering deep sleep when working on a device using Bluetooth and powered by battery. Specifically I took away how the libraries have evolved to make connectivity and features like deep sleep and wake-up-on-connect.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">The other presentation that fitted nicely into the topic was the presentation Shahid Raza of RI.SE (Research Institute of Sweden), formerly SICS (Swedish Institute of Computer Science) held under the title "Is IoT Security a Nightmare?". I simply assumed that the question was purely rhetorical, and had expected a "yes" with some elaborations on the subtler points. Boy, was I mistaken. The overarching message of the presentation was a resounding "no". In fact the current protocol stack for IoT has evolved a lot and now even support end-to-end security of communication, even when the data package has to make multi-hops from one device to another before ending up at its final destination. The protocols for doing this are essentially structured in the same way as we do with certificates and HTTPS over TLS. The largest surprise for me was that the computation power needed for cryptographic computation is not a problem. I was under the impression that the power needed for those computations would take too much of a toll from the batteries of battery-powered devices, but apparently not. The largest toll is apparently the radio-transmission of data packages. And, the protocol folks have worked hard to compress the protocol stack so that the overhead-parts of each package (delivery info and security) is compressed so that there is more room for the payload. In that way, fewer packages are needed for the same amount of payload, and that is where you conserve a lot of battery power.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">The third presentation was on the just-released Bluetooth 5 standard and was held by Ioannis Glaropoulos. He presented how the new standard has increased throughput of Bluetooth to 2 Mbps, making it feasible for e g streaming audio, which makes the protocol useable for more use-cases. Counter to intuition this might actually decrease battery consumption because the same amount of data can be sent in a shorter amount of time, diminishing the risk of interferences and resending the data. So the amount of energy needed per byte sent might be lower. Bluetooth 5 also features a longer range. For indoor use the main advantage is simpler topologies: many devices can connect directly to a central node or gateway, instead of having to form a mesh where some devices need to route-forward messages from more distant devices. This also conserves energy for the intermediary devices that doesn't need to wake up to forward messages, but can stay in deep sleep until they have something they want to transmit.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Put together these three presentations definitely broadened and deepened my understanding of where Internet of Things stand today. Something that is a worth outcome of a day at a conference.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Yours</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"> Dan</span></div>
Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-4344541194797644332017-01-17T18:16:00.000+01:002017-01-22T21:26:11.036+01:00Writing a book - Secure by Design<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">Dear Junior</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">I'm sorry for not writing to you for quite some time. But, you see, I have been working on a book together with my two colleagues and friends Daniel Deogun and Daniel Sawano. Late this summer we decided to try to write down our collective experiences and insights in design and security as a book. We are far from finished, but by now the first few chapters are released from the publisher Manning as part of their "Manning Early Access Program" (MEAP).</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">The book is named <a href="https://www.manning.com/books/secure-by-design?a_aid=danbjson&a_bid=0b3fac80">Secure by Design</a> and our main message is how good design and good code can help developers avoid security problems. We have found that lots of security vulnerabilities are due to bugs that could have been avoided if the design of the code had been different. </span><br />
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<img border="0" src="https://images.manning.com/255/340/resize/book/7/ea52628-bb90-4405-895a-861572e0ffb8/Johnsson-SbyD-MEAP-HI.png" /></div>
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">You as well as I know that it is a lot easier to think about "good design" when developing features, that it is to think "security" at the same time.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">Of course not all good design lead to avoiding security vulnerabilities. So we have gathered our experience on what design-tricks that are most effective in giving security as a side-effect. It's probably no big surprise to you that Domain-Driven Security is an important part of this, but there are many other parts as well.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">We still have a lot of material to cover. But, what we have started with things that are close to the code, such as building Domain Primitives, how to structure validation, immutability etc. I guess you will find several of these ideas familiar, as we have discussed them earlier - but there are also some new insights I have not yet had the time to write to you about. Well, not to mention all the ideas from Daniel and Daniel which you and I haven't had possibility to reflect on earlier.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">In the later parts there will be more material on integration, security benefits from cloud thinking. We also want to share our ideas around architecture such as security concerns for microservice architecture or how to handle legacy codebases.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">We will continue to write during the spring and early summer. Hopefully we will see the book in print sometime during the fall this year.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">Yours</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"> Dan</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">PS The early-access was released last night; you can check the book at <a href="https://www.manning.com/books/secure-by-design?a_aid=danbjson&a_bid=0b3fac80">https://www.manning.com/books/secure-by-design</a></span></div>
<br />Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-10533406619212893942016-04-26T09:40:00.001+02:002016-04-26T09:42:04.046+02:00Idea Mingle to Bootstrap Open Space<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">Dear Junior</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">Some of the things I do on a regular basis is to facilitate workshops and events of different kinds - open space being one of them. I'd like to share with you a small trick-of-the-trade I have evolved while facilitating those: the Idea Mingle.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">I really like the energy the open space format brings to the discussions. People are familiar with the format of participating in a discussion, and also shy or introvert people are given room to participate in a comfortable way.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">However I have sometimes found that the initial part can be a little bit slow, the part where you pitch topics for discussion. This is seldom a problem with groups that are used to open space. Everybody involved understands what "level of ambition" is needed for posting a topic - acknowledging the fact that the really interesting part will be the discussion that unfolds around the topic. However, with groups unused to open space I have found that people can get shy. Posting a subject might seem pretentious: "what have I that everybody else should find interesting". So, when asked at point blanc "what do you think should be discussed", their mind goes blank.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">To give the "pitching phase" of open space a soft start I do a "Idea Mingle" that gives people a chance to evolve their interests into discussion topics before it is time to post them. It is a "mingle party" with the purpose of distilling ideas for discussion, thus "Idea Mingle".</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">The instructions I give are simple: </span></div>
<div style="text-align: justify;">
</div>
<ul>
<li><span style="font-family: "georgia" , "times new roman" , serif;">Look around the room and lock eye contact with someone you have not yet spoken to today. </span></li>
<li><span style="font-family: "georgia" , "times new roman" , serif;">On my call, pair up</span></li>
<li><span style="font-family: "georgia" , "times new roman" , serif;">Introduce yourself by saying "Hi, my name is …" to each other</span></li>
<li><span style="font-family: "georgia" , "times new roman" , serif;">Continue by saying "I think it would be interesting to discuss something around …" and fill in a field. It does not need to be specific, it can be broad or vague, e g "something about testing".</span></li>
<li><span style="font-family: "georgia" , "times new roman" , serif;">Have a short discussion digging a little bit into each others interests</span></li>
<li><span style="font-family: "georgia" , "times new roman" , serif;">After two minutes I will break the discussion</span></li>
</ul>
<br />
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">The basic idea is that the one-on-one-format is a more comfortable format for talking about an idea than to do it in public. Speaking to a stranger is still an uncomfortable situation for a lot of people, me included. However, the short format and the very focused scope makes it managable - as opposed to the usual mingle setting "find a stranger, talk to him/her, and be nice and interesting for an undefined period of time". Just the thought gives me creeps.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">Now, after the first one-on-one, all participants have bounced one of their interests on another participant. Almost certainly they have received acknowledgment that "it is an interesting field" and most have probably got feedback of the form "testing is interesting; I myself is interesting in how to use automation to make it easier".</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">OK, so people have now got a slightly refined idea about an interesting discussion. But, for most of them it is not yet ready to publish as a open-space-discussion-subject.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">Allow me a slight detour. </span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">At a workshop class with Lyssa Adkins and Leslie Stein there was a small knowledge-sharing exercise. During that exercise I was given the task to explain "sprint retrospective" to a few of the other participants. I was given literally no time to prepare, and my presentation time was limited to five minutes (if I remember correctly). It was really awkward.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">Immediately after the first group of listeners, I was sent a second group of a few class-mates, and had to explain to them. This time it was less awkward. A third group was sent to me, and this time I basically knew what I should say or not. The fourth time, the explanation went smooth. So, in four iteration a very awkward rambling refined into a pretty crisp micro-presentation.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">Back to open space and Idea Mingle.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">The next instruction for Idea Mingle is: Now, lock eye-contact with someone else. And, we do the same thing once again.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">At the end of this second one-on-one the idea might have evolved to "automation in testing, and the trouble with databases".</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">And then we repeat the one-on-one a total of four times.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">At this point of time, many of the participants have received acknowledgement that they are interested in a field others also are interested in. And, a lot of them have refined an initial rough idea into something that is a more specific topic, e g "How to involve DBAs in test automation" - a topic ready for discussion.</span></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">And we are ready to form a queue for pitching topics to discuss.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">Also, everyone is a little bit frustrated over that each one-on-one was interrupted just when they were getting started. So, all participants are eager to start the open space discussions.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">Yours</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"> Dan </span></div>
<br />Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-25188402678912221602015-10-27T19:08:00.000+01:002018-07-10T13:08:13.130+02:00The Way Agile is Fast - Fast as in Orienteering<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">Dear Junior</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">It is often claimed that agile development is faster than the alternative approaches. However, "faster" used this way might be misunderstood. For example, we all know that running can be tiring, so running faster can be exhausting. </span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">Does agile development mean that we will exhaust the poor developers? And do so sprint after sprint? Does it mean we induce stress ulcer? Or will the developers have to cut down on testing, design, and quality to meet this faster pace of deliver?</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">Quite the opposite. Agile is faster in another way. It is not faster as in a long-distance runner being faster, rather in the way an orienteering runner might be faster - by making smart choices of route.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">In agile we realise that developing systems is not running down a pre-routed track. It is more alike to make our way through wild terrain. When doing this it is crucial to early see if we are moving down a dead-end route, and then stop ourselves. To run down a dead-end route without getting anywhere is the most wasteful exhausting thing an orienteering runner can do.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">In agile we try to adress this at as many levels as possible. To prevent the individual developer go down a dead-end without realising it, we have pair-programming or daily stand-ups as reality checks. At a team-level we have short sprints, or watch the kanban cycle-time, to prevent us from working on stuff in a bad direction for too long. At project- or initiative level we do impacts map and similar to ensure we do stories that matter. At the level of finance/funding and portfolio management we track effects to </span><span style="font-family: "georgia" , "times new roman" , serif;">stop us from continue spending huge effort on stuff that give no or low effect. </span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">So, agile does not make us faster by making us run at a more exhausting pace. Agile makes us faster by giving us tools to take smart routes, preventing us from detours.</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;">Yours</span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "georgia" , "times new roman" , serif;"> Dan</span><br />
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="font-family: "georgia" , "times new roman" , serif;">ps This is of course related to how <a href="http://dearjunior.blogspot.se/2013/05/domain-driven-design-to-speed-us-up-by.html">Domain Driven Design makes us faster, even in the short run</a>. Using the orienteering metaphor, what you to is to slowly jog for some a short period of time while exploring the map for different routes.</span></div>
Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-25050824363198971442015-03-24T17:07:00.000+01:002015-03-25T10:03:46.254+01:00Coding Kids, it is about Democracy<div style="text-align: justify;">
Dear Junior</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
These days it seems like a lot of people think it is important to teach kids to code. I would like to chip in my idea about why this is important. To me, it boils down to a question about democracy, but let us not start there.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<i>Code as a Profession</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The first argument is about job market. There is no doubt that today we are already short on good system developers, and all predictions and forecasts say that this is going to get worse. So, going for a career in system development seems like a good hedge. This is the argument seen from the perspective of the individual kid. On a side note, I'd like to add that I personally think that system development is an interesting mix of creativity, intellectual stringency and cooperation; so apart from being a job that will probably be in demand it is also a job that is quite fun, when done right.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
This argument also have the macro-economic side: companies need system developers to be able to continue their development. With a lack of skilled developers, the companies innovation pace might come to a halt, which would harm society at scale.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
So, learning to code is obviously a good way to take the first steps towards a job in systems development.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
A historical parallell is that there was a time when reading and writing was only relevant for a small </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
were jobs where reading and writing were essential skills: handling written text where in those days mainly done by priests and medieval administrators where in those days that where handling written text. Written text was irrelevant to the rest of society.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
This as definitely been true for code. Code was essential for the coding professions - a limited number of engineers and researchers - but not outside those circles. Code was irrelevant to the rest of society. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
However, I think that has changed. Code is no longer important only for those that work as programmers. Today the ability to code to some degree is fruitful to other professions.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<i>Code in more Professions</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Thus, second argument is that more jobs will involve code. If we look outside the profession of system developers, there are already places where coding helps people do their job better. Imagine Susan in HR, who is working on gender equality issues and is curious about how the salary level compares across different department, different ages with respect to gender. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Susan has all the data at hand, perhaps in a few spread-sheets, perhaps in some simple database. Now, she could ask the analysis department to do some statistics which she could analyse to see if there is something to her hypothesis. That would probably take a day or two before they come back. But, if Susan herself can put together some SQL-queries or some scripts, she can get the result the same afternoon. The difference in how well she can do her job - analyse if there are salary differences that should not be there - is significant.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Knowledge in coding is not just a profession in and of itself. It is also already a helpful tool in other professions, and I think it will soon be essential.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
A historical parallell could be at the beginning of the industrial revolution. At this point written text was not something that was relevant for the text-professions priests and adminstrators. Suddenly the factory workers where supposed to be able read, reading written instructions or work orders. To start with only the foremen needed this, but soon enough literacy was expected from all workers.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I think this is where code and society is today.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<i>Code in Society</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Looking forward, I think it will not stop here. I think understanding of code will become even more important.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Let me start with the historical parallell. After industrial revolution society evolved together with the usage of text. Text weaved into the fabric of society. People who could read were able to follow the news in the spreading news-papers. People who could write were able to participate, write letters to the editors. In parallell civil associations arouse such as workers unions or the anti-drinking movements. These were all possible because their member were able to read and write, to document their meetings in protocols, to create pampflettes to spread their ideas etc. The raise of modern democracy was fuelled by people knowing text.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
People who could not read or write were soon standing at the side watching society evolve, more or less unable to participate.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I personally had a revolving experience. An a journey in China in the mid-90s I found myself standing at a cross road in the middle of Beijing. Everywhere I looked I could see text, massive amounts of text. Every shop I could see had signs promoting their wares, there were banners and posters, there were road signs, there were advertisements for papers. Texts everywhere, massive amount of information, a world that everyone around me navigated trough without effort. And I did not understand a single thing. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Here and there I could see a sign I could recognise, the sign for "north", the sign for "water" etc. But I was feeling totally alienated. Watching people around me naturally navigating on this ocean of information, it felt like being surrounded by magic.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
It was not hard to relate to what it must have felt like being an illiterate while society quickly evolved, suddenly just assuming that people in general would understand text and could participate.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I think this is where code is going. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<i>A World of Automated Processes</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Already today we are surrounded by automated processes - powered by code. Most of them are pretty trivial, for example paying a parking using your credit card by checking in and checking out. Some of them are a little bit more complicated, e g when you order goods online and you can track the goods until it arrives at your post office, coupled with status-notification to your mail or phone. Some are pretty complicated. In Sweden the taxation rules for partnership incorporated companies are somewhat complicated - there are several set of rules to chose from and they give different results. However, when declaring taxes on-line on the tax authority web site - then the system helps you chose the set of rules that are most beneficial to you. Even though I know it is just code, it feels a little bit like magic.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
We are probably only in the beginning of this evolution. Within a few decades, automated processes will be in much more places, they will be much more complex, and they will probably be interlinked. They will be part of the fabric that constitute society.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Those people that know code, they will be able to understand, to participate, to protest, to support. The people who do not understand code will be standing at the side, watching society evolve, more or less unable to participate.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I realise this might seem like jumping to conclusions. But think back. When industrialisation was new and reading was mostly used by foremen to read work orders and instructions - did it seem probable that reading and writing would transform society, making those skills essential to participate in and effect society at large? </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I think that understanding code will be the literacy of tomorrow.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<i>Democracy</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Teaching kids to code is not just about opening the door to the programming professions; it is not just about giving them a better chance to do their non-programming jobs well; at stake are giving them the foundations they need to participate in society; it is about democracy.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
That seems pretty important to me.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Yours</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Dan</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-29701794764998831092015-02-13T15:08:00.000+01:002015-02-13T15:08:32.453+01:00CSR, Knowledge, and a Student Conference<div style="text-align: justify;">
Dear Junior</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
At Omegapoint we have for a long time struggled with the question: How can we contribute towards society? Or, put otherwise, how can we pay back to the society to which we owe so much? To use the business lingo phrase: How do we exercise our Corporate Social Responsibility (CSR)?</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
There is the obvious non-answer: We already contribute to society though our business. We pay taxes without fuzzing or hiding. What we do for our customers must be good in a broader sense, otherwise they would not pay for it. So, obviously we contribute.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
But our moral standard is somewhat higher than that kind of waterline mark.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Of course there is always the easy way out: Donate money to some beneficiary organisation. And of course we have done so. But it does not feel completely satisfactory. Anyone can donate spare money: should we not pay those money as salaries and let our employees donate at their own discretion? What could we as a company contribute with?</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Also we have done pro bono work: helping NGOs with their web-sites and support systems. Also we have given pro bono aid and coaching to local startups. Of course this is better, but we were still not completely satisfied. Lots of other companies could do this, it did not feel unique to us.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Slowly has the realisation dawned on us. We define ourselves as a knowledge company with an attitude of openness. The epitome of this is our semi-annual two-days competence conference, affectionately named <a href="http://opkoko.omegapoint.se/">OPKoKo</a> where we run presentations, workshops, and discussion - all powered by stunning colleagues and some occasional guest. This is the soul of Omegapoint, this is what we should share.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Sharing with whom became pretty obvious. At Omegapoint almost everyone has studied at a technical university, apart from some remarkable autodidacts. In Sweden university education has no tuition fee at any of the universities - it is funded through taxes instead. This means that even the best universities have a steady flow of talented young people from all corners society. Omegapoint as a company is build on this foundation. We should pay back to Swedish Academia, and its education of students in particular.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Once question phrased, answer was simple. This spring we will run our first student conference: <a href="http://www.studentkonferens.omegapoint.se/">Studentkonferens 2015 by Omegapoint Academy</a>.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
We have put together a one-day conference with three tracks: programming, security, and testing. We will bring our experts from the field to spend a day presenting, discussing and socialising with the students. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
We have tried to pick subjects that are as relevant to students as possible - not far-away is about "strategic architectural enterprise business process modelling", but rather about stuff they can relate to and hopefully use immediately. We ended up choosing "Craftsmanship" as the theme.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Now, "Craftsmanship" is a term that has been thrown around our community left and right, and I am definitely sceptical to some uses of the word. Still, I think the original message of craftsmanship holds: love the craft, pay attention to what matters, be pragmatic.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Yesterday we announced the conference to the public during the <a href="http://konferens.datatjej.se/">Datatjej2015</a> conference run by female-CS-student association <a href="http://datatjej.se/">Datatjej</a>. This is not a coincidence. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
At Omegapoint we always hire on merit. The idea to select from non-relevant attributes as gender or ethnicity is completely foreign to us. However, we also do know that women have had (and still have) a harder time in our industry than men. Thus, we want to encourage initiatives that encourage young women to make a move in our industry. Hence, it makes sense to draw some attention to Datatjej2015 by selecting that event for announcing our own initiative.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Now, this is going to be fun. Also, I have been given the honour to present the opening keynote, presenting my view of Craftsmanship in software development. I am really looking forward to all of it.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Yours</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Dan</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
PS To pay credit where credit is due, I really must praise my colleagues Lotta Hammarström and Daniel Deogun. They where both part of the original idea, and have really worked hard to it come alive.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-56033763485925607882014-11-19T17:07:00.000+01:002014-11-19T17:07:00.511+01:00Make Concepts Explicit when Fixing Bugs<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Dear Junior</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">To find implicit concepts and make them explicit is a very powerful way to improve code. But, sometimes it is hard to judge beforehand which concept is important enough to make explicit. We try to make good judgements, but sometimes we miss.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">But, no reason to despair, we can take Time as our helpful aid. So, instead of everything perfect from start, we continuously perfect it whenever we find a reason. Two of the topmost reasons are either a bug appearing or further development of the code.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Let me for now fokus on the case of when a bug appears. If the code does not behave the way we intended it to do, then there is most often a place in the code that was to convoluted. In that convoluted state, subtle misunderstandings and simple mistakes could hide. The solution is to clarify the code until it is obvious whereof the mistake consists.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Things get clearer by examples, so let me clarify what I mean with a very minimal example, the story about a bug and its fix.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">In real life, more or less a decade ago, I worked on a project where we did a batched import of records coming from an external source. The code looked roughly like this following in the class ImportCron.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;">public class ImportCron {</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> private RecordImporter importer;</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> private Logger logger;</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> void runImport() {</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> List records = importer.listWaitingRecords();</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> logger.log(Level.INFO, "Importing records: " + records.size());</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> for ( Object rec : records) // imports each of the records in turn</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"><span class="Apple-tab-span" style="white-space: pre;"> </span> …</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> }</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Now, the import was run once a minute, but most of the time there where non records waiting. Problem was the import log became filled with rows saying "Importing records: 0" so we had to grep out the non-zero lines each time we wanted to look at what was happening.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">One of those days I got tired of this, fired up the editor, and wrapped the logging in an if statement to filter out all those zero-import writes.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> void runImport() {</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> List records = importer.listWaitingRecords();</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> if (records.size() == 0)</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> logger.log(Level.INFO, "Importing records: " + records.size());</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> for ( Object rec : records) // imports each of the records in turn</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"><span class="Apple-tab-span" style="white-space: pre;"> </span> …</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> }</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">A few days later we released during lunch, which was the best time for our users. The deploy went smooth, apps started up as expected, and soon it was time for the first import "tick".</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Within a minute, import was run the first time, and the log line read:</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"><timestamp> Importing records: 0</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">While standing confused, a minute went by, and the log line read:</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"><timestamp> Importing records: 0</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Another minute went by … and no log line.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">While firing up my editor to check the code, another minute went by and a third log line appeared:</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"><timestamp> Importing records: 0</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">A colleague of mine looking in the database calmly reported "We just imported three records".</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">It only took me a split of a second to realise my mistake once I had the code in front of me.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> void runImport() {</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> List records = importer.listWaitingRecords();</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> if (records.size() == 0)</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> logger.log(Level.INFO, "Importing records: " + records.size());</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> for ( Object rec : records) // imports each of the records in turn</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> }</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Obviously my spine reflex for coding "check for zero" made me write the boolean expression the wrong way around. By the way, did you capture that mistake at first glance in the code on my first description? Confirmation bias is a nasty thing.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Now, I must say this kind of bugs are pretty uncommon, bugs that are typos or simply mispunching the keys. Most bugs in my opinion are rather that pieces of code subtly misunderstand each other.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Well there are at least two ways of fixing this code. The obvious, and fastest would be to quickly change "==" to "!=". However, humbled by the mistake I had done in the first place, I realised that that kind of hasty coding was what got me in the trouble in the first place.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">One of my coding mantras since long have been "<a href="http://dearjunior.blogspot.se/2007/12/code-should-mean-something.html">Code should mean something,</a> not just do something". So, a better way out would be to make the code more meaning-ful. From Eric Evans I learned the phrase "Make implicit concepts explicit", which says the same thing in this context, but gives a better guiding direction forward.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">I took to the challenge of fixing the bug by finding what implicit concepts had been missed, and making them explicit until it was blatantly obvious that the code was wrong. An added benefit would be to be able to make a test proving the code was wrong.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Extracting the boolean condition to a method of its own would force me to spell out the meaning of that piece of code.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> void runImport() {</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> List records = importer.listWaitingRecords();</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> if (containsRecords(records))</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> logger.log(Level.INFO, "Importing records: " + records.size());</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> for ( Object rec : records) // imports each of the records in turn</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> }</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> static boolean containsRecords(List records) {</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> return records.size() == 0;</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> }</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Granted, this is more code than I started with - but I think the code is more "to the point" (phrased inspired by Rickard Öberg, another of the great programmers).</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">At least this made me able to write a test</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> @Test</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> public void shouldConsiderEmptyListNotContainingRecords() {</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> Assert.assertFalse(ImportCron.containsRecords(Collections.EMPTY_LIST));</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> }</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Well, at least this is what the test would look today - at the time JUnit looked slightly different.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Anyway, now I have a failing test. Claiming "the empty list does not contain records" is simply false - as proven by the test. We safely update the code to fix the bug.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> static boolean containsRecords(List records) {</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> return records.size() != 0;</span></div>
<div style="text-align: justify;">
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> }</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Upon which the test switched to green as expected.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">During this "refactor -> put under test -> fix" something interesting has happened. The concept "import list contains records" that hitherto had been implicitly represented by the technical "records.size() != 0" has now been made explicit and given a name "containsRecords".</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">It might be claimed that the main benefit in this example was derived from the drive to put code under test before making a change. Undeniably, that is a point, but I think it only tells half the tale. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Simply putting things under test can be done in a myriad of ways, and I have seen several very technology-based efforts. I do not think those efforts have paid off handsomely. Mostly the code get cut along technical lines to push in tests in the gaps. But, the code does not get more comprehensible over time.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Focusing on "make implicit concepts explicit" have been a more productive course for me when working with code.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Yours</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"> Dan</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">ps My team-mates did not force me to skip lunch to fix the bug. We went out together, and when we came back satisfied and rested, I sat down and fixed the code. We released the fix during lunch-time the day thereafter.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<br />
<div style="text-align: justify;">
</div>
<br />
<div style="-webkit-text-stroke-width: 0px; color: black; font-family: Times; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: justify; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;">
<div style="margin: 0px;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
</div>
Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-21211500882523825022014-11-17T12:00:00.000+01:002014-11-17T12:00:05.032+01:00Make Implicit Concepts Explicit in Code<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Dear Junior</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">In our letters on software development we have touched upon the idea several times, but I think it might be worth spelling it out - the idea to <i>make implicit concepts explicit</i>; something I see as one central message of Domain Driven Design applied to coding.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Let me pick that phrase apart for a moment. When coding we have a lot of concepts in mind, e g when writing code that handles people I might have a class namned Person. In this case the concept of person has an explicit representation in the code - i e an <i>explicit concept</i>.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">A person might have a birth date, represented in code as a data-field </span><span style="font-family: Courier New, Courier, monospace;">Date dayofbirth</span><span style="font-family: Georgia, Times New Roman, serif;"> in the Person class; another example of an explicit concept.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">We might have business logic restrictions that are based on the age of the person, e g you have to be at least fifteen years to access some content. So there will be code calculating this.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> void contentRequest() {</span><br />
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> ... </span><br />
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> boolean access = </span><span style="font-family: 'Trebuchet MS', sans-serif; font-size: x-small;">((new Date().getTime() - customer.dayofbirth.getTime()) / msPerYear) >= 15;</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Again we have a concept represented in code, this time <i>age</i>. However, this time the representation is not explicit - there is nothing in the code saying "age". Age is an <i>implicit concept</i>. </span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">There is nothing strange with having implicit concepts. In the short code snippet we have several implicit concepts: current point of time, point of time of customer's birth, and age-limit for content are just three obvious. This is not a problem. The programmer reading the code will intuitively re-construct the relevant concepts.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">However, the design guideline from Domain Driven Design advice us to keep an eye open for important concepts - and if we find the represented implicitly, then <i>make that implicit concept explicit</i>. </span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Let us look at the code snippet again.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> boolean access = </span><span style="font-family: 'Trebuchet MS', sans-serif; font-size: x-small;">((new Date().getTime() - customer.dayofbirth.getTime()) / msPerYear) >= 15;</span><br />
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"><br /></span></div>
<span style="font-family: Georgia, Times New Roman, serif;">Of the implicit concepts dwelling in this like, which of them seem important enough to make explicit? </span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">The concept of "current point of time"? Probably not.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">The concept of "milliseconds since birth"? Nah, not that either.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">The concept of "milliseconds since birth expressed as years, rounded downwards"? Hey! I know this! We already have a word for it - we call it "age"! And we talk about it all the time!</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Well, that sounds important enough. Let us start with giving that value a name. </span><br />
<br />
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> void contentRequest() {</span><br />
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> ... </span><br />
<div style="text-align: left;">
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> long age = (new Date().getTime() - customer.dayofbirth.getTime()) / msPerYear;</span></div>
<div style="text-align: left;">
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> boolean access = age >= 15;</span></div>
<div>
<br /></div>
<span style="font-family: Georgia, Times New Roman, serif;">By the way: this is where I really like the IntelliJ shortcuts "cmd-w" to widen the selection until the expression is selected, then "cmd-alt-v" for the refactoring to extract the selection as a variable - naming it "age" in the pop-up. It literally takes less than 10 seconds.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Now, we actually have made the implicit concept age into an explicit concept. Mission completed.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Well, not completely. We need to find the concept a good home where it can lead a good life. Right now it is stranded in the middle of some access computation. At least we can give it a method of its own.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Applying another of my favourite refactoring "Replace Temp with Query" yields this code.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> void contentRequest() {</span><br />
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> ... </span><br />
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> boolean access = customerAge(customer) >= 15;</span><br />
<div>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"><br /></span></div>
<div>
<div>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> private long customerAge(Person customer) {</span></div>
<div>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> return (new Date().getTime() - customer.dayofbirth.getTime()) / msPerYear;</span></div>
<div>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> }</span></div>
</div>
<div>
<br /></div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;">Better, but can be improved to make the concept clearer. If we talk about the "age of the customer" it will vary from time to time, and it might cause confusion: the age when the customer requested access to the content, the age when content was first accessed, when it was last accessed, the age now? Better to clarify.</span></div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;">Of course we could rename the method to "customerAgeNow". However, I do not feel comfortable having my concepts depend implicitly on external things like the system clock. I prefer to make those dependencies explicit. So we make the time-in-question a parameter. </span></div>
<div>
<br /></div>
<div>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> void contentRequest() {</span></div>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> ... </span><br />
<div>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> boolean access = customerAgeAt(customer, new Date()) >= 15;</span></div>
<div>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"><br /></span></div>
<div>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> private long customerAgeAt(Person customer, Date timepoint) {</span></div>
<div>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> return (timepoint.getTime() - customer.dayofbirth.getTime()) / msPerYear;</span></div>
<div>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> }</span></div>
<div>
</div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;">This design also improves testability drastically. The tests can now use explicit test-data, and need not rely on checking, or changing, the system clock.</span></div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;">Kudos once again to the lovely refactoring support of modern IDEs. Another less-than-10-seconds-refactoring: two cmd-W to select "new Date()", cmd-alt-P to extract as parameter, change name to "timepoint" in pop-up. Enter. Done.</span></div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;">By now it is pretty obvious that the method "customerAgeAt" suffers from feature envy. The most relevant data it operates upon is the Customer, but it resides somewhere else. We should consider moving it.</span></div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;">Should we move it, the Customer class would get a method "ageAt", taking the liberty to rename it slightly. That method certainly makes sense in this context, but does it so in other contexts? As we do not have the rest of the codebase at hand, we will just have to pretend that "ageAt" makes sense in other context - and might actually be useful there as well.</span></div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;">This is really one of my favourite refactoring: move method. Again extremely smooth thanks to modern IDEs. Literally two keystrokes (F6, Enter - in IntelliJ) for the move, and a few for renaming. </span></div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div>
<div>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> void contentRequest() {</span></div>
<div>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> // ...</span></div>
<div>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> boolean access = customer.ageAt(new Date()) >= 15;</span></div>
</div>
<div>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"><br /></span></div>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;">class Person {</span><br />
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> Date dayofbirth;</span><br />
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> // ...</span><br />
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> long ageAt(Date timepoint) {</span><br />
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> return (timepoint.getTime() - dayofbirth.getTime()) / TimeUtil.msPerYear;</span><br />
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> }</span><br />
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;">}</span><br />
<div>
<br /></div>
<span style="font-family: Georgia, Times New Roman, serif;">You might not believe me, but I remember the days of yore when you actually had to do all the involved steps manually; cut-n-paste the method body and header, change the list of parameters, update the code to use the fields of "this" instead of the argument, change all client calls (which might be several).</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Now, we have finally ended up with a version I feel comfortable with. The concept "person" has now an conceptual attribute "age at" which has an explicit representation in code. In code we have "enhanced" our language of what we can talk about directly. So, when we discuss the age of a customer with business people, it is likely that we consistently mean the same thing - even if we for sure still can misunderstand each other.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">As a side effect the code checking the access has become a lot clearer.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Trebuchet MS, sans-serif; font-size: x-small;"> boolean access = customer.ageAt(new Date()) >= 15;</span><br />
<div>
<br /></div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;">This is a line of code that can be shown some person from the business side and explained by reading it out "access is granted if the customer's age at 'now' is at least fifteen years". Given that support, they can see by themselves - something that really builds trust. </span></div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;">The time invested was not huge. Coding-wise all refactorings took less then a minute together. The time to slowly realise that "age" is an important concept in this particular domain is not counted. However, that insight will have to dawn on the programmer sooner or later, and when that happens, that extra minute is well invested.</span></div>
<div>
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div>
<span style="font-family: Georgia, 'Times New Roman', serif;">To make concepts explicit does not only apply to code, it can be fruitfully applied to other areas as well, e g capturing and writing requirements/specifications. </span></div>
<div>
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div>
<span style="font-family: Georgia, 'Times New Roman', serif;">As we all stand on shoulders of gigants, I also must give credit where credit is due. The </span><span style="font-family: Georgia, Times New Roman, serif;">phrase "Make Implicit Concepts Explicit" I have picked up from Eric Evans, the thought leader of Domain Driven Design. </span></div>
</div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">In conclusion: to <i>make implicit concepts explicit </i>help us to over time close the gap between the code and the understanding of the business domain. It is not uncommon to in the process find bugs or crucial misunderstandings, that then can be adressed in a proactive manner instead of popping up as nasty surprises later on. </span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Yours </span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;"> Dan</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<br /></div>
<br />Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-57845404855267616442014-11-12T15:58:00.003+01:002014-11-12T16:30:14.280+01:00Agile Projects should have Effect Targets<div style="text-align: justify;">
Dear Junior<br />
<br />
Measuring projects and setting targets for them is a tricky business. And, it does not get easier when agile projects enter the scene. This is not really because agile projects are strange per se, but because they are different from non-agile projects.<br />
<br />
Setting targets and measuring projects is also an important business. I have seen several agile initiatives fail. Most of them have failed because they did not succeed in setting goals for projects, and monitor their progress. And if you cannot do that, you quickly lose the confidence and support from upper management. Agile initiative terminated, or left to dwindle away. End of story.<br />
<br />
However, it need not to be so. Agile projects can have measurable targets, and they can be monitored - you just have to do it right.<br />
<br />
There are some bad news and some good news.<br />
<br />
<i>The Well-Established Chaos Rod for Measuring Success</i><br />
<br />
The bad news is that agile projects cannot be measured using the de-facto established standard rod for project success.<br />
<br />
The standard rod for measuring projects is "on-time and on-budget, with all features and functions as initially specified", as used by e g Standish Group in their much-to-cited Chaos Reports. Let us call this the "<i>Chaos rod</i>". Most organisations use some version of the Chaos rod for measuring their projects.<br />
<br />
As we have discussed earlier it is pretty obvious that <a href="http://dearjunior.blogspot.se/2014/10/all-features-implemented-does-not-equal.html">"all features implemented" is not a good way to measure "project success"</a> - not for any project. Nevertheless, this is the standard rod.<br />
<br />
<i>Damned if you do, damned if you don't</i><br />
<br />
Of course agile projects will fail if measured using the Chaos rod. The reason is simple - agile projects does not manage to keep their hands away from fiddling with the original specification. Agile projects remove stuff, change stuff, add stuff - agile projects are in a constant state of scope-creep.<br />
<br />
This is no coincidence - it is how agile projects are designed.<br />
<br />
Think of it this way: If we learn something during the run of the project - shall we let that insight effect the plan of what we intended to do? Or shall we ignore that insight, sticking to the original plan even though inferior? Of course we will adapt! Anything else would be ridiculous.<br />
<br />
An agile project anticipates that such insights will emerge, so its processes are designed to harness and leverage upon those insights: demos, retrospectives, re-prioritisation of product backlog etc. These practises are all aimed at constantly refine and redefine the scope. But then, we have derived from the original specification "all features and functions as initially specified".<br />
<br />
Thus, any agile project longer than a sprint will fail - by definition. That is, if you use the Chaos rod for measuring success.<br />
<br />
To put it bluntly, if you measure an <i>agile project</i> using the Chaos rod, it will fail. Either the <i>agile</i> process will fail, or the <i>project </i>as defined will fail.<br />
<br />
Either, the project adapts to its measuring rod and blindly follows the "functions as specified", throwing whatever insight gained aside. Then, "project" will succeed, but "agile" will fail.<br />
<div>
<br /></div>
Or, the project will work according to its agile-minded processes, and then certainly the result of the project will not be "all features and functions as initially specified". Then, "agile" will succeed, but "project" will fail. I e project will fail as measured by Chaos rod.<br />
<br />
Damned if you do, damned if you don't.<br />
<br />
<i>A New (or Old) Hope</i><br />
<br />
The good news is that the Chaos rod is not the only way to measure projects. As we have discussed earlier, <a href="http://dearjunior.blogspot.se/2014/10/project-goals-using-effects-or-features.html">there has always been two ways to measure projects: feature list (Chaos rod) or measuring business effect</a>, what we can call the Effect rod.<br />
<br />
Let us take our earlier example with an on-line book store. They had an idea that recommendations of the type others-have-bought would increase their sales, so they set of some money for that projects.<br />
<br />
Using the Chaos rod they would have created a feature list around others-have-bought recommendations. The project would later be evaluated on how well it implemented the list. But let us look at a better idea.<br />
<br />
Using the Effect rod they might set a target that customers will by 0.35 more books per checkout on average. The Effect rod is used to state the value of a project. These 0.35 books can probably be converted to money, that makes the project worth the effort.<br />
<br />
The project might start out with an idea that others-have-bought recommendations would cut the cake. After the first small stories, deployed to production and put into hands of customers, the team learns that some kind of category would be helpful. To facilitate this they implement a simplified "search similar" as one of their features.<br />
<br />
Suddenly the number of books in the checkout carts raise to a level 0.4 above the pre-project baseline. And the level sustains, it was not just random noise - the change is statistically significant.<br />
<br />
The project has fulfilled its target according to the Effect rod, and is declared a success.<br />
<br />
Measuring using the Chaos rod "on time, budget, and specification" - the project would have been deemed a failure, because it did not deliver the initially specified others-have-bought.<br />
<br />
So, agile projects can be measured. You just have to use a measurement that is well suited. And, to be honest - which is better anyway.<br />
<br />
A sad side-note is that I know of several projects which have worked in an agile manner, and delivered enormous business benefit - but in the project report the project lead has had to apologise repeatedly for not meeting the project target as defined in the project specification - a feature list.<br />
<br />
Granted, to measure projects on business effect is not a new idea in any way at all. The idea was certainly there before the Agile Manifesto was written around the turn-of-millennia. What is new is that this way of measuring is essential to provide rigour to agile projects.<br />
<br />
For Agile to succeed at larger scale, we certainly need lots practises around agile-minded processes. Measuring agile projects on effects is certainly one of them.<br />
<br />
The way to measure agile projects is to set targets for business effect.<br />
<br />
Yours<br />
<br />
Dan<br />
<br />
PS Interesting enough, there is a sub-category "agile projects" in the later Chaos Reports, but the rate of success is not 0%, it is around 40%. I wonder what is going on here.<br />
<br />
PPS Within the agile community, the practice of projects is debated - at least in the sense of the common description "temporary organisation with limited time, resources, and ambition". So, it would probably be better to use some other term, e g talking about "initiatives". However, for convenience, I have kept the often-used and familiar term "project". Check out the twitter hashtag <a href="https://twitter.com/search?q=%23noprojects">#NoProjects</a>.<br />
<div>
<br /></div>
</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-43382340838249592352014-10-16T17:37:00.000+02:002014-11-12T16:13:32.455+01:00All Features Implemented does not equal Project Success<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Dear Junior</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Setting goals for agile projects is trickier that setting goals for waterfall projects. As I mentioned in an <a href="http://dearjunior.blogspot.se/2014/10/project-goals-using-effects-or-features.html">earlier letter</a>, for waterfall projects it is possible to set the goal in the form of a feature list to be delivered. This approach has several drawbacks - it does not guide the thousands of micro-decisions that are made, it gives no sense of purpose to support the drive or inner motivation, and it gives no guidance for evaluating whether the money, time, and effort was well spent.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">However, although all these problems, and although the approach is not advisable - it is still possible. The project management mindset and tools for waterfall projects are applicable for reporting project status or following up visavi a feature list. It is also possible to evaluate success by checking whether everything on the feature list is implemented.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Well, I still think it would be better to evaluate whether the project created some value.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Now, ridiculous as this seems it is still industry standard.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">The CHAOS report 1995 from Standish Group might be one of the most cited reports in system development. According to its statistics only 16% of software projects succeed. In the 2012 report this has been updated to 39%. And they collect data from tens of thousands of projects so the figures should be pretty reliable. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Now, this seems scary and low, but only until you check out their definition of success.</span></div>
<blockquote class="tr_bq">
<span style="font-family: Georgia, Times New Roman, serif;">"Resolution Type 1, or project success: The project is completed on-time and on-budget, with all features and functions as initially specified."</span></blockquote>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">OK. Not a word about actually getting value for the effort. Remember the on-line bookstore where they wanted others-have-bought recommendations to increase the number of books customers. Now, imagine they implemented the others-have-bought recommendations, but the customers did not buy more books anyway. Is this project a success?</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Well, you have spent lots of money building something, but made no money from it. To me it sounds like money, time, and effort down the drain - not as a success.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">To Standish Group, it is considered a success.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">On the flip side, imagine the project realising that a simplified "search similar" would increase the number of books each customer buys. Imagine further that this feature would be much easier to implement. So, the project decides to implement that feature instead. And the number of books sold per customer increases 0.4 on average.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Spending less money, time, and effort on something else than originally envisioned, but still getting the benefit - that sounds like success to me.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">To Standish Group, it is considered a failure.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Thus, the figure 16% or 39% actually says nothing at all about the state of software projects.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">So, Standish Group is probably filled with smart people. Why did they not evaluate software projects according to some meaningful metric instead? Most probably "generated business value as specified upon funding" would be more interesting. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">My guess is that too few projects actually stated an envisioned business effect, so analysing those projects would give so little data that it would not be possible to make any significant conclusions.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">So, instead of measuring something that would actually matter ("fulfilled envisioned business effect") they just measured something that could be measured.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Now, from the second example, where the team implemented another feature than originally envisioned, it is also clear that this approach is an absolutely worthless way of evaluating agile projects. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Yours</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"> Dan</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">PS The way to <a href="http://dearjunior.blogspot.se/2014/11/agile-projects-should-have-effect.html">measure agile projects is to set a target for a business effect</a>.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">PS The CHAOS 1995 report has been republished openly available for academic purposes. It can be found at <a href="http://www.projectsmart.co.uk/docs/chaos-report.pdf">http://www.projectsmart.co.uk/docs/chaos-report.pdf</a>. The 2013 version can be found at <a href="http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf">http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf</a></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<br />Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-35706771893384269322014-10-09T16:22:00.002+02:002014-11-12T16:16:05.226+01:00Project Goals using Effects or Feature List<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Dear Junior</span></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">There has always been two ways to set goals for a project, either you can define the goal of the project to be a list of feature to be implemented, or you can define some effect you want to see. Both of these have been around for a long time, and effect goals have always been superior. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Setting goals as a feature list is actually pretty simple - you simply state "these features I want to see before we consider this project closed". An online bookstore could say that it wants search-by-author, categories, and others-have-bought recommendations.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Following up during the project will simply consists of checking how far on this check-list the development team has progressed.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Effect goals are a little bit harder to set. You have to figure out and express why you want to have work done, what purpose it fulfils, in what way it makes your world better. Said bookstore must then express that it hopes people each customer will by 0.35 more books per checkout on average, or that it will increase its customer base with 10 000 new customers.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Following up during the project using this approach will consist of measuring the business parameters and watch the values change. A tricky part is that the full impact of the project might not be seen until the development work is "finished" (whatever that means), or even not until some time thereafter.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">To put things a little bit into context, it is not the "bookstore" that starts a project - it is always a person involved, in this case probably the product owner of the online store. And, this is the person who should explain why she is about to spend a lot of peoples' time and a lot of the organisation's money.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">I have always found that measuring success on effect, or impact, is the more intellectually honourable approach. To be frank, setting goals as a feature list does really say "this much work I want to have done" or rephrased "this much money I want to spend", nothing about what value it should result in. And if you want to have a group of people to work to bring your ideas to come real, the least you can do is to explain to them the value you think it will bring. Setting goals on effect is really about that - bringing purpose to the work.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Now, these two ways of setting goals and measuring success have a fundamental impact on how to manage projects in an agile manner, but that will have to wait until a later letter.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Yours</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"> Dan</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">PS An agile project cannot be feasibly measured using feature lists; <a href="http://dearjunior.blogspot.se/2014/11/agile-projects-should-have-effect.html">agile projects should be measured by setting a target for a business effect</a>.</span></div>
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-8474033250092885612014-06-17T09:00:00.000+02:002014-11-05T19:53:40.906+01:00CDE and Big Brother<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Dear Junior</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">What can a sleazy soap opera teach us about coaching agile teams and their managers?</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">It was somewhat a surprise to me when I realise that the reality TV show Big Brother makes a good metaphor for explaining one of my favourite models for understanding self-organised teams: the CDE-model.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">The Big Brother TV-show is a non-scripted soap opera where a bunch of people are locked up in a house together and followed by cameras day and night. The "thrill" of the show is how the people interact and react upon each other.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">The CDE-model is a system-theoretic model to reason about how teams self-organise as a reaction on their surrounding. Of course these reactions are very non-linear and hard to predict.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">What on earth have these two things in common?</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Let us put ourselves in the shoes of the Big Brother producers. Say that the events in the locked house have become a little bit dull lately. The people locked up have settled for a pace of life where they all sustain without unnerving the others. Nice for them, but not thrilling TV. We need something to happen.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">The problem for us is that Big Brother is non-scripted. We cannot direct Susan to "go and snug up Jonathan", even if we think it would be an interesting turn of events. We need to find other ways to change the behaviour inside the house without giving explicit directions.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">So we decide to shake them up a bit by changing the <i>conditions</i> under they live. A rough partition can separate three types of conditions: containers, differences, and exchanges.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><i>Containers</i></span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">One type of conditions we can change are the containers.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">We can lock the yard so that they are locked indoors. That will unsettle Bob who is used to take his morning strolls there. He might have to spend his mornings in the kitchen together with Alice, who has a terrible temper before getting her coffee. Or, we can open up an extra room, one that is a little bit hidden away, with very little insight - apart from the camera of course. Or, in the middle of the night we could push in an extra wall dividing the house into two parts; let us ensure that Tom and Lisa are locked up in one part, and Toms rival Jerry in the other part. Or, we could simply remove all doors. That could be fun.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">All these are examples of changing the containers that contain the contestants - making the containers bigger, or smaller, or less connected, or more connected, or even dissected. </span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Containers need not to be physical, there are other ways to divide a group. We can create a competition between two teams, then the teams become sociological containers. The teams can follow some obvious partitioning like city of birth or gender, or by some arbitrary dissection. </span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">The important part is that containers effect the patterns of interactions, so changing containers will change the behaviour.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Of course we could interpret "containers" literarily and put them all in a freight container. That is an idea.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><i>Differences</i> </span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Another type of conditions we can change are differences and how they are resolved.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">We can stir up events by introducing differences. For example, if we have an group of contestants with the same ethnicity we can send in a new contestant of a different ethnicity, for example sending in a white guy when there are only hispanics in the house. Or send in a professor of philosophy in a house with high-school drop-outs. You get the idea.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Sending in someone fair-haired when all are brown-haired will probably not make a lot of fuzz. In Big Brother, hair colour does not make a difference to how people treat each other - at least not in a way that make a significant change. We say that we only consider "significant differences". </span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">It differs from situation to situation what is a "significant difference" but in general the nuance of hair-colour is not one, whereas gender is - men and women are (sadly enough) treated differently. Same goes for ethnicity, sexual orientation and lots of other traits. All those are significant differences.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Introducing or enhancing differences are sure thing to induce change, but sometimes reducing differences can also unsettle the state of things.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Let us say we want to send in one person when there are four men and one women left in the house. Sending in a man would enhance differences from 4-1 to 5-1. Sending in a women would reduce gender difference to 4-2, but would probably be more interesting.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Apart from the differences as such, we have the issue about how these differences are resolved. </span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">One contestant might enjoy a particular kind of music, and preferably at high volume. Another contestant might not be so fond of that particular kind of music. However, they might be able to stand each other on a day-to-day basis. The difference is manageable, handling it is not difficult.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Now we can amplify the difficulty to manage differences, for example by introducing a large amount of liquor. Should either of them get drunk, or both, it will be harder to resolve the difference in taste of music, and we will probably see some interesting conflicts. </span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Another difference is food preferences, one way to amplify the effect of this difference is to insist that everybody in the house agree on what should be served for dinner. Can be fun to see how Mark "must have meat" tackles Vegan-Lisa, even more interesting when he gets hungry. </span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">As differences and resolving differences are a major driver for interaction, obviously changing those differences will change behaviour.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><i>Exchanges</i></span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Third and last of the conditions are the exchanges with the outside.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">If we let the contestants interact with the outside things will happen. We might let each of them have a (filmed) phone-call with a friend. Or we can have a small room where one at a time is allowed to speak to the audience. Or we might take away that room. We could put up a big TV showing news from the outside. We could fake the news we show. Surely things will happen.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Exchange need not to be communication. We can change the way food is delivered to the house; instead of small deliveries every day we make one big delivery once a week. That will cause some interesting effects at the end of the week when someone has eaten all the goodies on day one. If we are diabolic we can give them slightly too little to eat. Surely things will happen.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">As exchanges are the connection between the very limited system in the house, and the very large system on the outside, it is not surprising that how the inside and outside are connected will effect the behaviour on the inside.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><i>CDE</i></span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Of course there are a multitude of ways to unsettle the status quo in the house. However considering containers, differences, and exchanges (<i>CDE</i>) gives a good start to think about what leverages we can pull to cause the people in the house to behave differently. Or phrased in system lingo: to make the system reconfigure itself in another configuration.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">System theory teaches us that lots of systems are dynamic and non-linear. This means that it is very hard to predict the exact outcome of a change.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">As producers of Big Brother we know this. When we nudge the system in the house, we know that something will happen, but we do not know exactly what. We can have a guess, but we do not know. So, we need to be at our toes to watch out if things go another direction, and take compensating actions - or actions we hope are compensating.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Well, obviously neither you nor I are producers of Big Brother. And most probably we will never be. But same ideas can be applied to think about agile software teams that have self-organised and when coaching them or their managers. However, that is a subject which is a letter of its own.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Yours</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"> Dan</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">PS To be honest, my description does not perfectly fit how CDE was described by Glenda Eoyang</span><span style="font-family: Georgia, 'Times New Roman', serif;"> </span><span style="font-family: Georgia, 'Times New Roman', serif;">in her Ph D thesis. But I think I am truthful to the main idea.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">PPS Glenda Eoyang’s thesis can be read in full at <a href="http://www.hsdinstitute.org/about-hsd/dr-glenda/glendaeoyang-dissertation.pdf">http://www.hsdinstitute.org/about-hsd/dr-glenda/glendaeoyang-dissertation.pdf</a>. A briefer introduction can be found at <a href="http://wiki.hsdinstitute.org/cde">http://wiki.hsdinstitute.org/cde</a>.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">PPPS I think first time I came across CDE was when Mike Cohn introduced it to me during is tour when he released Succeeding with Agile, a good book for a lot of reasons and which also includes an introduction to CDE.</span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="min-height: 14px; text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<br />
<div style="font-family: Helvetica; font-size: 12px; min-height: 14px; text-align: justify;">
<br /></div>
Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-50656075327349594622014-06-05T09:13:00.000+02:002014-11-05T19:54:14.963+01:00The Three Elements of Agile<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Dear Junior</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Not that I necessarily claim to be an old hip-hopper, but an interesting part of the hip hop culture is the concept of "the four elements". </span></div>
<div style="text-align: justify;">
</div>
<ul>
<li><span style="font-family: Georgia, 'Times New Roman', serif;">Breaking - more commonly known as breakdance</span></li>
<li><span style="font-family: Georgia, 'Times New Roman', serif;">MC - more or less what rap is about</span></li>
<li><span style="font-family: Georgia, 'Times New Roman', serif;">DJ - you know disk-jockey</span></li>
<li><span style="font-family: Georgia, 'Times New Roman', serif;"> Graffiti - public painting</span></li>
</ul>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">An interesting thing is that within the hip hop community it is commonly agreed that all four elements are needed. If you should take away any of them, the hip hop culture would not be whole, it needs all four of them to be complete.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Also, all the elements are on the same level. That MCing should be "higher" than graffiti, or vice verse, is an idea that would be refuted as ridiculous. All the elements are of equal importance and each indispensable. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Obviously, the individual hip-hopper might not practice all of the elements. He or she will most probably immense in one of them. A few might practice two or three. Some might practice all four but are certainly not expected to master all of them.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Still there are a lot of respect between practitioners of the different elements: a talented MC easily gives public cred to a vicious graffiti painter. They are both needed and they would both feel poorer without the other. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">The four elements must be in balance for the hip-hop culture to thrive.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Well, that sounds all nice and cosy. But what does that have to do with agile?</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">I think the Agile community have a similar situation. Cutting the cake with a blunt knife I see three elements within the "agile culture": <i>tech, process and organisation</i>. OK, the knife is blunt so the cuts might not be perfectly clear, but I think it suffice to clarify my point.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><i>Agile Tech</i> consists of the technologies we have developed and use for the direct building of software. In this category we find frameworks as Hystrix for resilience; we find products as nosql-databases; we find tools as Chaos Monkey. Aside from the code we also have the close-to-code practices like Test-Driven Development, Domain-Driven Design, Continuous Integration, Build Pipelines etc. All these things enable us directly to write awesome software.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">With "process" in <i>Agile Process</i> I simply mean "the way we work". We work in sprints á la Scrum, or WIP-limited continuous flow á la Kanban; we demo at regular intervals; we use information radiators and stand-ups to synchronise work; we make forecasts to synchronise our work with other departments; we run retrospectives after sprints and projects to have a structured learning etc; we set targets and measure progress visavi effect goals, e g using Impact Mapping.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Finally <i>Agile organisation</i> is about how we structure ourselves. Within teams we self-organise, sure, but this is what we do on a larger level as well. We must ensure that information propagate across the organisation in a sound way; we want the architecture to stay reasonably consistent, preferably without a command-and-control chief architect. We must also synchronise and prioritise initiatives across this organisation so we also find portfolio management and finance/funding practices like Beyond Budgeting. Last but not least we find Agile HR/Agile Talent Management as part of this element.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Each agile practitioner might not do all the elements. On the contrary, most will stay mostly within one element or have their foot-hold in one and cross over to the other. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Comparing to the hip-hop culture I must claim that the agile community is not complete without all three elements. Doing only tech does not help us; doing only process does not help us; doing only org does not help us. Skipping any of them would hurt us.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Nevertheless I have during the history of agile I have seen competition between the element, sometimes even hostility between practitioners where one side have claimed to be the "true agile".</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">I think it is unnecessary and harmful.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Furthermore, I think it is unworthy of us, of a community praising "humans and interactions" over all things, a community that thinks "cross functional teams" are the superior model - should we not strive for a "cross functional community"?</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">In the same way as the hip-hoppers give cred across element borders I would love to see the kick-ass developer praise the agile-minded HR Director for "getting it"; I want the beyond-budgeting-inspired CFO to thank the engaged and engaging scrum master for the fantastic project retrospective; I want to see the impact-mapping business analyst to thank the devops for coming up with insightful real-time metrics about what customers actually do.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">OK, I might be guilty of hippiesm here, but I want the three elements of agile to share love.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Yours</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"> Dan</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">PS One of the reasons I care so much is that deep in my heart I feel that <a href="http://dearjunior.blogspot.se/2010/08/agile-is-different.html" target="_blank">Agile is different</a>.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;">PPS There is a video in Swedish from the conference <a href="https://agilasverige.solidtango.com/video/2014-06-05-agila-sverige-loke-02-dan-bergh-johansson" target="_blank">Agila Sverige 2014</a> where I do a blitz presentation on this subject and some related stuff.</span></div>
<div style="text-align: justify;">
<br /></div>
Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-73806814594093810042014-03-27T08:20:00.000+01:002014-03-27T08:20:00.326+01:00Deep Learning as a Strategy for Information Age<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Dear Junior</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Last friday we had the pleasure of having CS students Sofie Lindblom and Anton Arbring as guests visiting the monthly competence day at Omegapoint. </span></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">After this visit, <a href="https://twitter.com/SosLindblom" target="_blank">Sofie</a> have done me the honour of musing on the theme of our letters by writing an open letter "<a href="http://bit.ly/dear-senior-sofie-lindblom" target="_blank">Dear Senior, Letter to a Senior Programmer</a>". </span></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">That post is so full with interesting topics it would take a day just to briefly discuss them. But those topics are also way too important to leave uncommented. So, to do something, let us pick one important thing and discuss it. I pick the topic about "what to learn".</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;"><i>Too much information out there - as always have been</i></span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Sofie writes:</span><br />
<blockquote class="tr_bq">
<span style="font-family: Georgia, Times New Roman, serif;">But there is too much information out there to know where to start. I am not stupid, I did very well in all programming courses and is a fast learner. But I feel exhausted by the amount of information available.</span></blockquote>
</div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">To start somewhere, let us start with the vast amount of information, technology, frameworks, etc that are out there. Obviously there is no way to take in all of that. If we want to use metaphors, it does not suffice saying "drinking from the fire-hose", it is rather to try to gulp the Nile. </span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Good part is that the situation is not new. </span><span style="font-family: Georgia, 'Times New Roman', serif;">Of course there are more information out there now compared to 15 years ago when I left university. But even then the amount of information available was too much for any individual to comprehend. And the situation is even older. The proverb "so many books, so little time" is not fresh-out-of-the-presses. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">For those leaving university today, there will be truckloads of technology you will be using at work that you did not learn in class. But that situation is not new either. When I left university, I had not used a relational database in any single class or lab. Still, most systems (not all), I have worked with professionally have included SQL databases of some sort. Actually, one of my first jobs was to teach a class on the Java database API JDBC. How did I manage?</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">The obvious solution is to replace "know everything" with "able to comprehend". We cannot know everything beforehand, but we need to be able to understand any technology we come across with just spending a reasonable amount of work.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;"><i>Killing a meme</i></span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">There is a meme around in this information age that basically goes </span><span style="font-family: Georgia, 'Times New Roman', serif;">"you do not need to know, you need to be able to find information". I want to kill that meme in the context of system development.</span><br />
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span>
<span style="font-family: Georgia, 'Times New Roman', serif;">The meme might very well be true, with Wikipedia and the rest of the web at our fingertips we will be able to find data like "first historically recorded solar eclipse" (5th of May 1375 BC in Ugarit). Nevertheless true, it is worthless to us as software professionals. Because what we need is not data or information, but understanding.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;"><i>Deep knowledge feed deep knowledge</i></span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Now, this is only my own meandering experience, but I have found it invaluable to know a few things really well. Deep knowledge has interesting side effects. Suddenly you see some pattern apply to a new domain. It seems like no domain of knowledge is an island. Even if facts do not carry across boarders, some structures of thinking and reasoning actually apply.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">This is really vague, so let me throw some examples to clarify. When studying law I suddenly found that my studies of formal logic really helped me. I studied negotiation theory and found how it applies to finding a good architecture for a software system. I studied compiler technology and found it helpful when studying linguistics. Through my lifelong studies of math, I see wonderful aspects of beauty in the world every day. (OK, the last is a little bit off topic - but it makes my life richer, and that is worth something)</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">The strategy I try to apply myself is to study subjects in depth, to the level when I have to think hard about them. The specific knowledge might not be immediately applicable - I will probably not have any specific use of knowing e g how to count the number of ways to paint a cube using several colours. However, thinking hard has probably etched new traces in my brain - and those ways of thinking will probably pop up applicable in a new domain.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">To fall back on metaphors again. As software developers we need to dig deep to understand a new technology. To get down to depth we are not very helped by having dug a meter deep over a large area. But if we have dug a few 20 m deep holes in other places, there is a good chance that we can dig a short tunnel at the 20 m level from the bottom of some other hole. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">How did I survive that first job-gig teaching an API that I had myself never used before? Well, having studied functional programming in depth (using e g ML) had made me comfortable with the ideas of abstract datatypes. So the idea of an API was not unfamiliar. Having studied linguistics I was very familiar with formal grammars of languages so SQL syntax was not strange. Having studied compiler technology I could understand the semantics of SQL. Having studied algebra and set theory I could easily pick up how SELECT and JOIN worked.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">It took me a few days to read the JDBC API and specification combined with some small hacks to validate that I had got it right. And after those few days I did not only knew about JDBC, I actually understood it well enough to be able to teach it in a reasonable way. Not being an expert, but reasonably competent.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Without the deep knowledge in some very obscure subjects (linguistics, set theory, compiler technology etc) I would have been utterly lost. No skill in "searching information on the web" would have helped me the least.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Sofie writes</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<blockquote class="tr_bq">
<span style="font-family: Georgia, Times New Roman, serif;">The more I learn, the more I realize how little I know. It creates contradictory feelings towards the field I love. To twist it even further the part I love the most is that you can never be fully learned and that there is never a ”right” answer.</span></blockquote>
</div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">I understand the frustration. But I am not sure I would like to have a field where there was a right answer, a proven best practice - many in our field dream of such. </span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">However, to me a large portion of the beauty of the field is that we are constantly pacing unchartered terrain. The challenge is to constantly search your tool-box for something that seems applicable, to adapt, to improvise, to search, to try, to fail, to back up, to learn, to grow, to try again, to discuss, to exchange ideas, to finally nail it.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">This is nothing but my own personal experience, but if I should offer an advice to handle the world of information we have around us it would be the following:</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Find things to learn that you find interesting and that challenge your intellect. Take the time, pain, and pleasure to learn a few of those things to depth. The deep thinking will etch your brain in ways that will help you enormously whenever you approach a new field. And enjoy the pleasure of deep understanding when it dawns on you.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Yours</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"> Dan</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">PS Should you come across Sofie and Anton, take the time to have a discussion with them. And do not stop at a chat about everyday things - they have really interesting ideas to delve into.</span></div>
Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-82809646810241764602013-05-25T14:22:00.001+02:002013-05-25T14:28:57.051+02:00Days of Domain-Driven Security<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Dear Junior</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">It has been a truly interesting and challenging DDD Summit, where I have had the chance to present the subject of Domain-Driven Security and discuss it with several of the world's most prominent Domain-Driven Design experts.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">There seems to be a general agreement that the way <a href="https://twitter.com/johnwilander">John Wilander</a>, <a href="https://twitter.com/webtonull">Erland Oftedal</a> and I phrased the subject rings well with the insights of those experts, and that they agree on the means of using doman modelling and context mapping as tools to understand indata validation and vulnerability attacks as Cross-Site Scripting and the various forms of Injection.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">I had the honor of being interviewed by Daniel Gackle on Domain-Driven Security as part of a series of DDD videos that Vladimir Gitlevich is producing, and I will surely let you know when it is online.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Daniel amongst others has also given me excellent feedback on my assorted ideas about Domain-Driven Security to give it some structure that is more easily accessible for someone that has not been deeply involved from the start. Hopefully there are some articles or other pieces of writing on their way. Not promising to much, but I will let you know.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">You know well that one of my favorite phrases is "nothing is just a String" pointing out that a phone-number is more than any random string, that the same goes for a person's name, for an order number etc. This basically provides the case for typed value objects, typically with validation wrapped in the constructor.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">John Wilander has brought this one step further. If it is questionable to ever have just a String, then should not String be an abstract class? Besides making an excellent point in a very well written blogpost, he also provides an example of injection besides the usual SQL Injection which often is easily dismissed as "a solved problem, use prepared statements". I really recommend reading his <a href="http://appsandsecurity.blogspot.com/2013/05/should-string-be-abstract-class.html">posting</a>.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">It seems to me like this particular week, Domain-Driven Security as a field is experiencing an unusual high level of activity.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Yours</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"> Dan</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Ps. John Wilander recently defended his <a href="http://liu.diva-portal.org/smash/get/diva2:611283/FULLTEXT01">PhD thesis on software security</a>. Whereas the full text is of course pretty long, he also included a "popular brief" in Swedish which in a few pages summarises his work. Well worth reading, and a good example I think more researchers should follow.</span></div>
Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-55960390005397386592013-05-21T04:48:00.002+02:002015-10-29T09:09:46.813+01:00Domain Driven Design to Speed us Up by Opening Options<br />
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Dear Junior</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">At the DDD Summit a year ago there was an interesting discussion about how we motivate doing Domain Driven Design. We noted that one of the classical argument have been "proper domain modelling will make maintenance and further development easier", an argument which I have used myself. </span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">However, this is really a bogus argument; it more or less boils down to saying "spending a lot of time now will save us time later", which is a non-argument for anyone buying into the agile view of creating software. We need a better argument - If we are doing DDD it should be because it saves us time <i>now</i>.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">The general agreement last year was that domain modelling actually do speed us up now, so doing domain modelling saves time in the short term, e g the stories at hand in the current sprint if you are doing scrum. However, we did not much discuss the mechanisms that make it so.</span><br />
<br /></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">I have had this discussion in the back of my head during the last year, trying to keep my eyes open for how this could be the case - how doing more work actually could result in less work.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">At the DDD Summit this year I had a really rewarding discussion about this with <a href="https://twitter.com/sbohlen">Steve Bohlen</a>, sharing our experiences from the passed year. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">If you <i>do not</i> do domain modelling, you will look at the story to implement from a technical perspective. Doing so there is probably an "obvious" way to do it - "run that job, select the data from the database with a new where-clause, fetch it via XyzService, and push it to presentation". The approach will include activities A, B, C, D, and E - so write down those as five tasks, post them as stickies on the sprint board and start working. How could extra domain modelling <i>save</i> us time? Will it really make us work faster?</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">In order to make sense, let us think about "saving time" in the opposite direction. Efficiency <i>can</i> be seen as working fast. However, it can also be view as "maximising the work <i>not</i> done", which is how it is phrased in the <a href="http://agilemanifesto.org/principles.html">Agile Manifesto as the principle of simplicity</a>.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">One of the important mechanisms of domain modelling (if done right) is that it opens up options. In a domain modelling session you challenge yourself and the team to think about the problem in different ways, and a good modelling session might well result in three different ways of thinking about the problem - and thus generating three different solution. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Evaluating three different solutions might give you that first include activity A, C, E, and F. Second include B, F, and G. Third include A, B, D, F, H, and I. Now of these some might be worse than the "technically obvious solution". In this case third solution is probably worse; six activities instead of five. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Finding solutions that are worse than the one you had (the "technical")? Surely that must be a true waste of time!</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">However, you do not only find solutions worse, you most probably find some that is better. And, you only have to implement one of them - the best one. </span><span style="font-family: Georgia, 'Times New Roman', serif;">In this case, the simplest solution is the second, only requiring three activities. </span><br />
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">It is a little bit like throwing dice trying to throw an as low number as possible. Throwing one die will give 1 to 6 equal probability, so your average low will be 3.5. If you throw two dice, each die will give 1 to 6 equal. However, for 6 to be the minimum you will have to throw [6, 6] which is 1 chance out of 36. For five to be minimum you have to throw [5, 5], [5, 6], or [6, 5] - 3 out of 36. For three it will be 7 out of 36. For one it is 13/36. Throwing one extra die heavily skews the odds for throwing a lower throw ("finding a simpler solution").</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Back to software creation, the simplest solution found during the domain modelling is most probably easier that the solution that was obvious from the technical perspective. A small investment in opening options was well outweighed by finding a easier solution. So, we save time not by working faster, but by working smarter.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">And just to be clear - we are talking about a small investment in domain modelling, like a few hours or a day. It is not about a "phase of the project" were you spend weeks in day-in-day-out workshops and discussions.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">During the year my colleague Daniel Deogun had a wonderful example of this happening at our common client. At the sprint planning the team was convinced that they knew how to implement the story at hand. However, just to open up options, Daniel kidnapped the team for a two-hour domain modelling session. During that time </span><span style="font-family: Georgia, 'Times New Roman', serif;">they found new ways of looking at what they were building. So they ended up not touching the code they had envisioned to change. Instead they changed somewhere completely different and the amount of work shrank from being a dominating part of a sprint to be a few half-days of work for a few team members. And that insight was driven by asking questions about the domain - trying to phrase the answer in different ways.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">So, doing more work to save time might seem very unintuitive. However thinking about it as finding options to "maximise work not done", I think it makes sense. In a way, what we are avoiding is the sadness of a really fast boat sailing at high speed in the wrong direction.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">Yours</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"> Dan</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, Times New Roman, serif;">PS BTW, Steve and I had more interesting discussion around this topic, but that will need to be the topic of another letter.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">PSS Using the metaphor of orienteering what DDD modelling do is to spend a while to study the map, exploring different routes. As an orienteering runner this is definitely a smart move to <a href="http://dearjunior.blogspot.com/2015/10/the-way-agile-is-fast-fast-as-in.html">make us faster</a>.</span><br />
<br /></div>
<div style="text-align: justify;">
<br /></div>
Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-77676167935497494792012-12-18T16:26:00.002+01:002014-11-14T00:19:24.268+01:00Technical Details as Part of Domain Model<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Dear Junior</span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">A classical questions in Domain-Driven Design is whether technical details should be part of the domain model. The usual answer is "no, there should only be business concepts", but I would like to refine that a bit.</span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">One of the drives of Domain Driven Design is obviously to drive development from a design based on the domain - hence the name. So, concepts as "database", "table", "network" and "connection" should typically not be part of the domain and its language.</span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><br /></span>
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">This kind of technical details does not make sense <i>per se</i> in the domain - they add nothing do the direct understanding. However, databases and network and other technical details might have indirect effects that that we need to understand. The tricky part is to find appropriate abstractions for that understanding.</span><br />
<br /></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Let me take "buying a laptop" as an example. Recently I bought a new laptop from the Apple site. This is the "laptop to buy" model, and when doing this I filled out an order form, which is what constitutes the "laptop to buy" domain model.</span><br />
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><br /></span>
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">I know that a laptop is a pretty complex thing, so the "laptop to buy" domain is a really rich one. Some of my hardware freak frieds could talk to lengths about it. As I am not much of a hardware freak myself, I prefer if the "laptop to buy" domain model is as simple as possible - without "technical details" that I am not interested in.</span><br />
<br /></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">For example, the laptop I buy have a hard-drive, which is made by a manufacturer. I happen to know there are numerous subtle details that differ between hard-drive brands - but none that I care of. It is an uninteresting technical detail, and I do not want to see the choice of hard-drive brand in the domain of "laptop to buy".</span><br />
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><br /></span>
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Luckily for me, Apple agree, and there is no option for choosing hard-drive brand that makes the order form more complex and harder to understand.</span><br />
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><br /></span>
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Another technical detail is that the hard-drive have a lot of sectors and blocks, and the number of sectors and blocks differ from hard-drive to hard-drive. This is also something that I do not wish to care about - I just want to stuff my documents, photos, and film clips onto the laptop and it should just work. I do not want this to be part of the "laptop to buy" domain model either.</span><br />
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><br /></span>
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Unfortunately, Apple disagrees here. They think I need to be aware of that the hard-drive consists of storage cells, and that these actually are limited. Otherwise, I would live in the illusion that I could put things on my laptop indefinitely. That illusion would break down when there suddenly are "no space left on device" - an event which would leave me utterly confused.</span><br />
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">In order to make me understand the nature of how it is to work with a hard-drive, I need to be aware of the finite number of sectors and blocks - although it is a "technical detail". But, unfortunately, it is a technical detail I need to be aware of.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">Now comes the hunt for the appropriate abstraction to make the blocks and sectors understandable to non-hardware-technical me. "Blocks and sectors" does probably not work very well, but the concept of "size" does. I get that we are not talking about physical size, but some kind of analogy to the size of a suitcase. A small suitcase will become full fast, but you can put more stuff into a larger suitcase before it gets full. The size is still a "technical detail", but it is a detail that cannot be ignored, and it is put in a form I can understand.</span><br />
<br /></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Thus Apple has chosen to have options in the order form for how big a hard-drive I want, making it a part of the "laptop to buy" domain model. </span><br />
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><br /></span>
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">And I can agree with Apple.</span><br />
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">When considering whether a concept should be in the domain or not, it is really not interesting whether it is a "technical detail" or not. The interesting discussion is whether this is a concept which the user (or other stakeholder) needs to be aware of. We cannot take away concepts that will make their understanding "break down". And for those technical details, we have to find an appropriate abstraction.</span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">This reminds me of an Einstein quote: "Things should be made as simple as possible, but not simpler" which I think is an excellent way to put Occam's Razor.</span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">So, technical details should not be part of the domain if they are irrelevant to the business. However, it might be that the technical detail is a concept that you need to understand to comprehend how things work. And in that case, it should be part of the domain, even if it stems it origin from the technical side.</span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Yours</span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"> Dan</span></div>
Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-21877658487288574592012-03-14T08:30:00.000+01:002014-11-14T00:19:24.236+01:00DRY and False NegativesDear Junior<br />
<br />
In earlier letters we have talked about the DRY-principle, how looking for <a href="http://dearjunior.blogspot.com/2012/03/dry-and-duplicated-code.html">duplicated code can help finding violations of DRY</a>, but also about the false positives - the rare <a href="http://dearjunior.blogspot.com/2012/03/dry-is-about-ideas-not-text.html">locations where unrelated concepts by coincidence happen to be represented by similar code</a>. Using Domain-Driven Design terminology it is where two different concepts are modelled, but where the models happens to be represented the same way.<br />
<br />
But the hardest part of DRY is the false negatives.<br />
<br />
A "false positive" is when some kind of test raises a signal but does so wrongly. E g a medical lab test might say that you have a disease which you does not have. If you get a false positive you have to do further investigations before you realise that it was just a false alarm. In our case the false positives are where code that was alarmed as duplication, but actually was jus a coincident and no violation of DRY.<br />
<br />
A "false negative" on the other hand, is when the test <i>does not</i> raise a signal but does so wrongly. E g a medical lab test says you are healthy, but you actually have the disease. Now, false negatives are a lot harder to handle as the few mistakes (wrong classification by the test) hide within an enormous pile of "perfectly normal cases" (i e the true negatives).<br />
<br />
This is the reason why medical tests most often are designed to avoid false negatives even if that design means more false positives. In the medical field this is natural. The cost in money and suffering in a missed AIDS-diagnosis totally overshadows the costs and anxiety of having to run a few extra tests in case the initial test wrongly showed "infected".<br />
<br />
Talking about to DRY and code: what are our false negatives? Well, it is those DRY-violations that does not show up as code duplicates. Using DDD terminology we have exactly the same concept being modelled, but it is represented in different places in the model, and the representations differ from each other. Code-wise, we have pieces of code that fulfills the same purpose in the solution, but are written in a different way.<br />
<br />
We return to our online sales system as an example to make that clear. <br />
<br />
In the customer management there might be a method that validate that zip-codes are five-digit strings. Some programmer wrote the regexp as part of an if-condition and at some later point of time some other programmer extracted it to a metod.<br />
<br />
<pre>class CustomerManagement {
private boolean validateZip(String zip) {
return zip.matches("[1-9][0-9]{4}");
}
}</pre><br />
Totally unaware of the private method in CustomerManager, some third programmer was working on the shipping logic. This programmer wanted to avoid printing invalid zip codes on packages so he looked for some feasible method in the standard APIs for a minute or two before giving up and whipping together his own helper method. Also, this programmer was not so well versed in regexps so he found another way of validating.<br />
<br />
<pre>class Shipping {
public static boolean isValidZipCode(String zipcode) {
try {
int i = Integer.parseInt(zipcode);
return Integer.toString(i).length() == 5;
} catch (NumberFormatException e) {
return false;
}
}
}</pre><br />
(BTW, these examples are inspired be real code-bases)<br />
<br />
This is where we suddenly have a tricky instance of DRY-violation. We express the exact same idea - the criteria for how a valid zip code is formatted. But we do so in completely different way - so different that no code-duplicate detector will find them. <br />
<br />
It would be far from tasteful to compare the direct human suffering of failing medical tests with the effects of DRY-violation. Nevertheless, in medical tests the false negatives are far more troublesome than the false positives. And the same holds for violations of DRY. The false positives we can find and discuss, but the false negatives will just silently create implicit couplings between different parts of the code - couplings that are hard to find and might break when the concept change but only a few of the representations are updated. Also, it leads to our code getting bloated.<br />
<br />
In summary I dare to make an analogy to medicine. When looking for the DRY-disease, we will get a lot of help from testing for code-duplication. There will be some false positives that we need to keep our eyes open for so that we do not try to cure where there is no illness. However it is the false negatives that the easy test does not find that will cause us the most trouble in the long run.<br />
<br />
Yours<br />
<br />
Dan<br />
<br />
Ps My colleague Anders Helgesson phrased this as "Man ska inte upprepa sig och säga samma sak, om och om igen, flera gånger" wich in translation is "You should not repeat yourself and say the same thing, over and over again, many times" - a wonderful example of a DRY violation where searching for duplicated text gives a false negative.<br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-63193875366474697662012-03-07T11:25:00.000+01:002014-11-14T00:19:24.257+01:00DRY and Duplicated Code<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Dear Junior</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">In my last letter I wrote about how the DRY-principle (Don't Repeat Yourself) talks primarily talks about the number of times an idea is expressed in the code-base, not about text-repetition as such.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">If nothing else, the intention of DRY becomes clear when you go back the source that caused the DRY-meme to spread within the programming community: <i>the Pragmatic Programmer</i> by Andrew Hunt and David Thomas, published in 1999.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<blockquote class="tr_bq">
<span style="font-family: Georgia, 'Times New Roman', serif;">"Every piece of knowledge must have a single, unambiguous authoritative representation within a system" </span></blockquote>
</div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">(Needless to say, when reading this book I found its core ideas to be extremely well aligned with my own ideas about programming - and the rest of the book have had profound impact on my view of the craftsmanship aspects of programming)</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Now, to put my last letter in perspective it must be pointed out that the absolutely easiest way to find violations of the DRY principle is to search your codebase for duplicated text. It is very likely to find multiple places where the same idea is expressed over an over again using the same technical construct.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">If for example you have an order system, there might be an attribute "payment" on the order telling when the order was paid.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<blockquote class="tr_bq">
<pre>class Order {
Date payment = null;
Date payment() { return this.payment; }
}</pre>
</blockquote>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Most probably orders are not allowed to be sent for shipping unless they are paid. So, very probably there will be code somewhere checking this condition.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<blockquote class="tr_bq">
<pre>if(order.payment() != null) // do shipping
else // do not allow shipping</pre>
</blockquote>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">It is also probable that the same check is done in a lot of other places throughout the codebase. What we have ended up with is that the same technical construction "order.payment() != null" is used to express the same idea "order is payed" in a lot of places - a clear violation of DRY. Most probably we will also find a lot of places checking the negation "order.payment == null".</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Of course the codebase would benefit from encapsulating the interpretation of a nulled payment-field and putting that encapsulated interpretation in one place - preferably the Order class.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<blockquote class="tr_bq">
<pre>class Order {
Date payment = null;
Date payment() { return this.payment; }
boolean isPaid { return order.payment() != null; }
}</pre>
</blockquote>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">The benefits are several. To start with it is now possible to change the technical representation of an unpaid order without having to run around the code-base. We actually want all those places in the code to change at the same time - because they conceptually related things (actually they are conceptually the same thing).</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">An even more important benefit is that the API of the Order class becomes more expressive, making the client code more lucent. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<blockquote class="tr_bq">
<pre>if(order.isPaid()) // do shipping
else // do not allow shipping</pre>
</blockquote>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Obviously, searching for duplicated text is an excellent way of finding candidate violations of DRY. If the code looks exactly the same, then those places will need to change at the same time - i e we have implicit couplings in the codebase that we risk breaking when we change.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">There are excellent tools out there to detect duplicated code - some bundled in code-quality tools like Sonar, some available directly in your IDE. Most of these even have support for "fuzzying" where they detect that code is duplicated "apart from different naming of variables" for example. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Using these tools on an "average codebase of the street" will probably yield hundreds of places with duplicated code. Of these candidates, the vast majority of them will be violations of the DRY principle - especially the short code-snippets like "order.payment() == null" which are so easy to "just write" instead of looking for a method that does the job. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">However, be aware that within that huge pile of DRY-violations there might also be a few "false positives". Those are the code-places that by accident happen to look the same way, but actually represent different and unrelated ideas. To "reduce the common code" in that case would only cause a irrelevant coupling between unrelated parts of the solution.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">In summary, looking for duplicated code is an excellent "screening test" to find loads of candidates where the DRY-principle has been violated. However, the DRY principle is not about duplication of text, but about duplication of ideas. So, the two should be kept apart.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span><br />
<span style="font-family: Georgia, 'Times New Roman', serif;">Even if duplicate code most often is a sign of DRY-violation, there are valid reasons to have the same code-text in two different places. </span><br />
<span style="font-family: Georgia, 'Times New Roman', serif;"></span><br />
<div style="font-family: Times; text-align: justify;">
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><span style="font-family: Georgia, 'Times New Roman', serif;">Jérémie Chassai phrased it pretty well on <a href="https://twitter.com/thinkb4coding/status/175197914501611522">Twitter</a>: "You should repeat yourself if you say the same thing for two different reasons".</span></span></div>
</div>
<div style="font-family: Times; text-align: justify;">
</div>
<br /></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Get those tools, start searching for duplicates, and good DRY-hunting</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Yours</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br />
</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Dan</span></div>
<div style="text-align: justify;">
<br /></div>Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-60095623052793747912012-03-01T19:04:00.000+01:002014-11-14T00:19:24.250+01:00DRY is about Ideas, not Text<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Dear Junior</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Ever since the Pragmatic Programmer, the principle of DRY (Don't Repeat Yourself) has been one of the central pieces of advice for good programming. From a private perspective, it has many a time helped me to write code that is better than had I not had that meme in the back of my head. However, I have also seen it misused and (in my understanding) misunderstood several times - sometimes with disastrous result.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">What I think is central about DRY is that it refers to ideas. Slightly rephrased DRY can be expressed that "each idea about your software solution should be expressed once and only once in your code". With "idea" I mean stuff like "an order number is a six-digit string not beginning with 0 or 1", or "an order that is cancelled after shipping will still be debited the costs that we cannot recover".</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Unfortunately, a common misuse is to let DRY to talk about code as text. Let me make it a little bit more clear though an example. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Say that we have some kind of order system where order numbers are five-digit numbers. Somewhere we might find this code that checks whether a string is a valid order number or not.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> public static boolean isValidOrderNumber(String orderNumber) {</span></div>
<div style="text-align: justify;">
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> return orderNumber.matches("[1-9][0-9]{4}");</span></div>
<div style="text-align: justify;">
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">The code might be in the Order class, or even inside an OrderNumber value object, and possibly being called by the constructor.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">As it is an order system, there will also be a part that talks about shipping, to get the goods to some specified address. The address consists of a lot of things, among those a zip code that in this country is a digit string of length five (initial digit must be non-zero). So, somewhere we can expect to find the code doing this validation.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> public static boolean isValidZipCode(String zip) {</span></div>
<div style="text-align: justify;">
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> return zip.matches("[1-9][0-9]{4}");</span></div>
<div style="text-align: justify;">
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">This code might be in the Address class, or inside the ZipCode value object - possibly called by the constructor.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Now, this is where some DRY-zealots shout "duplication, duplication" because they have pattern-matched the string matching in isValidOrderNumber with the string matching in isValidZipCode and noticed that they consist of exactly the same text (barring a rename of a variable).</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">I think this is a mistake, and those zealots focus on the wrong thing. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">In the eyes of the zealots, the textual duplication is bad. Instead one method should call the other. This obviously becomes bizarre code if you try it. For example it would create a completely irrelevant coupling between the zip code and the order number - two concepts that are not related at all.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Alternatively, they claim, the common code should be broken out to a separate method called from both places. Now, that might make more sense, but you still introduce a coupling between the un-related concepts order number and zip code: they will now covariant - change one and the other will change.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">For example, should this company decide to use letters in their order numbers, then they need to regression test all their use of addresses as well. </span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Do this kind of coupling on a massive scale, and you will end up with a system where every change is full of surprises - conceptually totally unrelated concepts start behaving different just because they had some code-snippet in common.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">What to do instead?</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">We should not primarily look at the code as a mass of text. Instead we should look at it as representation of a set of ideas. This is of course the perspective of Domain Driven Design, where we see the code as the encoding of a distilled domain model - a model that captures our selected way of looking at the problem domain.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Now, seen from that perspective the "repeated code text" in the two validation methods is completely unproblematic. It is just two separate concepts that happens to be represented using the same technical mechanism. They have nothing to do with each other - the duplication is a pure coincidence and the two concepts should be able to change totally uncoupled from each other.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">The principle of Don't Repeat Yourself is about ideas, it does not apply to text.</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;">Yours</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"> Dan</span></div>
<div style="text-align: justify;">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div style="text-align: justify;">
<br /></div>Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-87272548556392209502011-11-15T22:54:00.001+01:002011-11-15T23:09:30.753+01:00Akka 1.2 Made it Simple to Get Started<br />
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><br />
Dear Junior<br />
<br />
The release of Akka 1.2 is about a month old, but it contains a change that is makes it much easer to try out Akka. It is not some revolutionary new feature, quite the contrary. They have simplified the package structure of Akka so much that the core Akka actor package now has <i>no</i> external dependencies. Correct: no, none, zip external dependencies - stands for itself.<br />
<br />
Earlier, if you wanted to try out Akka, you had the problem that Akka relied on a ton of other open source libraries. So, if you just wanted to try out to write a simple actor, you still had to download a long list of other jars. Well, that can be handled by maven, or by the wonderful little tool "sbt" (Simple Build Tool), but still that is a threshold to get over before getting started. And that threshold has noting to do with "understanding actors".<br />
<br />
In Akka 1.2 they have done a wonderful job of splitting out dependencies and managed to refine to "core actor" parts to be self-contained, i e it does not require any other libraries in place to work.<br />
<br />
To get started writing your first Akka actor, simply download Akka 1.2 and put "akka-actor-1.2.jar" on your classpath. Ready to start hakking.<br />
<br />
<i>An Example</i><br />
<br />
In InteillJ, I create a new project "akka12" in a library with the same name:<br />
<code><br />
dajob05:akka12 danbj$ pwd<br />
/Users/danbj/var/tmp/akka12<br />
dajob05:akka12 danbj$ ls -l<br />
total 8<br />
-rw-r--r-- 1 danbj staff 796 15 Nov 15:55 akka12.iml<br />
drwxr-xr-x 2 danbj staff 68 15 Nov 15:55 src<br />
</code>
<br />Well, I happen to use IntelliJ, but any other modern IDE would work as well.
</span><br />
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><br /></span><br />
<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Now, I create a "lib" directory for third party libraries (i e Akka), download akka and put the jar in "lib"<br />
<code><br />
mkdir lib<br />
curl http://akka.io/downloads/akka-actors-1.2.zip >akka-1.2.zip<br />
unzip akka-1.2.zip akka-actors-1.2/lib/akka/akka-actor-1.2.jar<br />
mv akka-actors-1.2/lib/akka/akka-actor-1.2.jar lib/<br />
</code>
<br />
Now the self-contained Akka jar is in the lib directory.<br />
<code><br />
dajob05:akka12 danbj$ ls lib<br />
akka-actor-1.2.jar<br />
</code>
<br />
I add the jar as a project library in my IntelliJ project, and now I can create an actor class together with a small script that sends a message to that actor.<br />
<code><br />
import akka.actor.Actor<br />
<br />
object helloworld extends App {<br /> val worlder = Actor.actorOf[Worlder]<br /> worlder.start()<br /> worlder ! "hello"<br />
}<br />
<br />
class Worlder extends Actor {<br /> def receive = {<br /> case msg => println(msg + " world") <br /> }<br />
}<br />
</code>
<br />
Running it (from inside the IDE) gives the expected<br />
<code><br />
hello world<br />
</code>
<br />
I just love what the Typesafe crowd have done to make it so easy to get started.<br />
<br />
Happy hakking<br />
<br />
Yours<br />
<br />
Dan</span></div>Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-35246865981807876842011-10-13T09:26:00.001+02:002011-10-13T09:26:19.731+02:00Scala Actors and Estragon's Bad Memory<div class="Lpande">
</div>
<div class="Lpande">
</div>
<div class="Lpande" style="text-align: justify;">
<br />
<div class="p1">
Dear Junior</div>
<div class="p1">
<br /></div>
<div class="p1">
The event-based actor model in Scala is obviously so much more memory-efficient than the thread-based, so there must be a catch somewhere. There sure is, the price we pay is that the code does not always behave in the way we intuitively expect. And unfortunately the coding model does not shield us completely from those situations.</div>
<div class="p1">
<br /></div>
<div class="p1">
The reason I think this is important is that I want to walk the road towards Akka. Once we get there it will be obvious why Akka’s design give us both an efficient runtime model and a carefully guiding programming model.</div>
<div class="p1">
<i><br />
</i></div>
<div class="p1">
<i>Unintuitive Effects of Event-Based Model</i></div>
<div class="p1">
<br /></div>
<div class="p1">
Let us return to the programming model of event-based actors in Scala standard library, and the things that might baffle us.</div>
<div class="p1">
<br /></div>
<div class="p1">
One of the things that might happen is that inside one instance of actor, <i>consecutive</i> lines of code<i> </i>might be executed by<i> different</i> threads. That is not what we expect.</div>
<div class="p1">
<br /></div>
<div class="p1">
Let us pick apart an event-based actor to see what is going on, and the same with a thread-based actor – just for reference.</div>
<div class="p1">
<i><br />
</i></div>
<div class="p1">
<i>Dissecting Thread-Based Vladimir</i></div>
<div class="p1">
<br /></div>
<div class="p1">
To see how that can happen, let us start with a simple thread-based actor – our dear friend Vladimir. In a small script, we create an actor, start it and send it the message (Godot) that it is waiting for. OK, in the play <i>Waiting for Godot</i>, the point is that Godot never shows up, but let us be nice to poor Vladimir.</div>
<div class="p2">
<br /></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">object vladimirwaitandrun extends Application {</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> def T() = "T" + Thread.currentThread().getId</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> println("Creating actor " + T)</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> val vlad = new Vladimir(42)</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> println("Starting actor " + T)</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> vlad.start()</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> println("Sending Godot message " + T)</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> vlad ! Godot</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> println("Finished script " + T())</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">}</span></div>
<div class="p3">
<br /></div>
<div class="p1">
The Godot-waiting actor Vladimir is implemented as a subclass to “actors.Actor” of the Scala standard library.</div>
<div class="p2">
<br /></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">class Vladimir(id : Int) extends Actor {</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> def T = "T" + Thread.currentThread.getId</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> def name: String = "Vladimir" + id</span></div>
<div class="p4">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> def act() {</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> println(name + " is waiting " + T)</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> receive {</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> case Godot =></span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> println(name + " saw Godot arrive! " + T)</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">}</span></div>
<div class="p4">
<br /></div>
<div class="p1">
All set up – let us run the script.</div>
<div class="p2">
<br /></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">danbj$ scala godot.vladimirwaitandrun</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Creating actor T1</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Starting actor T1</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Vladimir42 is waiting T11</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Sending Godot message T1</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Finished script T1</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Vladimir42 saw Godot arrive! T11</span></div>
<div class="p4">
<br /></div>
<div class="p1">
First we note that the script and the actor are run by different threads: T1 and T11 respectively – no surprise. We also note that both lines of Vladimir where run by the same thread. No surprise that either, the thread-based model gives each actor a thread and when the actor pauses (waiting for Godot), the thread pauses.</div>
<div class="p1">
But let us walk through this just to see the difference when we come to the event-based model.</div>
<ul class="ul1">
<li class="li5">An actor of the class Vladimir is created and started – its “act” method start executing in a thread of its own (T11) starting with a print.</li>
<li class="li5">The actor executes the method “receive” (still in thread 11). The call to receive takes an argument, which is the so-called “message handler” – a code-block to be used when matching the incoming message. To be precise, the argument is an anonymously defined function, which is passed as the argument to “receive”. </li>
<li class="li5">As there is no message in the actor’s mailbox, “receive” puts the thread (T11) to sleep. </li>
<li class="li5">Message “Godot” is dropped into Vladimir’s mailbox (by T1). Waiting thread T11 is notified. Thereafter the script finishes.</li>
<li class="li5">T11 wakes up and starts applying the message-handler to the arrived message. There is a match in the (only) case-clause and T11 prints “Vladimir42 saw Godot arrive! T11”</li>
<li class="li5">Execution of message handler is finished. As there is no more code in “act” the thread returns.</li>
</ul>
<div class="p6">
<br /></div>
<div class="p1">
OK, there are more subtleties going on, but this will do for now.</div>
<div class="p1">
<i><br />
</i></div>
<div class="p1">
<i>Dissecting Event-Based Estragon</i></div>
<div class="p1">
<br /></div>
<div class="p1">
Now let us look at the same thing happening with an event-based actor: our dear friend Estragon.</div>
<div class="p2">
<br /></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">object estragonwaitandrun extends Application {</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> def T() = "T" + Thread.currentThread().getId</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> println("Creating actor " + T)</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> val estragon = new Estragon(42)</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> println("Starting actor " + T)</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> estragon.start()</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> println("Sending Godot message " + T)</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> estragon ! Godot</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> println("Finished script " + T)</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">}</span></div>
<div class="p4">
<br /></div>
<div class="p1">
The Godot-waiting actor Estragon is also implemented as a subclass to “actors.Actor”, and the only difference is that it uses another method for awaiting a message in the mailbox. Instead of “receive” it uses “react”.</div>
<div class="p2">
<br /></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">class Estragon(id : Int) extends Actor {</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> def T = "T" + Thread.currentThread.getId</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> def name: String = "Estragon" + id</span></div>
<div class="p4">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> def act() {</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> println(name + " is waiting " + T)</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> react {</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> case Godot =></span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> println(name + " saw Godot arrive! " + T)</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">}</span></div>
<div class="p3">
<br /></div>
<div class="p1">
All set up. Let us run this.</div>
<div class="p2">
<br /></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">danbj$ scala godot.estragonwaitandrun</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Creating actor T1</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Starting actor T1</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Estragon42 is waiting T10</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Sending Godot message T1</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Finished script T1</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Estragon42 saw Godot arrive! T13</span></div>
<div class="p3">
<br /></div>
<div class="p1">
Now, let us walk through this run and see what actually happened.</div>
<ul class="ul1">
<li class="li5">An actor of the class Estragon is created and started. A thread (T10) is taken from the thread pool and connected to the actor. The thread start running the “act” method, which starts with a print.</li>
<li class="li5">The actor executes the method “react” (still in T10). The call to react takes an argument, which is the so-called “message handler” – a code-block to be used when matching the incoming message. To be precise, the argument is an anonymously defined function, which is passed as the argument to “react”. </li>
<li class="li5">As there is no message in the actor’s mailbox, “react” disconnects the thread from the actor. The message-handler is registered at the event handler. The thread goes back to the thread pool.</li>
<li class="li5">Message “Godot” is dropped into Estragon’s mailbox from the script (by T1). The event-handler is notified. The script thereafter finishes.</li>
<li class="li5">The event-handler picks an available thread (T13) from the thread pool and connects it with the actor. The thread is given the message-handler to run and starts applying the message-handler to the arrived message. There is a match in the case-clause and T13 prints “Estragon42 saw Godot …”</li>
<li class="li5">Execution of message handler is finished. Thread is disconnected and goes back to pool.</li>
</ul>
<div class="p3">
<br /></div>
<div class="p1">
Note that there are two different threads (T10 and T13) involved in executing the actor Estragon42. Having a pool of threads does not only mean that one thread can serve many actors (thus conserving resources). It does also mean that different threads might be involved in running the same actor during its lifespan. </div>
<div class="p1">
<br /></div>
<div class="p1">
To be honest, I must admit that I did run the script a few times before I got a run with different threads in “is waiting” and “saw Godot arrive”. The allocation of threads is non-deterministic from the point of view of the program, and the first few runs happened to reuse same thread in both phases – but that would not serve to make my point.</div>
<div class="p1">
<i><br />
</i></div>
<div class="p1">
<i>The Difference in Short</i></div>
<div class="p1">
<br /></div>
<div class="p1">
Let us focus on the core difference between these two examples; first thread-based Vladimir.</div>
<div class="p1">
<br /></div>
<div class="p2">
<span class="Apple-style-span" style="color: #38761d; font-family: 'Courier New', Courier, monospace; font-size: x-small;"> println(name + " is waiting " + T)</span></div>
<div class="p2">
<span class="Apple-style-span" style="color: #38761d; font-family: 'Courier New', Courier, monospace; font-size: x-small;"> receive {</span></div>
<div class="p2">
<span class="Apple-style-span" style="color: #38761d; font-family: 'Courier New', Courier, monospace; font-size: x-small;"> case Godot =></span></div>
<div class="p2">
<span class="Apple-style-span" style="color: #38761d; font-family: 'Courier New', Courier, monospace; font-size: x-small;"> println(name + " saw Godot arrive! " + T)</span></div>
<div class="p2">
<span class="Apple-style-span" style="color: #38761d; font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }</span></div>
<div class="p4">
<br /></div>
<div class="p1">
Here the same thread (T10, marked as <span class="Apple-style-span" style="color: #38761d;">green</span>), execute the consecutive lines. It executes the println and the receive, makes a small pause, and finish with the matching case clause and the last println.</div>
<div class="p1">
<br /></div>
<div class="p1">
This is execution of code as we learned in Programming 101.</div>
<div class="p1">
<br /></div>
<div class="p1">
Now, time for event-based Estragon</div>
<div class="p2">
<br /></div>
<div class="p2">
<span class="Apple-style-span" style="color: #0b5394; font-family: 'Courier New', Courier, monospace; font-size: x-small;"> println(name + " is waiting " + T)</span></div>
<div class="p2">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><span class="Apple-style-span" style="color: #0b5394;"> react</span> <span class="Apple-style-span" style="color: #741b47;">{</span></span></div>
<div class="p2">
<span class="Apple-style-span" style="color: #741b47; font-family: 'Courier New', Courier, monospace; font-size: x-small;"> case Godot =></span></div>
<div class="p2">
<span class="Apple-style-span" style="color: #741b47; font-family: 'Courier New', Courier, monospace; font-size: x-small;"> println(name + " saw Godot arrive! " + T)</span></div>
<div class="p2">
<span class="Apple-style-span" style="color: #741b47; font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }</span></div>
<div class="p4">
<br /></div>
<div class="p1">
Here two threads are involved. First one (marked <span class="Apple-style-span" style="color: #0b5394;">blue</span>) execute println and react, ending with registering the message-handler. Then at a later point of time some other thread (marked <span class="Apple-style-span" style="color: #741b47;">purple</span>) executes the case-clause and the last println.</div>
<div class="p1">
<br />
The result is that consecutive lines of code inside the same actor object is executed by different threads.</div>
<div class="p1">
<br /></div>
<div class="p1">
Not what we learned in Programming 101.</div>
<div class="p1">
<i><br />
</i></div>
<div class="p1">
<i>Does it Matter?</i></div>
<div class="p1">
<br /></div>
<div class="p1">
OK, but does it matter? Unfortunately there are situations where this makes a difference for us as programmers. For example, many security frameworks take user credentials of the authenticated user and stuff it into thread locals. In that way the credentials need not to be passed around explicitly but can be fetched from the thread when needed. Alas, that does not work if the code “suddenly changes horses midrace”.</div>
<div class="p1">
<br /></div>
<div class="p1">
There are also other situations where the code behaves in unintuitive ways due to this “thread switching” and where the programming model does not shield us programmers from strange effects and risk of making errors. More on that later. </div>
<div class="p1">
<i><br />
</i></div>
<div class="p1">
<i>Estragon’s Bad Memory</i></div>
<div class="p1">
<br /></div>
<div class="p1">
On a side not the difference in execution model can also explain one aspect of the play Waiting for Godot. In the play, Estragon suffers from a severe memory condition. When the Act II starts on the morning of the second day, it seems like Estragon has no recollection at all from what happened in Act I the previous day. This is enormously frustrating for his companion-in-waiting Vladimir, who clearly remembers how they waited in vain for Godot to show up.</div>
<div class="p1">
<br /></div>
<div class="p1">
Now given the knowledge about threading it is obvious why Vladimir remembers the previous day. Thread-based Vladimir is in Act II connected to the same thread of execution as in Act I – so the events in Act I happened to “the same memory-line” as Act II. Event-based Estragon on the other hand is not necessarily connected to the same thread in Act II as he was in Act I, so Estragon in Act II is not “the same memory-line” as Estragon in Act I. In a way Estragon experience the same situations as a person with multiple-personality disorder. Even if it is the same Estragon-body (object, actor), it is not the same Estragon-mind (thread) from time to time.</div>
<div class="p1">
<br /></div>
<div class="p1">
That might be an explanation for Estragon’s bad memory. It would be interesting to diagnose it more closely, like if we could probe his mind for what is going on from time to time.</div>
<div class="p1">
<br /></div>
<div class="p1">
Yours</div>
<div class="p1">
Dan</div>
</div>Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-59451732302772013152011-09-16T08:24:00.000+02:002014-11-14T00:19:24.246+01:00Public final and data encapsulation<br />
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Dear Junior<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">We were discussing
immutable value objects and using "public final" data-fields for
their representation. In that discussion I started off mixing up immutability
and encapsulation. Now that <a href="http://dearjunior.blogspot.com/2011/09/public-final-is-also-immutable-again.html">we have covered immutability</a>, let us return to
encapsulation. <o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Obviously, declaring a
field as public will break data encapsulation. You lose your freedom to change
data representation without having to bother the clients. <o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Let us have a look at a
name-class with some actual usage.<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">public class Name {<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> <b>public final</b> String <b>fullname</b>;<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> public Name(String
fullname) {<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">
if(!fullname.matches("[a-zA-Z\\ ]+"))<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">
throw new IllegalArgumentException();<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">
this.fullname = fullname;<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> public String[] <b>names()</b> {<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">
return fullname.split(" ");<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">}</span><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">The public API of this
class consists of three parts: the construction of a name from a string, the
attribute “fullname” (accessible through property data field), and the
attribute “names (accessible through accessor method).<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">An example of what
client code looks like we can find in the tests.<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">public class NameTest {<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> private final String
danbjson = "Dan Bergh Johnsson";<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> @Test<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> public void
shouldHaveFullNameAsAttribute() {<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> Assert.assertEquals(danbjson, new Name(danbjson)<b>.fullname</b>);<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> @Test(expected =
IllegalArgumentException.class)<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> public void
shouldNotAllowWeiredCharsInName() {<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> new
Name("#€%&/");<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> @Test<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> public void
shouldSplitIntoNamesAtSpaces() {<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> Assert.assertEquals(<br /> new String[] {"Dan", "Bergh",
"Johnsson"},<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> new Name(danbjson)<b>.names()</b>);<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> } <o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">}</span><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Imaging that we want to
change the internal data representation to using a char-array instead. Doing so
will break all the clients as they rely on having that public data-field
“fullname”. Thus, it is a bad design. Or?<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">I would argue that it
is still a good design. Using modern tools it is easy to add the encapsulation
when needed. Applying "Encapsulate Field" in e g IntelliJ yields.<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">public class Name {<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> <b>private</b> final String
fullname;<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> public Name(String
fullname) {<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">
if(!fullname.matches("[a-zA-Z\\ ]+"))<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">
throw new IllegalArgumentException();<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">
this.fullname = fullname;<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> public String[] names() {<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">
return fullname.split(" ");<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> public String fullname() {<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">
return fullname;<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">}<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">And of course the
client code has been changed accordingly.<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> @Test<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> public void
shouldHaveFullNameAsAttribute() {<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">
Assert.assertEquals(danbjson, new Name(danbjson).<b>fullname()</b>);<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Now, I could have
chosen "getFullname" as the method name for the new method. However,
I have always found that naming convention a little bit awkward, the property
is “full name” and adding a boilerplate “get” does not add any value in my
opinion. By the way, JavaBeans is just one naming convention in Java, the
naming convention for CORBA predates JavaBeans. In the CORBA convention if you
have a property “fullname” of type String, then the way to access it was to
call a method “String fullname()” and the way to change the property was to
call a method “void fullname(String)”.
So the convention I use is not new to Java at all.<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">In some languages there
is no distinction in syntax between accessing a field and calling a no-arg
method. Had the code been written in Eiffel or Scala, the syntax would have
been the same and there would be no change to the client code at all.<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Now that we have
encapsulated the usage via “fullname()” we can change the internal
representation to a char array.<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">public class Name {<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> private final <b>char[] chars</b>;<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> public Name(String name) {<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">
if(!name.matches("[a-zA-Z\\ ]+"))<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> throw new
IllegalArgumentException();<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">
this.<b>chars</b> = <b>name.toCharArray()</b>;<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> public String[] names() {<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">
return new String(<b>chars</b>).split(" ");<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> public String fullname() {<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">
return new String(<b>chars</b>);<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> }<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">}</span><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Just for reference, in
Scala the corresponding change would start with this "final public"
representation – here represented by the keyword “val”. <o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">class Name(<b>val</b>
<b>fullname</b>: String)<o:p></o:p></span></span></div>
<div class="MsoNormal">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">{<o:p></o:p></span></span></div>
<div class="MsoNormal">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><span lang="EN-GB"> if(!fullname.matches("[a-zA-Z\\
]+"))</span> throw new IllegalArgumentException();</span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> def <b>names</b> = fullname.split(' ')<o:p></o:p></span></span></div>
<div class="MsoNormal">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">}</span><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">The change would take
us to the slightly more verbose char array representation. Here we have no
“val” in external class declaration, but a private val-field hidden inside the class-block
instead.<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">class Name(name:
String)<o:p></o:p></span></span></div>
<div class="MsoNormal">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">{<o:p></o:p></span></span></div>
<div class="MsoNormal">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> if(!name.matches("[a-zA-Z\\
]+")) throw new IllegalArgumentException();<o:p></o:p></span></span></div>
<div class="MsoNormal">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> <b>private val chars</b> = name.toCharArray<o:p></o:p></span></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> def fullname = chars.toString<o:p></o:p></span></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> def names = fullname.split(' ')<o:p></o:p></span></span></div>
<div class="MsoNormal">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">}</span><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"><o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">In conclusion: As the
public final field is accessible by the clients, it is also a part of the API
for Name: This breaks data encapsulation. If you want to change data
representation, you will need to create an accessor method to which you direct
the client.<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">In Scala or Eiffel this
is a no-issue, as the new accessor could transparently have the same name as
the old datafield ("fullname") and be accessed with exactly the same
syntax ("name.fullname"). However, in Java you have to include an
empty pair of parenthesis to call the accessor method - thus the client code
must be changed.<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Now, I consider this a
small issue, as there is excellent refactoring support in modern IDEs that eliminate
the change to a fully automated four-click, one-minute exercise. Thus, there is
no point in designing for that change up front.<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">So, even if we *do*
break data encapsulation, I would say that it is not much of a problem. <o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Now, there are other
kinds of encapsulations that are more interesting than data encapsulation, but
that analysis will have to wait for some other letter.<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;">Yours<o:p></o:p></span></span></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<br /></div>
<div class="MsoNormal" style="mso-layout-grid-align: none; mso-pagination: none; tab-stops: 28.3pt 56.65pt 85.0pt 113.35pt 141.7pt 170.05pt 198.4pt 226.75pt 255.1pt 283.45pt 311.8pt 340.15pt; text-align: justify; text-autospace: none;">
<span lang="EN-GB"><span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', serif;"> Dan</span></span><span lang="EN-GB" style="font-family: Georgia;"><o:p></o:p></span></div>
Anonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.comtag:blogger.com,1999:blog-7928985878402740088.post-62215285878441910352011-09-12T16:26:00.000+02:002014-11-14T00:19:24.254+01:00Public final is also Immutable, AgainDear Junior<br />
<br />
I must apologise as in my last letter I mixed two separate discussions into one: one about immutability, and one about encapsulations. What I was after was immutability, even though encapsulation is also interesting.<br />
<br />
To make thinks clear, let us return to the Name class for representing value objects for a name e g "Dan Bergh Johnsson". To focus on immutability, let us simplify it.
<br />
<br />
<pre>public class Name {
public final String fullname;
public Name(String fullname) {
this.fullname = fullname;
}
}
</pre>
<br />
Now, if I create an object of this class, then no client can mutate the state of that object. This is because<br />
<br />
<ol>
<li>The datafield is final so the client cannot make the reference point to some other String </li>
<li>Strings are immutable, so the referred object cannot be changed </li>
</ol>
<br />
Just for reference. I mentioned that Scala has a very elegant way of defining "public immutable datafield properties". The corresponding Scala class would be a one-liner.
<br />
<br />
<pre>class Name(val fullname: String)</pre>
<br />
Elegant, isn't it? "Name is a class with the attribute value 'fullname' of type String". Scala promotes the use of immutable constructs by making it simple to declare them.<br />
<br />
Now, as my friend Tommy Malmström pointed out to me, I should also make my class final. This is a very valid and interesting point, so let me dig into.<br />
<br />
The problem in this case is not the objects we construct ourselves, but objects that are sent to us. We should rightfully assume that such objects are also immutable.
However, someone could wittingly and deviously create a mutable subclass of Name.<br />
<br />
Back in Java land such a subclass could for example overrride toString
<br />
<pre></pre>
<pre>package names;
class EvilName extends Name {
public EvilName(String fullname) {
super(fullname);
}
public String toString() {
return "Voldemort";
}
public static void main(String[] args) {
Name name = new EvilName("Harry Potter");
System.out.println(name);
System.out.println(name.fullname);
}
}
danbj$ java names.EvilName
Voldemort
Harry Potter
</pre>
<br />
You see how confusing it could be when toString is used to render the name object "Harry Potter".<br />
<br />
So, forbidding such overrides by declaring the Name class as final is really a good idea.<br />
<br />
On a side note, this is the reason why String is declared final. The String class is for example used to represent class and package information when loading code dynamically over the network - so imagine the consequences had it been possible to make a mutable phoney String.<br />
<br />
Well, that was about immutability.<br />
<br />
On the issue of encapsulation it can be argued whether "public final String fullname" breaks encapsulation or not - and that discussion also depends on what encapsulation we mean. Any way, that is a separate discussion.<br />
<br />
Yours<br />
<br />
DanAnonymoushttp://www.blogger.com/profile/07991087192133138300noreply@blogger.com