tech talk

Gregor Hohpe: All right, well, thanks everybody for coming bright and early. It’s 9 o’clock in Las Vegas and I actually have to get up even earlier, because I have to finish my talk for today. But at least, we’d like to look at this from the positive perspective. This is a brand new material that you have not seen anywhere else and I can be very assured that that’s true. Actually, while I was finishing my presentation, I was thinking a little bit about sort of how we rank talks, right. You guys get the little handout sheets, right speaker evaluation, so please fill this out, but I was actually thinking about my own sort of version of evaluating a talk and I started to think about the different talks I’ve seen and sort of how I feel, how the speaker actually prepared sort of, you know, what they thought they could get away with and what I realized is sort of the clever, but the lowest bar is you actually don't have a talk, you hold a panel, all right? I think, we’ve seen some instances of that, so if you have no slides at all, you just like, you know, make a panel. I think then there is so like the next step where you have some slides, but you weren’t actually able to reorder them in the right order and then you give like a top 10 talk. It is like, you just have 10 ideas and you make sort of this top 10 talk, and there is like another variation is and -- I fall sometimes into that category. You don’t have a lot of say to say, you just quote a lot of other people. So, you know, you’re just like, this guy says this; this guy says this.

So you guys can see how I did today. I’m sort of evaluating my own presentation here. I think I have a fair number of quotes, but I don’t have a panel and it’s not top 10. So I feel we’re moving up, it’s going to get better. So I hope you enjoy the next 50 minutes with me. I have a topic of “Where did all my beautiful code go” and it was sort of like a little brain bubble I had one day when I was working in our company and sort of looking at some stuff and said, well, really where did it go, so let’s see. Almost everybody has this, you know, in their little hiring statements, right. We hire only the brightest engineers in the industry, like which company would put on their charter, we hire only the dumbest engineers, right and actually Hani, most of you guys know Hani in the BileBlog. He had like a very interesting analysis once and I forgot the exact chain of reasoning, but knowing that it’s the BileBlog you probably have to have a few drinks before you really follow the chain of reasoning, but he had like a logic because I used to work for a company that made a very big statement about ‘we only hire the brightest’ and he had like a little chain of logic that actually invalidated or basically claimed that it’s really impossible, because if everybody only hires the brightest people, well, where do the other people go and so on and so forth.

So, given that, you know, and of course I work for Google now, and so of course Google also hires only the brightest engineers in the industry just like anybody else, but when I look through our code base, I find sometimes funny things and, of course, I couldn’t show any real code, so I decided to clip out just some comments and actually kind of reload those, but they are pretty close to what I’ve actually seen in our code base here and I hope this is -- yeah this should be readable. Actually, one thing I noticed yesterday is the projectors were a little blurry. So I was wondering what’s really going on there, and then last night I actually found out what’s going on. They used the good projectors for the shadow bar downstairs. Apparently, they are a lot crisper than the ones we got up here. So – or they use them at night, so they are way out I don’t know, but at least the pictures in the shadow bar were somehow sharper than what we got here. So go figure, I think it’s a Las Vegas conference, right. So anyway -- so I tried to steal my way here past legal by essentially just now, taking comments out, but this is probably not unusual for you to see in a code base, all right. So comments like, oh! You know, this is wrong, this is bad or somebody says, oh! This is wrong, it should be this way and the next person says, well, I don’t think that’s quite right, it might be another way and then of course the code that follows, you can only imagine, right there is probably some thing else, or the second example is one of my favorite. It’s close to real life. I’ve worked on this quite a bit. Well, there is a method, which says get me the only account, but then the comment actually says if there is more than one, it gets the oldest one. I said, okay, if there is only one, why are you getting the oldest one, right. Is it maybe get oldest account, is it get only account, right; is there one or are there multiple and then somebody says later on, it says, well, we really want to fix this a little bit, so it better deals with multiple accounts. So it’s like okay -- so it’s multiple – no its only, but it is the oldest, but we want to make multiple and it’s like which one is it now, right? Do we have one account, do we have multiple accounts and what is it and all this was written, of course, by you know, the brightest engineers in the industry and so the story goes.


Now, of course, this is sort of our usual problem solution commercial here, what can we do and, you know, the short answer is, well there is no lack of tools and techniques, right. I mean it’s not that we couldn’t express what we want to do in any of different ways that we choose, right. I mean we got, you know, nice object oriented technologies and more recently we got the whole, ROOS engine and BPEL workflow engines, we got aspects, right crosscutting concerns, code, listen to Rod Johnson, you know, etc., etc. Dependency injections, spring, lightweight containers, I mean, you name it. I mean it’s like we have very few excuses that we just couldn’t get it the right way, right. There are plenty, plenty, plenty of tools that led us get it the right way. So where is the problem, and sort of my little, slightly facetious answer is actually that nobody actually goes and writes the bad code, right. I mean, nobody sits down when especially since we only hire the brightest engineers. Nobody sits down and says actually, yeah, you know, I don’t really care, you know, it’s just like, you know, whatever. You know, I’m just going to write some crappy code and you know check this in. It’s like no, it’s sort of people usually have good intentions, people usually are fairly smart and have a lot of tools available, but somehow the bad code, you know, just appears and I would go and joke actually at Google with sometimes is “maybe at night the janitor comes in and rewrites it.” It is like who wrote this, right? Its maybe somebody came in and just sort of -- or worse yet, maybe the manager came in at night and rewrote it, right. That would probably be actually worse and we’re like yeah, it’s like who wrote this, you know, and so we had a lot of stories, you know, around how this actually happens.


So what I wanted to do is and I didn’t do a top 10, so I’m rating myself above the other top 10 top, but I have a list of sort of six recommendations, which I think is a sort of little story that helps a little bit, obviously 50 minutes is not enough to, you know, sort of solve all problems of ugly unreadable code that’s ever been written in the world, but I think it has a little bit to do about sort of how this comes about and how we can do a little bit better and as most key notes it’s a little bit more, I would say, more questions than answers in some sense. It was actually kind of funny, because Kelly just came up and says, do you have time for questions and answers? I said, well you know, usually I just talk enough you know that at the end I don’t have much time, but actually I can do a little Q&A by actually me asking the questions. So, I can turn this around a little bit. Yeah, cleverly I changed the last slide on questions to thank you, so people don’t actually expect, but we’ll see. I hope I’ve a little bit of time left at the end to actually answer some questions, because I think it’s a topic that’s really worthy of some discussion.


So, I’ve the word model here quite a lot and it’s not anything about, you know, MDA or so, but I think models are something quite useful -- it’s very close to the work I’m doing right now. So my little sort of recipe here, recipe might even be a strong statement, but a little bit of guidance here is that really sort of pay attention that you understand your model, really understand what you are trying to do and make a model that reflects well, what you are trying to do and your model doesn’t mean Rational Rolls or, you know, case tool of your vendor’s choice, we will see model can be sort of many things. I think actually Scott Embley yesterday talked about some napkin models and sketch models and whiteboard models, right. He talked about sort of, how many people like to draw on the whiteboard and a lot of people put their hands up. So, yeah, a model can be many things. So once you really thought about sort of your domain and sort of what kind of models you use, then you need to implement this, right and there is sort of like a very conscious step, especially today’s world. You've a lot of choices about what kind of language you want to map this to. I mean, obviously this is the Java Symposium, but nevertheless, I mean, if I look sort of around at the talks, there are a fair number of different programming models like right after this one of the talk is OS workflow.


You know, there is a Java component to it, but the core that it’s a very work-flowish thing, it’s not a very object oriented thing. So even it being -- sort of Java being your core language, you still have a lot of choices. So I want to talk a little bit about sort of how you do that and what the tradeoffs are. Then, once you have chosen the right language to sort of represent your domain and your model in, you really got to take advantage of the richness of the language, you know, show some nice examples for that and then of course one of the biggest dangers is let’s say you really created this beautiful code, how would you protect it right, how do you keep your manager from coming in at a night and sort of turning this into an ugly code. And then last but not least, this is sort of like, you know, the closing topic that really I think is very important we start thinking more about programming for ourselves, for human beings rather than the machine. The machine doesn’t care all that much. We tend to care a lot more.


So let’s start. I’ll take a little sample domain and don’t worry about understanding all this. This is sort of like your typical requirements document if you’re lucky and imagine a lot of like dot, dot, dot at the bottom. So this is a typical thing, almost every business application has something like this, you know, a manager can manage somebody else, right. It’s like sort of a little hierarchy being built and there are all sorts of business rules, right. So a manager can't just like go and manage somebody. They have to ask first whether, you now, they are allowed to manage this person, wouldn’t this be nice in real life, right the manager has to say “ooh, can I manage you, and he said, uhmm, let me think about that”, but in this domain, this domain it’s kept the way it is, because you manage other people’s accounts, right. So they need to kind of give you access to their account. So you have to make a request first, then the person can either accept or reject. Meanwhile, the manager can actually also rescind his request and say, “uuhm, I don’t want to manage him anymore” or there is also time-outs and then, you know, just like the usual business logic goes “so far, so good,” right, like you know, one person can manage another. Of course, there is different types, you can manage other people for full access or partial access, so little security thing in there and it turns out one person can be managed by two different managers, one is for full access and one is for -- and so on and so on and the hierarchy can only be three levels deep and so on and so on and so on. It’s like dot, dot, dot, dot, dot, dot, dot, dot, dot. I’m pretty sure this is not, you know, terribly, terribly different from sort of requirements many guys have gotten luckily. I mean, if it’s a nice bullet point forum is I think often already a step ahead.


So now you’ve got to start thinking about on my first part was sort of understand the domain and choose your model. So there is many, many different ways to look at these requirements and sort of, you know, you probably don’t have all these bullet points in your head, but you kind of get the general idea of this is something to do with people managing other people. So this is some by far not complete, but you know, just to illustrate that when you look at these requirements, there are so many different ways of looking at them right. Somebody might make a UI mock up, somebody might think more about sort of the process aspect, like sort of what happens over time and somebody might think about class diagrams or structural models, and I actually, you know, mocked up a little bit of a few examples of this and this is sort of loosely based. I took some screen clips from our advertising. I work out Google’s ad words, the advertising applications. So I just took some screen clips here, where essentially, you know, the UI version is somewhere the manager makes the request right, and then somehow the manager can see that there is actually a pending request right, the other person hasn’t answered yet, then the other person sort of accepts or rejects. In this case, I said accept and then sort of the manager gets a confirmation and, you know, the person accepted or rejected you see, don’t worry about the text, you know, you see a little green override box there.


They're very useful, very expressive sort of from a user perspective, you know, this is what we want to build, this is a web app obviously, so people very close to, you know, -- what they want it to look like, right. When a project manager comes or something, you know, this is what we like it to look like. However, it gets a little bit tougher when you start talking about what all, sort of you see in the very top left one where it says make a request, there’s a little red box indicating an error and what all kind of errors can happen in this kind of domain are not as easily expressed in, you know, a user interface model all right. Its like you would have to draw a lot of these things. You want to like choose a slightly different model. So, I have two other models here that I present and again these are just simple examples. So one thing I mocked up here specifically, is a state diagram right, and this is, you know, you could even -- this is probably not UML compliant because my things are oval I think, but anyway it doesn’t really matter. It matters that you sort of make a picture that distills or drills in on one specific aspect of the problem you are trying to solve, right. It’s like you really want to slice and dice, too often, which we see things where, you know, we have a user interface model and then we make 25 sort of screen mockups for all different scenarios that can happen. It’s like “no”, you want to make the user interface model for what’s visual and you want to find a model that's actually appropriate of the domain you’re dealing with.


So, in this case, you know, we felt a state diagram as simple as it is, it’s very expressive right like an invitation or request. It can be pending. It can be accepted or rejected. It can be expired. It was at the bottom of the list, things expire after 30 days and then we have this inactive, which is if the manager resends the invitation or after an advertise or an advertiser has actually accepted an invitation to be managed, later on they say no, you know, I don't want to be managed by this person anymore. So you can have a very simple state diagram and I think the key thing is, you know, not like the specific diagram I came up with, but the key thing is that as long as you pick the right perspective on your domain, you can usually come up with something relatively simple and relatively expressive. You focus on one specific aspect and you only represent that aspect and it’s sort of very free of the clutter. Here is another way of looking at this, you know, and this is not a UML diagram. This is something I just sort of came up with because we're talking about people managing other people. So M is the manager and A is an advertiser. I just drew out some scenarios that are valid or not valid, right. We were saying the user interface is kind of like a bad way to talk about all the different cases and things like that. So, here is the much better way to express, okay, so a manager, you know, at the top left, the manager managing an advertiser. Yeah, of course, you can do that right and we're not worrying about the state here anymore right. If you notice like this whole accept and rejecting is kind of gone away. We only focus on structure now.


So and if you look at the bottom left, manager can manage another manager advertiser; those are all good. In the middle, there are some more maybe unexpected cases, but it is actually valid that one advertiser can be managed by two managers, you know, you can have one for full access and one for partial access versus the one on the right-hand side, where you make, you know, manager 1, manager 2 or 3, and 4, that is not valid because there was a requirement in there, that’s sad. You know, you can only build three levels deep, and you can’t build four levels deep. So, again we pick like a very, very simple representation just poking on a specific aspect, but then at the same time, this long list of requirements actually becomes relatively simple in a sense. I mean, it’s easy to draw out many of the scenarios here that highlight what can and cannot be done and actually this helped us. We did something very similar in real life. This helped us find odd corner cases, for example, let me see what I can play with the mouse here. For example, what is not allowed is that one manager manages two other managers, which in turn manage one advertiser, right. You can't build diamonds in a sense because it’s like the multiple inheritance kind of problem, right it’s like one manager manages two other managers and then they manage the same advertiser once for full and once for partial access, it’s not clear sort of which path you should follow.


So having these simple pictures, the answer where we say sort of models don’t have to be overly formal, they just look kind of clean here because I put them in power point, but this all started out as sketches, very quickly give you a good feel sort of what the corner cases are, because you really sort of map the domain onto one very specific viewpoint and then I think that’s very, very key because a lot of business domains are very complex and they’re also full off what Martin Fowler usually calls, like the business illogic right. There’s the business logic, if it was really that logical, it wouldn’t be that hard to build systems that address it. So just zoning in -- sort of zooming in on one specific perspective and then just sort of making a simple model for that can be very, very powerful.

Now, of course, the next question is let’s say, you made your different models, like in my case here was a state model and this little sort of heirarchy model. The question comes, what is the best way to implement something like this, and sort of I took the little state transition model here. So you have these, you know, it’s the same states as before. You know, it’s like sort of pending, accepted, rejected etc., very simple state diagram. The question now comes, what’s the best implementation map? So we like this model, it is very easy, very clean. We got this on the white board. It all looks good. We’re happy we only focus on this one aspect of it, but now the question is implementation. So, the usual choices are just listed. Some sort of typical choices here is, yeah, I can write this in Java code. Yeah, of course, you know it’s like why not. I can use something. No, no, I think I’m making too much advertising here for Hani actually. I have OS workflow here again, which I think he is talking about right next or BPEL, the Business Process Execution Language. So the mini sidebar, it’s always funny when I always have to sort of, you know, get a little laugh when I look at BPEL because, so people can’t even quite agree on how to say it, right, some people say “BPEL” and other people say “Bepel” and I always say it’s like, wow, you know, if you guys can’t even agree on how to say it, it’s amazing you guys actually ever came up with the standard, right. How did you manage to agree on all these other things? It strikes me as I think it gives you little insight on how painful these standards can actually be, it’s sort of get an agreement because everybody has their own little version. So mine is BPEL and you guys probably see around, it’s all SOA area, it’s a language that, you know, is custom made to express process flow.



Since I have a process flow, the other question is not totally unreasonable saying, “uuhm you know, should I use something like that?” Well, let’s see what something like this could look like and I don’t want to dwell on the -- this is not a BPEL or OS workflow talk, but I just want to show some examples. So let’s say we want to make a flow and our model that we looked at -- our model of the domain, the one slice we made is actually a flow, where it is sort of like a flow of tasks or workflow you might call it. So here is a mapping and this is really, I think Hani really owns me because this is once again sort of taken out of OS workflow a little bit simplified, but OS workflow essentially is a relatively straightforward mapping. So you have these steps, so there is a pending step, there is a reject step -- so there’s a pending, an accepted, and a rejected step. I sort of condensed this down a little bit to get the font bigger and there are some actions, right. You see, so there’s like action one, which is actually accept and it moves from pending to accepted and there’s another action here, which is reject and it moves from pending to rejected. So, now, no big magic here, it’s like every body goes kind of like duh, but well that’s kind of the point, right. I mean, the point is that for somebody who has seen the picture and look at this, of course, you know, there is a lot of debates about, sort of angle bracket languages and I’m not a huge fan of programming and sort of, you know, angle brackets either, but the good thing is like if you look at the picture that we have before and look at this, you know, admitting that this is only a subset just because I clipped it off, the mapping is pretty good, right. It is a pretty good transition from the model into the programming environment like, we feel like there is a good match. Now, doing this in a flow language or in BPEL and yeah there is a bit more syntax clutter, but ultimately, you know, you could draw a picture, you know, there are visual editors. It looks almost exactly like the little model that you drew on the whiteboard.


Now, the one danger is, of course here like using these customized languages is, they are very nicely expressive or they can be very nicely expressive, but they’re very different languages than an all-purpose language, you know, like Java. So there is interfacing cost and there are interfacing costs sort of along two dimensions, right. There is an interfacing cost for the human beings, because you know, you have to learn this and sort of really understand the nuances, get used to the syntax. It’s never as easy as the little Power Point examples that come up in these presentations, right. It’s like you’re going to have real problems of your concurrent steps and synchronizations, right. It’s almost like making stuff really work it’s always much harder. My popular code is always, you know, Power Point always compiles, right, it’s like this stuff is always good. So once you take this into the real word, it’s a little bit tougher. So that’s sort of like the whole mental shift here and actually I think my talk tomorrow about the SOA patterns talks a little bit about all these different programming styles and sort of the goods and bads, but there is also like a technical transition cost, right. I mean, BPEL usually runs in a separate engine, so you know when you do something, you have to talk to the engine, there is a little bit of overhead, etc. There are more libraries here to be linked in, etc.


So, you need to think a little bit carefully about sort of when is what I want to do big enough to actually warrant this. You know, when is it complex enough that I want to use my own language to represent this more closely. So, let’s say you’re still somewhat skeptical and say, yeah this is really nifty, I can see how this model thing represents very quickly but I’m like -- you know, I don’t know I want to install all the stuff and learn BPEL and buy licenses or OS workflow and all this kind of stuff. So another option, of course, is to stay in your main language, right. Just stay in your Java programming language, which is object oriented, right. It’s not per se a language made for flow models, for workflow models, but since its general purpose, you know, one of the purposes might well be making a flow model. I think, it’s quite interesting to see that people start to do this a little bit more and I was very, very clever with the title here, because this is actually C#, but nobody really noticed this. Let me see if there’s anything in here, all they have the funky naming conventions, as this may be the only thing they would give it away, but yeah add this upper case A, but otherwise there is actually no difference and this is actually stolen or borrowed straight from the Microsoft Workflow Foundation. It’s like the dark side -- I’m not so picky with the sources where I borrow from, borrowing is always good if it helps the cause.


So what they’ve done here, this is something called Workflow Foundation and I’m sure there might be something similar in the Java world, but what they’re doing is, they’re really composing a flow in an object-oriented way. So if you look at this code, it’s not terribly object oriented. I mean there is a news statement in there. So there are obviously some instances being made and you can sort of receive request and process request and send confirmation. There are also activities that happen instantiated somewhere, but they actually use a declarative model. They are not building -- there is not much sort of like the OOS, it doesn’t in the foreground, right. They are not building a class hierarchy. They’re not building decorators, right, to change these things together like all the language that we have sort of in the OO world that you could apply to this, they’re actually not using. Basically, what they’re doing is, they’re using the language sort of as a harness to wire something together, which is actually a flow.


So in this specific case, they have a nice sort of -- the example uses a slightly different vocabulary here, but they wire together a sequence, so there is a sequence activity and they put three steps into the sequence. You know, it’s like receive request, process request, and send confirmation. It’s all like the, you know, the prototypical linear workflow and once again, this can get more complicated, but it’s kind of interesting to see and then ultimately they would say, create a new workflow of the sequence activity and they would say run this workflow or either, which is like go, execute this thing. It’s almost like you are writing a program in your code, right. You are like essentially you are programming a workflow engine here in object-oriented code and that is kind of interesting. You know, it’s kind of like, “uuhm” you know. This sort of again translates relatively closely and I didn’t have time so I should have rewritten to really use our little manager client domain, but if you think about sort of implementing this or looking at sort of a correct implementation about this, you know, so rejecting, accepting, you know, pending, etc. Looking at this code could make it relatively easy to see sort of what the connections are. You can see, ah! I make a connection from here to here, but I wrap this into an OO language. So, I think it’s kind of interesting to see the choices and also what I really wanted to highlight is that picking the model and picking the language are somewhat -- I mean, obviously connected, but somewhat independent choices, right. You could make a proper object model for all this, you know, state pattern and all the kind of stuff or you can choose to stay closer to a flow model, but use an OO language or you can choose the flow model and actually go with a flow language.


So, you have a lot of choices actually here. And as always, there is no like sort of, you know, hard and fast answer for what’s best, but you know, sort of just a few things you can think about. So, the one thing as I already mentioned a little bit, the switching cost and think about both sort of intellectual switching cost as well as a runtime technical switching cost. People are working on this to actually reduce the switching cost and I don’t know, I haven’t looked at the program yet whether there is actually a talk on --is anyone else going to talk about domain specific languages and things here? Probably, there should be -- I didn’t see anything yet. But I haven’t looked quite to the whole thing yet. I was working in my presentation. But, the idea is that a lot of the language workbenches. There is a nice article actually on Martin Fowler’s website on language workbenches. The idea is to make it much easier to create your own languages, so you can make a language for your specific purpose. And, I think, actually he sort of like coined the term. I mean Martin Fowler is kind of like the king of, you know, taking stuff that other people have done and then he puts his own name on it and everybody somehow feels it’s a lot better, but somehow it is. It’s kind of strange, you know, it’s like suddenly he has a new name.


So, he coined the language workbenches, but those are the things that make it easy for you to have multiple languages, little domain languages, but you can still sort of debug through, for example. You know, they map on to a common runtime, right. So, even though I use a little language, which, you know, might be a little workflow language from my workflow aspect, but I might use Java code for the UI, etc. They integrate very well. They integrate to the extent that I can, you know, search across, I can edit source code across, I can, you know, debug through, etc., which is pretty appealing. But unfortunately, most of them I don’t think is sort, sort of ready -- ready for prime time yet, but it’s definitely coming. And, the main driver there is really the main driver once again and so expressiveness of code right, like being able to have a language that more closely maps the way you like to think about your domain, the model you have chosen and you can choose from the portfolio of languages that are out there, but basically the language workbenches say, why don’t you make your own, right? So, make your own language. So you get a language that’s very targeted just to your domain. So rather than even like – if I was going to make my own language here rather than using sort of the angle bracket step equals, you know, pending or accepted or rejected, I could make actual live key words. So that I could have, you know, accepted, rejected, and I can, you know, so make a little language recess, you know. If you go from pending and you do the accept activity, you go to accept and I could actually write that as executive recall. It would be very nifty, but I think we have to wait a little bit for those tools to get a bit more matured.


The other thing to be very careful about and that’s again where the language workbenches are trying to help is don’t underestimate how many tools you actually have for your general-purpose language. It’s like, you know, refactoring editors, you know, control+n and IntelliJ kind of thing, you know, easy navigation, clicking on a class and going to the definition, you know, as a control+shift+F7 when, you know, whatever you have and all the little shortcuts, step-by-step debuggers, conditional breakpoints, nice version integration right, diffing against last version, diffing any versions. As soon as you go out, you know, sort of general-purpose languages, you can possibly take a pretty big hit there. So once again, that’s an argument to think about is, maybe I can do something that uses my more expressive model, but are still rapid within my regular OO language right because the main advantage I gain through that is that I can still use all the tools that I’m used to and I can refactor it, etc., like the code we saw on the previous slide where I put, you know, these activities together and I sort of say basically sequence activity and add these three things into the sequence. If I want to rename a variable, of course, I can do that. It’s sort of like shift+F6 kind of thing, because it’s, you know, well this one is C# code, but anyway essentially it’s code that I can use, you know, all my little refactoring tools, etc., which is a huge advantage because if you think about it, you know, the beauty of the code is not just picking in the right model, the beauty of the code is also as things evolve as new requirements come in, you want to be able to restructure your code and I would say actually from my experience, I have worked in fair amount with sort of these business process, models, etc., is they are often very, very good at creating a model straight out. I mean you can almost create a program. You’ll take it like this, Oracle BPEL, Microsoft Vista, you know, there is a lot of these little BPEL process editing engines. You could essentially draw your program and it’ll look almost exactly like the activity chart we have. It’s like it doesn’t get any better, right. It’s like one-to-one my program, my visual little thing looks like just my specification. It’s like wow, right. I can show this to the business user. Do I have everything; it’s very, very close. Where they often stumble still unfortunately is if you need something that’s very integrant, right.


We don’t live, you know, we don’t live in a static world, you know Scott Embley gave a talk and actually Clinton also gave a talk yesterday about agile, you know, obviously everybody knows, everybody responds to business requirements and that’s where unfortunately these custom languages and the custom tools don’t do as well yet. So, you might start out with something beautiful, but it tends to degrade a lot quicker, because you don’t have, for example, refactoring tools. But, if my Java code, you know, has to respond to change in requirements and I want to break a method into two methods, very easy, so I highlight control out MX strike method, right. I give it a nice name, very, very quick. I can sort of maintain the expressiveness of my code, as it sort of gets stretched on the new requirements, right. As you make a certain code structure and it fits well with what you have, but as it changes, you know, the code has to adjust a little bit. That is still much, much harder with these tools that tend to be sort of much more closer to the model, unfortunately. So, you might be lucky that you are able to create your own language that is so simple that you don’t really need the refactoring tools like -- we played around for test cases. We made little domain specific language right, and the language is really, you know, create manager Mary, create advertiser Bob, Mary invites Bob, Bob accepts, you know, who is the manager of Bob, the answer expect is Mary. I mean, really this is like sort of executable code and it varies say, you know, maybe this is close enough to the domain that even as things change, I can copy and paste instead of refactoring, but I just want to warn people that a lot of these tools, especially sort of the process tools are very, very good at creating an initial model, but there are not as malleable. They’re not as easy to change. There is no diffing, for example as well either. So, it’s a very important decision.


The next thing to me is now, let’s say you’ve chosen a language. In this case, I assume we have chosen Java and I focus on a very specific aspect really, really take advantage of the expressiveness this language gives you, right. It’s like -- that’s I think the number one problem and I borrowed this example actually slightly from Eric Evans’ book, which some of you might have seen, I have it on the next slide, where -- looked at it a very specific requirement, right. We have here – so the invitations expire in 30 days and to make it a little bit more interesting, I said, it’ll expire in 30 days from the end of the month where they are actually extended. So if on sort of April 20th, I made an invitation, it will expire like May 30th. Right, sort of 30 days from the end of the month. And, I didn’t even get the whole code example down here and I don’t know it’s kind of easy to pick on, you know, calendar. So, it’s always like the proverbial bad example, but you know, I didn’t want to stray too far from the beaten path. So, I’m going to beat calendar here as well. Mapping that requirement implementation of calendar is actually kind of strange. So, you have the whole proverbial months start with 0 and you have to set an hour and minute and second even though we don’t really care about hours and minutes and seconds, right. The requirement only talks about days, right. It talks about days, months and ends in invitations, right. It’s the only vocabulary that’s in there. I don’t want to talk anything about like time zones and hours and minutes and seconds and arithmetic operations like -- like -- like minus one, etc. So, a better way to do this and this is actually -- Eric Evans has a time and money library and they should jot a time, it is similarly nice. It’s not quite as expressive in this specific case. What does his, you know, time and money library does is what I call March is not a number, right? March is not the number 3. When I get a month, I shouldn’t get a 3. Right, like we’ve chosen now -- we have chosen an object-oriented language, right? So, that was one of the conscious decisions we made to map our little domain model view on to an object-oriented language. Well by all means, let’s use object-oriented construct. So, if I had mapped this under something else, I would do something else. So, since I mapped this on a nice OO -- expressive OO language, I can now use all these mechanics to verify and nicely express nuances. So, for example, in this class with a calendar date if I want to implement my logic, I can compute the expiration date for the invitation by -- by looking at the completion -- by looking at the – I guess I should have said invited, actually the invitation time and from the invitation time, I can do dot month and according to my rule, month is not a number. This month is actually a period of time, right?


The month of March is, you know, from March 1st through the March 31st is a span of time. It doesn’t care about time zones and hours and minutes much. Its -- it’s -- it’s an interval, it’s a sequence of days and since it’s a sequence of days, I can also look at the last date and again, I don’t worry about hours. I am not saying it’s like this date ends in like, you know, 12 a.m. and then you start already a.m., p.m., 24-hour clock and all that kind of thing. Which time zone, right, I don’t really care. I just say this is the month of March and everybody around the world has their right notion of month of March and I could say the end of March is March 31st, which is a day and not a point in time, but it’s a whole day as well and then I can say I add to that my 30 days. So, when the invitation was extended, I compute which month it’s in. I go to the end of the month and I add 30 days and to me a very simple example, and as I said, I borrowed this from Eric Evans. So I’ll put this little -- it’s called Domain-Driven Design for those of you who haven’t -- haven’t seen the book yet. It’s kind of a -- it’s kind of a dense read. It’s very, very subtle, but has -- has a lot of very important points. So, here for example, if we think about what was on the last slide is my domain didn’t talk about time zones, minutes, seconds, subtracting for month, etc., but my domain language, the little expressiveness I use, you know, it talked about, you know, months and dates and ends of months and if you look at this code, particularly the last line, this code exactly states what that did, right? It’s like the month’s end plus a certain time and I think that is very nice. I think we often times very much under utilize sort of the actual expressiveness of our -- of our language in this sense. I think this serves as a good example to show you can do -- you can do a lot better. It’s not just because calendar is bad. It’s because you need to really think about how the vocabulary that you use to describe your model, how that vocabulary can find itself back into your language. One sort of rule that I use and actually I have to sort of use this more often than I would like is when we talk about our code if you go through our code, every time somebody says, you know, Foo and they say “oh yeah, yeah, that’s right”. Foo is really barred, all right. How many times does this happen? But they say, oh it’s just account, but say, oh, account is really the manager or account is really this. Every time it says okay lets rename this thing because it’s so often, it’s almost scary, but people have to sort of translate in their head, right. They say they see something in the code, but it really means something else. So that, you know, it doesn’t really -- doesn’t really have to be. So, one of the points that I mentioned that is this is quite important.

So, let’s say you’ve done all this. You know, so you made this great expressive. You chose these like a workflow language or your object-oriented language. You really mapped the model over it. It reads nicely, has test coverage, etc., etc. Then the question is how do you keep it from degrading and I think sort of the -- the biggest problem there is actually no longer -- it’s no longer actually sort of like a technical issue. It’s like -- it’s much closer to like how do I prevent my -- my artwork I put in my city from being graffiti. It’s like, you know, people come and sort of mess with it. It’s like the same thing happens to code, right. There are natural changes, but some people just like don’t even care so much and they sort of mess up your whole code. So, it’s much more of a sort of social management issue at this point in time, like how do you write code that people are not sort of compelled to sort of mess up and I think this is one of those things as I mentioned in the beginning. There might be more questions than answers, but I think it’s worthwhile quite, you know, to think about it. One of the things is sort of -- what I have seen a lot is and I called it’s the symptom of being too smart for your own good where you use like all of the object-oriented expanders and patterns in construct that you possibly have. So you have, you know, your class hierarchies and your compositions and dependency injections and, you know, everything and everything and you say, “Wow, isn’t this great” and yeah, it’s great, you do use a lot of language constructs, but it’s not kind of like beautiful in the sense that it really represents, you know, its like people don’t feel bad with messing something with that, right. If you make a big complicated mess people like, “Oh my God, you know, this is big complicated mess. I just like sticking my method here”. Its like how much worse can it get. So there is really sort of this and this is a very subtle point about sort of making something that people can look at it and say “Oh I can -- actually somebody put some thought into this”. Right, you need to somehow write code where when the next person looks at it, there is some appreciation for what you’ve done. And again, this is probably like a fluffy topic for a developer conference, especially in Las Vegas, but it’s -- I think it’s a very important one. So how can you sort of somehow show people that you put some thought into this and this is some, you know, sort of -- it's an elegant solution. There are some more mechanical ways as well and some people call it sort of the anti-corruption layer because all of them are kind of like beautiful little piece of code, doesn’t live in complete isolation, right. It’s like who writes systems from scratch these days. It’s almost always, you know, there is some legacy system, there is something else going on.


So, what some people try to do is sort of put little bit of wall around it, sort of where you have sort of an inner core, you know, the core of your domain that’s actually where things look quite nice and then you sort of have this whole, you know, this stuff that interfaces with the rest of the world and we’ve actually quite a lot of it. We right now, we’re taking a large app and we’re trying to actually take domain objects out of existing objects. So the existing classes tend to be very large and they tend to have a lot of database dependencies and all kind of the other stuff that you don’t necessarily like, right. There’s too much clutter in there. So we’re trying to factor out domain objects, but then we have all these kind of problems, right. If you have a reference to a domain object, which is more like POJO, but ultimately you need a reference to one of those real objects because ultimately you have to get out of your beautiful world into sort of like the real ugly world. So, you make a lot of helper methods, you make little factory methods. These essentially give me a nice domain object from the ugly real world object and then you sort of have to reverse this like, you know, you have to sort of maybe upcast or do some other things just like go back from your beautiful domain world into the other. So make those things separate. You know, put those in a separate package and sort of acknowledge that this is sort of like the back and forth.

And actually one other thing that we haven’t tried as much yet, but we want to do is also put little validations. So for example if somebody adds an import into our domain logic that we don’t like and these are more mechanical things, but its only put to import in there to like a package that we don’t think is appropriate, the bill should fail, right. We should have some reasonable rules that say yeah, from this domain package you shouldn’t make for example, JDBC calls or you shouldn’t go to the whole database persistence framework that we have.


The last point is actually a very interesting one. I talked with Eric a little bit -- actually we’re giving -- just about lunchtime, we’re giving a talk together. He had an interesting example where people actually created, you know, fairly nice application and it was, you know, so typical agile style, really high test coverage, you know, sort of like really the way you would say, you build good software and then later on people came and they needed to add, as always happens, you know, they needed to add other requirements. The funny thing was in that sense since test coverage was actually that high, the people who came later didn’t actually worry that much about actually understanding all the code that was there because as long as it’s a green bar, the whole thing is working, so it’s a very funny thing. So don’t take this, as like test coverage is bad, right. I mean, test coverage is good, but its interesting to sort of have this scenario where if you have a lot of test coverage in your module sometimes people abuse the confidence that it gives them, right. So one of the themes we like to use is program with confidence not with fear, right. It’s like lot of us unfortunately, sometimes have to program in fear because its like nobody wants to touch that module. So you want to program with confidence, and a lot of ways we get that confidence is through test coverage, but then sometimes that confidence can also lead to overconfidence. So people just said, “Oh I need to like sneak this new requirement into this large code base” and they just sort of like -- I think this was also C#, so they stuck like a delegate in there, which essentially is sort of like a call back, right. They essentially sort of put like a little hook right into the middle of this beautiful thing that just sort of calls out to something else and they could do that because as long as it’s green bar, what do I care. So, unfortunately there’s no green bar on the appropriateness of your design, right. It would be nice to have like, sort of like, oh, you know, somebody graffitied my code red bar, but unfortunately, we don’t quite have that. I know there are a lot of people working on metrics, but the metrics don’t quite do this, right. You can have cyclomatic complexity, etc., but it doesn’t really sort of tell you what the code is about and whether it is sort of in the spirit of what it was meant to be. The keeping there that I can just recommend is pairing and knowledge exchange, right. Just don’t get in a situation where you wrote something and you saw it kind of like disappear and then somebody else takes it over. You always want to make sure people work together in teams and, you know, sort of exchange the knowledge about what should be and should not be done in that way, which leads me to my very last topic, and that’s very close to sort of my heart. It’s like we should really develop software for the humans and not for the machines.


This sort of sounds a little bit like Terminator 4.5 or something, but it actually has a sort of a more serious underpinning. I think too often it is -- ultimately, yes. The byte code is for the machine, right, but the source code I challenge very much is for us, right. If we didn’t care about programming for humans, you would all be still writing assembly code. The reason we don’t write assembly code is because we like to write the code for ourselves. We want to read what we’ve done and we want it to be nice and expressive and I think sometimes people underestimate that a little bit. That is a good reminder. It’s like, you know, this code sort of -- the fact that it runs correctly is sort of like the minimum bar, right. I mean obviously it has to run correctly, but I think sort of often people stop at that level. And say oh it runs green bar, it’s good enough. Its like, no you should really focus, you should think about that someone else -- chances are, somebody else will read your code. Now, you know, it might be a person in a far away country that works much cheaper and is taking your job, so maybe you don’t want to make it too easy to read, but let’s be nice, you know, generally the people that read your code, you know, trying to fix bugs, trying to make enhancements, etc. So you should really focus on making your code so that it looks good to a human and one thing we have done there and this was actually sort of like a total spur of the moment experiment. We wrote a little interface, you know, little façade into our domain layer that we created and we were going to invite one of the guys, who was going to the write the sort of the front-end to that, like the Web service layer that was going to use our nice domain model. We said, oh we should invite the guy in, you know, in the spirit of communication and stuff, invite the guy in and run him through what we’ve done, right, show him what we’ve done and see sort of what he thinks and then suddenly we thought its like hold on, actually we shouldn’t do that, right and if this was a user interface, it would have occurred to us much sooner. We shouldn’t actually explain to him what we’ve done. We should sit him down in front of our API and have him walk us through what he thinks this is. So, if this is like essentially usability testing for programming interfaces, and it was as I said sort of very much little of a spur of the moment, but it was very, very effective. I mean, so we didn’t have like the two-way mirror and all the stupid stuff, on the recorder like you do usability testing, but that doesn’t really matter. The fact that we sat the other person down and said, “okay, we made this interface for you that we think your team is going to use, here’s the package” and they had some idea generally what it was going to be about, right. They kind of new the domain.


We said, “what do you think, what do you think this thing is”. You know, it’s like they browse through and we do the usual things like usability testing, right think out loud, tell us what you think, write out things like you are, right. Its like what do you think, and he reads out the Java doc and he is like, yeah, it makes kind of sense and let me look at this class and this method is kind of odd, but I would have thought this method could be here and it’s usability testing, was enormously valuable to us. I mean we sort of then started taking notes like crazy as he was talking and he fixed out documentation. We renamed things, we reshuffled things, but I think that’s the technique that’s very, very much underused and if you keep in mind, that you’re really coding for humans and not for the machine, you should also not only test your code with the machine, getting the green bar, but you should also test your code with humans. You should test your code -- your portion with the people that are going to use your portion. We were very, very surprised how well that worked, and then you can get a little bit fancier and I have this sort of more like a dot, dot, dot here. There is a lot of talk about sort of usability and there’s a nice book called the “Design of Everyday Things” by Don Norman. This is like the coverage, you can see this at the Masochist ‘s Teapot right, like the snout is on the same side as the handle, and it talks about all the little stupid things like the doors that have the white bars, where you never know which side to push, to open, etc., etc. So I think a lot of those ideas actually apply to code quite as well and just have -- just a few references here and we’ll make this available, but a few places or a few people that I know have talked about similar areas. Kevlin Henney has a very nice talk about end paper, so essentially you can just Google for these things, yeah, hidden commercial, but you can just use your favorite search engine for these things and you’ll probably find them. So Kevlin Henney has a nice paper about effective interface design and he actually maps it to some of those usability concepts like affordances, and affordances like, imagine like a door handle. A door handle that’s a flat plate, you can only push, right. Nobody is going to try to pull on that door versus something that’s obviously like a handle people want to pull it. It’s very easy to get people hints on how to use something and that kind of thinking you could use in code as well. And then Josh Block also has a nice paper.

I am never so sure whether to trust people who work for Sun in terms of good API design or not, but we give Josh the benefit of the doubt there, you know, I hope he didn’t write the calendar interface, but he has a nice paper and then Ken Arnold, actually one of the key people on the whole Jini thing. He has a nice paper which is called “Programmers are People Too” which I kind of like. So that takes you to the end sort of of the keynote, as I promised, no, actually I have I think a minute or two. Want to leave you just sort of like with the quotes. At the beginning, I gave my little sort of metric about, you know, if you don’t have anything to say, quote somebody else and I didn’t have like a great wrap up, so I’m going to quote somebody else here and it’s a good friend or mine, Ward Cunningham is, go and write code that’s worth reading and with that, thank you very much.