ARCast.net - Presenter First Pattern (Part 1)

Announcer: It's Friday, June 1, 2007, and you're watching ARCast TV.

Ron Jacobs: Hey, welcome back to ARCast. This is your host, Ron Jacobs. Today we are having just a great time enjoying the first day of June. I can't believe it's finally here. It's summer, and the sun is shining--it's wonderful!


Hey, and one of the great things about my job as host of ARCast is, I get to go investigate things that I think are cool. Well, sometime ago I read about this pattern called the, "Presenter First" pattern. I contacted the guys who wrote this, and they work for a company called, "Atomic Object."


It was such a blast for me to get on a plane, fly out to Grand Rapids, Michigan. A lovely little town, which I'm sure is a lot better in May, than it is February. [laughs] So, we sat down and talked about--what is this Presenter First pattern? We had so much fun it went on, and on, and on. In fact, this is going to be a three part episode of ARCast TV. So sit back, and enjoy the guys from Atomic Object.


Welcome back to ARCast. This is your host Ron Jacobs. Today I'm in Grand Rapids, Michigan at the offices of Atomic Object, where I'm joined by a couple of very interesting guys who have been working on patterns, and some agile concepts, and we're proud to bring them to you today.


So Scott, and Dave, would you guys just take a minute, and introduce yourselves. I'll start with you, Scott.

Scott Miller: Sure, Scott Miller. I've been in the software development industry for about 20 years now. I moved over to Atomic two years ago, and just having a blast learning new stuff every day, putting good practices to work.

Ron: Yeah. OK, David.

David Crosby: Another software developer here, or "software craftsman"--my business card says.

Ron: [laughs]

David: But nobody else gets that card right now.

Ron: Yeah.

David: So, we'll say a developer. I graduated from local college here, Grand Valley State University in '99, and went to work for Lockheed Martin for a little while, and came here shortly thereafter. So about five and a half years on this job, and been loving it ever since. I love my job everyday.

Ron: What more could you ask, huh? Hey, that's pretty good. You know you got to love the job, and you get up looking forward to it. I have to tell you that, this looks like a very cool place to work. When I came up the stairs just looking at--it feels like a boutique kind of shop. I mean, it's got everybody out here in these common work areas.


I can tell just from looking at it, you guys are very much about kind of agile, good at practices, and team. I see people pair programming all over, you got the traffic light for your build server. I mean, it looks like a very cool feel.

David: Yeah, it's really hard to shout questions across the room, there's cubicle walls in the way.

Ron: Yeah.

David: So we got that all taken out, so that anybody can yell at anybody at any time. Without any of those barriers it's very easy to wonder around, see what other people are doing, and share ideas. Put your nose in maybe where it doesn't belong in a product you're not working on, and starting up discussions that may not have happened otherwise.


So aside from the noise factor and the distractions, the past six years everyday we find someway to appreciate the fact that it's open and clean. When we work in environments that don't have this openness, we really feel like we're losing something.

Ron: Yeah, yeah. You even have a dog wondering around with you. I totally love that. [laughs]

Scott: One of the benefits of being the owner is, you get to bring your pets to work!


[laughter]

Ron: So, tell me about Atomic Object. I mean, what is it you guys do?

Scott: Well we've been in business officially since 2001, and moved to this building a couple of years ago. Basically, we work for clients building software to their specifications using our development methodologies.


I would say that the biggest thing that we sell is, our method of doing software development. We've been able to apply that method to a very large range of product types. We do web stuff, we do embedded stuff, we do gooey stuff. You name it, and we've found a way to apply agile practices to developing it.


We've been very successful doing it. We get a lot of repeat business, I'd say probably 60% of our business is repeat business. In the last, I don't know year-- 18 months--it seems like our name recognition at least around town has really picked up. We've picked up a lot of new clients in the last couple years, too.

Ron: So in 2001 when you first started, agile was relatively new, at extreme programming I think, cause when I first heard about that concept around then.


Tell me about the journey that you guys took to kind of pick up these practices. Why, and when did you move into them?

David: My first day on the job was about three days after Atomic was called, "Atomic." The team consisted of Carl the owner, and Bill his partner, and a couple of interns who are--one is still here, the other is--might be in town today, might drop by.


They handed me the XP Explained book by Kent Beck, et al, and said, "We're doing this," so I would take it home and read it. So I took it, and read it. It's a thin book, which is nice, cause you can get through it. Said, "OK, I don't know about any of this stuff." I hadn't experienced it--it's not that I didn't believe.


They showed some grafts, I didn't believe it. I didn't understand some of the test stuff. I hadn't done test-driven development. I hadn't done any real automated testing at all at that point. We sat down, and started writing code and java--test first. I didn't know what to write.

Ron: Yeah.

David: I assumed that people around me were use to it--they had been at it four days longer than I.

Ron: [laughs] OK.

Scott: So did we all.

David: We all assumed that everybody else knew what they were doing. So we read the book, and we were trying to say, "Does any of this stuff make no sense, or does it make sense, and we should try it?" So we kind of just picked things up, and tried them all.


No cards--story cards--constantly having the customer involved. We got a customer on-sight, and working with us. Some of the other engineers were completely located the whole time for this first project. So you're always in front of them, you're always having to show them something, and speak some sort of language that makes sense to them.

Ron: Yeah.

David: I got my database set up wondering what's showing up on the screen, what makes me happy as a customer. I ask you to do something--how much of that is done?

Ron: Yeah.

David: So going through iterations, or stopping iterations, doing builds every week, and making sure that it can happen automatically. Things that took a lot of up-front time, things that I wouldn't have done given my own intuitive choice up front.


We just kind of held to them to see how they would work out. In some practices we misinterpreted, or interpreted it in a different way than was meant, or just didn't apply to the situation. We would discard, but only after trying them for a little while. One thing we never would discard, would be test-driven development.


It's still--six years later--we were pretty good at it back then, I thought. After week one, we kind of got our head around it.

Ron: [laughs]

David: But, still getting better at it today.

Ron: Yeah.

David: It's kind of one of those things I think about on the way home sometimes, after a day of work like, I spent too much time writing that test. How can I write it better?

Ron: Yeah.

David: Not what's that could I have avoided writing but how could I have done it best?


Pair program is a really important one, even when the person that you're pairing with might be slowing it down, don't know much about the problem, you have to spend too much time explaining to them, some times just saying what is this you're doing out loud can we help you understand how bad your idea really is.

Ron: That's a good one because I found that when I tried to do these agile concepts for the first time, you know you sit and you go, "Ha, OK, test driven, I am going to be test driven," and then you sit down and you go, "I don't know where to begin," or where you do start.


And so I have a couple of very good friends who I have worked with in the past Peter Proboscis is big TDD guy and works at Microsoft and he did a webcast with me where he just showed the whole thing and that was amazing to see and he taught me the old phrase "YAGNI" -- you aren't going to need it -- right, which is so amazing because how true it is.


When you come and do the traditional development, you have in mind, "Oh, we're going to need this, we're going to need that, we're going to need this," and you start writing on this stuff and when you do it the test driven way, you realize, "Hey we got the whole thing working and we didn't need that and we left that part out and we didn't do that either," and the whole thing works beautifully and clothes very clean and we would have never come up with that solution.

David: If you'd have taken a video of my first day and watched it today, it would look like a staged production of XP advocacy. "Well, I'll just add this variable Bill," not going to need that, "I'll just do it anyway, because I know I am going to need it," and then at the end of the day, I am pulling at other, wasting last half hour of my day moving one variable saying, "Gosh, Bill you were right. Our tests didn't need it so we shouldn't have put it in there."

Ron: OK, so after six years, do you ever find yourself thinking, truly everybody does this now. I mean everybody's got to have this but I find I go around the world, I speak at lot of conferences, I ask people, "How many test driven?" No I think it's something less than five percent of the people who come to my event.

Scott: That's something that we definitely wrestle with, something that we're trying to branch into a little bit more is getting out and doing some of these talks and presenting at conferences and stuff and we'll knock around ideas on what to do at a conference, what sort of a topic to cover.


And at first, nobody can come up with anything because nothing that we do we feel is groundbreaking -- like whose going to be interested in hearing this? And it takes somebody from the outside to say, "Well, to you this is everyday stuff, but take this out to the world and you'll find lots of people who never really tried it or maybe even never heard of it but to whom it would be really interesting."

Ron: Oh yeah absolutely and in fact I am about to go next week and speak in Slovenia and later I'd be speaking on this topic at the Tech Eds around the world and I am borrowing from new guys.


So that's why I am here today because a few months back, we were having a debate on one of our internal mailing list architecture mailing list at Microsoft and somebody mentioned a paper that you guys wrote or some of your folks wrote called "Presenter First" and so they had a link and there and I went and read this paper and I thought, "Oh, that's very interesting," and I actually spent a couple of days kind of just writing code, if I went across an idea, I think it feels good.


The first thing I want to do is write some code and then see does it really work, so I wrote some code and I came away pretty well convinced this is a good idea and that's why I contacted you guys so that let's have this on ARCast. So we're going to tell the story of "Presenter First" but we have to go back a little way as I start the beginning.


Probably one of the earliest patterns that most people have heard about was the good old Model-View-Controller. And I was researching this. I was stunned to find out this goes all the way back to the mid-80s, you know the Model-View-Controller is very very, been around a long time. I was first exposed through it in good old MFC in the 90s if you know and even then I didn't get it.


Even, you read about, OK, model is a model, there's a view, there's a controller, I sure didn't get it and then I started hearing about this thing called "Model View Presenter" and I wasn't sure what it was.


So let's begin with that. What is the difference between Model View Presenter and Model-View-Controller and why do you think Model View Presenter came around?

Scott: Well, the two concepts are pretty similar, as you might imagine and it's not a clean sense that they differ by one layer. The primary difference between the Model-View-Controller and a Model View Presenter is that in NVC architecture, the View still has some communication with the model. Typically the View will grab data from the model to use for display purposes.


In NVP, that connection is completely separate so that the model and the View know literally nothing about each other. It seems like a small change and technically I suppose it is but from an architecture point of view, it's a pretty big difference. That allows your models and views to develop completely independently to suit their own needs without ever affecting the corresponding model view or vice versa.


So that's a pretty powerful paradigm if you can get the model developed completely independent of the view, because now you're no longer tied to your GUI, for instance, now the NVP model is typically applied to a GUI application, not always but that's the typical application.


One of the reasons that we really like this particular method is its very difficult to test view code. There's lots of really expensive applications out there that'll sort of run through some automated click and response reading screen scraping programs but they don't work very well, subtle changes in your dialogue, if that's what it is, result in huge changes to the test that you have put together. It's really hard to test the view.


So, we want to test as much as we possibly can. So our philosophy was to take everything that we can't test or is very difficult to test and package it up into a small a unit as possible and just sort of set that aside and say, "This we'll test by hand."

Ron: OK. So let me hold you right there because as I was looking at the history of this evolution, I saw that some people moved to Model View Presenter, you know apart from test driven development because they thought that Model-View-Controller was a little... it was evolved from Smalltalk, in a time when people were writing their own GUIs and things like that. So it didn't seem to fit that well into modern operating systems and languages, so they kind of moved that way, but then this influence of test-driven and agile practices came along. Like you said, testing GUIs is really hard.


Microsoft actually used to have a product for testing GUIs, I don't know if you guys knew that. It was called Visual Test. When I first came to Microsoft in '99, they had Visual Test, and I remember trying to use it. [laughter] And you know, if you had, like, a simple form with basic controls, OK, you could make it work. But like you said, you found out very quickly that until you hit a visual freeze, writing tests with this thing was virtually impossible because you would spend more time maintaining your tests and try to keep them working that you would actually writing code.


For that reason, it doesn't fit the TDD process very well, because you can't use it until way late in the game, and so you end up with all this code in your views that's, like you said, very difficult to test. So then when you say, well, OK, but I want to be test-driven and write a test first, how can I write a test first without locking down a GUI and having all of this big problem.


So I just wanted to connect the dots between what was happening there. So today, a lot of people have GUIs with very complex code that is virtually untested. [laughter]

Scott: And if you've got any program logic or business logic in there at all and that's going untested, you can pretty much guarantee that that's going to be a problem area. Before we get off the View topic, I think that testing the GUI with some sort of automated product is still a good thing. But that's more of a system- or a user-end testing. It's basically just automating what somebody sitting in front of the computer would be doing. And that's still important to do, because that's the part that your user sees, and you still want that to work the way you expect it to.


But as far as getting the GUI to work the way you want it to, relative to getting the business logic right, that's pretty easy. Getting the business logic right is where you really make your bones. Because you really want your algorithms and basically the crux of the application that you're writing to work correctly and work the way that you expect it to. So that's where we really focus on the TDD development, is mostly on the model. And also the Presenter, but if we get into it very deep, you'll find that there's really not a lot of code involved in the Presenter. But it's still important and important to get tested.

Ron: So let me just reiterate then: using these GUI test tools--good, valuable testing GUIs--but it comes so late in the process that it's not useful for TDD purposes.

Scott: That's right.

Ron: OK, just wanted to be clear on that. So let's talk a little bit about some of the pieces of the triad. So we mentioned View, which is kind of simple for people to understand. That's the GUI, the widgets, that visualizes the data, right?

Scott: Typically the kind of code you would see in a View would have a set method. Say, if you've got a text area that holds somebody's name, there would be a method on the View called setName, and all it would do is populate that text box. So it's very simple, it's hard to get wrong, and the other end of it is the user actions that come out of it. If you've got a push button, usually you'll get some kind of "button clicked" event, and the only thing that the View would do is send that click event on to somebody else. So, again, very small and hard to get wrong.

Ron: So I like one of the... When I read up about the roots of this trend, there was a guy who wrote this paper some years ago where he talked about this pattern that's come to be known as the "humble object." And his basic notion was: if you have something that's hard to test because of its dependency, like code that depends on a GUI--it's hard to test, because it's in this GUI environment. It could be other things, like it may require some sort of a container environment that's difficult to reproduce, or whatever it is.


You try to take the code that requires this--what he called the "impossible dependency"--you try to humiliate that code. In other words, make it as simple and basic as possible. So if it's just like, you know, set this text box, handle that click, but that's all it does. So it's just humiliate and make it as humble as possible, and you take all the interesting stuff and you put it somewhere else where it becomes more testable. So that's the idea behind this, what you're talking about.

Scott: Absolutely. In fact, I read the paper that you're talking about. I'm not sure who the author is--it might have been Fowler--but I think it was called "The Humble Dialog." And it was exactly what you said, to take as much out of that as you possibly can and, literally, the only thing that you're doing is doing the direct interaction with the GUI -- setting text into a text box, or taking an event from a push button and passing it on to a testable object who can listen too.

David: "The Humble Dialog Box" article was one of things that really helped to reveal the Presenter First pattern. It was one of the gold nuggets that Mark Sigley and Harlton uncovered and read it, and went after it. It wasn't quite enough for them. It answered two-thirds of the puzzle. And then they found a way to--there's one thing added to it, and it's at the start of the paper--the emergence of the Presenter First pattern on top of that. But I believe that paper credits "The Humble Dialog Box" as one of those steps of "Oh, this is good."


And so that was one of our primary references for teaching people before we had any papers written or any description of the pattern. We would talk to each other about it, and other people would hear, "Well, what's that?" And it's, like, "Well, it's kind of when you do this thing," you have to go show them, and they're like, "Well, where can I look this up?" We would refer them to ThoughtWorks' pages on MVP. But it actually turns out that it wasn't quite the way we went about it. If you followed that exactly, it would get confusing, and it wouldn't mesh with our code, and it didn't have the benefits that our pattern that was emerging seemed to have.


So we would point people to "The Humble Dialog Box." Read that first; that gets you in the right mindset, because it's the mode of thinking that lets you create any number of patterns that work really well given the circumstances, because it's about "Keep it simple." If it gets complicated, keep it simple, and push it somewhere else. And that piece might be complicated too; you make him simple too, until all you're left with is a big stack of simple things that work together.

Ron: I like the picture of the "humble dialog" or "humble object" because I can just--I can almost visualize that. It's like, "Well, what do you do?" "Well, all I do is put text in a box, you know, that's it"--you know, that's humble. [laughter]

Scott: It's really just an extension of the single responsibility principle taken to an extra degree where literally his only responsibility is to take the information and translate it into something that the dialogue or the GUI can understand. So I get a string and I know how to put that into a GUI text.

Ron: OK, so let's quickly talk a little bit about for those people who don't know about the model. When I kind of first learned about NVC going way back, the model, example of that people used was Excel.


They go, "Here's Excel and you got these rows and columns of data in your spreadsheets. See that's one way to look at it, right, but then over here is a chart telling the same stuff but it's just visualizing it in different ways. You have a model, the chart is like a view of the model and you can have multiple kinds of charts." So that kind of locked it for me. But if we think about it a little more abstractly, what would you guys say is the model?

David: Model, it's typically in Presenter first, more of our people would call an application model than strictly a data model. It does more than just hold on to data or store data. It will meet events to tell you when information is changed, it may not hold directly some piece of data but rather provide references to it or a translation layer for data stored elsewhere. It also may respond to form actions like to trigger a file open sequence and response to an event in the View.


So, in that regard, it seems to be a lot less data oriented and more function oriented, in the sense that a presenter is designed around user story, language and an example might be when a user has used the file menu to select the "open" option. That it's time to pop up a customized dialogue for browsing for files to let the user select the file and do something with that data or is the file an XML?


You create a dataset and put it somewhere and notify people of that change in data like opening a new document in a text editor, opening of a new Excel sheet and then repopulate that grid and repopulate that chart with completely different set of data. But the presenter wouldn't have a file dialogue, he would listen to an event from the view layer saying that this has happened.


The View will contain the code, the specific code, map the dot net menu bar or I think even MSC can be adapted. I mean it's not language specific but most the presenter knows, the user wants to open some file, the presenter delegates that work down to his model, in this case. The model may have any number of methods that are just meant to serve the needs of that presenter, open file and the model that use several classes to accomplish it's goal of opening a file, whatever that may be.

Ron: So you think that you would actually have the model like showing a dialogue, that view is kind of weird thing?

Scott: Not literally but it's not too far from that. When we talk about NVP Riyad that the model end of it is sort of this light wrapper that receives all of the messages that the View generates and then travels through the Presenter and it sort of coordinates the work that's going to be done to get the user's request accomplished.


So the model might be composed of three or four different worker classes that actually get some of the work done. Those specific one that you bring up like bringing up a dialogue. Is one that we've actually spent a fair amount of time on and nicely written paper because it is a little bit tricky.


It does seem odd that a model would pop up a dialogue box. The way we ended up, I must say rationalizing it through ourselves but the way that it ended up making sense to us is if you consider that nobody would have a problem with the model through its delegates going out to a database, getting some information it needs and retrieving it that way through some abstractive database interface.


We considered that if you're going to a user to get some needed information, that's really no different than going to a database. So we have an abstracted interface, all the dialogue shower, more specifically it might be an open file dialogue shower and from the model's point of view, there's no GUI there, it's just like a database interface would be.


So we just say, go get us a file and then that sure itself would use its own NVP triad to accomplish its work. The View become the actually GUI for the dialogue and the model would take care of whatever processing of getting that file in and you'd end up getting that back from your dialogue shower interface.


So from a model's perspective, it's no different than going to any database to get information.

Ron: OK, I have met you now because I like the idea of, OK, if we're saying, "Model, go get us some data," and the model says, "Well, I need to find out from the user which file they want to open so here's this interface that with use to penalty injection or whatever for me to get," and I say, "Find out for me from the user what file they want," and then I go off and get it, populate the model.


So I had been thinking in my own head that the model was sort of like the set of domain objects, the customer object, invoice object or whatever. Here's this hierarchy of objects that you go when you want to get stuffed in, you work with these objects. And they sit in front of a bunch of data sources like databases or web services, or whatever, that they're going to use to get their work done and for me, I was thinking well, I would probably work on those guys first but then I said, "Hmm, being very TDD given that would be probably the wrong approach, wouldn't it?" Because you want to begin with the user story and drive from that point of view, don't you?

Scott: Absolutely.


[music]

Ron: Oh I am sorry, but we're out of time for this episode of ARCast and we were getting started, I am telling you, I had so much fun talking with those guys, we went on through an hour and a half which has to be one of the longest ARCast recording sessions ever and then we sat around and chatted and ate some pizza and just celebrated, just having a great time sharing ideas. That's what this is all about.


I think that's why people like to engage with the community of developers and architects and kind of just sharing ideas and learning what works and what doesn't and that's what so powerful about ARCast, it's not me, I cannot take credit for it. But it's you and it's your listening and the people who are on the show and all the things that we share and learn from each other. It's just great, doesn't that make you feel warm and fuzzy inside? And we make pretty good money, too, while we're at it.


Hey, thanks for watching. We'll see you next time on ARCast TV.

Announcer: ARCast TV is a production of the Microsoft Architecture Strategy Team: www.arcast.tv.