The panelists talk about technology radars with Neal Ford.

 

Hey everybody and welcome to episode 84 of the iPhreaks Show. This week on our panel we have Jaim Zuber

Hello, from Minneapolis.

I’m Charles Max Wood from DevChat.tv and this week we have a special guest, Neal Ford.

Hello.

Neal, do you want to introduce yourself really quickly?

Sure. I’m Neal Ford. I work at ThoughtWorks. I’m a Director, Software Architect and Meme Wrangler, which is a side effect of ThoughtWorks allowing people to choose their own titles.

I live in Atlanta, or at least my mail is delivered in Atlanta because I travel a lot as a working consultant – and by travel a lot, I mean I’ll make about a moonshot this year in air miles.

Wow. So this week we brought you on because Martin Fowler told me about this idea you had for building your own technology radar. You want to give us a thumbnail sketch of what that's about?

Sure. ThoughtWorks, the company I work for, we’re a big international consulting company and we have this group of people within ThoughtWorks called the Technology Advisory Board and we meet face to face two times a year and build this thing called the ThoughtWorks Technology Radar. If anyone’s interested in seeing this thing in a near computer, if you go to ThoughtWorks.com/radar, you’ll see the current interactor version of this thing.

51], and also tools that we think you should try to avoid and stay away from.

We have several different quadrants that have different categorizations of tools; we have different rings within the radar that indicate our level of like or dislike for something, and we put that out a couple of times a year. The next new version of the radar will be out early January next year, because we’ve already gone through the exercise in Recife, Brazil about three weeks ago.

We’d been doing this radar thing as a white paper since 2010. I was speaking in a conference, talking about – some of the things that I talk about at conferences are usually about software architecture or related to subjects like continuous delivery and things like that. I had several people come up to me after my talk and just casually mentioned that they had downloaded the ThoughtWorks Radar and they thought it was kind of cool and they had used that radar metaphor to build their own radar within their company. That made me start thinking, “Hey, this is actually a pretty good metaphor for capturing this kind of information” and I realized that it’s really applicable for people to use to build their own radars – in fact, two different radars. One for yourself as a

career guidance tool and another for your company as a way to help better assess the actual consumers of the technology, getting a feedback loop back to the purchasers of technology, to make sure they understand what’s actually working and what’s not working. We’re finding a lot of companies have a broken feedback loop that the people who really consume technology, their opinions don’t really make it up to the people who make decisions about it and this radar metaphor becomes a mechanism for them to do that.

That’s basically my insight into this technology radar thing. It was this idea that you could actually use this metaphor both as a career planning tool and as a way to make the world a better place inside your big, giant company.

I think I kind of get the idea where you have rings or areas I guess –.

Let me talk about the rings. There are four rings on our radar. The outermost ring is Hold. For the ThoughtWorks standpoint, any technology we put in Hold, we’re basically saying, “Proceed with caution.” We realized we’re pragmatists; you can’t just instantly stop using some technology when someone said they didn’t like it for some reason, and so when we put something in Hold on our radar, what we’re suggesting is “Don’t start anything new in this technology, that there are probably some better alternative technologies out in the world to solve this problem.”

So it’s something that might be a little bit outdated or moving out or something that’s not ready for primetime?

Yes, all the above.

Or something that you’ve adopted in the past but just isn’t working for you the way you want anymore.

Yup, absolutely. All those things are true about things in Hold. For example, we put things in Hold like enterprise service buses because we hate enterprise service buses. We much prefer the choreography enterprise integration pattern over the orchestration integration pattern, which is what an enterprise service bus does. We put that in Hold because we’re trying to suggest an alternative.

A couple of years ago, the things that ended up in Hold kind of ended up being controversial sometimes. A couple of years ago, we put Java language in Hold because at the time, the JDK had dried up. I mean, there was a time that Sun, when they had stopped having the capability of producing new JDKs, the entire pipeline for using JDKs just stopped. We looked at that and so that's a really bad thing.

We didn’t say step away from the JVM; what we were suggesting was there are better languages on the JVM to build something in Java, because at the time, Java was starting to look like a very antiquated language. Other languages were living much more quickly, so we put the Java language on hold, which was of course very controversial because that’s still where most of our project work is, in Java.

But then, Brian Goetz became the Chief Architect of the Java ecosystem and they rebooted the JDK pipeline and put out Java 7 and then put out Java 8. We now have lambdas and so they’re now evolving the language again, so we moved it back out of Hold back into Assess, which is now saying “We think it’s worth thinking about using Java or brand new projects now because it is now back in the same kind of evolutionary stream that other programming languages are.”

So how soon can we get rid of outdated frameworks like Android?

Wow, that’s going to take a while [chuckling].

Seriously.

We do have a category – when ThoughtWorks was to get the radar a category called Too Complex To Blip and I think Android in Hold would probably in the category of Too Complex To Blip, because it’s a little too nuanced [chuckles] to capture with just a blip on the radar somewhere.

A more reasonable question: what are some of the more recent things that have gone on Hold?

Enterprise service buses get put on Hold a lot on our radar. Things like the WS-* stack, we put on Hold; we prefer REST style integration over the kind of SOAP-based integration.

Okay. In the mobile field, what’s going away? How long it was Blackberry?

Well Blackberry’s been gone for a long time. They'd been on life support for quite some time. Things that we have on Hold currently are things like Ignoring the OWASP Top 10 list – we think that’s a bad idea to ignore that.

Oh, why? Come on! [Chuckling]

For obvious reasons. DevOps as its own team is something that we have on Hold. We put OSGi on Hold, which is a pretty relatively controversial thing. See, OSGi is a good example of a technology that actually works pretty well for the thing that it’s trying to do, but we find that people end up using it for ill-suited things. Ultimately, the problem with OSGi is they’re trying to build a capability into Java that was never meant to be in Java, and it’s a really, really leaky abstraction and so it ends up in a lot of churn.

44] mobile space has handwritten CSS and JavaServer Faces. Those are not unreasonable things to have on Hold.

I think we have an idea of things in Hold. Hold is something that you are ceasing any new operations in; these are things that you already have used or tried out and are no longer going to move forward with unless the situation changes somehow.

Exactly. There’s one particular piece of technology – Intentional Software, Charles Simonyi’s company – there’s this really elaborate, really cool language workbench thing, and it keeps being right on the edge of Assess, of Hold, because there’s so much promise in the vision that they have for this tool. But then we look at the actual implementation and we move back into Hold, and we look at the vision, and we move to Assess, and we look at the implementation, we move it in Hold, so it’s kind of skirted back and forth across that line.

Hold is the only right that we have that’s in any way negative on our radar. The others are various degrees of research and development versus Adoption.

The next ring in from Hold is called Assess, and that’s the general R&D ring of things that look promising but we haven’t had a chance to really kick the tires of it yet. Trial is the next one in from that, and anything that shows up in Trial on our radar means that we’ve tried it on a real project and we had found it to be good, to do what we were expecting it to do. That’s a pretty firm statement for us, that something moved from Assess to Trial, because it’ really just promising vision versus promising implementation and really does what you want it to do.

Finally, the innermost circle is called Adopt. Those are the things that we consider no-brainers. The kind of criteria we have for this – Mike Mason is one of the members of the TAB and his criteria is, if you’re using some sort of hideously broken technology, we won’t give you grief about it at work, but we will give you grief about it at the pub later, so we’ll make fun of you at the pub if you’re not using something that’s on Adopt. That’s our criteria for that, but if something is in Adopt, it’s just a total no-brainer.

Things we have in Adopt right now, for example in languages, we have things like DocWizard, the Go language from Google, Java 8 we have in the Adopt ring now. These are all things that we definitely use, we definitely like; they have really good best practices for them and we’re super recommending people to go forward.

I want to talk a little bit about the Assess Ring. I’m wondering, how do you get things in there? How do you encounter things that you want to try?

This actually is the difference now between the ThoughtWorks radar versus the one that I try to encourage people to build for themselves. The ThoughtWorks radar, the way that we come up with the things in Assess is the TAB is this group of a couple of people from each country in ThoughtWorks or each region. We have about 15 countries now that we are in within at ThoughtWorks; we’re about 3,000 people worldwide. All the TAB members, the ones who actually put this radar together, before we meet face to face, we go to project teams within our region and solicit contributions to the radar for things that they want to see on the radar – either good things or bad things. And so we come into this meeting with a really long list of things that we want to nominate in each one of those quadrants, including Assess. For us, it’s really driven from groundswell of actual project work [inaudible 12:00] ends up populating the original list and then we go through a calling exercise as part of the TAB face-to-face meeting to make sure that it’s not just some one-off technology that it seems to have a broader appeal across lots of projects within ThoughtWorks.

When you’re doing this exercise on your own, one of my suggestions is actually use this radar metaphor to build a technology radar for yourself because I think that a lot of technologists are very tactical from a career management standpoint and not very strategic in that they’re not really thinking long-term about what kind of technology you should buy and be investing my time and effort into. It’s much more likely to be distracted by a shiny thing and then follow that for a while and be distracted by another shiny thing and follow that for a while. While that’s a fun way to build a career, it may not be the most sustainable from a financial standpoint. When you use this radar metaphor to build your own radar, what I’m suggesting is for this Assess phase, what you need are some really good litmus tests that you can apply. When you look at new technologies, you need a

few triage kind of tests you can run against that technology to say “Should I invest any more time looking into this technology?”

Here’s an example of one of those. I’m really big in the Agile software development and I really like Agile engineering techniques, and so one of my big litmus tests every time I look at a brand new technology is how well does it fit into this Agile engineering ecosystem.

For example, how testable is this technology? Is it really easy to test this on multiple levels? If it’s not, then I set it aside until its testing score gets better or it dies. For example, Flex. When it came out, I looked at it and said, “Well that looks kind of cool” that I looked at its testing score, which is really anemic, so I said, “I’m not going to look at Flex until its testing score gets better or it dies.” It died, so I didn’t waste any time with it.

And so it didn’t even make it into Assess.

No, because it didn’t meet that first criteria for me, which is testability. I think it’s important as a technologist, from a career-planning standpoint, to start thinking about the things that you really like out of technologies and the things you don’t like out of technologies. A lot of this is very personal; it has to do with things like how accommodating are you to change, do you like change, do you hate change? A lot of those things will play into exactly what kind of technologies you’re going to find yourself drawn towards versus the ones that you’re just having to endure.

Let’s say I hate change. How am I going to approach my radar?

In that case, what you’re going to do is look at radars that you can double down on. Pick something that’s a really good, employable space right now. I do this as a conference talk, build your own technology radar and one of the things I solicit from the crowd is what’s a really good, safe, nobrainer kind of technology to be invested in right now. One of the common answers I get back is pretty much anything right now in the HTML5, CSS, JavaScript space is really, really safe right now. And so if you really want to double down on that career to get really good at JavaScript and that sort of stuff and you’ll have a pretty nice career path at least for the next four or five years.

Probably an even more stable one is something like Spring and Hibernate and the J2EE space because Java has become the COBOL of the 21st century in a good way. That’s the way people write business applications in the 21st century, and so if you don’t like a lot of change, then invest heavily in that space and you’re going to see small, incremental change for probably the rest of your life, but I’m pretty convinced that there are Spring configuration files that will outlive all of us.

Definitely.

Just like this [inaudible 15:38] COBOL code that will still outlive all of us. If you don’t like change, then that would be the perfect place to really start holding your efforts in that space, but if you really like radical change, then I would suggest plugging in heavily into the JavaScript web framework space.

That sounds good. I suppose it’s probably not the most useful question for our audience, because if you don’t like change, mobile is probably not where you want to be.

Yeah, that’s probably not the place you want to be in. I would say this audience is much more – not only just used to change, but probably enured and known to change by now.

So one of the things we do on our radar is try to identify trends, and one of our last trends in our radar was churn in the mobile space – JavaScript and mobile space, because it’s just changing so fast all the time. It’s like trying to chase a running freight train.

I do want to bring that up a little bit. This show is about iOS development, so in some ways, it’s fairly limited. We’re not really going to be talking – unless you’re using Ionic framework or Famo.us or something like that, you’re not really going to get into the JavaScript world or a lot of these other areas that are changing. The changes are mostly dictated by Apple, and then the rest of the changes are dictated by the community. But things like the language – it’s either Objective-C or Swift, so you could put Swift on here I guess –.

Which is there. It’s going to be on the next radar, NSS. We also have engineering practices around iOS development on our radar. We have continuous delivery for iOS devices that’s been in our Assess for the techniques for a while. It’s in Assess or Trial. We’re actually doing some sort of a project, so this is in Trial now.

So I guess the question though is, do you put things in here that you see at the Apple keynotes, or do you –?

No, we respond very poorly to marketing stuff. If somebody mentions something at an Apple keynote, what’s going to happen is some ThoughtWorker is going to download that and start trying to build real stuff with it, and only if we can actually build real stuff in it do we actually start talking about putting it on the radar.

Even if one team finds something cool and starts building cool stuff in it, that’s not enough to make it on our radar because we usually end up with about twice as many blips that will fit on our radar, and so we call the things down that we don’t think is going to have a big enough impact, industrywide. We’re really trying to take a global perspective on this, seeing how this is going to impact technologists all around the world, not just in particular ecosystems.

Okay. I mean, what we’re looking at here is you’ll have things that are like Swift or some new Cocoa Pod or some technology that helps you build or move your process along one way or another, or some practice like TDD or things like that that you can throw on your radar and start working on and then assess whether or not it makes sense for you to move into Trial. It seems like there’s a lot more process around doing this for a company as opposed to doing it for a person.

There is more process for doing this for a company because you’re trying to assess company-wide what works well. The real benefit for doing this from a company’s standpoint is actually not the asset you create; it’s the exercise that you go through. It’s having these conversations about technology with all the technologists in the company together is what turns out to be a really, really valuable exercise.

For yourself, particularly if you’re in a relatively closed ecosystem like iOS, there are not a lot of things that you could do on a radar like this because someone else is mostly controlling the ecosystem, but I will also strongly encourage to look outside that ecosystem and see what kind of cool stuff are there. There’s a lot of really cool testing frameworks, a lot of cool things that support continuous delivery engineering practices that are available to that part of the Apple ecosystem that are useful in the Apple ecosystem. Anytime we identify one of those things, we try to highlight them.

I think it’s actually a mistake. This goes back to one of the stories that I tell as I talk about building a radar, and this is very applicable to the people that are listening to this podcast, back a long, long time ago, I was the CTO of a trading and consulting company that did development in Clipper. Have any of you guys ever even heard of Clipper? It was an ancient DOS-based technology that was object-based and there was a library called Class(y) that would make it completely objectoriented. We build this really nice object-oriented application, developed that framework, and we did training classes in Clipper and we had consulting projects in Clipper – and then Windows came along it was like somebody turned off a faucet overnight. All the Clipper work disappeared almost instantly; we had to scramble around and find a new thing.

one is whether you like it or not, technology keeps moving on. When you signed up in this field, you also signed up for a lifelong course in continuing education. You can’t stay still in this world because the world will leave you behind.

Any time you’re using a technology, particularly a technology that is being managed by a company, it’s really hard – you’re basically then living in a technology bubble, and when that bubble starts collapsing, it’s very, very difficult to tell from the inside that it’s collapsing.

This is even worse if it’s something that’s controlled by a commercial company, because they will hide the fact that that bubble is collapsing from you, because it’s in their best interests to keep you engaged in that community, in that world, as long as possible.

Now I’m not for a moment suggesting that the iOS ecosystem is in danger of collapsing anytime in the future because it has a very healthy ecosystem, but you have to be cautious. Any time you have a technology platform that is so tied to a vendor, you’ve got to be careful to always be objective when you look at that technology, to make sure you’re not just drinking the vendor KoolAid all the time, but you are actively looking around at different parts of the ecosystem to see if other people are doing interesting stuff, or maybe building, or replacing the tools or techniques that the main vendor is not talking about.

I want to ask another question about the radar here. How much of this is a mandate to use or mandate to try or mandate to have the conversation, versus just kind of a “hey, this is what we’re looking at these days and so we recommend rather than mandate that you check this out or try it out”?

For the technology radar, there's an implicit “Here, use this where applicable.” We may put something in Adopt that is really applicable but only for some kinds of projects.

For example, let’s say that we put – one of the things that we have in Adopt under Techniques is Dependency Management for JavaScript is a good example of that. That’s something that’s in Adopt for us, Dependency Management for JavaScript. If you’re not doing dependency management, you’re probably going to drive yourself crazy.

What we’re saying there is if you’re not using JavaScript in your project, we don’t suggest you start using JavaScript just so you can do dependency management for JavaScript. Adopt for us doesn’t mean to go out of your way to try to adopt this, but we’re saying that if you’re in the JavaScript ecosystem, then this is kind of a no-brainer to try to use this.

What we’re trying to do on this radar, these are all things that we’ve vetted. We would never put anything on here that just looks kind of cool but we haven’t actually done anything with it. we have way too many technologies that we’re trying to assess, so everything that shows up on our radar at Assess is something that we’ve done some research and development on and we think it’s very, very promising or it wouldn’t show up there at all.

There’s no mandate to use any of these things, but the closer it gets to Adopt, we’re making stronger and stronger suggestions that “Hey, this is really a technology you should be looking at because it’s cool or innovative in some way.”

So you talked a little bit about continuous delivery as in the Adopt in the mobile space. Some of the things that I see coming down the pipe, a growing interest in using JavaScript in your native apps, maybe using more HTML – is that even on the framework [inaudible 23:26] that we’re discussing?

Does that make sense too?

That would probably show up in a technique somewhere. We don’t have that called out specifically as a technique because I think that’s really common. We actually have a framework that a bunch of ThoughtWorkers created called Calatrava that’s an open source framework that lets you build single code-based applications that run on iOS and Android and several flavors of Android. The way that it does that is by capturing all the common stuff in JavaScript – all the workflow and business logic and that kind of stuff – are captured in JavaScript, and so that’s an example of a framework that already does that. It embeds JavaScript in there to give you device independence.

We might call that specifically as a technique, but we just call that [inaudible 24:07] specifically because I think that’s a relatively-common practice in the JavaScript space.

So do things go from Adopt to “goes without saying that we’re going to do this”?

That is the closest thing to a no-brainer category that we have. We’re basically saying, if we put some sort of version control in Adopt, it’s a no-brainer to use that in almost all of the situations where you might find yourself using something like that.

But the things that move into Adopt for us – one of the things that confuses people a little bit about our radar is that our blips age off after a time, so if a blip hasn’t moved in two full radars, which means it hasn’t moved in a year, it fades away. What happens ultimately to our technologies is that they pop up in Assess, and then they move their way through Trial, and they hit Adopt, and then they don’t move from Adopt because we still like them, and so after two radars, they fade away.

There is, actually, if you look at the radar page, there’s a Radar A-Z category at the top. If you’re curious to see if any of your favorite technologies have ever showed up on our radar, you can go to the A-Z and you can see all the things around a particular technology that has shown up anytime on our radar – not just the things that we aged off in adopt, the things that we aged off because they didn’t move at all.

For example, hosted solutions for testing iOS is one that showed up on our last radar in July 2014 in Assess and it was also on radar on January 2014. For our next radar, if this one doesn’t move, then it’ll fade away automatically because it’s been in the Assess quadrant for two radars. Typically what happens is things move into to Adopt and then they fade out after two radars.

If you’re interested to see something interesting, for example, if you go to Radar A-Z and type in iOS, you’ll see a good 20 or 30 different entries that have happened around iOS over our radar over the last four and a half years or so that we have been building this radar, including continuous delivery for mobile devices, which moved into Adopt in January 2014 and so it will still be one adopt on our next radar, and then it will fade away because we’re not viewing that as a no-brainer.

Going with the radar metaphor, effectively you’ve moved right on top of it and so it’s not a blip on your radar anymore.

Exactly, we’d incorporated that. We were actually trying to be really loyal to this radar metaphor, which is one of the reasons we have Hold and not a Void. A Void, I think, would be kind of a fun category to have because it would let you – when you say terrible things about all the bad decisions you’ve made in the past, but that’s not a very forward-looking kind of exercise and we want this to be relentlessly forward-looking because we’re trying to assess the future. The most negatively bad thing we’ll say about things in the future is don’t use them. That’s Hold for us.

Right, and then if it comes back on later, then they can come back to Assess and Trial again if something changes in the ecosystem.

Exactly, and that happens sometimes. A new version of something will end up getting reassessed and readopted.

So one other thing that I’m seeing, and this is something that I run into all the time. I mean, I’ve got my fingers in a lot of pies – I do Ruby and JavaScript and iOS. I dabble in DevOps and I’ve got a bunch of other fun, little things that I do. I’m pretty bullish on Angular.js in my web development stuff. I like to play with robotics and stuff like that, so there are a lot of things that I want to do. How do I not get an Assess category that I’m never going to actually work through all the stuff in it?

Well, you will end up with an Assess category that you’ll never work through all the stuff in it [chuckles]. That’s the nature of the world, because there are just way too many cool things in the world.

What I’m suggesting is, this radar metaphor, when you use it for yourself, is a way to actually get all those things in front of you so that you can start deciding “How do I want to prioritize these things?”

In my experience, a lot of technologists – I don’t know if you’re this way – as you work on something for a while, it’s like “Ooh, shiny!” and you start working on that, “Ooh, shiny! There’s something over there” – there’s not a lot of strategy about “What are my long-term goals as a technologist and how is this supporting those long-term goals?” Being able to put them all together so you can weigh the priorities against one another I think is a useful exercise.

I don’t think this radar metaphor is perfect for that purpose, but I think one of the reasons it has become popular is because it’s a way to capture that information when there was no real way to capture that before. While it’s not the perfect way to capture it, nature abhors a vacuum, so I think this has filled in a spot that was a vacuum before.

Yeah, and I guess the other thing is that you can handle it like you handle most other prioritized task management, and basically, you have your column or ring or whatever you want to call it for Assess. You pick the thing that you think is going to have the most payoff, be it the most interesting or the thing that is going to impact your business or your employer or whatever the most, and you assess that. Once you’ve assessed it, then you can move it into Trial and you can keep fiddling with it on a trial basis, while you choose something else to assess when you have assessment time.

That’s exactly how you use this as a way to try and keep track of all the balls that you have juggling in the air at a time. That’s a way to prioritize things.

It also seems to me that you could – for a company, it seems like having a standardized process around this where you create this radar at the beginning of the year, or maybe twice a year or something, makes a lot of sense. But for your personal radar, you should be able to toss things onto your assess pile whenever you want.

Absolutely.

I’ve heard about this library, so I’m going to drop it in there and do it.

Yup, and at the end of the year, look at all those Assess things and decide, “Okay, which of these things will I move into Trial?” This is the way to triage the interesting things in the world and then sit down at one time and think about all those things together and prioritize what you’re going after.

Mm-hm.

That’s exactly what this is useful for. In fact, the companies that we – we do this exercise for companies as well and we have several clients who are going through this exercise once a year to update what’s going on in their current radar. They’re using this as a decision-making tool.

So it’s an exercise. If I’m an iOS developer, Mac developer, we would use this for, say, do I want to stay with Objective-C or do I want to go to Swift? So we would put Swift in the Assess category and try it out and wait to see how the industry is going. Is it being adopted?

That’s part of what you would do. One other thing that I encourage people to do when they’re trying to assess new technologies – Rich Hickey, who’s the creator of Clojure, has a great quote and I’ll quote him here, that “developers understand the benefits of everything and the tradeoffs of nothing.” This is a problem that developers have when you see a new technology and you get really enamored with the shiny bits of it, but then you don’t think about what are the negative implications that this technology might bring with it.

One of the things that we recommend doing is when you’re trying to assess new technology is to actually build a feature matrix just like commercial pieces of software have where you talk about all the things that it does. But rather than just a list of features that it has, think about the problems that you’re going to need to solve with whatever this particular technology is – what kind of applications you’re going to need to build, what kinds of things you’re going to have to plug into your existing ecosystem.

Let’s say there’s a brand new web framework that comes out that looks really nice – Bob’s Web Framework – and you go to Bob’s Web Framework page and he extols all the virtues of Bob’s Web Framework. But when you go to the bottom of the page, it’s not going to say, “Oh by the way, Bob’s Web Framework really sucks when trying to do authentication and authorization in your company.” So you need to be able to assess whether it does that or not.

30] sweet spot that it’s optimized for versus these other things.

Yeah, I also want to point out that sometimes it’s because it lacks features and it seems like that’s the most obvious thing, but sometimes it’ll actually have features or functionality in it that will get in the way of what you’re doing. That's why you need to try it out because you may find out “Okay, it looks like it has everything I need,” but in reality, it does this one funky thing that makes it really hard for me to get the one thing I need done.

Yup. That’s why a common antipattern I think that developers fall into is that it’s actually a famous, classic antipattern called the boat anchor antipattern, when you’re abusing something that has way more capabilities than you need because it’s nice or it’s expensive or we paid a lot of money for it, or we spent a lot of time writing that thing, and so everybody has to use it for something.

I actually view that as technical debt. Anything that you use that’s in a framework or a tool like that that you’re not using right now is just technical debt. Because it’s in the way of the stuff you’re using, and until you start using it, it’s just going to be technical debt.

Yeah we talked to Martin Fowler on Ruby Rogues and we talked about refactoring. We did get into technical debt and it seemed like technical debt was essentially anything that slowed you down on the project.

Well, it’s certainly one of the side effects, is it slows down the velocity of the project. It’s just like gardening – when you let weeds continually grow up, before long, you can’t find the plants anymore because there’s so many weeds. That’s exactly the problem with technical debt on projects is there’s so many compromises in there, to do legitimate work, you have to understand all the compromise that came before you and that slows things way down.

Mm-hm. What were you saying, Jaim?

There’s such a fine line between full-featured and bloated.

Oh yeah.

Yeah.

And full-featured to one is bloated to somebody else, so there’s not one-size-fits-all in any technology, I don’t think.

That’s because we have variance in our problems. In other words, it’s full-featured for me because the authentication, the whatever other features, they all work as I expect them to and they mesh nicely with the way that I approach my problems. But for you, you may have just one or two little requirements here or there that make it so that it’s bloated because I’m never going to use those features, or I’m going to have to work around them.

Absolutely. There's no one technology to rule them all; it just doesn’t exist.

Right. So you’re looking for the fit that will get you the closest to it, and then you make the tradeoffs for efficiency of work or efficiency of the app.

Ultimately, what we’re looking for from a technology adoption standpoint is exactly the point where you get the most balance of risk versus reward. You may invest more risk in something that’s really important in your problem domain. Maybe you’re in the financial services industry in Manhattan and you really need to invest heavily in really high concurrency frameworks like Scala or Aca or Clojure or something like that, and so that means you really need to invest more time and effort into understanding that because it’s an important part of the problem domain.

Now, does it mean anything looking at your radar that some of these are closer in or further out within Trial or Assess? Or did you just group them to make them look nice?

That is exactly – our criteria is we don’t obsess about position. If something is one millimeter closer than another one, we don’t obsess about that; we’re just trying to get the labels not to overlap.

Okay.

We do have a little bit of iconography there, so the triangle mean it’s brand new on this radar, and the circles means it’s been here at least once before, so there’s a little bit of iconography there to show this stuff, but we’re not trying to make editorial comments about precise placement within the rings.

Now one other thing that I’m wondering about is it seems like you’ve got these general ideas for if most projects or most new projects are adopting something in the Trial category, then we move it into Adopt, or if we want to say, “This is the best way in general to do whatever – to solve a particular problem” then we’re going to move it into adopt. But do you do any kind of metrics to measure this, or is the general conversation through the company is Segregated DOM plus node for JS Testing is the thing that is making everybody happy right now?

Yup. We will revisit this. We don’t gather formal metrics across our projects, but every time we do a radar, we revisit every blip that’s currently on the radar and decide “Should it still be there and does it still have the promise that it had before?” We do revisit each one of these to make sure that it still belongs to the quadrant that it belongs to, or sometimes they get booed.

And so do you just revisit it by having that conversation? “Hey, are you using this? Oh you are?

And is it still good?”

Yup. The people who are on the TAB also are attached to projects as well, so we get to see code all the time; it’s not like we’re always “Okay, record some people” and so we get to see things out in the world and see how things work. There’s not a formal kind of verification, but there's an informal verification across a lot of people in the TAB that whatever this thing is don’t happen.

Segregated DOM plus node for JS Testing – that’s a really common practice in a lot of our projects now. If projects stopped doing that I think we would have found another way to do this particular thing and that would start showing up on our radar somewhere because we’ve started doing this other thing.

What’s come down the pipe for the mobile developers, people doing iOS? What type of thing should we be looking at if we’re trying to develop our own radar?

Well, the things that show up on our most recent radar around iOS development in particular is hosted solutions for testing iOS. Things like Travis CI, for example, your usual cloud-based CI for iOS and OSX projects, so that’s pretty nice. That was on our Assess in July of 2014. Zucchini is another. It’s a testing framework that gives you Cucumber-style BDD testing for iOS apps. That was actually in Assess back in 2012, so that may be outdated by now. What I did was go to the Radar A-Z and look for things that mention iOS.

I remember Zucchini a while ago, 2012 [inaudible 38:34] people were working on it. I hadn’t heard much of it lately. Is that going away?

It didn’t show up on our radar again, so that suggests it probably faded away. One of the things that is in Assess for our GUI 2014 radar is Appium, which is to test mobile, web, native and hybrid applications, a testing framework. That’s in that space.

I mentioned Calatrava, which is something that a ThoughtWorker created that gives you a Titanium-like independence. Calabash is another one, an automated acceptance tool for Android and iOS. It acts like Cucumber – that was in our 2014 January Trial for iOS.

So do you do this for January and July?

We do it twice a year. It usually falls around those timeframes; we’re actually moving it back a little bit next year so that our radars will basically come out early in the year and late in the year. The new one will be out early in January of 2015. Next year’s radar will come out before the end of the year, so we’re shifting our meetings around a little bit so that we can get the second radar out just before the end of the year rather than just at the beginning of the year.

One thing that I’m looking at and I think would be really interesting and I’d like to get your feedback on this – I think it would be really interesting to put together a community radar, something that the community in general is looking at. Maybe an iOS community radar, and we could have one for iPhreaks and one for some of the other iOS communities out there.

I’m going to point you to something that was going to be one of my picks that I’ll talk about at the very end of the show. That radar visualization that you see, somebody has essentially already implemented that for you.

On GitHub, one of my former colleagues is a guy named Brett Dargan. He has a project called techradar. If you go to GitHub, the site GitHub, and just search for the phrase techradar, you’ll find this.

What he has done is built an open source framework that does this radar visualization for you on an HTML5 canvas using JavaScript. All you do is fill in a JSON data structure and it actually draws this radar for you, so you could easily set up, for example, a radar that people who are listening to this podcast contribute to and then use this visualization to actually publish this somewhere as an asset that the community owns.

And then basically we could set the criteria for what the community gets into Assess, Trial, Adopt and Hold.

Exactly. I would say, it’s similar to ours. Assess is kind of R&D, Trial is we’d used it and it looks really promising, and Adopt is no-brainer.

Yup, I’m going to do Adopt for Send Jaim Cookies [chuckling].

Yeah, I would almost want to put a no-brainer in there, so just to give people an idea if they’re new to it. We’re not talking a lot about this because it’s been adopted for a while, but if you’re wondering –.

The only downside to that is, the problem is, you end up adopting a lot of technologies, so there’s no way you can visually get them all on there [chuckles].

Oh, yeah.

That’s the challenge we face. That's why we eventually ended up with this aging off kind of idea.

Right.

There’s nothing that says of course that you have to have four quadrants. You may have just a couple of quadrants, or they may be hyper-specialized. If you’re building a radar just for iOS stuff, for example, you might build Development Tools for iOS as one quadrant, Testing Tools for iOS as another quadrant and split out the technologies using quadrants like that so that you have more of an Apple to Apple comparison within a quadrant.

We picked Techniques, Tools, Platforms and Languages and Frameworks because we were trying to dice up the entire technology world, but if you’re doing this for a much more cloistered space, you may build some very, very specific quadrants. It’s really just “what categories of things do we want to assess against one another?”

I’m really tempted to play with this, and that GitHub library is something that I definitely want to go tinker with.

Yup. The only weird thing about the GitHub library, never let it be said that one of my colleagues can’t over-engineer something just a little bit. He gives you the ability to do exact placements of the dots within the rings by using polar coordinates. So there’s a little bit of a gentle yak shaving to convert things into polar coordinates so you can get them to show up in the JSON data structure, but that's the only real thing you have to do. You just fill in that JSON data structure and it does all the drawing for you.

So you can’t just say, “I want it in this ring and have it figure out where to put it”?

No, you have to convert it to polar coordinates to do that.

Okay.

[Chuckles] I’m sure that Brett would be happy to accept a pull request that just automatically handles that for you, so if you’d like to build that and send it to him, I’m sure he’d be happy to accept it.

It’s a cool library.

Yeah, it’s a handy, old thing.

I just keep thinking that it would be really fun to build collaborative tech radars; give not just companies, but communities, the ability to do this kind of thing.

I think it’s a great idea. Back in 2012, QCon London actually stole our radar metaphor. I’m going to say it was an homage to our radar metaphor during the conference, to talk about cool, new technology stuff, and they built an interactive radar thing that had our categories on it that people during the conference were filling out the radar. I think this is a really useful tool for communities as a way to track the community consensus on what’s going on around these tools, because again, this is one of those things – there no metaphor in place that does that. Just by putting something in place, you give a place for people to start hanging ideas off of.

We’re trying to encourage other people out in the world to create their own radars. We think this is actually a pretty nice radar metaphor for assessing technologies like this, so we’re encouraging people to take this metaphor along with it.

Very nice. Is there a place where all of these definitions are contained? Oh yeah, they’re right here in the radar. Adopt – we feel strongly that blah, blah blah; Trial – worth pursuing, it’s important.

Yup, all those are there. The other pick that I was going to point you to is I actually have a blog entry on my website. It’s a white paper, basically, that describes this whole build-your-own-radar process, but particularly for companies, including logistics or how to put this together for your own company. That’s on my website – nealford.com. There’s a blog entry over there called Build Your Own Technology Radar.

Very cool.

As a consultant, I can see doing a technology radar to find technology some of my clients would use, things like that. But if you’re a low-end developer, you have an employer, you’re an employee, what other type of things are you thinking of when you’re putting things in your Adopt, Hold, that type of thing?

[Crosstalk 45:06] depends. This goes back to the example – I was in the Clipper world. If I was heavily investing on Clipper, not paying attention to the other technologies out there and it was gradually going away, I had no strategic way of assessing the world. So as an individual, I think you can use this tool as a way to keep your pulse on what’s happening in the technology world right now. You got to be careful because things move out from underneath you without you realizing it. People were heavily invested in SOAP for a while, but now all of a sudden, the whole world’s doing REST rather than SOAP. If you were heavily invested in SOAP, you will have had to move in a hurry. This is a way to – as you find out about new technologies, to put them as a radar like, “How is this going to affect me as an individual?” and you may find some really cool thing that you really want to invest time and effort into.

I view this building a radar – one of the things that I point out is if you’re a technologist, if you make money from technology, then your technical portfolio was kind of like your financial portfolio, and they’re very intimately tied to one another. What does your financial advisor tell you as your number one advice for your financial portfolio?

Diversify.

Diversify! So you want to do the same thing in your technology portfolio, and this gives you a way to assess what things are really super promising that I know I need to have knowledge in. What kind of things are maybe the far-out investment ideas that look speculative but may turn into actually the best job in the world? I think this radar helps you try to assess those technology choices even for an individual.

Man, you’re ruining my weekend. I want to go and build some stuff now [chuckling].

It’s actually super easy, using all the open source bits already out there on GitHub; just download that thing. There’s already a JSON data structure so you can start filling in all the stuff; you don’t have to build it from scratch. I think this is a good weekend project [chuckles]. Your family may disagree with me on that, but [chuckling].

Yeah. Well the way this week’s going, I’m not going to have time for anything anyway. Cool, do you have any other questions, Jaim? Because I think I’m out.

I think we’re good. I’m ready to get my radar going.

Alright, well let’s go ahead and wrap up then. We’ll do some picks. Jaim, do you want to start us off with the picks?

Sure. I’m going to do one pick. I’ve got a book from Steven Pinker who had written some other books that I was only vaguely familiar with, but people still think he’s kind of a big deal. He wrote a book on writing, The Sense of Style. If you do blogging or writing or if you’re in a technical field, we don’t really know the best way to write – how to communicate. We look at abstract legalese and weird abstract papers, academic stuff, and we tend to do our writing in ways that are hard to read and we think we’re doing it the right way but it’s really not. Not very helpful. Steven Pinker, The Sense of Style, is a book – he went on a book tour a couple of months ago and just really spelled out a lot of rules for improving how you write, how you to write in a way that people will understand what you’re saying.

The book itself is pretty big and denser than I thought, so I didn’t get through all of it, but I picked up quite a few tips. Even my wife who’s a blogger, I’m actually helping her improve her writing. “Well, try it this way and this isn’t so bad even though Strunk & White might think it’s not the right thing to do.” But Steven Pinker, The Sense of Style is a solid book if you’re looking to improve your writing.

Very cool. I’m going to go ahead and just do one pick. My friend John Sonmez, he’s getting ready to release a book. I don’t remember who the publisher is, but it’s called Soft Skills for programmers and it’s basically a book that talks about all of the other things that go into having a well-balanced and enjoyable life as a programmer. He talks about working out, he talks about managing your finances, he talks about marketing yourself, keeping your skills sharp – all of that kind of stuff. It’s kind of a broad set of topics, but a lot of times we get excited talking about the new technology and we don’t talk about all of the other things. This is a book about all the other things and it’s looking like it’s just terrific. I’ve been looking at it and I’m excited to get my hands on it. It comes out really soon, so go check it out. I’ll put a link in the show notes to where you can get your hands on it. That’s my pick.

Neal, what are your picks?

I’ve got several radar-related picks. One is the ThoughtWorks radar, which is just ThoughtWorks.com/radar. I also mentioned the white paper on my website that you can download if you go to nealford.com. There’s a Build Your Own Technology radar link there. And then I mentioned the GitHub link from my colleague Brett Dargan. It’s GitHub B-D-A-R-G-A-N (slash) techradar, which are all the bits to do this with.

I feel compelled to give you one other pick that has nothing to do with technology whatsoever. If people had never heard of this, it’s one of my favorite kind of intellectual bombs to throw into people’s satchels. If you’ve never read it, then go read David Foster Wallace’s Authority and American Usage, which is an essay that’s online. It was published in one of his books.

It is an 8,000-word review of a dictionary and it is absolutely the most riveting thing you’ve ever read in your life. If you’ve never read that, treat yourself and go read David Foster Wallace’s Authority and American Usage and it will lead you to a bunch of other David Foster Wallace stuff as well.

Very cool. I’ve read a number of his stuff and I’ve always enjoyed it.

Yeah, he’s a very cool writer.

Nice. Alright, well I don’t think we have any other announcements or anything, so we’ll go ahead and wrap up the show. Thanks for coming Neal, it was a terrific conversation.

My pleasure!

Alright, we’ll catch you all next week!