Tag: tools

From a common developer frustration to an award-winning company that has clients like SAP, IBM and Mentor, what does it take to turn a problem into a lucrative business?   I had a chat with Greg Law who is the co-founder and CEO of undo. Greg went from founding his company in a shed to building a business with top enterprise customers. What we all want to know is – how? Read on and get inspired! Could you be the next Greg Law / Undo?

Vanessa: Tell us a bit about Undo.

Greg: Undo is a tool that allows developers to see what their software did and why, at any point in time. The tool (LiveRecorder) allows engineers to record the execution of a program and wind it back to see exactly what it did to identify software defects. You can step line by line in a debugger – forwards or backwards – and see all of the program state too.

Customers use us when they are completely stuck with an issue, and rather than guess what the problem is, they can pinpoint it. There were devs who would spend days, even months trying to figure out the source of a bug, and they try LiveRecorder and it enables them to figure it out in a few minutes.

The tool was originally aimed at the enterprise market, but more recently it has been used by more smaller companies, even those with small teams.

“The pandemic helped change this, there was no more travelling to meet with potential enterprise customers, and thankfully the tool was matured enough that it could be downloaded by people from our website, without the need to support hundreds of support requests.”

It was always part of the grand plan but the pandemic brought it forward.

Vanessa: How did you build your team?

Greg: It’s kind of the classic story. I founded Undo with a good friend of mine, Julian from when we worked at Acorn back in the day. We worked evenings and weekends together, it reminds me of a quote I heard recently, a programmers mantra of “We do these things, not that they are easy, but because we thought they were going to be easy”. We did eventually get to a v1, then bumped into an old friend that Julian and I had worked with at Acorn, he was looking for his next job. He joined us in the shed at the end of my garden, that was in 2013, and he hasbeen with us ever since.

Vanessa: How many are devs on the team?

We have 34 on the team.

Vanessa: Which collaboration tools do your team use to stay on top of the projects?

Greg: Git with GitHub on top of that, in fact in the early days it was just Git.  

We used a todo.txt file and when we had 3 or 4 people that worked really well. It’s quite nice that you mark things in different states in different branches and it all just works. But obviously, it doesn’t scale. We used Phabricator for a while but ended up switching to GitHub.

Google Meet – and all of Google’s G-suite. There were worries about locking into a giant corporation but the convenience of it is too great!

Collaboration is about culture more than tools. We were definitely an “in the office culture” prior to the pandemic, and felt that the facetime, building deep relations and trust were good face to face, and that worked really well. That said, we were already beginning to recruit remotely in some exceptional cases. And of course, that has now changed 18 months ago and we transitioned like everyone else due to the pandemic. 

If the pandemic happened ten, even five years earlier, it would have been alot worse for those in the knowledge industry. Even five years ago video conferencing was expensive so having Google Meet made things a lot easier. The most important thing with remote working is to write stuff down so that you can communicate asynchronously, not just remotely. Google Docs has been very good for that.

Vanessa: What kind of culture do you offer to developers in your company?

Greg: It’s one of those things that is quite hard to define. I cringe so often when I hear people’s answers to this question. It can be cheesy, and buzzwords. Often if a company publishes it’s values, they are actually aspirational values, kind of what they want to be better at, not what they are doing right now. So one of our values is no bullshit. Be honest with each other and ourselves.

That is a key component in building trust, and that’s the biggest one for me. There are the easy kinds of trust, like, do I trust that I can leave my wallet on the desk and it will be there when I get back? Then there are more difficult levels of trust such as:

1) Do I trust your intentions? Do I trust that we are trying to achieve the same thing? 

2) Do I trust your judgment? 

3) Hardest of all – healthy conflict. 

I can say to you: “I feel let down, you didn’t do what you said you were going to do or you didn’t do a good job with that.” I can trust you enough that I can say that, and it’s going to be ok between us. It’s much easier said than done, and though we are fairly multi-cultural sometimes we can be a little bit too English about everything! So we need to be un-English about it, and say what we feel, obviously in a respectable, polite way, to have that trust and transparency.

And that was actually part of why we were quite big in the early days of building the company, not remote first, but having us all together. Not that you can’t build high integrity and high trust remotely, you can, but it is harder.

We were already becoming a remote culture and had a remote office in San Francisco, and we hired people from across the country, like in London.  The first few people you hire will define your culture. As a founder, you have a lot less influence than you thought, culture is a self-defining thing.  With picking the right early hires, we just got really lucky, we had no idea what we were doing. Now we’re in this new world and we hire much more freely regardless of location, and we have the core culture that we can build it on, it actually works really well.

Getting to know you

Vanessa: Have you always wanted to be a developer?

Greg: I wanted to be a train driver! Once I got over that, I got a home computer at the age of ten, my mum sacrificed to get the computer. At first I was just playing games on it (Commodore Plus 4) and she strongly encouraged me to learn and program with it, so I picked up a book to learn, out of guilt really, and from then on I was hooked, all I wanted to do was program. 

Vanessa: Did you go to college and beyond or are you self-taught?

Greg: I took Computer Science at degree and also at A level not many six forms offered that at the time. I realised that it paid well to do something I’m good at. The world developer population is not growing that fast, which is surprising, We need to train more programmers, but we’re always going to have a big undersupply so we need to make that finite pool of programmers as productive as possible.

We need a healthy ecosystem to help people be more productive. Ten years ago, software tools were a brave business to be in. Now it’s one of the hottest places for VC’s to invest in. 

Vanessa: Have you ever been involved in mentorship, either as a mentor or a mentoree?

Greg: We’re all still learning every day, I have mentored. In fact many of our employees are a mentor to me. We’re lucky that there is a healthy ecosystem in Cambridge. It’s amazing really – you can email almost anyone you can think of, even when you’re right at the beginning and they’ll spend a bunch of time with you.

The Future

Greg: Core tooling, slowly they have evolved compilers, IDE’s. Debuggers have not changed much over the years, new tools have come along but the fundamentals have not changed much over the decade

We see waves of tech. There are rapid periods of changes, computer operators were like train operators – if you used a computer for work that’s all you did, and no-one else would be let near them. Then in the 80’s people started using computers as part of their other job, now everyone is using them, and now there are smartphones. As these waves went by, the way we developed changed too – i.e. it goes in waves. Between say 1990 and 2010 the way we develop code was all evolution not revolution. Then suddenly it all changed again, first with agile, then CI/CD, huge amounts of reuse of open source, etc. With these big changes comes an explosion of tooling. It’s really hard to imagine what will continue. I think most of the tools we use today will still be in use in ten years, but they will have been added to. Like how GitHub compliments git, or our stuff does with Jenkins. I’m sceptical on the AI writing code thing – understanding of requirements through context and delivering creative solutions to that – it’s a million miles away from the state of the art. But I do totally see computers helping us to write code – the GitHub Copilot stuff promises to save a bunch of time. But it’s not quite as exciting as it looks because if you think about it, Copilot saves you time typing in the code sure, but what proportion of programming time is actually spent typing the code in? Pretty small. A much larger chunk of time is spent figuring out why that code you typed in this morning doesn’t do what you thought it was going to do! That’s why we started Undo, and I think we’re going to see a lot more around this notion of understanding or auditing exactly what happened.

Collaboration will be key. Asynchronous collaboration. Once you sever the link, you no longer require people to be geographically in the same place, well then you no longer need to be in the same time, either. This has potentially profound implications for how we might work. We have used version control in development for decades which allows people to collaborate remotely and asynchronously; I think these practices have a lot to teach a wider audience in asynchronous collaboration. In kind of the same way that the first word processing applications were actually code editors.

We’re good at writing code, but not at debugging, most devs spend alot of time debugging – remote and asynchronous collaboration through debugging would be great. 

Vanessa: It was great to talk to you Greg!

We love to hear your development stories, get in touch to share yours.