You spend half your time thinking about how to break into systems and half your time thinking about how to defend them

Mark Maxted is a senior software engineer with Blue Coat Systems, a leading supplier of network appliances and tools that secure and accelerate business over the web. A southwestern Ontario native, Mark was born in Chatham and raised in Mississauga.

Maxted has an extensive and diverse educational background. He holds both an Honours Bachelor of Science (‘78), and a BA in Philosophy (‘79) from McMaster University, as well as a double Honours degree in Computer Science and Combinatorics & Optimization (‘88) from the University of Waterloo’s highly-regarded mathematics department.

Mark’s winding career path has covered a lot of territory, including key roles with several startups such as DDR, Waterloo Microsystems, FRED Systems and CacheFlow, which later became Blue Coat.

What was your path to Blue Coat?

“After my degrees at McMaster [university], I [spent] a couple of semesters in political science and a year managing the radio station. I’d taken one computer science course at Mac, but I was basically unemployable. In 1980 I wound up working on a neuro-psychology research grant – [it] involved programming an Apple II, (completely new at the time) – to present perceptual tasks, measure response times and correlate data. After that ran out, I had enough computer skills to get myself a job in computing. That may seem shocking, but this was 1980.

“I worked for a company called DDR (a startup in desktop business software market) that folded after about a year, then moved on to a company that did business apps time-sharing services on the old PDP1170’s. It was fairly obvious that the time-sharing business was going down the tubes and my choice was being unemployed in Edmonton in February – not so good – or going back to school.

In 1983 I decided I needed to get a real computing background and The University of Waterloo was the best you could get.

I did a double honours in the co-op program, which wound-up in 1988, and then ended up doing three semesters in the school’s software portabilty lab. After that, I co-op’ed my final three semesters with their spin-off group, Waterloo Microsystems, which was bought by Hayes, which went on to fold in 1994. After that, I worked with Virtek Vision Systems as a systems architect, then it was off to FRED systems and that takes us up to 1999.

“What became Blue Coat had actually started in 1996 when I was part of a consulting group that had six of us as partners. Michael Malcolm was starting CacheFlow and contracted our group to do the embedded operating system that was really similar to what we’d done at the software portability lab when I first met Mike. At the time, www used to stand for the World Wide Wait.

Everybody was expecting these large capacity increase requirements, so CacheFlow had two value propositions: reduce response time and gain bandwidth to reduce the cost of acquiring objects. In 1999 I joined CacheFlow, and was the architect for the policy system.

After the dot com bubble burst, the policy system allowed the company to

refocus on security.  CacheFlow became Blue Coat in 2002 to reflect the

new focus, and here I am."

Your team build software tools that are tied to a hardware product. How would you say that compares to developing in a pure software environment like building web apps?

“Right, we sell an appliance so most of the tools I’m personally involved with run either on the appliance or in some agent associated with them. One reason that’s unique from an engineering perspective is that we own everything from the hardware on up, so there’s no excuses.

If you’re trying to write something that is going to run in the context of say a browser or a web server, you’re limited by what is already there in the platform, what the operating system provides. We don’t have that issue. If we want something that the OS doesn’t provide, we go at it and fix it.

That frees us to look at solutions from various levels – operating system, device driver, app code – any of it can be massaged to provide the solution the customer needs.

“Another difference is that we build appliances that sit in internet cores and that means that we handle a lot of traffic, so we’re very performance sensitive. If we were writing things in a general-purpose operating system – where it had to mingle with apps written by anybody else and we didn’t know what that interaction was – we’d have to be very careful and defensive in our programming; that comes at a cost to performance.

When you’re handling hundreds of thousands of requests for internet content per second, performance is really critical. So, we spend a lot more time and effort in performance than is normal in many other applications.

When you’re junior, you’re expected not to know stuff. And you’re expected to tell people so they can help you

“Security is the other thing. We really do two things: accelerate content and provide security layers. In that job you spend half your time thinking about how to break into systems and half your time thinking about how to defend them. That’s probably not something that your average web app developer thinks about much.”

Do you use Agile or Waterfall methods as a matter of course and why?

“I’ve been using rapid iterative prototyping methods since about 1989, before Agile was even a term. We don’t follow a strictly Agile method, I think it’s important to realize that there can be different components that are amenable to different development techniques. For example, some components have an RFC standard specification where you know exactly what features you have to build. Often times that can be done well with a Waterfall approach.

“However, we also provide solutions and value to customers in newer markets like app acceleration. In those cases, you can’t assume you know what the deal is ahead of time and the best approach is to go in with a small set of features and watch and listen to the customer. That tends to encourage an iterative approach. Internally, between release cycles we’ve started to move a lot more heavily in to that approach as we get focused around user interfaces and those sorts of things.

“I think that – in a space where the competition is between who has the feature and who doesn’t – as the market matures, you achieve rough feature parity and the value proposition goes up a notch. It becomes “Can I use that feature reasonably in my organization’s workflow?” As soon as you’re into that space, it’s to your advantage to think about rapid iterative prototyping in Agile or whatever methodology happens to be the flavour of the day.”

What sort of people do you look to surround yourself with and why?

“I don’t know” is a very good answer for young developers. A better answer is “I don’t know and I’ll find out”.

“I believe in hiring good people and trusting them to do their job; I don’t like second guessing people. A lot of us here have worked together long enough to know what we’re capable of as a team, so we know who is the best person to do a job and how we fit together. Really most of the division of labour around here is by mutual consent because.

“I also like people who question assumptions – they don’t need to do it continually – but if an idea can’t be justified, there’s probably an issue there. One of my things is, people shouldn’t listen to me because I have a position, they should listen to me because my opinion is worth listening to. I really like people who will think independently.

“I also like people who understand a bigger picture and can balance constraints. Sometimes, we may not be creating the “perfect” solution because of time to market or something else. Having a broad perspective that at least allows people to understand some of the non-technical issues, or at least appreciate them when it’s time to compromise, is key. I don’t like to micromanage people’s time.”

Blue Coat employs a number of co-op students and interns. What does a young coder need to do to make an impression with you?

“Most of the time now I don’t supervise directly, but you can’t be afraid to admit what you don’t know. We’d much rather somebody put up a red flag early and say “I can’t get any further and I need help,” than to not tell us and have a time where we’re expecting a result pass with nothing getting done.

““I don’t know” is a very good answer for young developers. A better answer is “I don’t know and I’ll find out.” When you’re junior, you’re expected not to know stuff. And you’re expected to tell people so they can help you.”