Talking Software Ep1: Mark Jeffries

In the first episode of our Talking Software podcast series, Technical Director Mark Jeffries sits down with VP Product Gordon Plant to discuss all things development, including why building software is like building a house, aligning dev solutions with real world challenges and video games.

When you get asked what you do for a living, what do you say?

I tend to say I work in software and not that I’m a technical director. I tend to say that either I run the ops and dev teams at BaseKit or that I’m a software engineer.

And if someone who knows you a bit better, but doesn’t know anything about software development says to you okay, but what do you actually do all day? What do you say then?

So obviously we are creating software and creating software is kind of similar to building a house. Apart from you can’t use pre-made constructs like windows and doors. You’ve got to build everything from scratch.

So it basically boils down to distilling what you’ve got to build into the smallest chunk possible and then only building the smallest chunk of this whole piece of software that you’re building. So it’s a lot of meetings, talking to devs, talking to product and working out what these features are before you actually cut any code at all.

So for you then, does that mean it’s more talking than typing and coding? 

Yeah, it is. I probably only get to do about maybe 25 – 30% coding. There’s a lot of management overhead for me, but even as a dev there’d be an amount of design, talking about the features and trying to reduce the features down to the smallest possible change.

And in the past, you’ve been a software developer. I’m guessing you used to spend a lot more time coding at earlier points in your career. Is that right?

Yeah. Yeah, definitely.

And thinking about that time, what was the satisfying part of the job?

I think when you actually develop a feature and start to see real world users using it and getting benefit from it, there’s definitely satisfaction there.

There’s also satisfaction when you take an unreliable, flaky or bloated bit of code and reduce it down to a much smaller piece of code. So refactoring and either making it better or the same, but in a much more efficient and elegant way. 

And now that your life has changed and you are managing the team and spending less time coding, what is the most satisfying thing about the job? 

I think it’s probably when you start to see the developers that we manage become very independent and start helping each other off their own back. Basically being able to step away and let the team you’ve built and shaped deliver the software, helping each other along the way, creating all of that good stuff without, you know, needing to be micromanaged or needing direct input.

Thinking about how things have changed, since you were where they are. Do you think that the challenge for new developers or people coming into this has got harder? Is it easier? Is it about the same? What do you think is different now?

I think in general, in software engineering, it’s a tricky one, but probably easier.

I think especially front-end, there’s a lot more established ecosystems, the React Redux ecosystem is fairly mature now and pretty much all of the front end devs we hire are now fully experienced React developers. The challenge certainly for a BaseKit dev is you’ve got an absolutely huge code base.

It’s a massive challenge to come in and get to grips with a code base that spans probably 10 years. There’s four versions of the site editor and lots of different libraries being used. So that’s a whole different way of constructing user interfaces or some of the backend code. 

And, you know, over the years, different ways are established of doing things. So it’s a massive undertaking for a dev to come in and get to grips with the code base at BaseKit. We’re very mindful of this and try and bring them up to speed as much as we can. We give loads of help. But yeah, it’s a big challenge.

When you talk about those software frameworks let’s use React as an example, what’s a good way of explaining a framework to someone who’s not familiar with software?

So a framework is basically all of the building blocks and the scaffolding you’d need to create and actually write code.

So a classic framework we might use would be symphony HTTP components. Quite often in a web application you’re going to want to call another web application like an API, that kind of thing. And rather than writing these steps to create a HTTP connection, to send a post request, to add some data, to start post requests, then to decode the response. All of that is wrapped up quite nicely in the symphony HTTP libraries that we use.

So we can just focus on creating our code, our kind of USP for BaseKit, as opposed to continually reinventing the wheel of these well-known software tasks that every developer is going to need to do out there. 

So the library just gives you some preassembled pieces that you put together and, you know, they already work. Is that it?

Yes. Certainly for the components, and then at the higher end they become a fairly prescribed and regimented way to actually construct an application. But essentially they’re all doing the same things. They’re all cutting out all of the boilerplate code that we would have had to otherwise create, but isn’t actually creating stuff at BaseKit. It’s just doing the nuts and bolts of what a modern web application will need to do.

And having access to all of those frameworks, and I’ve seen lots come along in the time I’ve been working at BaseKit, does that speed things up?

Massively, but it also creates technical debt. When you use any library, framework or components, you’re using a version of someone else’s software and all software has bugs. When new versions of these components get released we need to update them to have the bug fixes and security fixes. These have probably got some breaking changes. There’s various improvements with them, and that requires potentially quite a big code change on our part to suddenly change our code that uses them to work with this new way of working with the framework.

When we build things in software, sometimes we all know it turns out to be more complex than it looks at the start. Can you think of an example of where something seemed simple and it turned out to be way more complex?

Yeah, when I first joined BaseKit one of the early things I worked on was mission control, which is a basically BaseKit’s accounting system that finance used to bill our partners. And it had already been created, but I guess it’s fair to say it was a failed software.

The devs had implemented exactly what was asked of them with mission control. But the bottom line was our finance department at the time wasn’t using it, it just didn’t do what they needed it to do. So my remit was to basically make the changes to mission control so that it worked.

And there wasn’t really a specification list of dev changes to do. I basically had to work with the finance team at the time to decide exactly what it was they needed and then make those changes, showing them the changes in action to get it over the line.

So it’s a case of where you’ve got to talk to the actual individuals to work out what it is they need, as opposed to kind of just following a specificity. But yeah, I mean that got mission control being used month by month by finance. So it was a good result. 

And what other things would commonly turn up in the lifetime of a project that make it take way longer than you first think it’s going to take?

I think when you’re working with something like BaseKit, it’s obviously massively configurable. Every environment is different in terms of configuration. It’s only when you start to develop the project and test it you can realise that the certain aspects of the V10 editor that you hadn’t considered, maybe the V8 editor.

To try and keep everything in your head that BaseKit can be while you’re specifying, creating, designing a software project is incredibly hard. Also, the interactions between all the different systems, you know, it’s all well to know theoretically how all these different systems are going to interact. Like for example, with GCB, when we were integrating with Cronofy, we’ve got their API guide so it’s a known quantity, but it’s not until you actually start putting data through it that you can see it doesn’t actually quite work how we wanted it to, we had not accounted for this, times zones over here, etc.

What do you think is most commonly misunderstood by people about how software gets made?

I think there’s a few things. The theory that you can estimate software, the problem with estimating software, as I alluded to earlier, is that it’s like building a house, but it’s the first time you’ve built that house and there’s no construct. So you’ve got to make your own windows, your own roof and your own doors and what not.

And so you’re basically estimating how long a software project is going to take at the point when you know least about it. Inherently that is going to fail.

Can you remember the first time in your career that you solved a really challenging development problem? 

I think it was probably a software system for the Office for National Statistics. It was an interface to essentially search and process through a whole load of surveys and the original search they had was terrible. It took ages to find any results.

So I engineered a solution that would index all of the information. The end result was that this search of thousands surveys was suddenly lightning fast. So that’s an example of a kind of a real world benefit that you’re providing.

What got you into software development in first place? When did you first think I want to do this? 

So as a lad I was absolutely mad on video games and still am to a large degree. So I was always typing in these games that you’d get in magazines for the ZX spectrum and ZX 81 back in the day. So I definitely wanted to be a video game programmer, but it’s not a great career. So as soon as I learnt a bit about software development and started training, I moved into some more rewarding jobs rather than video game programming.