Software systems to innovate and grow

Episode 40

How Architecture Has Helped to Be a Better Engineer: Mike Simpson with IgnitionOne

Show Details

Today we have Mike Simpson on the show.

He is the Principal Engineer for search at IgnitionOne, a web based system which specializes in ad campaign managing across multiple search engines.

On today’s episode, Mike offers insight on what it means to be a digital media suite, the daily stresses of technical debt, and how a background in architecture has helped him to be good at what he does.

Show Transcript

Carlos: Alright Mike, thank you so much for joining the show. How are you doing today?

Mike: I’m doing great. Thanks for having me.

Carlos: Alright Mike, it’s been a while since we did our pre-interview but I’m really excited and I’m glad that we’ve been able to connect to this interview. For those who don’t know you that are listening to the show, tell us a little bit about your background and what it is that you do.

Mike: Well, I’m a software engineer, an architect, and a bit of management. Currently my job title is Principal Engineer for Search for IgnitionOne. I actually did not study software engineering formally. I mean, I have one class in high school that was a long time ago. I started programming basically on my own when I was about 13 on a TRS80 Model 3 and kind of learned some basic programming, and took this class in high school and then didn’t do a whole lot. I mean, I wrote some things while I was in High School. But then I went to Georgia Tech to study architecture, and I studied architecture for four years, and then decided at that point I didn’t really want to be an architect. I was able to get a programming job based on being able to actually write some code and show what it is I wrote. I’ve kind of taken that and learned a lot along the way and done consulting work for the last five years of work for IgnitionOne which is a software product company. Basically, just trying to learn as much as possible and do the best job I can with it.

Carlos: Alright. Mike, that’s great. Now, one of the things that will help us get some more context is tell us a little bit about what is IgnitionOne does. And just for those who are listening the idea today is we’re going to talk a little bit about Mike’s experience through his career, but also about his role at IgnitionOne, and some of the experiences he’s had as an engineer especially one coming from a non-traditional engineering background such as architecture and how that shaped some of his career. So Mike, tell me a little bit about what does ignition want to do, who are their customers and etc.

Mike: Ok, so IgnitionOne is a software company. We have a product that, well for the past few years it’s been called the Digital Management Suite or Digital Media Suite. But what the company does is we have a software platform for managing ad campaigns on Google, and Bing and various search engines like Facebook. But where we differ from a lot of companies in that space is that we cover multiple channels, so we have search, we have display advertising which is for example if you’re just browsing around the web and if you’re on or whatever and they have a space on their page for ads, those are supplied through a central broker like Google or company like that and we work with them to coordinate those ad campaigns. Our customers are usually large companies like Fortune 500 companies, those kinds of large retailers and things like that. So what they’ll do is they can use our software to manage ad campaigns across multiple engines and also tie together different channels. So for example, if we serve you an ad and you click on it, we’re able to kind of tie that into other types of campaigns, email or that kind of thing.

Carlos: Very interesting.

Mike: Basically, our job is about making sure that we support all the features that our customers need in order to make these campaigns successful to optimize these campaigns so that they can get the most bank for their buck. I can talk a little more about that maybe in a few minutes. But one thing that kind of surprises some people about that is that advertisers don’t necessarily want to show as many ads to as many people as possible. They may not even want you to click on an ad. They want to show the right ads to the right people. But there are some fairly significant problems of scale that come with this space and this is something that’s been new for me since I came to IgnitionOne about 5 years ago. Prior to that I’ve done some things that had involved some scale but it was a different type of scale. For example, instead of simply large amounts of data or large numbers of users. IgnitionOne mainly has large volumes of data, but large amount of activities happening in the system at all the time but it may not be based on large numbers of users, so we have to consider problems of scale but it is more like a lot of it is automated activity and we have to think about how to make that efficient and that kind of thing. Those are really interesting problems to me.

Carlos: It’s definitely sound interesting. One of the biggest things is that you’re solving a problem that needs, it’s not an easy problem to solve because as you said they are trying to get the most value for their dollars, and that is a complex problem to solve. Meaning that if you mess up, not if you mess up, but if the feature doesn’t perform in a certain way there is an arrow eye by your customers, right? So you’re walking a fine line in essence.

Mike: That’s true. You know, I would say our company in particular that’s not a 100% our problem in that we are not an ad agency and we don’t generate content, so we don’t come up with the ads. But we facilitate our customers or the agencies that represent them, getting those ads into the system and making sure that the bid amounts are correct and being able to coordinate that activity across busy holiday weekend for example, Black Friday or Cyber Monday. There’s very tight timelines that these campaigns have to act too. Our software platform has to be stable so that those things can get done. And if they don’t, some of these advertisers spend large sums of money every month, and there are some risks associated with handling those accounts. For example, if an advertiser, and normally we might charge a small percentage, 1% or 2%, of whatever the advertisers is paying the search engine. So if one of our customers is paying Google million dollars a month or something we’ll get a small percentage as our revenue. However, if our system goes down and that traffic does make it to the advertisers and then they lose sales, we’re on the hook for whatever they still have to pay the engine, so that can be pretty scary.

Carlos: “I was a Principal Search Architect”, what does that role mean? I think in the engineering world we might think of that as somebody who builds search tools or internal search tools. But how does that apply at IgnitionOne when you guys are working with Google, you’re working with all these search engines, does it have to do anything with that or is it purely internal?

Mike: You know, you kind of hit the nail on the head. It is not that IgnitionOne is building a search engine. We don’t do that although I actually did built a search engine way back in my career maybe around 2000 or so. I actually built one as part of an internet for the company that I was working for at that time but that doesn’t really count. It’s nothing as sophisticated as what Google is doing. What we do for IgnitionOne, search is a vertical so it’s what we would call a channel. So that would be for example, if you went to Google and search for something and then you comeback with some results. Those results are broadly classified into two areas. There’s paid search ads which are ads that appear at the top and down the right side, and then the natural or organic results which are the actual search results. Our department, the search vertical within IgnitionOne is concerned about the paid search ads, so at the top and on the right. There are other companies that focus on organic search results like search engine optimization companies. I’ve already talked about display, that’s another channel. There is also email, social which will be Facebook and other channels like that. So we have a lot of custom integrations with our customers and with other partners. So as far as search goes, within IgnitionOne my job revolves around our software platform for managing ad campaigns that deal with direct search of the ads that show up in the search engine when you search for something.

Carlos: Got it, so yeah that’s what I kind of thought it would really lead to that because it could trigger some thoughts of, “Whoah, he is a search engineer”, which I know has its own kind of world. So talking kind of different worlds and backgrounds, again you’re education background was architecture, do you think this gives you an advantage or do you feel like it goes against what other people studied. How do you think that gives you like a unique perspective into your role?

Mike: I think it helps me be a better generalist. You can think of software engineers or probably any profession. You can kind of divide into specialists or generalists. I think myself as a pretty good generalist. I know a little bit about a lot of things. Actually there is a guy that I worked with that describes it the ideal thing to be is what he calls “T-shaped”. So you know a little bit about a lot of things and a lot about some subset of those so you have a lot of depth. I think I fit that mold. Architecture is also a profession that involves a lot of integration of a lot of disciplines. With that you really train both sides of your brain. You are turning both the visual side. The right side of your brain is more artistic and creative. As well as the left side because there is a lot of technical details that you have to master and your success is really determined by how well you integrate those two things. From that standpoint I think it’s similar. I will say it drives my wife nuts. Actually right now I don’t have this but for a long time I’ve had Architect in my title, she is an actual architect. And so this is kind of a running joke between us but it drives her nuts that I have Architect in my title but I’m not a building architect.

Carlos: And talking about that, I know that throughout your career you’ve had a little bit of switch between managing people and being a developer. Can you talk to us a little bit about that and which area do you feel more comfortable which is you preferred kind of area between management and being an actual engineer?

Mike: I kind of qualify this by saying that I haven’t spent a long amount of time as a manager. I spent maybe about two years as a manager of a development team at IgnitionOne, and I found it more rewarding than I thought it would be. Also more difficult that I thought it would be but it’s a very different job than programming or architecture. And I would say it doesn’t necessarily fit myself image as much as the more technical roles.

Carlos: Got you. So you feel more indentified with one of the other and I think what’s important is that people don’t need to feel that they are forced to being a manager when their nature is not to be one. It’s to be a really good engineer and that’s it, and then sometimes people think of being a manager is you’re not making any progress if you don’t pick to be a manager. But I don’t think that’s true. I’ve met a lot of people who go down the management track because they love it. But there are some that are like, “Ok, I’m forced to be manager now and I hate it.” It’s an interesting problem to have because in a way it’s supposed to mean progress but in other sometimes it isn’t. Talking a little bit about challenges, what are some of the challenges in your everyday life as an engineer? By that I mean what are the biggest areas of focus of your work as of now that push you or pull you to do a lot of work or to exercise your brain and learn things. What’s the biggest challenge right now?

Mike: I would say the biggest challenge I have at IgnitionOne is that within search we have a significant amount of code. A lot of it is really legacy code. This is code based and parts of it are 10 or 15 years old. We’ve probably got, if you count all the store procedures and things like that in the database and along with the rest of our code, it’s probably a million lines of code total. The biggest problem I have is that we have significant technical debt and to me that is both a symptom of and a compounding problem that is related to our business model. So this isn’t something that would necessarily apply to every company but I think there are probably people listening that can relate to this. One of the business drivers that we have, like I mentioned earlier, IgnitionOne operates in multiple channels with multiple large partners like Google, and Bing, and Facebook and whatnot. It’s important that we remain partners with those entities because it helps us not have to pay API fees, so we save a lot of money by being a partner. However, being a partner requires that you have to implement certain features according to your partner’s timeline. So Google can come to us two or three times a year and drop some features and say, “Ok, we have to implement X, Y and Z by this date.” Those features compete with those features that are product managers come up with and they also compete with technical debt. So when we have this kind of feature set that is dictated to us with a timeline it makes it difficult for us to be in control of our roadmap. And at times it creates very tight deadlines and it makes hard for us to, it both encourages us to cut corners and it also gives us less time to address technical debt, so over time the net effect of this is the dynamic where technical debt increases over time. So that’s probably the biggest problem that I have to deal with is trying to find ways to satisfy the deadlines while simultaneously addressing technical debt where I can try to keep it from getting worst over time.

Carlos: So this is going to sound like a painful question, maybe unfair, but again you guys have been around for a while and you’re talking about occurring technical debt as part of the business model just sometimes you’re forced not occurring as part of the business model but again through relationships, you’re forced to do a lot of that work so incur extra work that puts other work behind. But again, the company began for some time now there is legacy code I’m sure. Do you guys have dedicated resources just to handle those old systems, or are they integrated to the modern like the newer stack and what’s the plan for those? How do you plan for some of these legacy code while still dealing with not only your story work, your product work but also the partner work?

Mike: Well, the general approach that we try to take, there are certain times in the year, like late in the year, like during the holiday season and maybe in the first month or two of each year. We’ll have a little bit of breathing room to address the technical debt, so that’s given. Right now actually my team is addressing some technical debt and taking out some really ugly feature toggle and permission type code that’s been in there for a long time. Then we are replacing it with something better. A general approach that we try to take is with each new project we ask ourselves what are the pain points related to this and can we re-implement those as part of this project in a way that doesn’t cause it to take twice as long or three times as long. The challenge that I have is kind of the technical lead for search at IgnitionOne is indentifying which of the pain points within the system can I draw a box around and easily re-factor or re-implement it in a way that doesn’t involve a lot of risk for everything around it. As part of the issue with the legacy code is that it’s not especially well segregated so when you have a lot of tightly integrated code that doesn’t have boundaries within it it makes it very difficult to pull this one thing out and replace it with something better. That’s my job is to understand where the potential boundaries can be drawn in that code base such that we can improve it without involving a ton of risk.

Carlos: Is there a mechanism of prioritization for say some of your bandwidth whether it goes for A, B or C. Is there some or who prioritize it for you? How does the company prioritize those things? Generally speaking our prioritization is done by our product team so we have a team, product managers each. Within Search we have two development teams. Each one has its own product manager. They report to a higher level product manager. They are responsible for prioritizing the work that we do and I’m actually lump into one of those two development teams just from the standpoint of making sure that my work is accountable and tracked. But the actual work that I do spans to both of those teams. You know, I would say at IgnitionOne it’s not especially systematic in terms of, like one thing that I pushed for that we haven’t implemented yet is I suggested that we dedicate one or two people to technical debt reduction kind of a more long term basis. And basically modulate how much effort we devote to technical debt just by controlling how many people are working on it as opposed to kind of doing it on a project by project basis. You know, this would be true for most companies I would think even people practicing Scrum or whatever. The project managers are not necessarily in the best position to be able to evaluate and prioritize technical debt stories. That involves a lot of conversation with somebody like me who can articulate why this ugly piece of code is a problem and how it’s costing us money. Until they can understand why it’s a problem and why we should implement that before we tackle this new shiny feature, those kinds of things tend to fall by the wayside. That’s why I feel that it would be nice if we had a more systematic approach to addressing technical debt but currently at IgnitionOne we are more pragmatic about it. We basically surface technical debt stories. We have an epic for those and we put stories in the backlog to address technical debt and we have to have a lot of conversations to evaluate what we can do now versus later.
Carlos: It’s interesting I think for others that are dealing with similar issues, I don’t want to call it an issue, but as similar challenge where technical debt is there, right, and some strategies to deal with it. I think it’s interesting just to start thinking of that as an idea of having dedicated people for it. Now, the last question before we head down to last three final questions but last question about the company and the career, what are you excited about? What are you excited about for the future? What’s the next thing in terms of projects? What’s one of those things that you can’t wait for?

Mike: Well, like I mentioned, we’re currently addressing some technical debt right now. That is fairly exciting to me but actually we have a project that is coming up which hopefully I mean is we haven’t kick it off yet but it’s slated to start pretty soon. It’s a project to rewrite one of our major backend services and if it pans out the way I’ve designed it, it should end up ultimately cutting our workload down on our backend services by 90%. In a nutshell we have to stay and sync, we have this big tree of hierarchical account or campaign data. We this big hierarchy with account at the top and then campaigns and under each campaign you have ad groups, and under ad group you have ads, keywords and various things. We have to keep the structure in sync between our system and between the engine. So if you go into our system and make a change, we have to push that to the engine. If you to the engine and make a change, we have to pull that to our system. So pulling that into our system is a very inefficient process right now. We basically pull the whole account from the engine which might be millions and millions of records and we compare everything with what’s in our database. And anything that’s different we update it in our system. Because it’s so big we can only do that every two days or so for most of our accounts. So the change here is to only pull for changes and the engine can now tell us what’s different.

Carlos: Got you. You know, that’s very interesting. It not only sounds like a cool challenge to work on we’re in fact doing something similar in one of our projects. Not 100% the same but I can see a couple of similarities and it’s definitely challenging, but challenging just again fun. Alright Mike, I have three last questions for you. The first one is what advice would you give your younger less experience self? Let’s say you run into yourself and you have to give yourself a good piece of advice, what would it be?

Mike: Well, when I first took my first professional programming job. Like I mentioned I didn’t have a formal education in programming, at least with the college level. I’ve interviewed a lot of college graduates who were in Computer Science or whatever and have done more programming than others. But when I first took my first programming job there were lot of little things that I didn’t know about the actual practice of programming. Things like creating a variable to represent constants, things like that. So in retrospect, you know, a lot of that kind of stuff is in that book Code Complete so I would probably say, if you’re starting out as a programmer just get a copy of that and throng through it and read it as you have time. It’s not necessarily, it might be a little bit outdated right now. There is a lot of more modern programming practices that are in there or that people do these days that are not necessarily covered in the book but there is a lot of really useful information in that. So that’s one thing I would say.

Carlos: Alright, and I guess that would be, my next question actually you might have answered. Well, what’s a book you would recommend some of these subjects, is that one of those?

Mike: That’s one book, I mean, I’ve got a whole book case full of books that I could probably pick from but let me think for a second. There is a book called for OO design, there is a book called “Head First Design Patterns” that I like quite a bit. I would say find some thought leaders. Ok, so this goes back to the first question. Sorry I’ve jumped around a little bit but, find some thought leaders in the space that you’re in. So if you’re into UI programming find some people in that space. If you’re into particular backend language C# or whatever find people who are luminaries in the space and follow them. Follow their podcasts and things like that. Like for example I follow Martin Fowler, Udi Dahan, Kundalini, and some other people like that. They have a lot of really good information a lot of times on their box, so that’s another good thing. One other book that I might recommend is more UI or design focus. I’ve actually recommended this to a friend of mine who is an architect in the landscape architect. But there is a book called “Universal Principles of Design” which is really interesting. I wouldn’t call it like a very deep scholarly book but it’s got a lot of really interesting topics laid out in a very clear easy to consume manner, so that’s a good one.

Carlos: Awesome, I think I heard of that book before but I don’t think it has been brought up in the podcast before so I think that’s a good one. Alright, and the last question I have for you is how people can find you and find your work? And if you guys are hiring at IgnitionOne, how can they apply and how can they be actually taken seriously? What’s something you respect when people apply for jobs?

Mike: Ok, so first question, how can people find me and my work? Probably the best things to do would be to go to my website which is That has just information about me and contact information and things like that. I’m on LinkidIn and Facebook. I kind of would like to open up some source code that I’ve written. I’ve got a few quite side projects that I’ve done over the years that are mostly on Bitbucket but I haven’t open them up yet. It’s not really because I don’t want to be collaborative or anything like that. I just haven’t gotten around to kind of polishing everything up and kind of making it presentable. But that’s something I would like to do at some point. It’s kind of put some code out there so people can find it that way. As far as getting in touch with IgnitionOne, IgnitionOne is hiring. We have offices in Atlanta, in New York, and some other cities around the world. One of the best things I would say, if you come to IgnitionOne it’s a fairly casual style atmosphere. We have kind of trendy open type offices and casual address and all that kind of thing. One of the things that I look for when I interview people is I look for sense of curiosity. I not only want you to be a good programmer. We give programming exercises to most developer candidates but I look for somebody who is not dogmatic about this language versus that language who likes to use the best tool for the job at hand and who is curious to learn about new patterns and new technologies.

Carlos: I think it’s really interesting because sometimes people get carried away. I think It’s important to specialize in some cases but some people get carried away with instead of working on engineering principles they get carried away with one specific framework or language and so forth. I think engineering principles are stronger in my opinion.

Mike: Right, I mean even things like languages. You can say, ok well I’m not going to box myself into this one framework instead I’m going to focus on the language that’s little broader which it is but even so I’ve seen people getting religious about language. You know, like Java versus C# or whatever. I like both actually and I like some other languages that are pretty different than those. I just feel like that kind of person who would do well at IgnitionOne is the kind of person who is really, they just look at the relative merits or weaknesses of each technology and they are going to pick the best thing for that job and push for that. And also I would say this religious thing might extend to practices as well. At IgnitionOne we’re fans of automated unit testing. We write lots of automated unit tests but we’re not TDD practitioners, like we’re not porous about that. So we shouldn’t like some tests add more value than others, so one of the things you should do is ask yourself how much value is this adding. Once you’ve written quite a few test you understand what type of code is testable and you kind of default to doing it at that way. At that point it’s good to have automated test. We actually have a guy who is implementing automated test through our UI right now as well. I would say we’re not the type who would give a blanket rule and say you must always write a unite test first before you write any code for any code. It really depends on what you’re doing.

Carlos: Great illustration there, I agree 100%. Mike, I want to thank you so much for your time today. I think this has been amazing. I’m really glad that we got to have you on the show. It’s really interesting to see with somebody in search as you say is doing because you worry about different things. Again we all have our different context in which we all operate and I thought it was very funny that your wife doesn’t get the architect role. Because you’re an architect really like a real architect, but at the same time you’re an architect in systems. I think that’s hilarious, that’s really cool. But anyways, overall, I really appreciate your time with us today and really glad about having you on the show.

Mike: Well, it’s been a pleasure. Thanks for having me.

Carlos: Alright Mike, thank you so much and I’ll catch you later.