02:25 - Neal Ford Introduction

02:20 - The Thoughtworks Technology Radar

06:28 - Quadrants

07:01 - Categories (Rings)

09:23 - Adopting New Technologies

14:42 - Providing Familiarity Resources

15:24 - Radars as Resources and Lifecycle Assessment Tools

18:36 - Themes

22:17 - Making Decisions

27:40 - Jamming Radars

31:53 - Hireability?

36:54 - Financial Portfolios and Planning Your Career

42:03 - Software Architecture & Engineering Practices

43:57 - Functional Programming

44:16 - Estimation

46:03 - Creating Your Own Radar

Picks

All Watched Over by Machines of Loving Grace (Avdi)
The Project Euler Sprint (Coraline)
Gloom (Coraline)
The Bad Plus: Inevitable Western (Jessica)
tmate (Jessica)
Screenhero (Chuck)
Slack (Chuck)
DevOps Bookmarks (Neal)
Elvis has left the ivory tower by Neal Ford (Neal)
Culture Series (Neal)

Special Guest: Neal Ford.

 
CORALINE:

We went to the animal conservatory and we had a headcount problem coming back and we all were hypothesizing about which animal had eaten who.

Hey everybody and welcome to episode 195 of the Ruby Rogues Podcast. This week on our panel, we have Jessica Kerr.

Good morning.

Avdi Grimm.

Hello, hello.

Coraline Ada Ehmke.

Coffee, coffee, coffee, coffee, coffee.

I’m Charles Max Wood from DevChat.TV. And this week we have a special guest Neal Ford.

Hello.

Neal, we hadn’t had you on the show before. Do you want to introduce yourself?

Sure. I work at ThoughtWorks as, we’re an international consultancy that some of you may have heard of. We’re pretty well known in the Ruby community and the intersection of enterprise-y stuff and Ruby. My role at ThoughtWorks, I’ve been there, actually will have been there 10 years in April because I’ve come due for my three-month paid sabbatical which I’m very excited about which is coming up in May, June, July this year. And my role at ThoughtWorks is typically as architect or tech leads on projects, although I have an unusual role at ThoughtWorks because I also travel and speak at a lot of conferences. I’ve spoken at RailsConf. I did a keynote at RailsConf in 2010 and a bunch of other Ruby-related events. And I’m also a member of the ThoughtWorks Technology Advisory Board and we’re the ones who create the ThoughtWorks Technology Radar which of course is I think the ostensible topic of the podcast today.

Yes. I’m really excited. Do you want to explain the idea behind the Technology Radar for ThoughtWorks?

Sure. And I’ll actually give you an idea of where it came from, because this was not some sort of strategic master plan that we hatched at a smoke-filled room at some point to get a lot of web impressions. It actually started out as, so there’s this group within ThoughtWorks called the Technology Advisory Board. It’s a group that the CTO, Rebecca Parsons created because she wants to be very proactive about technology choices within ThoughtWorks and the way that we guide our clients to do things. And Ruby is actually a good example of that, because we were really early proponents of Ruby on Rails in the enterprise and the places where it made sense. And so, we came out very early and were very vocal about doing that. So, that’s an example of the kind of technological proactivity we like to have.

And so, she created this group of working technologists pulled from ThoughtWorks offices all over the world. We’re in about 14 countries now, so a couple of people from each major region. So, it’s about 30 people or so that make up this Technology Advisory Board. And we have a phone call every couple of weeks where we get together and talk about all things tech at ThoughtWorks. But twice a year we have a face-to-face meeting where we have much more serious conversations. And part of those face-to-face meetings, it’s inevitable when you get a group of geeks as part of their day job, when you get them together on a very sparse semi-regular basis, it’s going to turn into at least a partial geek-fest where, “Ooh, you got to see this cool thing that we did here,” and, “You got to see this cool thing on this project.”

And so, at some point we formalized that during our face-to-face meetings and then started inviting other people from ThoughtWorks within whatever office we were meeting in to contribute and hear what we were talking about. And then one of my colleagues, Darren, came up with this really clever radar metaphor. And then we started publishing at our white paper. That started in late 2010 I think. And since then we release this thing twice a year. And we get press releases and a bunch of fanfare and other stuff whenever we released one of these things. So, that’s where this thing came from and at least on the surface what it is.

Very cool. Now, one thing when I looked it up that really helped was to be able to visualize it. So, where can people get the Technology Radar?

You can consume it in two different formats. If you go to ThoughtWorks.com, that’s thought and works all one word, .com/radar, you’ll see the latest interactive version. The latest version that came out was released. We soft-released it back in mid-December because our face-to-face meeting was in early November last year, our most recent one. And we wanted to get it out just before Christmas but we also wanted a marketing thing so the official release of it was in midJanuary. But that’s the January Radar. And if you go to ThoughtWorks.com/radar, that’s always the latest interactive version. You can also download a PDF from there.

techniques, languages and frameworks, platforms, and tools. So, the four categories are techniques, tools, languages and frameworks, and platforms. And with each one of those quadrants we have blips that represent a particular technology that we’re making some comment about. So, let me explain what the rings mean. There are four rings around our radar.

The outermost ring around our radar’s label is Hold. And anything that we put in that Hold ring basically means proceed with caution. So, when ThoughtWorks creates one of these radars we’re basically getting a bunch of opinionated technologists together and we’re trying to advise the world based on our experience of technologies you should either use or should stop using. And that Hold ring is really the, “We think you should stop using this technology mostly because we have alternatives that we would prefer for one reason or another.”

So for example, we put all of the SOAP stack in Hold a while back because we think REST is a much better alternative for most of the situations you find yourself in. We don’t care much for enterprise service buses, so we’ve had enterprise service buses in Hold on our radar for a while. But it’s almost always because we’re trying to suggest an alternative. We pick things that are kind of common best practices that we think are stinky out in the world and put those things on Hold to make a comment about them, to point people to what we think are more enlightened ways of looking at things. That’s the only semi-negative ring.

And we specifically do not have an avoid category. We’re trying to be really true to this radar metaphor. And radar is looking at things that are incoming in the near future. And we find that if you put an avoid ring on here then this radar becomes rather than a forward-looking exercise, it becomes a backwards-looking recrimination about all the mistakes we’ve made in the past kind of document, which while that’s probably a fun exercise to go through it’s not very constructive for making decisions in the future. So, we tend to try to say Hold is the most negative we say about anything.

The next ring in is called assess. These are all things that we think are interesting and we want to do more research and development on but haven’t actually built anything interesting in them yet. Trial means we have started building things interesting in them and we actually have things in production using those technologies and we like them for one reason or some variety of reasons.

And then finally things that make it into the innermost circle Adopt are the no-brainer things that we’re basically saying, “This is clearly the technology leader in its space. And this is a no-brainer that we think you should probably adopt this technology.”

So, I’m curious. We have a perception of enterprise software development as lagging behind the curve when it comes to adopting new technologies. How has that, what has your experience been with that? Does that hold true or is that a tired cliché?

It’s a little bit tired. But I think the gap is [widening]. It’s a spectrum. So, William Gibson, a science fiction author, has a great quote that says, “The future’s already here. It’s just not evenly distributed.” And I heard…

Actually, the best example I’ve ever heard of this quote not too long ago, about eight months ago, India did elections. The largest democracy in the world with 750 million registered voters. And they have real travel challenges within India. And so, at least one of the candidates was making campaign appearances via hologram, like the Tupac hologram. And one of the things the hologram was promising people at these campaign events was indoor plumbing. And that’s a clear indicator that the future’s already here. It’s just not evenly distributed, when the hologram promises you indoor plumbing.

Wow.

[Chuckles] But a lot of companies are in this situation too, because a lot of big enterprises view software as just overhead. And it’s’ just like the heating and AC system is like, “Well, everybody seems pretty comfortable. I’m not going to invest a lot of money in overhead.” But you [you see that] a lot of other companies who are getting very interested in this continuous delivery metric called cycle time which is a measure of engineering efficiency, how quickly can you get things from “Let’s start working on it,” to, “Get it running in production”? This is the source of all this continuous deployment stuff.

And so, a lot of big enterprises are starting to look at that as a potential strategic advantage over their competitors. Because if you’re on a six-week release cycle and then you cycle time down to a couple of hours, all of a sudden you now have weaponized infrastructure and can start using that as a business advantage. So, we’re finding that the gap is actually widening between companies who are reacting to this kind of stuff much more aggressively and other companies who are just sitting on their hands.

So, I think the future’s already here. It’s just not evenly distributed. But that’s across different industries, too. So, some industries are moving a lot faster toward adopting what we would consider best practice-y kind of stuff than others.

This is fascinating to me, because one of the perennial questions in working with technology is when is a technology worth looking into? When is it worth playing with? When is it just something to keep an eye on? And I’m kind of, in having heard you describe this and read a little bit about it, I’m kind of shocked that it’s not common to systematize this judging of new technologies.

We’re trying to encourage people to do this. I’m doing a conference talk at a lot of conferences I do now called ‘Build Your Own Technology Radar’. And I have on my blog as well, there will be a resource attached to this, on my blog at NealFord.com. I have a blog called ‘Build your own Technology Radar’. We’re actually encouraging people to build two different versions of this for themselves.

One, as a career guidance tool, because I find that way too many technologists are very tactical in their career decisions, not very strategic. You get distracted by a new, shiny thing and it’s like, “Ooh, that’s cool,” and you start investing your time in that. But one of the things I discovered at my hazard many years ago, this is going to be kind of an embarrassing history lesson for me.

But many, many years ago before I joined ThoughtWorks I was the CTO of a trading consulting company based here in Atlanta. And we did development on this platform called Clipper which was DOS-based. And everything was great. We had 20 people and we had training classes and we had projects that were going on in Clipper. And then all of a sudden Windows came along and all the Clipper work just stopped. And it made me realize two really important things from a career standpoint. One is, no matter how much you don’t want it to, technology keeps marching on. When you signed up for a career in dealing with computers and programming computers, you also signed up for a lifelong course in continuing education. So, you better get really efficient at that.

But the other thing that, the more important lesson I’ve learned, was that when you’re heavily invested in a technology you’re living in a technology bubble. And when that bubble starts collapsing, it’s very difficult to tell from the inside that it’s getting smaller. And this is particularly true if you’re invested in a technology that’s owned by a vendor, a big giant company, because they will hide the fact that their bubble is starting to collapse. And so, it made me realize, you really need to be super proactive as a technologist to guard in your career against the thing that you’ve heavily invested all of a sudden turning into a pumpkin, because it’s really hard to see that happening when you’re inside that ecosystem. And very often, once you realize that, it’s too late and you have to start scrambling to reskill yourself.

So, part of this radar exercise is a way to sit down and assess, “Okay, what kind of technology stuff am I really interested in really long-term?” and as a way to shepherd your efforts to make sure you’re getting the best bang for your buck for the kind of technology stuff you’re playing with.

I’m curious. At ThoughtWorks, once a technology has been identified, do you provide any sort of resources for getting people familiar with it, getting them on board, and training them?

No, because this is mostly from us, something that’s very reactive from our projects. So, when we build one of these for ThoughtWorks, we’re actually harvesting stuff from all the projects that people have been working on. So for example, our next face-to-face meeting is going to be in London in March. And so, before that happens, I’ll gather together some of the projects here in Atlanta and get people’s opinions about things so I come to that meeting armed with things that we know work pretty well. So, the only thing that we really provide to the world is the name of the technology. And then we do a little paragraph write-up about why it’s on our radar and why it is in the circle that it’s in. Then people are left to their own devices as to how they end up consuming that.

This technology radar has become a great resource for developers who are trying to get their company to move forward in the new technology. As I was reading it just now, one thing that I noticed is that technologies fall off the radar if they’re not changing rings. Is that how it works?

Yeah. That’s exactly right. This is again, true to that radar metaphor, that blip. So, we have a rule that says if a blip hasn’t moved in two Radars, then it automatically fades away. So, some people want to view our radar as a lifecycle assessment tool. So, they look in this Adopt ring and think, “Oh, that’s all the cool stuff that ThoughtWorks is using.” That’s not true, because we’re trying to stay true to this radar metaphor. And we use a lot of technologies, so it would be just a solid mass of blips if everything we ever used was there.

So, they do fade off if they haven’t moved after two blips. And that’s true no matter where they are. So, the normal course of events for something is to start out in Assess then move its way through Trial then make it into Adopt, and then fade away after two Radars if it hasn’t moved because we truly love whatever that technology is. And then it might now ever pop up again on our radar. Or if it does, it pops up three years later in Hold because we found a much better alternative to whatever those things are.

But some things move back and forth. So, a great example of something that’s moved back and forth between Assess and Hold is the stuff that Intentional Software is doing. That’s Charles Simonyi’s company. He was the guy who created Excel at Microsoft. And he’d been working for about a decade now on this really revolutionary language workbench platform called Intentional Software. And we keep getting enamored of the technological promise of this. And so, we put it in Assess. And then we actually touch it and try to do something with it and it’s very immature so we put it back in Hold. So, things sometimes jockey back and forth. But in general, things move into Adopt and then fade away.

But like you said, some people use this as justification for, “We should use X in our company,” which has really surprised us that anyone would value our opinion highly enough to make a case based on it. And so, for people who want to make a case for it, or if you’re curious to see if your favorite technology has ever appeared on our radar, when you go to our website ThoughtWorks.com/radar, you’ll see on the right hand side a Radar A to Z. That’s everything that’s ever been on our radar searchable.

So for example, if you go to Radar A to Z and search for Git, Git is something we really love within ThoughtWorks. And it faded away in Adopt years ago. But you can see if you look at that history for Git, you can see when it showed up on our radar and then the stages it went through before it finally faded into Adopt. So, we’re actually now pointing more and more people to the search function to see if we’ve ever made a comment about something either pro or con to make a case about something.

Are there any common characteristics you’ve identified for technologies that appeared to be really interesting, appeared to have potential, but ended up fading out into the Hold or disappearing completely?

Well, we find that places, technology locations that have a lot of churn ends up getting a lot of things in Asses that never make it into Trial. So, we went through this recently with JavaScript frameworks because they’re like mushrooms after a rainstorm. They keep popping up and going away. So, one of the things we do for every Radar is call out themes that we’ve seen across all the blips. And one of the themes that we called out then was churn in the JavaScript space. Because at the time I think there were two common build and dependency management tools. And one was in the process of replacing the other one and you needed all three of them to get something to work. And so, there was just a lot of craziness in that space.

We obviously have a lot more things in Assess than Trial because we have a pretty strong opinion about things that we think are good technology. So, things fall off a lot after Assess. Once they’ve made it into Trial it’s pretty common they’d make it into Adopt. But the things that, probably the common characteristic across all of our things is we’re obviously very invested in Agile software development and the engineering practices around continuous delivery. So, we tend to prefer lightweight, a la carte kind of low-ceremony tools versus really fancy, heavyweight kind of things. But that’s not much of a criteria because I think most people are now leaning toward those kinds of decision criteria.

I’m kind of curious. It makes sense if something fades out in Hold or fades out in Adopt. But if it’s under Assess or something like that, then it fades, what does that mean? In two cycles…

It means it didn’t make it to Trial. So, that just means that we looked at it and it didn’t live up to whatever promise we thought it might deliver to make it all the way into Trial.

And so, it doesn’t have to go into Hold. Is that the deal?

No, no, certainly not. Hold is very distinctly… so Assess might be, so a good example, say a new JavaScript web framework comes out. It looks really promising. Then we put it in Assess. And then we realize that while it’s really good for some kinds of applications, it’s poor for other kinds of applications and it has a sketchy testing story. We don’t want to put it into Hold because we’re not actively telling people, “You shouldn’t use this.” But we’re not going to advocate for it either.

Oh, I got…

So, we actually did this for Angular for a while. Actually, the first version of this Radar page was written in Angular. And then we actually backed away from it and made some comments in our Radar about the suitability. Not every project is suitable for every kind of framework. So, we tried to look at that. So, there’s an implicit, on our Radar, Adopt for when it makes sense. So, if we put something like reverse proxy in Adopt, we’re not suggesting that every project on earth should use a reverse proxy. But if you’re in a situation where that’s a handy thing, then this is the technology we recommend to do that with.

So, what if you Adopt both Angular and Ember for example?

We do that all the time. We’re not trying to pick the winner. We’re trying to say these technologies have worked well on our portfolio of projects. So, we have over 200 projects going worldwide [at any] time. So, I think that’s one of the interesting things about our Radar, is because we are relatively big and we’re very international – we’re 14 different companies and we’re 3,000-ish people worldwide now, a little more than that – we’re actually talking about a wide swath of different kinds of projects. And all the different, all the same engineering practices but very different problem domains and different ecosystems. And so, we have a broad view over technologies more so than somebody in a particular country or a particular technology stack.

So, one other question I have, and this is going to get a little bit more into where I’m at. So, I’m a freelancer. I have five podcasts that I do very week. And so, you can imagine that I hear about a lot of different technologies. So, how do I pick the things that I’m going to put into Assess or Trial or Adopt? How do I make those decisions with the stuff that I’m seeing?

Yeah so, what I suggest that people do when I talk about building your own personal technology radar is you need a set of litmus tests. So, here’s an observation. So, this is the Ruby Rogues podcast. So, let’s say that everything new in the Ruby world stopped this instant. You could easily spend the rest of your life just looking at the cool stuff and playing around in the Ruby ecosystem. So, what that suggests is if you really need to assess technologies you need to come up with a

good filtering mechanism, a good set of litmus tests that you can applies to technologies to say, “Should I spend any more time looking at you or not?”

And actually, this radar thing is not a bad way to categorize things for, “Hmm, Assess looks kind of promising. I want to do more research on it. Trial looks very promising in that this is both a cool technology and it looks good from a career standpoint.” And then Adopt is of course the things you really want to heavily invest in. This is a way to think about the kinds of technologies that will drive your career forward. Because one of the things I realized was when the Clipper world vanished and I realized that I really started to manage my technology portfolio is it’s very similar to a financial portfolio. And if you make a living off of technology, those two things are very closely intertwined.

And so, what’s the very first piece of advice that your financial portfolio guy tells you?

Diversify.

Diversify, of course. So, you should do the same thing with your technology choices. So, one of the things I suggest is pick a good middle of the road no brainer I know I’ll be able to get work in this in the next five years kind of thing. JavaScript, HTML, CSS is probably one of those spaces right now. Certainly any major language platform like Ruby on Rails or Python or any of those are probably pretty safe in the near term.

But also think about some more far out speculative investment kinds of things. Like an open source project or maybe you have a passion for doing podcasts. And all of a sudden you get really super popular on iTunes and become the podcast king of the universe for technology podcasts. That’s a good example of chasing something that is not necessarily on the mainline path of your career but something that you’re interested in doing and want to pursue and it may turn into something kind of cool. The building this radar kind of thing is a way to balance those things, to think about where should I put my time and effort, and a way to get it all laid out together on one view and think about time spent versus reward versus just always defaulting toward the stuff that’s really the newest, coolest thing, which is my problem sometimes (problem/opportunity). I need to be able to balance that, I find.

I like that you emphasize to choose something that one, you’re interested in, two, that you personally want to pursue, and finally that might turn into something cool. Because even if your podcast doesn’t take off or your open source project is never downloaded, you’ve learned something.

Absolutely. And investment I think is the key thing there, not the outcome. The outcome might turn out to be something cool. But I think the time investment ends up being the more interesting thing. And it’s really a way to marshal your time. That’s a really tricky thing. You need to constantly be learning new things but you probably need (I’m doing air quotes which you can’t see) “a life” in addition to technology stuff. And balancing those concerns is really tough.

So, the other thing that I realized is I need to get really efficient at learning and assessing new technology stuff to see if I need to spend more time looking into it. So, a good example for a litmus test for me, because I’m really into agile engineering is testability. So, I remember when Flex came out. Flex is like, “Oh, that’s kind of a cool-looking thing.” But one of the first questions I asked it is, “How testable are you?” And the story came back very anemic. So, I said, “Well, you know what? I’m going to wait either until Flex’s testing story gets really good or it dies.” That’ll be my decision point. And it died. And so now, I never have to worry about Flex because I never spent any time looking at it because it didn’t match my baseline criteria for, this is what I should do to spend more time on it.

So, that’s actually a way that our Radar helps individuals create radar because presumably we’ve done at least short-circuited some of this assessment phase to see what kinds of problems a particular technology is applicable to try to solve and can short-circuit some of that research and development. Conferences are also great ways to short-circuit that R&D phase because you can go and get an accelerated view of what this technology does and what’s good about it and also more importantly, what some of its shortcomings are.

So, I used to work on radar systems and I love stretching metaphors out. Of course one of the things that come up when you’re talking about radar is the fact that at least in the military situation, other people like to jam your radar. It seems to me that vendors tend to like to jam technology radars. Is that something you’ve experienced?

Oh, sure. And that’s exactly what I was talking about before, that if you’re in a technology bubble and it starts collapsing, the vendor will absolutely try to keep that fact from you because they want to try to keep the life support system going as long as they can for a technology. So, I think it’s important to… this is less true for open source technologies. But it’s also a little bit true there, because… so, you’re always being marketed at. So, say you discover a great new web framework, Bob’s web framework. And you go and look at Bob’s page and it’s got all these cool things on there. It doesn’t say at the bottom of the page with an asterisk, “Oh by the way, Bob’s web framework really sucks at these three things you’re going to need critically.”

Because they’re marketing to you. So, even open source projects are trying to keep their weaker points away from you. So, I think that’s just a natural tendency for people who are trying to get you excited about a technology and start investing your time and effort into it.

Right. And they’re solving their own problems. And they might not have run into those weaknesses.

Yeah, absolutely. So, they have their own bias about what’s good and what’s bad. And so, the tricky thing is to evaluate those biases. So, one of the things I always do anytime I’m trying to assess a brand new kind of technology, like for example if I was trying to pick a new JavaScript frontend framework or something, I would try to find what the candidates were that met my criteria. But then, so one of the cool things that most commercial products add even though it’s mostly used for evil, is the feature matrix that tells you how this weighs up against all of its inferior competitors. I tend to build a feature matrix too when I’m trying to evaluate a technology and try to put the good, the bad, and the ugly on there.

And so for example, I might have a category in there about how does this interact with the authentication authorization service I know I’m going to have to use with it? I’m never going to find that on Bob’s main webpage. And I probably won’t be able to find it by research. And so, I’ll do a little spike project so I can understand how that works. I think it’s really important before you adopt a technology broadly to understand both the good parts and the weaknesses of it, because the weaknesses are the really hard things to find. It’s easy to find the strong points because everybody will broadcast those things. It’s the weaker points of it that you have to poke around and dig up sometimes.

Right. So, you keep a list in your head of areas where you’ve seen weak points or that might be risky in your next project? Is that how you [inaudible]?

Yup. Those are exactly those litmus tests that I try to apply to technologies when I start to look at a new technology. So, testability is one of the things for me. ‘Integratability’, how well does that integrate with the other stuff that I’m working at. I may get really enamored by Erlang or something like that, but I’m on a Ruby stack then it’s going to be really hard to get those things to play nice together. So, maybe I look at the things that enamor me about Erlang which is all the functional and see if I could apply that to the stack that I’m in right now and still get some of the goodness without taking on a lot of extra accidental complexity to be able to deliver [inaudible] technology is.

Right.

Effective learnability is something that I look at too. Because again, I’m trying to maximize my learning time to make that as efficient as I possibly can. So, I’m a big fan, if you’re trying to learn some new fairly complex thing, is try to enlist more people. Get a little study group together and do brownbag lunches and that sort of stuff. That helps both socialize the learning and it keeps a little bit of pressure on you to keep coming back and pursuing it. And it also helps to get you out of sticky situations where you can’t figure out something where something odd is going on. It’s a way to unstick you from those things.

Mm.

Wow. Those are some useful suggestions. I have a question. In the Technology Radar, is there a consideration toward whether you’re going to be able to hire people who understand this technology?

We’re not concerned about that on our radar. We’re mostly just concerned with technical efficacy, that it solves a particular problem well. So, we’re big advocates of what other people view as scary complex things like Clojure and Scala and things like that.

Right.

But this is actually one of my giant pet peeves in the technology world. Only in the software world is “It’s too hard” considered a legitimate reason not to do things. You know what’s hard? Open heart surgery is hard. And if people had the attitude that programmers had, we wouldn’t have open heart surgery because, “Ah, that’s just too hard. People died when we started trying to do that. So, we should stop doing that.” We’re big believers that professionals should suck it up and learn things that they should learn. Now having said that there are a lot of things that are enormously accidentally complex out in the world for no good reason. So, you have to be careful to marshal your learning resources effectively.

I know there are some companies here who are like, “Well, we don’t want to adopt Scala because we won’t be able to hire Scala developers.” And yet it seems to me that all the really good Java developers would love to learn Scala. But pretty soon you won’t be able to hire a good Java developer.

Exactly. Well, that’s a similar thing to, there’s an old trope that says, “What if we send all of our developers to training and they end up leaving?” It’s like, “What if we never send them to training and they end up staying?”

[Chuckles] Exactly.

Which is worse. [Chuckles]

So, we don’t fear technology. We try to apply it where it makes sense. And we also try not to get too fan-boyish about technology which we suffer sometimes from that, just like all technologists do. But we try to be very pragmatic about it. And certainly as a group, the TAB tries to be extremely pragmatic about stuff we put on the Radar and try to avoid fan-boy-ism as much as possible.

At ThoughtWorks when you do adopt these new technologies, do you pay developers to learn them?

Well, we pay them to do development. [Chuckles] We don’t pay them to make sure…

While they’re learning?

Yeah. Like I say, most of the stuff on our Radar are things that people have already learned on projects. We’re harvesting the results of that. We do, we will occasionally do training classes and that sort of stuff within ThoughtWorks. But we, like most technologists, we’re very self-starter in terms of new technologies. Most of the people that work at ThoughtWorks, the technologists are very keen to play with new stuff anyway and tend to do a lot of that on their own time. And of course ThoughtWorks as a company is well known for open sourcing tons and tons of the goodies that we’ve created in our spare time in the past.

So, CruiseControl, the original CruiseControl was ours. And I-nu-IT and Selenium. And the original CruiseControl for Ruby, CruiseControl.rb was a ThoughtWorks open source project. So, we tend to be pretty proactive as technologists. That’s not to say that if we went into a situation where some sort of advanced geocoding or something like that, we wouldn’t spawn a training class for people who are working on that. But in general, we’re not trying to match, we’re not even trying to match the things on Adopt to say that all future ThoughtWorks projects shall use this. We very much trust the people on the ground to make decisions on a case by case basis for projects.

Kind of a similar related question that was, and we’ve often been asked, we do a mix of Java and .NET and Ruby projects throughout the world, and with other things mixed in as well. And people have often asked us, do you have a standard Java project starter kit or template or some set of assets that we always start with? And we’ve actually tried in the past to come up with something like that. And we always failed because we always find that the peculiarities of the individual projects outweigh any kind of [inaudible] generic template or anything like that. It would be so customized that before long you’re fighting it more than you’re benefitting from it.

We do a lot more learning I think in active development than we do in training classes anyway.

Yeah. So, would you be reluctant to put a Java developer on a Scala project?

No. But I would make sure that I would pair them up with an experienced Scala developer and not expect them to be super productive in that environment for a while until they got their feet wet. We’re also big worldwide. All of our projects we do pair programming all the time. So, that’s by far the most effective way to get people up to speed on something, is to pair them with someone who already knows that stack. Because you see realistic problems in a realistic setting, and you see how someone who’s experienced in that space solves a problem in a realistic setting. There’s no better way to pick up something than that, I don’t think.

I’m curious now. You discussed the financial portfolio metaphor earlier. One of the things that I think goes along with that is when you’re younger you want to be more diverse and take more chances with your portfolio. And as you get older you want the stability and predictability of stable, predictable stocks. How does that translate into planning your career?

I think that’s a natural proclivity. I was actually chatting with a well-known technologist. I won’t give his name away, but he’s a well-known book author. And we were chatting about when we were both younger we used to love playing with stereo stuff, wire them together, individual components, and you really geek out about that. And we found that as we got older we don’t care anything about that. We just want really good sound to come out. We don’t really care about how the moving parts work. And he was lamenting that.

But we reached the conclusion that part of what we’ve lost in the insatiable curiosity for everything we touch is that we now have a much deeper concentration ability on deeper, more complex subject. I think that’s the natural tradeoff. I think that’s the natural career path as you see developers that move up through developer and then become tech lead and then eventually become an architect. You’re looking at bigger, more complex, more nuanced problems that are deeper in and of themselves. And so, I think you can afford to be a little deeper and less broad as you build up more expertise and get more experience in things. And I think that reflects that.

Do you think that specialization versus generalization is an inevitable career path?

I think it is. We’re trying to fight it because we have a saying within ThoughtWorks that specialization is for insects. And we really like generalists. Even saying that and really feeling that to our core, we now have specialized roles within ThoughtWorks for user experience designers and data scientists. And it’s just like medicine. Back in the civil war, there were doctors. And mostly what they had were salts and whiskeys. That was about as good as medicine got. But then as the technology improves and we learn way more about medicine, you see this really, really intense branching and specialization.

I think that’s inevitable in the software world. It’s way too complex for anybody to hold big chunks of it in their head, particularly at the rate of change that’s happening in all of the different branches of software development. So, I think it’s inevitable that some specialization’s going to happen. We try to be as generalist as we can and then specialize in niches. And the way that we mitigate the negative side-effects of having too many specialists running around is we pair all those specialists up with interested generalists so that they learn more about what’s going on. So, that’s another good mechanism for spreading specialist knowledge around a project, is pair them up with someone who’s interested in soaking up some of that knowledge.

I read some business article the other day that recommended repotting yourself once you’ve been at the top of a career path for long enough. Do you ever have specialists that move to another specialty to increase the number of niches they know?

Oh yeah. We’ve got several people within ThoughtWorks. I know at least one guy, Patrick Sarnacke is his name, I think he’s worked every role at ThoughtWorks, every billable role at ThoughtWorks. He actually started in networking. I think he actually started as an intern when he was in university. And then came aboard as a networking and a sys ops guy and moved to dev ops. And then moved and became a developer and he did that for a while, became a really, really terrific developer. And then moved into, became an iteration manager for a while. I think he’s running our associate consultant program now within ThoughtWorks. So, he’s definitely repotted himself over and over [chuckles] and over again within the company.

I think that’s a great idea. And we see people do that all the time. People move from being a QA to a business analyst or within technical roles on projects. We actually try to encourage that on projects. We identify people by the role that they have on a project which is separate from the grade that they have in the company, which is how salaries and that kind of things are based. So, if you’re a business analyst but you’re just really curious about what the role of iteration manager looks like, there’s nothing… we would try to encourage you to see if you want to play that role, at least temporarily on a project just to see if it’s something that you like better.

Switching from something you know well into something that you’re just learning can be scary. But it makes you so much more valuable later on to know both things.

Oh yeah. The broader you are… anything you learn that’s technology related, there’s a synergistic effect that I think is really amazing. People say that learning a new programming language makes you better in the programming language you spend your day job in. And I think that’s true pretty much in anything in the technology world. It’s all so intertwined in sometimes unexpected ways. Anything you learn, it’s amazing how you end up accidentally applying that. And it seems like, and this is just a coincidental thing, but it seems like when you learn something new, it seems like you end up applying within the first couple of weeks, learning some new cool thing.

That’s so true.

So Neal, what are you excited about right now?

The biggest thing that I’m really geeked about, most of my consulting work right now is in the intersection of software architecture and the engineering practices in continuous delivery. So, I’m doing a lot of work in the software architecture space right now. I think that’s the most interesting part of software anyway. A lot of the process stuff in Agile, we’ve gotten resolved. We know now how to put projects together and how to estimate projects and that sort of stuff. But there’s still a lot of really interesting stuff in the, getting better at the engineering practices of building software, and then particularly the architectural impacts.

I think it’s fascinating that we’ve seen a revolution in architecture over the last four or five years as people have started realizing that operations and architecture can’t be separated, that architecture is really an abstraction until it’s operationalized. And so, that’s really what the dev ops movement and then all the interesting microservice architecture is now, is really this realization that you have to pay attention to what it looks like at runtime. And not only how to deploy an architecture but how do you evolve an architecture without breaking everything. So, I think there’s a lot of really cool stuff in that space.

Did you just say that microservices is the arch ops?

No.

The combination of architecture and operations caring about each other?

No.

Okay.

That was probably Skype doing that to me.

I said it was the intersection of… I call microservices the first post dev ops revolution of architecture. It’s the first architecture that fully embraces all the operational concerns and makes it a moving part in the architecture, makes it a first-class citizen in the architecture. Which is why one of the biggest things that we’ve always feared in architecture was change, because change is so expensive. Well, change is built into the microservice architecture idea. And so, change is much less expensive in that world. So, I think that’s fascinating. So, that’s where I’m spending a lot of my time.

And then I’m also fascinated by functional programming in general. My last book was called ‘Functional Thinking’. And in particular Clojure, I think Clojure’s a beautiful, elegant thing. It’s been my favorite language since I learned Ruby. Those are my two favorite languages to get things done in now, is Ruby and Clojure.

Neal, you said one other thing that, I know this was not Skype mangling something.

You actually said, we know how to estimate.

Uhuh?

Can you teach me? Because I never thought that was actually possible.

Oh yeah. We do this all the time on projects. It’s an engineering practice. Certainly, there are constraints on it, but estimation is something that you can get pretty good at if you do it enough. It is an estimate, so I’m not saying that we’re deadly accurate on these. And I realize there’s an entire movement in software, the no estimates movement in software, which I’m a big fan of because all an estimate really is… so really, I’ve been an advocate of this a long time, all an estimate really is, is they’re trying to hold you down to, you’re going to get this set of things done by this date. But agile software development invalidates that because we’re saying, well you can change your mind at any point along the way about the set of features you want by whatever date you want. So, what you’re really buying when you buy software is a subscription to agile software development where you get to change your mind any time you want.

That’s a much better perspective on software, but that’s a really hard thing to do for people who have budgets and need to do resource planning and all that sort of stuff. So, we do estimation. This is a pretty well-known practice in the agile world. We don’t do anything special or magical beyond the stuff that Mike Cohn talks about in ‘User Stories Applied’ or anything like that. But we also give confidence levels for estimates and we tell people, if you change the scope of things after we’ve estimated, we have to re-estimate. We try to be realistic about it.

Okay, thanks.

Alright. Is there anything else that we should know about the Technology Radar? I think the overall concept is pretty straightforward once you see it.

Yup.

But at the same time, sometimes it’s a little daunting to try and put one together.

Yeah. So, if you do want to put one together… so when we do this for companies we tend to do this, just capture it in a spreadsheet or something very lightweight like that. If you do actually want he visualization together, all of the hard work has been done for you. So, there is a project on GitHub that was created by one of my now ex-colleagues called, his name is Brett Dargan and his GitHub account is bdargan. That’s bdargan. And he has a project called techradar. So, it’s GitHub.com/bdargan/techradar. And what he has done is created this little chunk of code that you supply a JSON data structure and it will draw this radar visualization for you on an HTML5 Canvas. So, if you want to create the visualization for this, the hard work for that is already done. You fill in the JSON data structure and then it draws all that stuff for you. I think our interactive radar is actually a fork from a while back of this visualization thing.

The only tricky thing about Brett’s tech radar thing on GitHub is that when we put blips on our radar we’re not super obsessed about the exact placement within the ring. So, if something is a millimeter closer to something else, we’re not trying to make some sort of editorial comment about that. But Brett did want to give the ability for really precise placement within rings. And so, the JSON data structure you fill in, you have to use polar coordinates which gives you precise placement of the blip within the ring. It’s a little bit of a yak-shave to convert things to polar coordinates to put them in the radar. But once you’ve done that, then things show up as you expect them to.

So, I would encourage you if you are going to do this exercise, capture the results of this exercise just so that you can refer to it the next time you do this exercise. I think this is not a bad idea to do this on a semi-regular basis. I tend to go through an informal version of this every December for myself to think about, what am I spending my technological research budget on now, and am I using that wisely, and is there something I should put in place and reprioritize things? And so, that’s a good time to take a step back from your career decisions and look around as if you were a thirdparty observer and say, okay if I were giving myself advice about my career, what advice would I give at this point? Going through this radar exercise is a nice formal reminder that you should do that on a regular basis.

This is also something we encourage people to do for their companies. So, this is on my website, NealFord.com. There’s a ‘Build your Own Technology’ blog there. It’s mostly focused on doing this for your own company, as a group exercise for your company, as a way of vetting the technology choices. It’s a way for the people who touch technology every day to give feedback to the people who make decisions about technology. So, putting a radar together as the company snapshot of what we think about technologies that we’re using and what technologies we want to push through going forward versus the one we want to spend less time on. And so, that’s another way that we suggest people can use this radar metaphor.

Alright. Well, thanks for discussing this with us, Neal. I’m hoping that a few people will go out there and do some awesome stuff with their own tech radars. Why don’t we go ahead and do the picks?

Avdi, do you want to start us off with picks?

I only have one pick today. My pick is a 2011 BBC documentary series called ‘All Watched Over by Machines of Loving Grace’. It’s a three-part series. Each part is I think about an hour and a half long. And it is basically about how computers have been ruining us. [Chuckles] Each one picks an example of people getting really excited about computers and cybernetics and software systems and then trying to reflect those systems back into the world, or assert that the world is going to change and become new and special as a result of these systems, and then just really royally mucking things up instead.

The first example has to do with the Alan Greenspan and the 2008 economic collapse, ideas that went into that. Another episode has to do with the idea, 60 and 70 ideas about cybernetics and ecology and how people were basically thinking that the world could function like distributed systems that self-organize and self-balance. And it turns out that even natural ecology itself doesn’t actually self-balance that well. It’s hard to sum up these into a short description. But they’re very, very thought-provoking. And they’ve definitely given me a lot of food for thought about when we work with software we don’t just reflect the world into the software. We also start to reflect the software into the world around us. And that can be very dangerous if we’ve not careful. That’s it for me.

Alright. Coraline, what are your picks?

Okay. My first pick is a website called EulerSprint.org. Basically you sign up to compete in a team of four to solve problems from Project Euler and you get to use your preferred programming language. It is basically, you can pick your level, beginning, intermediate, or experienced, and find problems that are at your level and people to team up with. It’s a great way to level up and also a great excuse for some pair programming with people you haven’t worked with before.

My second pick is actually a card game. And this has become a favorite of mine at conferences. It’s called Gloom. And in the Gloom card game you’re in control of a family of misfits. And the goal of the game is to make your family suffer the greatest tragedies before moving on to death while simultaneously making good things happen to your opponents’ players and pile on the positive points on them. So, you have cards like pursued by poodles, or marooned on the moors, or happily married, that you’re playing. It’s a really interesting mechanic. It lends itself really well to storytelling. And it’s just a great game to play with a group of friends. So, that’s it.

Awesome. What are your picks, Jessica?

Alright. I have two picks. The first one is a music pick. The Bad Plus. It’s a jazz group and their new album, ‘Inevitable Western’ is excellent. A little bit dissonant, very interesting.

My second pick is a tool that we use at work a lot. It’s tmate. If you ever use tmux then this is basically tmux that’s really easy to share with someone else on another computer without having to create a login and ssh directly into that computer. It’s great for remote pairing when all you need to share is a text editor, because that’s super-fast. So, you can google it, tmate. It’s pretty useful. The end.

Awesome. I think I picked what I want to pick this week last week. So, I’m just going to pick a couple of things. I know they’ve been picked on the show before. But I’m just really liking them. The first one is Screenhero. I understand that they just recently got purchased by Slack, which is another pick of mine. So, Screenhero is just a screen sharing option that you have out there except that it’s interactive. In other words, I can click and type on your machine and you can click and type on mine. And the pricing is incredibly low. But the quality is pretty decent. So, I’m going to pick them. And I’m also going to pick Slack. And Slack is just an awesome chat option if you’re looking for a way for your team to communicate. Neal, what are your picks?

I’ll give you three in decreasing level of technical interest. The first one is this really awesome site that a bunch of my colleagues posted up on Heroku called DevOpsBookmarks.com, all one word. DevOpsBookmarks.com. what they’re trying to do is take the enormous explosion of DevOps tools like provisioning and service discovery and all those things, and create a live site so you can go in and filter. So, let’s say I’m only on the Linux ecosystem. You could filter them by Linux and see the tools that are available to do a particular thing like [AW] degradation. So, it’s a lot of really, it’s a cool live site that lets you do some comparisons around those common categories that have so much stuff happening right now.

The other thing I could point people to is I just published a blog today that showed up on the O’Reilly radar site called ‘Elvis has left the ivory tower’ about some current perspectives on software architecture, some of the stuff I was just talking about but a little more cohesive version of that. If you do a search for ‘Elvis has left the ivory tower’ you should be able to find that on O’Reilly’s site.

And finally the last thing, I’ve got an ambitious goal to read 50 books this year, which is about a book a week. And one of the things I’m reading through that I’m really thoroughly enjoying is a

science fiction series from an author who just died recently, Iain M. Banks, called the Culture Series. It’s a shared world kind of series, this culture of opposed scarcity civilization. Particularly the book ‘Use of Weapons’ is really cool because it tells two stories, one front to back and the other back to front. And they meet in the middle. So, it’s like the movie Memento but in book form. And he manages to write it in such a way so that the story that’s travelling backwards still has a really interesting climax. So, really, really interestingly well-written book called Use of Weapons in the Iain M. Banks Culture Series.

Alright. Well, thanks again for coming and talking to us. I find this topic just fascinating. And I’m hoping that we can really help some folks prioritize the things that they’re going to learn and the things that they’re going to adopt in their businesses and in their careers.

Yup, I do too. Like I say, I love this topic, too. I talk about it at conferences. So, the more people I can get interested in this, the happier I am.

Yeah, thank you so much.

Is there a good way for people to get a hold of you if they have questions or anything like that?

Yup. My website, NealFord.com has my email address on it. I’m also at ThoughtWorks. I’m just nford@thoughtworks.com. And I’m on Twitter, @neal4d, which is the leet version of my name.

Alright. Well, I think that’s all we’ve got so we’ll wrap up and we’ll catch you all next week.