Hello Tech People. Today I'm joined by Martin Snyder. Martin is the CTO of Wingspan and he's got over 20 years of experience leading software teams. Wingspan develops document management applications for regulated industries.
In my time with Martin we discuss his background, what is a 'Hostile Environment', how do we change hostile mentality, waterfall vs agile methodologies and many other topics centering around 'Hostile Environments'.
We are extremely pleased to have Martin on our show this week.
1. What is a 'Hostile Environment'?
2. How do we change the mentality?
3. What is the waterfall methodology?
4. Why agile is better, in the right environment?
5. How do we get everybody to buy in?
6. Why companies don't make the change?
7. Balance in a hostile environment
Carlos: Hello, Tech People. Today, we have Martin Snyder on the show. Hey, Martin. Thank you so much for being here. How are you today?
Martin: Oh, great. Thank you for asking.
Carlos: Just let me do a quick intro, but then I'll let you expand on it. For those who don't know Martin, he's the CTO of Wingspan and he's got over 20 years of experience leading software teams. I thought it will be a very interesting person to bring on the show because he's got a specific exposure to the things that we live as tech people and I thought it will be an interesting one for the podcast. We met at a conference in Philly, right?
Martin: That's right. Philly ETE.
Carlos: Philly ETE. I think because of your talk is what I thought, this is now something we're covering enough in the tech world and I thought it would be really interesting. Yeah. Now, for those who don't know ... I know I just gave a very rough intro to you, but why don't you tell us a little bit about yourself and what you do?
Martin: Sure. I've been developing software for a little more than 20 years. I've been in Wingspan for 15 of those years. Wingspan develops document management applications for regulated industries and the talk that I gave at Philly ETE was delivering agile methodologies and emerging technologies in hostile environments. Really, it's about being a modern software practitioner for myself in a world where you are subjected to a lot of onerous rules that makes it hard to be a modern software practitioner.
Carlos: What's your background like? How did you end up being in software?
Martin: The story starts when I hit 20 long, long time ago. Typing programs in and out of magazines and stuff like that. I've always been interested in how things work and so, I've done a lot of programming on my own as I was growing up, writing simple things but as far down as the rabbit hole as I could get. Then, I got a computer science degree and started in the field right around the dawn of the .com era. It's been an interesting ride, but I've been doing programming and then, software engineering and then, management and combinations of those three throughout that time period.
Carlos: You've been at Wingspan for over 14 years, right? That's a long time.
Martin: Yes. It's been long especially for this field. I think anytime someone's in a place for more than three years, your eyebrow goes up and you're like, "Oh, really? That's interesting." 15 for me here and we have a lot of people that have been here for quite some time as well. I think that what we focused on here at Wingspan in addition to making sure that everyone's compensated fairly. We focused very hard on the non-monetary benefits of an organization, that element of company building or culture building of management is ... I think it's becoming more and more popular and it's not as simple as soda in the fridge and ping pong tables and stuff like that, it's about really improving the quality of life of your work force both in the building and outside.
Carlos: You know what's really interesting is for somebody who's been at one company for 14 years says a lot about your experience and what you've been exposed to in terms of the changes in technology and also the ways that the technology is delivered.
Martin: That's absolutely true. For Wingspan, we've been predominantly on the JDM but this is the JDM from 1.2 up through Java 8 and we've touched some stuff. We do things on .net, we do things from C++. We've seen a lot of ancillary bits and pieces as well. It's a long time, we have continuity in this space but it's always changing and if you let yourself fall too far behind, it can be really hard to catch up both in terms of personal expertise and then, just corporate and engineering credibility.
Carlos: What's your core role at Wingspan? I know that you're the CTO, but what is your life look like there? What's your main challenge?
Martin: My biggest responsibility is making sure that as an engineering organization, we're headed in the right direction and that means we're choosing the right technologies. We're deploying them correctly. We're using the best practices and it's not always the most modern things but you got to strike some balance on there but you need to make sure that you're doing things that keeps your organization as efficient as possible. That's the biggest word that you had out there is efficiency. If you want to get the greatest value generation for time spent and there's a lot of different ways to achieve that. That's really the biggest part of what I do is how can we make architectural decisions that lets us solve the problems of highest value while avoiding things that ... You spent a lot of time to produce low value and things like that. Technology selection, what you're going to deal versus what you're going to buy, what third party software you're going to rely on, things of that nature.
Carlos: All right. Our mission today is to help those who are in some of these hostile environments still thrive using modern technologies and also modern ways of executing and as you said, the title of this podcast is going to be delivering agile methodologies and emerging technologies in hostile environments. I think the first thing we should do here is let's define what a hostile environment is. How do you define it?
Martin: There's two definitions. The first is it's almost little flipping but it's simply anything that's hostile to agile methodologies for emerging technologies so I think I can't remember the exact statistic but when they talk about people that work, writing software for a living, a very small percentage of them actually work for software companies. Most of them write software for non-software companies and those environments are generally hostile to agile methodologies. They're hostile to emerging technologies and they are mainly because software is a secondary concern. Their primary goal is not to have the most efficient practice. Their primary goal is not to have energized technology work force and to keep their software engineering skills sharp and at the leading edge and things like that. Those sorts of environments can be hostile to the things that people are trying to achieve to be as efficient as they can be. Â Generally, the main characteristic is just the software is the secondary concern. That's the number one warning sign that you're in such an environment.
Carlos: Hostile in the way that let's say that software engineering becomes part of IT and usually, I don't know why, but I've seen IT being relegated almost to a maintenance type of role where it's just there to support the business, make more money or wherever their money making lies in but actually, it's interesting. This is probably something we're going to talk about further down, how do we change the mentality of the business people to understand that the technology side of ... The way that they implement technologies could really impact even the bottom line?
Martin: The first thing is it may not be the business people that have to change. It could be that it's not a one size fit all for software development. It might be that the development attitudes need to change in certain circumstances. It's really a balance that people need to strike in figuring these things out. The most important message that I have is in a lot of these cases where things are hostile to what the software practitioner wants to achieve, there's reasons for it. It's not simply that no one cares about the software engineer or they don't appreciate the efficiencies or something. Typically, there's something more important that's driving those decisions. In a lot of cases, you end up in these circumstances where you have rationale actors and those rationale actors make decisions which don't really look like great decisions on their surface.
That's one of the things that I got into my presentation. Â I had a little bit where I was talking about cellphone selection and basically, you can manipulate people on to choosing a really lousy cellphone if you just make certain requirements more important than others. Â Even though you've loved to have the phone with the biggest screen and the longest battery life and the best apps and all those stuff, if you're looking for the best phone to take on like a six-month submarine tour or something like that, then a lot of those things aren't going to matter anymore if you were going to choose something else.
When you get into these large enterprises, you might want to build a piece of software with a project team that's going to have a life span of 18 months but you want the software to last 18 years and it turns out which developing methodology you use in those 18 months isn't really the most important decision. I think having that kind of broader perspective for what is really trying to be achieved is important in making those decisions. That's why the primary versus the secondary element is so important because if you're working for a software company, we're a cloud service. We make greeting cards or something, and that's the business that you're in, obviously all that really matters is you just want to improve that service every day.
You want to do frequent delivery. You want to just always be thinking about how to make it better but if you're one of those other circumstances, what you really want is you want to build it to be good enough and then, you want it to have the greatest staying power. You want it to last with the lowest maintenance cost for the longest amount of time, it's really different thought processes that have you construct these things.
Carlos: What industries would you single out as being hostile for emerging trends of technologies?
Martin: Well, I wouldn't want to single out anyone, but certainly the larger the organization, the more likely it is. The more regulation that the organization is subjected to, the more likely it is. For instance, if you work for the largest bank in the world, it's likely that it's hostile to agile methodologies and it's hostile to emerging technologies.
Carlos: In a way, we are promoting agile and emerging technologies but we are also playing the devil's advocate and saying, "Well, it just doesn't apply to everything because there's areas in the business world where it just doesn't apply."
Martin: Well, it's not that it doesn't apply. Really, my message is about how do you do the best you can when there's so many fixed constraints that you don't have all the choices? You can't just pick up your Scrum manuals, and say were going to do Scrum because there were so many other things that you're responsible for that that just doesn't fit that role. When you're in that, you have these pillars in the sand that you have to navigate around, what is left? What do you have a lot of control over? How can you make choices that lets you make some gains and some efficiencies without really upsetting the apple cart or having to fight really lengthy political battles The hope is I think for a lot of people, the hope is that if you have enough success doing that incrementally, that might draw attention and that might lead to having a little more latitude in the future but I say all of this but my clients are in this category, and so we need to deliver software into these hostile environments but Wingspan is a small and mid-sized agile software development firm.
Software is our primary business. We just happen to operate this space where we come into contact with this stuff a lot. While I've experienced some of these problems and I've dealt with them over a great period of time, I'm very far remove from someone who's in like a cubicle farm at some large organization moving from software project to software project. There's definitely people that have this source of problems much worse than I do. What would I like to speak about is I like to speak about the things that I've seen be effective in this environment setting and why I think that they're effective.
Carlos: I think the two items that we picked out as just for our conversation is the way that we're delivering projects and let's call that waterfall versus agile if that's a way to call it. Then also, technologies technician versus we're using trending or emerging technologies. Let's start with waterfall. In reality, we all know what a waterfall is but for those who still needs some clarification, how do you define it?
Martin: Waterfall is when you breakup the different elements of a software project into static pieces that occur in a linear sequence. You have the conception of a project typically followed by the drafting of requirements, typically followed by the design of the software, followed by the implementation, followed by the testing, followed by the deployment, followed by the support and maintenance. All of these things must be completed before the next phase can begin and it's typically, you want everything to be perfect at the hand off ... From one stage to another. For instance, you would like the requirements to be as detailed and complete as necessary before the software design starts, so that you don't have to reengage those people and have more conversations about requirements and likewise to the software design to the implementation and from the implementation to the testing.
Carlos: It sounds good though.
Carlos: By the way, it sounds like, "We could live with this," but what's the downside?
Martin: There's a couple of downsides. The first is and I think regardless of quality assessment, I think that most people could agree that it is ultimately the most expensive way to develop software. I think that's a fair statement. It turns out that it's very, very challenging to get all these things right on the first shot. It's hard for the requirements to be complete such that all of the software engineers understand what's required exactly and all of the testers and so on and so forth. Just by way of an example for that, I remember when I was in grade school, I think it was at 6th or 7th grade, we had this exercise in English class where we sat down for 15 minutes and you had to describe your room, so you will write down I have a bed I have a desk and you have this and she spent 15 minutes, "Write out in as much details as you possibly can."
Everyone sits there and writes it and then they say, "Okay. Well now, take your paper and pass this to the left and let's just pretend we were all sitting in the circle so that was not complicated at all." Everyone gets someone else's sheet of paper and they say, "Okay." Well now, take another sheet of paper and you draw the room that is being described and you've run into all of these issues that you don't even know necessarily how many walls... The rooms probably have four walls but if you think about most like bedrooms, it's not exactly four walls, it usually does an inset of doorway or something like there might actually be more than four corners of the room. They're not describing things like the material of the floor and baseboards and what style of bed. The drawings end up looking nothing like the actual room.
The question is did somebody mess up there? The requirement wasn't necessarily to describe a room in English such that a non-experienced person could render it completely but you can see where the problem arises. The people writing the requirements don't necessarily know all the questions that are going to be asked by people down-stream from them so it's difficult for them to articulate on the first try exactly what needs to be included and what doesn't need to be included. This is why good BAs make a lot of money. The same thing with the testers asked and the developers asked. They contribute to clarifications of the requirements.
If you spend enough time on it, then you can definitely get it. You can just keep adding and augmenting the requirements until there's no questions left and how do you construct that in the waterfall methodology and things like that. It is a question. It's a challenge to do it in all those linear steps. It is possible. It's just the most expensive and what agile methodologies really strike at is they strike at two things. The first is the efficiency of producing the highest value thing in the shortest amount of time and the second thing is they focused on that value proposition and the communication between the groups so that value is not measured as a number of requirements which are met, the value is measured by the happiness of the people that requested the application and how accurately the manifestation of the application reflects their understanding in their needs.
Carlos: Let's figure out where each fit just to give us an idea. Let's say you're building a plane. I know I'm going out of software here in a second. Let's think we're doing something such as a plane, something that is going to carry a couple hundred people, it needs to just fly, it needs to just work 100% of the times unless we're going to have dead people. Would you say that waterfall applies in that environment better than agile?
Martin: Yeah. This is where waterfall came from. Waterfall came as a software development methodology in the 50s and 60s or maybe even a little earlier but it was applied because they were thinking, "Well, this is how we build bridges and this is how we build boats and this is how we build planes, so this is how we're going to build software." There's two things that is an issue here. The first is that people have been building boats for probably a thousand years. A long, long time, people have been building big boats and they know a lot of things about boats. Even if you just look at modern boats or airplanes or something and if you were looking to specs of like a Boeing 747, I think the detailed specs for like one rivet that is used in one of those planes would probably surprise you at how much detail it goes into in terms of the materials and the strength it needs and all of these different requirements.
Fundamentally, planes have a lot in common with each other but software hasn't been built for nearly as long and software, a lot of times, there's not as much common ground in software applications as you would find in something like bridges or building foundations or something like that. I think that's one element of it and the second is the parallels are usually wrong is that people like in the implementation phase where software engineers are writing code, they liken that to pouring concrete where welding joints or something like that and it's really not, it's more like that's the architecture step. That's where people are doing very detailed drafting of every inch of every nook and cranny of this and that where all those details are being represented.
They're not being represented in pictures that people can see. They're being represented in source-code that has dual meaning to humans and to computers and stuff. I think that there's been this weird offset where people, originally waterfall was made to line up with construction processes but then, I think the things were lined up with the wrong steps and so, that's produced a lot of the misunderstanding. That being said, places where waterfall makes the most amount of sense is where software touches the real world, and by that, I don't mean like a website or something, that's the real world but not in the same way.
If you're building software, for instance like that operates in a medical device or something in a self- driving car or telemetry computations for a rocket or something like that, you don't get as many chances. It's like failing unit testing and getting a little red screen isn't really that big of a deal but sending a $70 million rocket into the ocean, that's a little more costly. When you start to have software that interacts in a more real way with people, with the world, with people's lives, I think that there, you see that the waterfall methodologies make a lot more sense where your tolerance for failure is much lower and that's kind of the tenants of agile is it isn't just you're iterating quickly and you're trying to deliver as quickly as possible in all those things, you're trying to have this really tight communication between all of the interested party, so you find out your mistakes as quickly as possible.
It's not just you're trying to deliver quickly, you're trying to fail quickly, you're trying to make your mistakes early in the process and have them be detected and corrected and there's circumstances where you can't really test the software that early.Â You have to be more rigorous with other parts of the methodology.
Carlos: Let's build a case for those people that are not going to say, "Yeah, waterfall." Let's show them why agile is a better way to deliver software in the right environment.
Martin: Well, a couple of things you're trying to avoid with any software product, the biggest one is after the money is spent is showing it to the people that requested it and having them say, "This isn't what I want." That's really one of the most colossal failures. It's always better to fail sooner because if the customer's not going to get what they wanted, you'd rather have been six months late and have your project cancel then make it all the way to the end and only you find out then. That's a problem because if at the user acceptance test phase, when the people that commissioned an application get a chance to see it, it usually happens very late in a project.
And so you might say something like why not just move that up and they can't move it up and you can't move it up because a lot of these people aren't software practitioners and so, if you showed them some work in progress, they don't have the vision to see what you're trying to get them to look at and so, they are always disappointed then either. Really what agile says the answer is to engage them completely in the project. Don't just show it to them here or there or whenever you're told to in daily contact or more, just constant contact with what's going on, let them see the construction of the process, let them interact, ask the questions, don't wait, don't be like, "Oh, you have to write all your requirements, and then we're going to go and build it." No. We're going to draft the four requirements as we're building it.
This is the story that we're constructing this week. Let's just talk about that and we're going to keep iterating to make this better and better and better and then, we'll all know more about it in the end and we can decide are we done or are we going to take another shot at it or something like that. Really, it's not so much about technology. It's not really about anything other than communication. Agile is trying to take away that static serial communication structure waterfall and is trying to get constant communication between all interested parties, so they're all making progress at the same time rather than saying, "Hey, for three months, it's your job. I am going to sit on the sidelines and I'll just let you know when I'm ready." It's not like that at all. It's really a communication mechanism but it's also an organizational culture. You have to have everyone on board that that's the right way to go and you can't just say something like, "Oh, we developed our software agile-y. Our software engineers are agile practitioners."
Statements like that, they reflect a lack of understanding of what agile is. Agile has to be like top down and pervasive through the whole organization that everyone is participating at all times. It's really the most important facet.
Carlos: What will be your biggest piece of advice for somebody in let's say software leadership within an organization? Let's say that has been established for more than 20 years and they're in the midst of implementing some of these new ways of delivering. Again, in a hostile environment, what's the biggest thing they need to be thinking about in terms of how do we get everybody to buy in?
Martin: That's a great question and it turns out it has a really great answer as well. There's one thing you want to focus on, it's a continuous integration server and this can mean different things to different people. You can have something like Jenkins or Bamboo or something that's doing continuous builds and unit test and deploying to an environment or it could just be some extra computer that someone is happens to have in their office. The thing is it takes what you can get especially in a more hostile environment. When you set up something which is updated with great frequency and by that, I mean daily or more and that becomes the focal point of your communication. You communicate through that.
If you have a question, you point them to some area of this work in progress build and you say, "This is what I'm asking about," and then somebody ... If they want to see something, they can tell you where they want to see it and that increases engagement in a couple of different ways but it also will improve many other areas of your software development practice. To have an active continuous integration server, you're going to be doing a ton of builds. You're going to have build automation perhaps better than you've ever had before. You're going to have a unit test. You're going to have things that you have to do to be able to deliver a continuous integration server in a real sense and once you start down that path, if people start to see the value, it just makes you want to invest more in it.
If you pick one thing, that's what you pick but it drags almost everything else along for the ride. Everything else is good about agile and about best practices in software development in general, just doing that well will cause you to do so many other things well and you will never go back.
Carlos: What's interesting about your answer is that it almost takes you towards an anti-technologist/technician, right? Because all of a sudden you are having to implement new technology, so let's jump on that subject. What are some scenarios where this can happen and why does it happen where companies just say, "I'm going to stick to PHP because PHP is the future forever." They may have valid reasons but they're not willing to move from version 0.1 of something towards where we are today.
Martin: I think ultimately it comes down to cost but not in a bad sense. I think that like I said earlier, the people making these decisions are usually rational actors and so, for instance, one of the things they might be saying and your example is they might think that they have greater access to a talent pool of PHP developers and if they had a need for a PHP developer at say one of the three levels, they know exactly what that position will cost. They know that they can find somebody that will meet those requirements and they know that they can fill that position within a certain amount of time and if you were to compare those elements both what you think the numbers are and then, what your confidence in those numbers are for something like PHP and then can go and compare that to something like Haskell. You would see why this makes such a difference.
You can't hire an entry level Haskell programmer. Most of the Haskell programmers are very advance practitioners, they're very expensive and there's not very many of them and there's certainly not many on the open markets. Answering any of those questions, what they would cost? How applicable they would be and how well it would take to find someone to fill the role? Those things all turned into questions, and so when you're looking at programming platforms, that's one big thing. If you have a large organization, that's already filled with PHP programmers, you have two choices. You can retrain them all or you could get rid of some or all of them and replace them.
Both of those are pretty expensive and it's not necessarily a great way to treat your work force, it's a challenge. If you wanted to make a big shift and you had say, a thousand developers even if you were committed to retraining, it's not necessarily that likely that they're all going to complete the training and still be effective or you're going to have some attrition one way or another through that process. When you're looking at technology platforms, you're committed to more than just the language. You also have all the people involved. The other thing you see more like the service side technologies like operating systems databases and things like that, the larger organizations, they realize pretty quickly they can save some cost by not having a lot of specialties on the project teams and instead having a pool of specialist for technology that are shared throughout the enterprise.
Ten people use your Oracle shared database and that cost 1.5 million a year run, then each of the ten projects get charge $150,000 and that's a very easy way to do the accounting and so, once you start doing something like that, if you're standing up a new project like your costs are much higher to introduce your new technology because you have to bear all the build out costs versus you can just choose some existing internal platform and just get a slice of those shared platforms in as much less costs. I think there's a lot of direct economic factors that come into play in those larger organizations.
Really all we're trying to do is we're just trying to amortize cost across multiple projects and that leaves the homogeneous environments and then, once you start down that path and you start to have homogeneous environments like two thirds of your applications use BEA WebLogic and Oracle, then it becomes much more costly to build something that doesn't use that shared platform, so it creates this very high friction for using your technologies.
Carlos: How do you balance that? In your specific case as a CTO where you are making these decisions, for example, I think all the variables you just pointed out are extremely important and are the it for a business but how about the cost of that? Meaning for example, let's say that you're losing engineers because you are working with the old technologies or technologies that are paying to work with. As we both know, the modern engineers want to work with modern technologies, do you want to get ahead? How do you balance that out?
Martin: Well also, there's a couple of things. First is the further behind you fall, whatever that means to you. The further behind you fall, the more expensive it is to catch up. One way is the changing more frequently and when you're talking about like library versions, that's a little easier to understand. It's like, "Okay." This library we depend on, from version 1 to version 2 and it's still taking a while to handle the upgrade but if we wait until it goes to version 3, then it's going to be a real, real mess. It's a little harder to see with programming language like when do you go from ... When do you adopt to Java 8 like when do you retire Java 6 or something like that? Those things are ... They're hard. It's definitely hard.
When do I select new technologies? I think what it forces people to do is it forces people to really answer the question of what they're getting in return. If you look at, let's say I've been building Oracle applications my whole life and I want to build a Mongo application instead, having to cost justify that isn't necessarily a bad thing? Why do you want to do it? It's because you read a blog post and you'd like to try it out because there's a lot of better ways to try out Mongo than to put some some $5 million corporate project at risk but on the flip side, you might end up in some situation where, "Oh, no. We're actually looking at what we're trying to do isn't achievable with Oracle and what we've really need is we need something like a solar index. If we can just get solar farm deployed, then we'll be able to build ..." The same piece of functionality, we're going to build it in like a quarter of the time, it's going to operate 20 times faster and it's going to save us this amount of money at Oracle licenses or something like that.
There's definitely a lot of cases that have to be made in those larger organizations but also it gets down to what exactly are you trying to achieve and why you want to achieve it that way? There's definitely cases where people are turning software projects or technology decisions into science projects. Gee this is curious. I wonder what happened if ... There's a more deliberate way when you actually bear the responsibility. You need to take a closer look and you need to really understand what it is that you're giving up by not using what you're used to using and what it is you're gaining with the new thing that you want to achieve? Then, the recruiting angle is an interesting one as well. You don't only want to attract the people because of the technology stack that you have because that's the only reason you got someone, I think you're going to have a tough time retaining them. You can't always put the shiny new thing in front of them every six months.
At some point, there will be something else they're interested in and they might leave for that reason but at the same time, I think that if you're really trying to manage a healthy work force, you have to do at least something to help people stay current with what's going on. If you let your entire work force stagnate in terms of technology growth and development, I think that that is a failure of management because what's going to happen is you're going to lose access to a whole portion of the talent world that is staying current and there's likely a lot of people in there that you would like to have access to it and all you're going to be left with when you go to hire is you're going to be left with other people that haven't been able to keep up either and that's usually not a high selling point like when you're starting to say, "I want to add five people in my organization." You don't normally start with, "I want to hire five people that haven't been able to keep up."
You might have your own reasons for struggling to keep up but when you go out to the work force, you're going to want to bring in like the people that have done as much as they possibly could.
Carlos: Martin, this has been an awesome interview because you've given us both sides of the equation not just the one sided. A lot of people fall into like this is the only way because for everything it applies and the reality is that it doesn't. The reality is that there's two sides for everything and you've given us both sides for both ... The ways to deliver and also, the actual technologies that we think that we're delivering but now before we end the interview, I have three last questions for you that are more about you personally. What advice would you give your younger, less experienced self?
Martin: That's a good question. I thought about this since I saw it in the preview on the question, I thought for that a little bit. What I would say to my younger self in terms of software engineering is embrace a new ability sooner. It's a functional programming concept but you don't have to be limited to functional programming to apply. If I was to pick one thing, that leads to a clarity of thought as a programmer faster than anything else that I can think of.
Carlos: Awesome. What will be a book you'll recommend on the subject we discussed today?
Martin: I don't have one book to recommend. I think for what I'm talking about, I'm talking about this world of compromise of trying to do the best you can in an area that isn't particularly interested in you doing the best you can. There are no books on that topic. I think that what people want to do is in terms of methodologies is you want to read anything that's going to help you understand agile principles, not agile methodologies like knowing Strong Well doesn't really do you any good versus understanding the benefits of the communication pathways and the integration servers and things like that. I would just read online for the agile stuff and then for the emerging technologies, it's so much of it depends on what problems are interesting to you.
I wouldn't for instance recommend people will go out and read up on Spark because Spark is really cool and a lot of people like it and people that know it well make a lot of money. Those are the wrong reasons to go and read about Spark, but if you're actually interested in digging big data problems if you have access to large data sets especially there's a lot more data coming out of municipal governments than has ever been available before. If you're interested in problems like that, then using Spark in that context would be a very smart move. You want to start with a problem, don't start with a technology and read up on it. Try to find a problem that's interesting to you and then, seek out the technologies that would let you do it. I don't have any one book on either topic, but that's the approach that I will take.
Carlos: All right. That's a good approach. Now, how can people find you and find your work?
Martin: I'm on Twitter, @martinsnyder. I have a blog, martinsnyder.net. Those are the two best ways, I'm on LinkedIn and other things but if you can start at one of those two spots, you can find me on all the others.
Carlos: Are you guys hiring at Wingspan? One of the things we're doing is the people that we're interviewing may want to hire people that are listening. Are there any spots you guys are trying to fill?
Martin: Wingspan Engineering is always interested in people on the back end, our dominant technology is Scala. On the front end, our dominant technology is ReactJS but we recognize that when you deal in emerging technologies, those are not hot off the presses but they're enough. We don't necessarily hire for skill and experience in those areas. If people are interested in them, that's usually enough. They can pass the other parts of the interview and we train up in those areas.
Carlos: They can check you guys out at wingspan.com?
Martin: Correct. Thank you very much.
Carlos: All right. Well Martin, once again, I want to thank you so much for the interview. I think as I said, it's been very interesting because you're not just exposing one way like this is it but it's more of a brainstorm approach to this like if then, do this type of thinking versus only do this, do this, do this. This stick is not the only tool we've got. We've got all sorts of tools, so I think your answers have been great. Thank you so, so much.
Martin: Well, that's the rule I live in so I'm happy to share it with you.
Carlos: All right, Martin. Thank you so much.
Martin: Thanks a lot, Carlos.