 So welcome everyone, this is Build Your Own Technology Radar. This is a talk about making and assessing technology decisions both from an individual standpoint and from a corporate standpoint. It turns out those are very different decision criteria and I'm going to dig into why that is a little bit and talk about how can you make good technology choices because one of the problems we constantly face is that we're constantly distracted by new shiny things. Ooh, look, Node looks really cool. Let's pull all of our resources into that without properly assessing does it do all the things that we need to do? That's really what this talk is about. So my agenda for this talk is I'm going to describe this technology radar that my company ThoughtWorks produces every month. That is the actual metaphorical inspiration for this talk. I'm then going to talk about ways you can assess technologies, creating litmus tests so you can help decide if this technology is suitable or not. And then I talk about building two radars, a personal one and a company one, and a bit about strategy. And in fact, I'm going to talk about three distinct radars in this talk. The first one I'm going to talk about is the one that ThoughtWorks produces for everyone, and then I'm going to talk about building one for yourself and then one for your company. So just out of curiosity, has anyone here ever downloaded a copy of the ThoughtWorks technology radar? I don't assume that you have. Okay, several people have, that's good. So for those of you who have not seen this before, this is basically a white paper that ThoughtWorks releases twice a year called Technology Radar. And this is produced, well I'll show you what it looks like first. So this is the one from August 2010. They all pretty much look the same from a visual standpoint. Of course the content changes every time we meet. The first page is basically who we are and the people who are in this body that make this document. But this is the main metaphor, is this radar metaphor. What we've done here is said these are the technologies that we think are going to be very interesting for whatever reason for our clients and people who are consuming knowledge from ThoughtWorks. And we have several quadrants here and I'll explain the rings and the quadrants and all that stuff. But this is what the Technology Radar is. This is the white paper we produce. And then the subsequent pages go into detail. So this is four quadrants. The subsequent pages now break each quadrant into pieces and have some pros around why we made this decision about this versus that. We don't write up every blip, but any blip that we think is going to be confusing as to why we put it here versus there. We'll try to add some context in the pros. And in fact that's the rest of this short white paper. Each one of the quadrants, there's tools, there's languages broken out and some explanatory pros as to why we chose what we did. And then the last page are references for things that we mentioned in there and some general stuff about us. This, however, is the main metaphor that I'm using in this talk, this idea of creating a radar and then the pros and explanation that goes along with it. And to understand where this thing came from requires a little bit of history. And it's not much history, but this provides a really useful context, I think. ThoughtWorks, for those of you who are not familiar, we're a global consulting company. We're in 10 countries now and we're about 2100 people worldwide. And we have a CTO. She's actually doing a talk here later today, I think. She's definitely at this conference she arrived yesterday. Rebecca Parsons, she's the CTO of ThoughtWorks. And one of her jobs as CTO is to make decisions about technology directions for ThoughtWorks and also for our clients. But she actually has a much more proactive role than most CTOs do because we tend to try to encourage our clients to go toward technologies we think are better for concrete reasons and discourage them from going to technologies that we don't think are better. So a good example of that is very early on, when we saw Ruby on Rails, we saw a lot of really nice technical characteristics in Rails and we started encouraging some of our enterprise clients to go to Rails before it was really well known in the enterprise because it suited the problem they were trying to solve really, really well. That's what I mean by trying to be proactive about technology so we can advise our clients more effectively. But the problem is, Rebecca, no matter how much she travels and how impressive she is, she is just a single person. And no single person can possibly have their pulse on all the technologies that are happening in the software space at any given time. And so one of the things that she created at ThoughtWorks is this body called the Technology Advisory Board or TAB for short. And I'm a member of the TAB and this is the group that puts together the technology radar. That's not all we do, but it is the most visible thing that we do. The TAB Technology Advisory Board is a virtual body that meets every two weeks via a hideously timed international phone call. It actually wasn't bad for me this week because I was here. We had the call on Wednesday and it was 6.30pm to 7.30pm, which is not bad at all. The people in Sydney typically get either 5am to 6am or midnight to 1am on this international call. That's the hazard of running an international company and trying to get somebody from each country on the call is going to really suck for some people. So we meet by phone every couple of weeks and we have discussions. But we also meet face-to-face two times a year. And when we meet face-to-face, we discuss all things tech at ThoughtWorks, how to get and retain senior people and what kind of technology choices and what kind of methodology and technology intersections are we interested in. But the entire TAB are a bunch of basically really impassioned senior technologists, a couple from each country. And we only see each other face-to-face a couple of times a year unless we happen to travel to one of the countries that one of these members is in. And so it's inevitable any time you get a bunch of technologists together it is going to turn into at least a partial geek fest. Because you'll talk to someone you haven't seen in six months. It's like, hey, I just found this cool new thing. You got to see this cool thing you can do with it. It's inevitable when you get a bunch of technologists together. And so part of the TAB face-to-face, we started creating a chunk in the agenda for a couple of hours where we could just basically talk about hot technologies and things that we were really passionate about that were coming up very, very soon. But then we realized there was an audience for this discussion. And so we started publishing the results of this discussion internally on an internal mailing list. But what always happens when you start doing that is some of the developers thought that, well, we've got a client that might find this assessment of technology is interesting. So it started becoming this kind of underground email out to select clients and other friends of ThoughtWorks and things like that. We actually, as the TAB, had no idea that anybody outside ThoughtWorks would find this thing interesting. And when we found out that people did find it interesting, we said, well, we should just create a public document out of it. And that's how this thing came about. It started out as this kind of internal assessment of technologies and technology direction. And it's now expanded so that this is a public thing that comes out twice a year. In fact, now every time the TAB meets, we're required to create a radar as one of the things that we do as part of our face-to-face meeting. And this is inevitable. The very first radar looked like this. The actual radar visualization was drawn by one of my colleagues, Darren Smith, in fact, using a keynote, the presentation tool, to draw that. If you've ever tried to do drawing in keynote, you know how painful that is, but that's the only drawing tool he had available. And so this is kind of hacked together using whatever was available. When it was decided we were going to start publishing this thing out of the world, now it's required to have beautiful marketing fairy dust over the technology radar before it's produced. And as you can probably guess, the biggest bottleneck to publication now is getting all the styling done after we've figured out all the technology stuff. So we have a goal to always produce one of these things within a month of meeting face-to-face, and usually the prettiness is the biggest drag on getting it out the door. But then, without us really certainly not planning it or even guessing that this would happen, this metaphor went really viral. We started seeing a lot of interest in thought works from the radar. We get tons and tons of hit every time we produce a new radar. And in fact, last year, this is last year in March, at InfoQ, sorry, QCon in London, this is on the InfoQ site, at QCon in London, InfoQ produced a technology radar to let the attendees of the conference pick what they thought hot technologies were going to be. And except for the slight difference in labeling of that outer ring, they borrowed this metaphor directly from us. So the point here is that this has become a pretty useful metaphor for thinking about technology choices. And I think it has become useful not because it's a fantastic metaphor, it's because it's a metaphor. What we've done is put a framework around a decisioning process that has not had much formality to it before. It's always been kind of ad hoc and sometimes seeming like arbitrary in companies. I'm not suggesting this is the perfect way to assess technologies. I'm suggesting that this is a way to assess technologies and when there's nothing really good out there, then this is the classic land of the blind, the one-eyed person is king and land of the blind. So this is not a perfect metaphor, but it does serve a nice purpose. So let's talk about the mechanics of what's actually on this thing and how we produce it. This is always done at our face-to-face meeting and it's typically done on very low-tech, agile kind of things like whiteboards and sticky notes, things like that. So we have four quadrants. What we do, one of my colleagues put together this logistics slide, is that we brainstorm for about 20 minutes. Everybody has sticky notes, they write technology things and they would like to nominate to be on the next radar. And we have a whiteboard. We go sticky, all those sticky notes up there and then an organizer goes and gathers them all up. So for example, we're all technologists, so if we did a radar session right now, there would probably be four or five, while I guarantee there would be four or five things on closure script, for example, which some of us are really passionately into. And so we cluster all those things together and then we spend about an hour and a half discussing. Through each one of those blips, decide, should it be on the radar, where should it be on the radar, et cetera. We'll capture all that and then write up the pros for each one of those blips. We actually write pros for every blip and then decide which ones actually get published, depending on space and things like that. We then share and make sure that this all makes sense to everyone and then we start this cycle again for the next quadrant. So we go through the cycle four times one for each of the quadrants. Yes. Yes, his question is, do we ever find something cool now and stop like it later? Yes, absolutely. I'll show you the trajectory of those things in just a second, in fact. So next let's talk about what the rings mean on our radar. The outermost ring on our radar is called hold. And any technology that shows up there, we are basically saying proceed with caution. We're not saying you should stop using this technology right now. We're saying you shouldn't start anything new in this technology because almost always we believe that there's some better technology available to solve that problem. We almost never put things in hold just out of spite, except maybe something like Enterprise Service Buses, but we generally don't put things in hold unless we have good alternatives and even in that case we have good alternative. But notice that we have no avoid category. This was actually Rebecca's idea early on to avoid an avoid category. Hold is about as strongly negative as we say about anything because this document is meant to be forward-looking. This is a strategic document. This is not a recriminations from the past document. This is not a backwards-looking document trying to figure out what went wrong with technology choices. This is a forward-looking document. So what we're saying is any technology that shows up here don't start anything new in it because we think there are better alternatives. So you should put a hold on that technology. The next circle in is assess, which means we think this technology is worth exploring. You've read a little bit about it. Now you probably want to go to a conference talk, download it, start playing with it, build a simple application or whatever it happens to be, a simple data graph or something like that. So this technology you're interested in and curious about. The next circle in is trial. For trial things we believe we've done an assessment and we believe it's worth pursuing the real resources into this thing. It's important to understand how to build this capability up because we realize that competitors may be utilizing this technology to get some sort of advantage. So you'll probably try this on a low-risk project. And we wanted to have some sort of criteria for us, an objective criteria for moving something from assess to trial. And our objective criteria for this is we have to have used it for a real project of some kind. Generally for a client, there are a few exceptions for very elaborate internal projects, but we only move it to trial if we've used it to solve real problems. We firmly believe that you cannot really understand a technology until you spent some time really building real things with it to understand both its strengths and, more importantly, its limitations. Because for any technology you choose, when you go to their web page, there are a lot of fantastic things about it. They never tell you the limitations. You have to find those out for yourself. And it's important to find those things out because nobody that's advocating for that technology will tell you what those limitations are. And then finally, the innermost circle, the bullseye of the radar as it were, is ADOPT, which we suggest that the industry has finished the trial and found good patterns of usage for this. And this is essentially a no-brainer. You should absolutely be using this technology. We feel strongly that this is a really good technology and has many more pros than cons. And we also wanted a criteria for this. And Mike Mason, who's one of the members of the tab, supplied this criteria, which we're calling a Mason's razor, which is basically if there's a technology in ADOPT and you're not using it, I won't make fun of you while you're at work, but when we go to the pub, Blade of Her Drinks, I'll make fun of you for using that technology. So that's the criteria. I'll make fun of you at the pub if you aren't doing this. So if you're still using something hideous and broken, like, for example, Clearcase instead of Subversion or Git, then I won't give you grief at work, but when we get to the pub, I'm going to make fun of you for using a hideously broken technology when there are clear, better alternatives available. So let's next talk about the shape and then we'll talk about the trajectory of technologies. You'll notice on the main radar we basically just have two shapes, which are circles and triangles. But on the blown-out quadrants on individual pages, we actually have several other shapes. Some of these are a little hard to see because the contrast is not fantastic on this projector. I'll highlight each of these. The first of these shapes is a triangle, which means that this particular technology, whatever it is, is new on this radar, versus something that's represented as a circle, which means that it's been at least on one radar before. So we have a special icon for things that have just been introduced to our radar. And circle means it's been there at least one before. We also have a little ghost of where its position was on the last radar and also some movement. So I don't know how well you can see that, but there's a little ghost triangle there, so that means that for this particular radar that cross-mobile platforms was new on the last radar and has moved in closer to trial on this one, on the subsequent radar. And the little vector that you see there indicates the movement from the last radar. We also have these little stars that burst into circles. Those are things that are categories that become constituent technologies. So a radar a long time ago, we had NoSQL as a category of interest. But then as NoSQL matures, it explodes into Mongo and Cassandra and all these different technologies, and so the category explodes and you have all these little technologies that are on their own trajectory now. So that's what the little star means. And finally, when it gets to adopt, and it's been there for a little while, it fades away. We call that passing through the center. So let's talk about the general trajectory of things on our radar. So typically things come into our radar at the assess level. There's some interesting new technology. We want to assess it so it comes in and assess, and then if it's a good technology, we want to assess it. We want to assess it so it comes in and assess, and then when it gets to adopt, when it gets to adopt, and in fact any blip that stalls more than two radars automatically fades away. This is not meant to be a comprehensive document of all the technologies you're using. Don't think of it that way. Because if it was, it would be solid blue mass. You'd never get them all on there. That's why we forcefully fade these things away. It's not meant to be longer than a snapshot at a point in time. So like I say, typically things will come in and assess, move into adopt, and then fade away. But there are cases, and this goes back to your question earlier, of things starting out in assess and then moving, for example, into hold. A classic example of that is intentional software that builds this language workbench tool. The underlying technology we think is fascinating, but the implementation is left a lot to be desired because at this time we've had a chance to play with this technology, and so that is in fact right there. It keeps kind of skirting back and forth between the assess and hold line because we think it's really cool underlying tech, but the current implementation is really, really lackluster, so it kind of goes back and forth. And so the other typical trajectory for something is it starts in assess, moves into the center to adopt, fades away, and then a year or two later pops back up in hold because it has now been supplanted by something better. A classic example of that is subversion. We used to have subversion of our old radars that in fact came up and adopt because it's been a long time favorite of ThoughtWorks and faded away, but now it's managed to pop up and hold because we like distributed version control like Mercurial and Git a lot better. That's exactly what I was saying before. Things typically show up and hold when we think there's a better alternative out there and we're trying to point you to what we think is a better alternative, at least for some use cases. Yes. So his question is are we trying to slice and get into particular domains? This is purely what 20 opinionated technologists think is cool today. That's all this is. That's nothing else to this. People who try to read a lot more into this are trying to read way too much into it. This is literally just a bunch of 20 technologists from all over the world. So there are huge gaps in our radar in terms of technologies because there are a lot of technologies we just don't use much because our clients don't use them or we're just not in that space so this should not be considered a comprehensive view of the entire technology landscape either. I don't think anybody could produce that radar. This is very much the things that we care about and it's very opinionated. Opinionated is probably the most accurate term for this thing because it's very opinionated. Other questions about this? Yes. We're not tracking that at all. It looks somewhere else to get whether it's stable or not, we're not producing that. There's so much information you could put on one metaphor and we're cognizant of the fact of trying to overload too much onto this metaphor is going to make it creak and fall apart so we're not trying to do that. So the question is do we have any standard parameters by which we validate assumptions? Somebody has to think it's cool and nobody can bring up a reason why it shouldn't be on the radar. We do have some criteria like we moved things from assess to trial only if we've used it but that very, very loose criteria. There's very little formality to this and there are no rules whatsoever. A radar session is basically ThunderDome. ThunderDome is a reference from Mad Max. It's a very chaotic kind of process. Very little process. Yes. The question is do we assign different technologies to different people? Everybody comes to this meeting with their own technologies. So again, we're not trying to cover the entire technology landscape. These are things that people come in that they are passionate about because they have used on a project. So we come in with pre-knowledge about things I want to be on the radar. So we have a tab face-to-face meeting in three weeks in Chicago. I've started percolating in my brain the things I'm going to write down on sticky notes for things I'm going to argue because there's no formality around trying to partition up the space or anything. It is literally just a bunch of impassioned people getting together and brainstorming. Use the term brainstorming. That's a perfect description of what this process looks like. Pure brainstorming. Well, so agile organizations have to make decisions about technology. So I'm going to talk about building your own radar in a second. That's really where this comes down to is decisions about agile technologies actually proceed differently than decisions and kind of big design up front shops because you have a lot less luxury up front of assessing things and so there's a lot more real-time assessment coming along and actually I think one of the deficiencies on agile projects is this helps is that agile projects have a very tactical use of technology and not a very strategic use of technology a lot of times. People come into projects and they've got some new thing that they just started playing with and they immediately want to start using that without understanding the long-term consequences maybe for this team or more importantly for other teams the same company because you can make a technology decision that optimizes one team but then it's terrible for another team and if you try to standardize a company now you've got this really misbalanced portfolio so you have to think about that. So it's really in some ways it's orthogonal to process and agility but it addresses I think one of the problems in agile projects is too tactical use of technology and not a strategic assessment of technology. Yes. I'll actually talk about that in a bit when I talk about building a company radar because I'll directly dig into that because that's an important aspect of this. In fact, one more question I'll move on. Yes. Twice a year. Face to face twice a year. We do this exercise twice a year. So the next one will come out. Our next meeting is first week of April so by the end of April you can always get the latest one at ThoughtWorks.com slash radar. That'll be the latest one. The latest one is going to be I think it was labeled November of last year that was done late October last year 2012. So the next one will be April. First week of April this year. Every time we meet face to face. So while I'm still talking about the mechanics here I wanted to point you to this if you want to do this exercise then the hard part of drawing this thing is already done. One of my colleagues has open sourced this thing called tech radar that will draw a technology radar on HTML5 canvas. All you have to do is fill in a JSON data structure and it'll do all the drawing for you on HTML5 canvas. So you can download this. It's open source created by ThoughtWorker in Australia. The only weird thing about this is this is the JSON data structure and the only kind of cumbersome thing is you can use puller coordinates so you can get exact placement within the rings. So you have to translate things to puller coordinates but once you've got that done then you can do exact placement. We actually don't worry too much about the exact placement within the ring. We're not making a statement by putting it closer to one thing versus another a lot of times. It's really more kind of space organization for getting all the blips in there as to where it ends up. So anything within a circle there's an analogy bit out there if you want to produce this visualization. So now I want to talk about I want to leave the ThoughtWorks radar and talk about two radars that you should build. And one of them is as an individual particularly if you're a developer or a technologist. And that's what I call a developer radar. And this requires a little bit of history about me. When my first job out of university and then eventually I became the CTO of this company that did clipper development. Anybody here ever done clipper development or even know of clipper development? You realize that you're dating yourself if you say you know something about clipper development. Just FYI. So I was the CTO of a small training consulting company 25 people. We did training in clipper. We did consulting projects in clipper. It turns out I could turn clipper into a really nice object-oriented language with a couple of extensions. So we built up these really nice frameworks. This is a DOS based technology and things were going great. We did training classes and then slam. Windows came along and destroyed our business. And I was the CTO and I got blindsided by this. And I realized that's a bad thing. Whether you like it or not technology marches on. And the problem is any time you're heavily involved in a technology you are in a bubble. And you can't tell when the bubble starts contracting when you're inside. That's a really dangerous place to be in a contracting technology bubble and not realize it because one day you'll wake up and the bubble is contracted too small for you and now you've got to really struggle to catch up and move to another technology space. What this suggested to me is that you need to manage your technology portfolio much like you manage a financial portfolio. Because as an individual it's kind of the same thing. Because if you're making money writing software then you are managing your financial portfolio if you manage your technology portfolio better. This is where I see a great dichotomy between people where they do a lot of strategic long-term planning for things like finances but are very knee-jerk on technology choices. This is really I wouldn't say a problem but an issue in the agile world is that people like to get distracted by shiny things. And that's not necessarily a great way to choose technology as to whatever the coolest latest thing happens to be. So when we do an individual radar we use the exact same quadrants that we use in the regular radar. Techniques, tools, platforms and languages techniques are things like processing like agility falls in there continuous delivery would probably fall would certainly fall in there. Tools are things like IDs and editors and databases, things like that. Platforms are obviously Java.net but also JavaScript is a platform here anything that has platform like characteristics. And of course languages we're referring to computer languages there. One of the things, so let's say that you wanted to sit down and create a radar for yourself. There's a problem. Let's say that you're in the Java space right now. If they stopped innovating every single thing in the Java space today you could easily spend the rest of your life looking at the stuff that's already out there right now. And that's just one technology space. The point here is that this space is way too large to possibly navigate yourself and get any sort of reasonable assessment of the technologies that are out there. And so what you need are litmus tests. You need tests that you can apply to technologies where you can basically triage them to say should I spend more time with you or not. You need a few very coarse-grained decision criteria to decide should I pursue this technology further or not. I can't tell you what your litmus tests are. These are highly individual. I will give you some of mine and these may be useful to you but these are very highly individual. Particularly for this developer radar this is very, very ties very much into your personality characteristics. So I'll give you a few of mine. My main criteria, a litmus test for technology is testability. I'm a big agile guy. If I can't test it effectively it's not going to be that useful for me. So for example, I managed to avoid flex forever using this criteria. When flex came out I looked at it oh that's kind of cool. Is it testable? No. Okay. Don't even need to look at that. And now it has end of life before it became testable which is good for me because I never had to look one minute at flex. I managed to eliminate that whole category because it failed this really important litmus test for me. And I think this is a really good one because a lot of technology still fail this test. This is a really important criteria if you're doing agile development it needs to be testable in some sort of reasonable relatively easy way. Next one that I care about is integratability. How well does this integrate with all the other technology stuff that I'm using right now? You may have a wicked cool little technology but if it doesn't match nicely with all the other stuff you have, you'll end up even if you save a lot of time using this technology you'll waste time trying to get it integrated with all the other mismatched technology you have running around. Another one for me is narrow suitability to task. There's kind of a spectrum swing that happens in the technology world and we're seeing a spectrum swing right now is that people build these big giant bloated things that do one of everything but they do nothing particularly well. A lot of commercial software sufferers do this because they're actually trying to fill out a feature matrix not build a tool that's making your life way better. They're more interested in competing with their competitors in terms of features than they are specifically making your life better. They might accidentally make your life better but mostly vendors are trying to compete with one another to make money. That's what they're in the business for. And so you see this for example manifest in the JavaScript world because for a while in the JavaScript world these big giant frameworks like prototype delivery, now you see micro frameworks all over the place. Angular and backbone and mustache and Batman and all these things. These little micro frameworks just do one thing each. This is the pendulum swing going from the big huge comprehensive back to the simpler things. You see this in the Ruby space you have Rails which is the big full service stack web framework and you have Sinatra which is the very lightweight basically just routing framework that you can plug other stuff into. I tend to prefer as a technologist that are narrowly suited to tasks and then compose those and aggregate those together rather than trying to get these big comprehensive things and getting them to work. Another good litmus test as an individual are external references for things. A great place for that are things like conferences. This is a great way to kind of accelerate things through the trial and assess part of the radar because somebody else is basically doing trialing for you doing a conference talk. Obviously coming to a conference is the best way to get this because it's face to face and everybody here knows about agile and the richness of face to face communication but you don't even have to go to conferences to get a good feel for the technology landscape. Every software conference on earth publishes their agenda online and so the next monsoon Sunday that you have here if you're in the Java space go poke around at Java conferences all over the world and look at what people are talking about and you'll get a pretty good feel for what's really interesting in the Java space at that point in time. That's a really good way to find out what other people are interested in from a technology standpoint. You can also look for things like this. I doubt many of you have seen this book. The interesting thing about this book, Tricks of the Java Programming Gurus by Glenn Vanderberg was that it was written in 1996. Now Java came out in 1995 and this is the very first advanced Java book which came out less than a year after Java itself was released. Clearly Glenn saw something there that a lot of other people didn't because Java was not a runaway success technology from the outset. In fact it was kind of dicey for a few years as memory was very expensive and machines were very slow but Glenn clearly saw something there. You have to ask yourself the question well if he was this far ahead in 1996 on Java, what's he doing now? Does his crystal ball still work? There are a few technologists out there who seem to have good crystal balls and Glenn is one of them. I happen to know Glenn and I can tell you that he is working right now at Living Social doing a mixture of Ruby and Clojure. The two things that Glenn is very passionate about right now. Another great person to follow in this regard is Bruce Tate who is a famous author. I think Bruce Tate actually does have a crystal ball. Software development magazine releases a jolt award every year and one of the categories is books. Bruce has actually won two jolt awards which is almost unheard of. He won one for Bitter Java which is the first book to suggest that Java maybe wasn't the greatest thing since sliced bread and then he wrote from Java to Ruby and then he wrote a Ruby books and he's still in the Ruby space right now but he recently won another jolt award for Seven Languages in Seven Weeks which is another terrific book and it really reflects the kind of polyglot multi-language nature that our projects are really becoming more and more like now. So he's a really, really good, very prescient technologist. So one of the ways that you can shortcut your decision process is find people who have similar opinions to you and then follow what they do. I do this with movie critics. When I find a movie critic that has about the same taste I do, I read their reviews to decide if I should go to movies or not, you can do the exact same thing with technologies. And that's basically this one, find similar opinions, find other technologists who have the same kind of litmus test and the same kind of weighting criteria that you do and then look at the things that they're following and that'll give you a good jump start on things that you might want to follow. You have to be a little careful though with external references to things. You've got to chase down where is the providence of the data behind these things. There are famous cases of white papers that come out that prove that this technology is the most awesome thing ever. You dig two levels back and it's created by the marketing department of the company who released the technology so it's not actually a white paper at all, it's really just marketing that looks like a white paper. The classic example of this is the Tile B Language Index. How many of you are familiar with the Tile B Language Index? This is a site you can go to that purportedly tells you the popularity of given programming languages. But you have to ask yourself where do they get their data? And where they get their data is by slurping through news groups. And so let's say that you've just come out with a new version of RPG for the OS 400 and it's the worst release ever for RPG for OS 400. The news group is going to light up about how much I hate this new release and it's going to ascend to the Tile B Index Scale because if it's mentioned whether good or bad it goes up. That's why C has perpetually been at the top of this thing. It's not like there's that much development in C but there are hundreds of user groups saying why is my stupid C program not working? And that drives the numbers up on Tile B. So I would not use this and invest heavily in doing C development for your technology radar unless you're in the embedded space or somewhere like that. So this is a bit misleading from that standpoint. So always look at the providence of the data. You can look at Google search friggin there are lots of things that look for how many hits of the page getting and things like that. But make sure you know the providence of the data. Google's data is pretty good. You have to be fishy about things that are too much derived from vendors. One of things vendors like to do is hire consulting companies to produce white papers that are favorable toward a technology and then it's kind of you don't know if that's accurate or not. As an individual I do this about once a year for myself. In fact that's what kind of gave me the inspiration to do this talk was I've kind of informally been doing this technology assessment for a while and I formalized it after we started doing our radar. And for example I tend to do this in December every year because December's kind of quieter and things are kind of in the beginning of the new year. So for example, about two years ago I was splitting my time between the Java space, the C-sharp space and the Ruby space and while I was doing my radar I realized that there was a lot of really interesting stuff happening in the Java space around scholar enclosure and less and less interesting stuff happening in the .NET space for me. So I made a conscious decision and made me realize I kind of dread looking at the .NET stuff and I'm really excited about looking at the scholar closure stuff and so that's where I should be spending my time. In fact for the last two years that's exactly what I've done. So building a developer radar I think is kind of a no-brainer. This lets you manage your knowledge portfolio in a more strategic way and encourages analytical thinking about really critically important career choices for you as a technologist because of the technologies you know define what jobs you can get. And it helps proactively guard your career so I think this is a useful exercise where you go through the formal writing it all down or just kind of informally go through this I think this is a makes good sense for individuals and kind of a no-brainer I think. But here is a place that you might not think this applies but in fact much more important I think than the individual radar is the company wide radar. And the way this came about was so ThoughtWorks started producing our radar I think in 2007 or 2008. And I was speaking at conferences not doing any kind of talks about radar or anything like that and I had several people come up to me after a talk and say hey you guys produce the technology radar right? They said you know we did that exercise for our company it was the greatest thing we ever did. We hadn't thought about that having companies self-assess themselves using this radar metaphor. Then we started thinking about it and we realized to do this and I've we've now figured out six really good reasons why your company should do this. Here's the first. So I'm sure you're all very familiar with the Gartner adoption curve for technology you have the innovators who are the first ones to adopt the technology and then the early adopters and then the early majority then the late majority and then the laggards. For any given technology there is a perfect place for you to be in the Gartner adoption curve. Let's say that you are in the insurance business you don't really care that much you think about let's say functional programming and so you can afford to be a laggard on that technology because that's not going to make a big business impact on you but you have huge data sets and so big data is really important you need to be an innovator an early adopter for that to make sure you don't get behind. Every single technology you use there's an ideal place for you to be on this curve that balances risk versus value. The problem though is trying to capture all those adoption curves is that you don't have this one technology you don't have 10 you have thousands of technologies every open source thing you download, every technology you buy those are all technologies and they all have an adoption curve and they all have a perfect place for you to be on that adoption curve the point of this is if you take our quadrants and kind of overlay them on these adoption curves and then drop a snapshot line through it and then rotate the entire thing 90 degrees organization so let's say that you have an organization that has an ivory tower CTO or it's a group of architects technology decisions that are not intimately involved in hands day to day kind of coding and let's say that this ivory tower CTO comes and just kind of does management by walking around chatting some developers he'll bump into some developer that says I'm really excited about some new random thing I just read about, okay that's cool talk to another group of developers they're really mad at Maven for some reason you're probably post technical so you're not quite sure why but okay that's nice to hear you go talk to somebody else you're talking about something you've never actually heard of but okay that's kind of nice you go talk to another group of people it turns out they're discussing the palm your tech post technical you don't know that's also Maven but okay I can kind of come in and iterate with that but then when you ascend back up into your ivory tower your impression is a lot of developers complain a lot and they're really passionate about weird things I can't figure out why they're so excited about the stuff I've never even heard of this is a problem in the agile space because agile developers love new shiny things and love to be able to adopt those things very quickly but here's what never happens almost never does the CTO gather all the people together who are impacted by his decisions and ask them did I do a good job choosing that technology this never happens in big enterprises because bosses hate it when their underlings tell them they're stupid and so they never give them a chance to do that but that's a problem because I'd be willing to bet a lot of you work for companies where the developers hate the technology they're using and somebody else is making decisions about that and there's no feedback loop that's the fundamental problem this is a missing feedback loop from the people who touch it every day from the people who may pay money and make decisions about this stuff this is where the radar comes in very nicely because it gives you a unified form of communication it gives you as a group a way of putting together a non-confrontational document that says here is our objective assessment of our technologies and the CTO can look at that and act on that without having to ask the question that makes him look like he doesn't understand the technologies anymore that's a really really important thing so this becomes a really great way to get together and have a unified message to non-technical but interested people including perhaps your CTO and CIO who are a little bit post-technical and maybe don't quite understand all the implications of the technology that they're choosing this gives you the feedback loop back up to them to explain why we should be doing something versus something else this is purely selfish but this is also a great excuse to get together with a bunch of other technologists and have in-passion conversations about technology if you're like a lot of large enterprises you probably have a Java development group and a .NET development group and some Ruby guys and PHP and some other stuff running around and you probably never get much out of your monoculture the Java guys probably don't talk to the .NET guys very much there's huge value in getting that group of people together and discuss technology choices because you'll find a lot of commonalities here's a classic example of that I have a friend who works in a giant insurance company and he's in the application development group and they've been trying to get Ruby approved on the official list forever but the CTO is like no you're the only group that wants it so we don't approve one-off technologies and then they did a technology radar and it turns out there's a group of PHP developers in a completely different part of the company who really want to use Cucumber and Ruby and so that popped up on the radar oh we have multiple groups who want to use it two weeks later Ruby is approved for more than a year they tried on a monthly basis to get Ruby approved as soon as they found out that more than one group needed it okay approved that's the benefit of having that unified form of communication and the last two reasons you want to do this there are business views on technology and there are IT views on technology and you would hope that those are in sync with one another but sometimes they get out of sync for example maybe from a business standpoint you merge with another company that has really dysfunctional IT I've seen this happen a bunch of times and now all of a sudden the technologists are scrambling to try to get back to the point that they were before this gives you a good indicator of is the business technology view aligned with the IT view on technology because now you have a radar and over time this becomes a really important decision making tool because it gives you an objective way to assess technology choices over long periods of time based on real data from the people that are using the technology yes business view on technology is we need to buy that company because they have something we need without looking at the IT underneath can I talk about this company there's a really well known company whose name I can't say who really wanted to expand into a particular business area and so one of the things that they did they produced paychecks for companies it's an outsource for paychecks and one of their claims to fame is you give us any format they will basically if you scroll it on a piece of toilet paper with crayon they'll figure out a way to scan it in and get that data into their system well they bought this other company that had this really slick little thing strategic for our business and then the technologists discovered that piece of technology had to have this really rigid well defined data format and there was no way to get all these crazy data formats they are accustomed to into that format in any kind of sane way so now the business has made a decision that the technology people literally cannot reconcile now so the ten million dollars they paid for that company write it off because they didn't have a good business and technology view aligned as to whether we should do that or not that's my example when you do this for a company the normal quadrants we have are techniques, tools, platforms and languages languages should be a consideration for companies but frequently is not and so when I do one of these for a company I tend to move languages up to tools and add something that is very important to big enterprises which is package or commercial off the shelf software which is an assessment that companies have to make that individuals typically do not have to make there are litmus tests here as well but the litmus test for a CTO is very different than the litmus test for a developer so I would ask you to put on your CTO hat for just a second and think about what litmus tests you apply to technology one of the litmus tests is probably going to be exactly what you mentioned licensing and cost because for a CTO cost is everything even open source technology costs a CTO lots of money you pick Angular a JavaScript framework which is free it's open source but now you've got to send all your developers for training for a week and you've got to pay for hotels and airfare you've got to take a productivity hit until they get up speed on it there's always cost for any technology and you have to balance that on your radar this unfortunately has been a question that CTOs have asked forever where can I find a million cheap developers and whatever this technology happens to be this has forever been the wrong question the correct question is I should take all the money I'm paying these 50 developers and split that across like 4 or 5 unbelievably good developers you will actually produce more quality software with 5 really super good developers than 50 mediocre developers this is not news we have actually known this since 1975 when this book came out mythical man month this is a fantastic book still because it is so schizophrenic now because the book gives you a mix of technology advice and project advice and the technology advice are things like you should consider using a high level language rather than mainframe assembly language so the technology advice is ridiculously outdated the management advice could have been written yesterday so we are still doing the exact same stupid things now that we did in 1975 around staffing and things like that this by the way makes a great gift for your CTO another thing that I have seen a lot of CTOs obsess about a lot is what choices most likely to cost me my job back in the late 90's when I was with DSW one of the technology we moved to was Delphi which is a really nice technology for doing client service systems and this big competitor time was PowerBuilder so we had negotiations with this big giant company and the big decision was PowerBuilder vs Delphi and we finally got down to the last big meeting and the guys told us we think that the only way this project could possibly be successful is choosing Delphi because we can get it done a lot faster but we are picking PowerBuilder because it is the industry standard we know the project will fail after two years with PowerBuilder but there is no way we are going to lose our job for making this choice whereas there is a chance we could be really crazily successful with Delphi there is also a slight chance that we could take a hit for that politically so we are not going to take that chance so they relegated 20 developers to two years of a known cancelled project just because they didn't want to take a chance of losing their job and yes this is someone covering their ass one of the things that CTO should be really concerned with and I don't think are concerned enough about this competitive blindside we are at a time in the technology space where really strategic use of technology can give you a huge boost over your competition continuous delivery is actually one of those things we have a client this is one of our favorite success stories recently you know cycle time and continuous delivery is the amount of time when you start working on a problem and when it shows up in production we recently had a client who had a cycle time six weeks that we reduced to two and a half minutes now if you can now bring out new releases a hundred times faster to your competitor if you can't beat them in the marketplace you should just give up there is at some point where technology acumen becomes a business advantage and it's happening in several different places now there is a fantastic story around this that comes with a really horrible epilogue there is a great story in the cathedral in the bazaar sorry no yeah not cathedral in the bazaar hackers and painters by Paul Graham who talks about via web which is the very first build your own online e-commerce site this is where Paul Graham made all of his initial money and when they built via web they built it in Lisp which is a very unusual technology at the time and they never said anything about that but the consequence of that decision was they could actually everybody else all their competitors were writing in C primarily and so anytime they implemented a new feature it would take months for their competition to implement that feature but anytime they implemented a new feature they could usually get it knocked out in a week or two they had this huge technology advantage they could run rings around these guys and Paul Graham said that when he was running via web he always looked at his competitors job if they were asking for C.R. Perl or Python developer C.R. Perl develops he didn't worry about them if they were asking for Python developers he worried a little bit he said if somebody were trying to hire Lisp developers I would have gone into a blind panic because now he would have to compete on an equal footing from a business standpoint whereas now he has an advantage from a business standpoint because he can run rings around those guys so here's the horrible epilogue now who purchased via web this is where Paul Graham made his initial millions and didn't understand the technology so they rewrote it in C all they purchased that for they immediately threw away because they didn't understand the technology they tore down their advantage and put themselves on a level playing field actually put themselves behind because now they're having a catch up so package and commercial off the shelf software is a special category you need to verify everything the vendor says have a geek look at the contract to make sure they're not sneaky terms in there we've had several places where someone promises it will do X it won't do X but then you can pay the vendor to do X but then you sign a contract where they retain ownership of that code of course it gets rolled into the next version of their product so you're basically being an angel investor for them negotiate licenses for things like continuous delivery and try to measure technical debt for these things the software is not all benefit there's some downsides in terms of technical debt so you should measure that as well and so there's my company radar with package and cots in the lower right hand corner so building a radar the exercise is more important than the artifact if you don't produce the little pretty picture there's no harm and no foul it's the prod fault process that is important for this it gives you a chance to think about the near-term and long-term future both to tactical and strategic when you do this for a company try to avoid politicizing it's very easy for the Java guys the Ruby guys to try to kick sand in the face of the PHP developers but you should listen to them because they have valuable insight into technology that you may be missing so try to keep an open mind and revisit the process periodically for most companies we actually recommend doing this a couple of times a year particularly if you're in a place where technology churns a lot because the more of these you get the more kind of assessment you have the more history you have in making these decisions and maybe your decision processing a little better there's one other benefit of actually doing one as an individual and as a company because when you have the same artifact for those things that allows you to do a delta between those things and decide is the company I'm working for going in the same technology direction my radar suggest that I should be going in because notice radar can be used as a defensive tool but also be used as an offensive weapon building a radar might let you decide maybe the company I'm working for is not going in the right technological direction maybe I should choose a different company that is going in the right direction this metaphor is getting a little more popular out in the world it would be my dream come true someday if you showed up for a job interview and asked the company could I see your technology radar so I can compare it with mine and make sure we're a good fit with one another that is a really good way to see how close we are compatible from a technology standpoint is just overlay the two radars and see how much things line up so really nice concise metaphor so I'm a little bit over time so I'll thank you for coming I'll answer a few questions if you like any questions left over about this or perhaps you'd like to get to lunch I don't know is lunch now actually half an hour I think any questions left over about this I'm sorry you'd like to have well there's actually an article on the ThoughtWorks website about how to build a technology radar that goes through some of the logistical steps yep so you can just go to ThoughtWorks.com and do a link there any other questions