Thank you, thanks very much for having me Amr, I am honored to be here. I am a second generation computer programmer, so I would like to say that my father has gone into this business many years ago probably just to make money for his family. And I remember him handing me a book on C when I probably wasn't even a teenager yet, and I was trying to make sense of it . So I got involved very early and then professionally in college I started programming at a bank on Wall Street and fell in love with programming really, I have been doing in junior high school and high school and then professionally I was hungry to learn to become really good so I read lots of books and eventually I started forming study groups and a meeting a wider community of practitioners.
So my company started in 1996, Industrial Logic. We are heavily involved with the patterns movement, design patterns and hanging out with people like Ward and Kent and Ken Auer and Martin Fowler and all these great folks, Norm Kerth. We got involved in the process movement early on, doing Agile projects back in 1998, and really seeing that this was the future of our industry so we have been building up the company ever since and doing bigger and bigger projects around the world and enjoying what we do.
2. Excellent, thank you Josh. So what are your current passions and interests these days?
Well, right now I am really focused on system metaphor, the lost XP practice. System metaphor is interesting; it's one of those practices that I myself was fairly vocal about to Kent saying I didn't think it was working as a practice. And even though I am a second generation of computer programmer, I am a liberal arts major, so I love metaphor, I love all those things, similies, metaphors, analogies, I am the first person who you'd think would want something like that but back several years ago when Kent was writing the second edition of Extreme Programming explained, I was really vocal in saying that I thought it was a practice that probably should just be subplanted by Eric Evans Domain Drive Design concept.
3. Can you define the practice for us?
System metaphor is really about having an overarching - a domain that you understand very well which you would call the source. The target is the system you are building and in metaphorical speak there is target and there is source. The source is what you use to understand the target. Targets are software and the source is something you understand intimately, that can help you understand your target. So basically we try to find the right source to understand the major components of the system. We are not talking about what database you chose, what distributed architecture are you using, or anything like that.
It is more about what are the core parts of the business system or let's say it's not a business system but what are the core parts of the process you are doing with this computer software, what are you doing. How can you understand that quickly and easily given that it's a fairly complex piece of code probably? So it really helps for the non technical folks and the technical folks to have a shared understanding of the system via this metaphor. And that is really what system metaphor is, it's not a low level thing, it's really metaphor of the system, the system metaphor.
4. It's a very, very high level concept.
It's high level but it can affect objects inside of the system. So it's just that is has the overarching goal of helping you understand the system, without having to think really hard. So of course the mythical birth place of this practice in some sense was the Chrysler compensation system, the payroll system at Chrysler, although I believe practitioners were using metaphorical concepts prior to that, it's just the most famous example of the manufacturing analogy which used assembly line as a metaphor where there are bins coming down the assembly line, and ultimately you want to produce a paycheck. So they conceived the paycheck as a collection of parts.
Eventually I thought it should have been dropped because I just couldn't find enough practitioners who were able to practice it, including myself. I didn't find that metaphors came easily, and therefore I felt like we were asking too much of people to come up with this thing. That was my prospective on it, I wasn't anti-metaphor I just felt like it was too difficult and we only had a few examples that worked and for those folks it didn't matter that much if you had a well crafted system and potentially had a ubiquitous language like Eric Evans says, that your language is the same language of the business or of the organization, so in your spoken language, in your emails, in your source code, everywhere you are using the same terms, but that was enough.
And what I've come to find in the last several years is that ubiquitous language is great, it's wonderful, however if you can find a metaphor it can have a very powerful effect on your software and potentially on your product. For us we really struggled to find the right metaphor in our e-learning software, we started out what it really felt like a website, and there wasn't really a metaphor at all. Then we decided that this wasn't working we did some usability testing and got some low scores on the look and feel of the site and usability of the site, and that led us to start redesign and we said "Well maybe what we are doing is we are selling online books, we are sort of that interactive online book things".
Maybe book is our metaphor. And for a little while there we pursued the book metaphor and felt good about it and we felt "Wow, this is helping us", this is going to be a table of contents, started suggesting things. And ultimately we abandoned the book metaphor one day, we were having a planning session, this was an iteration planning session and what I would like to say about that day is that first of all the planning session was completely distributed on Skype, we had someone in Alaska on vacation, I was in Berkley, California and Brian Foote was in Illinois, and we were half kidding with ourselves half the time making jokes and then getting serious and then planning and then going back to joking, and then all of a sudden Brian said, and Brian had been teaching a lot with easy learning materials, so live performances, and he said: "You know, I really want a playlist", and when he said that, I immediately said certain expletives; not in anger just in "Oh my Gosh we have missed something huge". We don't have the concept of playlist with books.
Yet what Brian is asking for is clearly the kind of thing we would like to have in our e-learning, a playlist, the freedom to pull from various different sources and create your little own customized list of something you want to talk about or expose people to.
6. So you pulled modules to create a particular presentation or class that you want to deliver.
Correct, and that could come from a diverse group of modules so whatever you want. And once he said that, I went into a two or three day don't disturb me sort of session, everything came to a complete halt. And we just started talking more and more about this music metaphor concept and realized we had to do it. And we had already spent a fair amount of time going through the book metaphor stuff, even the look and feel of the size was bookish. So it was a very big decision to me to say "Let's move towards the music metaphor".
But we did. And what we did - what you ended up seeing was: we had a scene where we actually had instead of books we had albums. And those albums were composed of tracks. And if we wanted to we could have box sets of albums, collections of albums, and then eventually we also supported playlists. So at this conference I am going to give a talk on system metaphor we revisited, and in preparing that talk I really want to do a good job because I think we have to rethink system metaphor, I think there is more to it there than we first thought and we should not give it up as a practice. I am hoping that we can find ways to make it easier for people, and hopefully my will tutorial address that.
In any event, in looking for example code for this tutorial, I started asking some questions of people and looking at our own code and said at one of our main programmers, our lead programmer, his name is John, I said "John, does design metaphor help you?" And he kind of looked at me and said "No, it doesn't help, I mean he had just spent an entire week working on something very technical involving labs and uploads and looking at time stamps and things like that and he explained that and he said "The music metaphor did nothing for me there".
So then we started having conversations wondering why is this? And then we realized that our music metaphor was there but it was very superficial, it really hadn't penetrated the system design. So we started looking around and found that we really missed quite a bit that there was a lot, I would say eighty percent of the system hadn't been touched by the music metaphor and could have been. We found the fact that our action processor that we called which had its origin in earlier code we have written was more of a conductor.
And that our commands or actions are more like players, musicians and that they would play scores, and that there is a constant of mixing where we mix templates with parameters so it's a mixing concept that a technician does and then instead of having a services manager we have a roadie and the roadie provides equipment that the players use. And on, and on, and on. Just finding deeper and deeper ways, to make this metaphor work in our code. Now I could explain our system to my ten year old daughter and I think she would understand it and I show a couple of pictures of the symphony where there is an audience and a conductor and players and scores and all of a sudden the understanding of the architecture of our system becomes illuminated to her. It also inspires us.
We talk about the three eyes of metaphor: illumination, inspiration and integrity. The metaphor helps illuminate the design if it's a good metaphor. It inspires us with new ideas, in the future for us we might have a top forty chart, in the United Stets we have the top forty top hit songs, we don't have that today in our e-learning, we may have something like that, and the integrity of the metaphor helps us to really feel like the system design is coherent it really fits well together, so it gives us that. In fact we we've even looked over all of package names and realized that we could totally put the music metaphor onto that as well, there was the concept of stage packages which do stuff behind the scene and then there is stuff that is central stage which really is where the action happens. So really total makeovers is what we saw.
Anyway that music metaphor has been powerful for us and it's so powerful that I feel like others could benefit not from that same metaphor but potentially from other metaphors that could have the same impact. So, we are looking at more and more example code to see where consistent metaphor fits. I know a lot of people just feel like this practice just didn't work, it's too hard, we want to find ways to make it easier, we want to find ways to show the impact and how powerful it is that others are inspired to look for it as well. We also just want to find the "gotchas".
What are the things that are preventing people from succeeding with this practice? Mixed metaphors for example that just don't work or metaphors that are overly tactical, which lead people to say "Well I don't know what that term is" Someone said to me the other day the word Coda, Coda is the last part of a score, I didn't know that. Most people wouldn't know that I think. Will we use that term on our site? Probably not. Etude some of us don't know what etude means so it's almost perfect for the music analogy but it's kind of one of those words that it's a non English speaker it's going to have trouble with it, so we try to find words that are more international. Anyway it's exciting to me because I feel like it's a lost practice, and it has a lot of power to it so we are trying to revive it and see what happens there.
Yes I mean for us it's a little different in the sense that it does those things internally for us programmers, but it also has had an impact on our actual UI design, that the experience the actual users have. And I don't know if every metaphor is going to have that, but it certainly has that for us so it may be that more metaphors can have both an impact internally and externally and that we just hadn't seen that before. Or it could be that ours is an outlier. But certainly it's making us think about things, even bookmarks.
For a while bookmarks were causing us issues. We are not selling books, we can't have a bookmark but students have asked for bookmarks, they have used the term bookmarks, what do we do? We don't want to pollute our music metaphor with the book concept so we need to think about it a little bit. Now as Bill Wake said when you are going in your car and you play a CD and you turn your car back on the music song goes straight where you were usually it just picks up. That starts to offer some ideas to us about how things should automatically pick up where you left off. Things like that come up and it's a fascinating discovery process that I am enjoying.
Yes. What I have discovered is you learn a lot from building your own product especially when it's your own investment in the product, it's your own money. When you are spending your own money, you really care about value. You want to get the highest value for the least amount of dollars. We have evolved our process based upon this. And funny; I have described our process recently on a few email lists and someone who doesn't even know me was like "That's not XP".
Maybe you should practice XP before you start doing stuff like that and they don't know that we have been heavily involved in the XP movement for so long. So, people have said that of you are doing the same process or what you were doing last year or the year before, and not change at all, you are probably doing something wrong.
Right, you are not learning. And also for us it's a matter of taking some risks and trying things, experimenting. We have been very good about experimenting over the years, just to keep learning. One time we tried using real hours to estimate and we did the experiment we did it whole-heartedly and we realized it wasn't for us, it didn't work well, most of the people in the company did not like it. So we abandoned that. And in 2007 at the Agile conference there is a lot of interesting things happening.
David Anderson gave the "Birds and the Feather" talk in the opening space, and he was kind enough to stop by our booth and tell me about it so I showed up to it and this was the first time I heard about kanban and then his work on kanban. So soon after we got back from that Agile conference in 2007 we started doing some even deeper experiments stopped estimating all together. Soon after that we stopped iterating, we stopped doing fixed length iterations and said "Why don't we just do a little chunck of work then release, then go work and release". And keep doing that micro-releases as I started to call them.
And we started looking at all of the things we do saying "What can we drop to go faster? What's not adding a lot of value?" in the last year I'd say we don't maintain a backlog anymore. I am not recommending what everyone should do I am just saying specifically of what our company is doing, in our context.
10. What has worked for you and worked well.
That is right. And it's a matter of looking at that stuff and fine tuning it. And being courageous enough to try things because you can always bring stuff back, we can bring back a backlog if we are having trouble without one. Now how do we work without a backlog? We basically know what is important to us, the big goals we want to achieve we still do some form of chartering even if it may not be formal chartering we have our ideas of where we are going so there is a road mapping concept. We are not that formal about measuring our success we sort of look at the money coming in and it gives us a feel of us being successful or not.
I would say we are not very quantative, I would like to be more quantative, and that is an area where I think I have a lot more learning to do. Whereas where can be bring the quantative stuff into the rather ultra-lean process we've got? Where would the metric help us? We stopped the backlog, we said defects for example. We have very few defects, we have some defects, web based e-learning tool so that means there will be browser bugs here and there, we know about those, the ones that are predictably troublesome effects.
Features, it's always a trade-off, is there going to be a sale to a company that's really big? Will we got to do something to make that sale happen? Are we in a little bit of a low, where we can do some heavy duty refactoring, potentially do the metaphorical changes we wanted to make that were so important in our talk? Maybe our build system is not fast enough anymore and we want to start messing around with the Amazon cloud service to have an ultra-fast build and that is the most important thing. So it's a constant discussion and a constant balancing and rebalancing priorities.
The backlog would just get in the way, would just slow us down, at this point. So we are not using one. Retrospectives, I would say we used to be very disciplined about that, the end of the iteration, the fixed length iteration we retrospect and only keep records. We have really stopped doing that. If something is not working we pretty much stop and talk about it until we come up with a solution and we found some tests for example that are giving us some problems. And it's the kind of thing you say "We are not going to tolerate that so we are going to stop and we are going to fix it". That's the kind of thing that we do.
We have been together a long time, we are relatively a small team, we are very distributed. Our folks are all across the US. We have an office where we meet in person in Berkley, California, very well set up for pairing, we do pair programming, we do it as much as we possibly can. Because it is so crystal clear that the bugs happen when the solo coding occurs, it happens, so occasionally we do solo coding, and when it happens we immediately see bugs to a point where we don't want to solo code, we want to do well and you are talking about some of our people have 20 plus years of coding.
12. Very senior, very experienced people.
Very senior. They are very good, they know that they will write higher quality code in a pair so we do it as much as we can, we still use VMC I am not crazy about it but it does work for us. I would like to do something else we tried various tools but we use it. We use Skype and we do as much paring as we can. That is a practice that I doubt would ever go away for us.
It's huge, particularly the knowledge transfer but just having multiple sets of eyes on that code produces higher quality code, and you catch each other making potential mistakes and then it won't happen so there is about two I would say two and a half to three programmers on the system on any given time. There is one full time programmer who is absolutely full time dedicated, and then the others come and go but pretty regularly so it's about two and a half, three people. And there are the authors, people writing content, producing content. We are looking at content development and seeing how Agile and kanban and things can help because people have different ways of producing content.
And it's as diverse as people develop software. I think that it could benefit quite a bit from more of these Lean and Agile concepts. There is a lot of waste that can occur if you want a piece of content that isn't going to fly. There is a lot of waste. You can waste days and weeks and months on something. Applying test driven concepts to content, failing fast, shooting down ideas that just aren't going to work well, or getting content in front of people extremely rapidly, and getting feedback, or just simply having even a little handbook of what works and what doesn't work, I mean we don't like our pages to look like they have a little clip art things on them, Clipart doesn't look good, but not everyone knows that so how can we get people to be better at choosing photographs or choosing art? All these ways can ultimately help us go faster so I think that area of our business needs to get more Lean and we are focused on that now.
For example, take a drag and drop quiz, we have a drag and drop quiz, it's some pretty difficult code to write to make it work in all the browsers, and the browser change, all of a sudden Firefox version comes out and something that has been working for years suddenly starts working differently, there is a horizontal scroll bar showing up for no good reason and this things happen. A horizontal scroll bar is annoying so it's the kind of thing where we say "That bug, we may want to fix that right away". That's less important though than a potential sale where someone is emailing us saying "Hey, this isn't working at all for us, so I can drag something here but I can't drag it back to the docking part, it is not working".
And you are worried that this person is going to give up on that quiz and that won't lead to a good sale. So all of a sudden that thing we thought we are going to do working on the Amazon make the build faster thing, all of a sudden we realize: "You know what? We may be selling fifty licenses to this client, I think it's more important. Then a couple of phone calls and emails "Hey, let's rejigger the priorities right now". And we do.
People are very flexible, as Jim Highsmith would say, they are adaptable, Jim talks about the importance of adaptable software and now he is always talking about the importance of adaptable people. They are adaptable, they are quite adaptable, they want to do what is good for the business. So if we learn something like that, we haven't spent a lot of time planning, we spent the most minimalist time we could to plan, and if that plan changes, fine. Whatever is good for the business. So, re-factoring we like to do all the time, however debt accumulates, there is nothing you can do about it.
14. No matter how good you are.
No matter how good you are the design you come up with today, looked at a few weeks later you are going to realize "You know what? It could be simpler, I could get rid of stuff. But reading some books on art recently and Michelangelo loved sculpture, because he loved to get rid of what wasn't needed, he loved to chip away and get rid of the stuff that wasn't adding any value, so you have to look back and constantly look at your code, if you want to build something good. I am a business man so I could easily take a stand of path to inject feature after feature after feature. I call them feature junkies, it's like "More features, great!". That is how most businesses are run, that's how people are rewarded, and it generates the big balls of mud as Brian Foote calls them, it generates complexity and technical debt that just becomes very difficult to manage.
So, we try to balance that. Sometimes we'll accelerate, we'll go very fast, feature, feature, feature. Then we say "Oh, we got to slow down we have accumulated some debt". Hopefully by injecting those features really fast we have done something good for the business, we'll have some money rolling in, things like that. Now, if the money is rolling in we say "Ok, time to slow down a little bit, where can we improve things? How did we mess up?"
15. When you inject feature, feature, feature you are doing it in a test driven manner still.
We call it doing test driven however.
Yes. Always pairing, always doing test driven development and even so your test may not be that great. You go a little fast. Or for example a test could be slightly slow. And over time if you allow a slow test that is no good, we all know that, so that test that you wrote that wasn't as fast as you like it to be, you might come back a week later and make it faster. Or you didn't refactor as much as you could have. You saw that duplication or you saw something that was off, usually if it's just simple duplication you are gone, you get rid of it right away. But it's usually the tough stuff, the stuff where you gaze something and you say "That is not right, but it's going to take me days to fix that.
And so I have to make a choice: can I take care of that now? Or is there a business priority that is going to supersede that?" And if there is, again we don't have a backlog of refactorings we want to do, but we are always looking at the code so we know where the messes are in the code. And what I like to do is periodically have like a spring cleaning, spend some time to just start cleaning, it's a wonderful feeling. In fact we do it sometimes for more than a week, we go like a week or two, to a point where the guys are like "Ok, enough, this has been great, we loved it, but now we are ready to start doing features again". That's what I mean we'll refactor without user stories at all.
There is no user story driving a refactoring it's just the need to keep things clean and simple that is what's going to allow us to build features faster, we know that, we know it from experience; we want to walk the talk. So we pause every now and then to do some heavy duty re-factoring and of course we do the continuous re-factorings it's not like we are not re-factoring when we do test driven development, it's part of the process. It's just like there are larger refactorings that take more time to clean up and yes you can do those incrementally we do them incrementally, in fact we will start re-factoring and ship, do a little more re-factoring and ship. But it takes time and you have to decide where your focus is. It's through fine tuning that process that you can make a successful product. If you ignore that stuff, you do so to your peril.
17. And your ability to switch on a dime to not have a backlog, that's because?
Well, we are heavily involved in this product it's not like we have fifty products and we have a business analyst trying to beg some time from the subject matter expert to figure out what we need to do for the system, we're very small and lean and focused on what we are doing so we are able to do that. And we'll make decisions sometimes, like let's say on a Monday "Here is what we are going to do".
And then rethink it Monday night and go "You know what? That was a bad decision, there is a better decision and if we do that we'll be opening up the product to more users". Come in Tuesday morning "Hey guys, I think we have a better path to go down, do you mind if we change?" And they don't.
18. And you can do that because you don't have a lot of work in progress.
That's right, I don't even have to re-jigger the planning tool. It's all just words, it's all jus communication, like you can just say "Let's do something different". And the guys work in such a way that the system isn't broken on Monday afternoon, it's not broken. We could have shipped it, so we work in such a way that we keep the system green, keep the tasks green, keep the code ready to ship. That takes some discipline and craftsmanship to be able to do that but it gives us freedom, we want that freedom to be able to ship whenever we can.