Posted on 22/07/2019 by Michael Oliver
If you pressed them for job titles, Joe Horsnell and Harry Lascelles would call themselves tech leads. But they tell Client Server’s Michael Oliver why hierarchy isn’t as important as passion and curiosity.
Michael Oliver: Not everybody would have heard of Bamboo Loans – tell me about yourselves?
Harry Lascelles: We are a fintech company specialising in consumer finance.
Joe Horsnell: Bamboo was initially a guarantor loans company and that's still part of our business, but by volume, we focus more on unsecured lending now.
MO: You have something of a flat team structure – how would you describe your jobs?
HL: Titles aren't something that we lean on much here. Depending on the temperature, I've called myself principal software developer, lead engineer, tech lead, all these kinds of things. I use tech lead most often.
JH: We're an interesting team because Harry and I both came from working at UBS, where it's very corporate and regimented, but we're very flat structured here. We're all part of the team, but it's not like people report to Harry and me.
MO: How did you get into software development? Were you the kind of kids who messed around with Q-Basic and the like?
HL: My dad first showed me programming when I was about four years old, so going way back. IT has just always been in my blood. He was a journalist for the FT, so he also taught me about financial products and services. Finding something where I could bring them together was a real bonus.
JH: I just was interested in computers from a very young age. My dad got a VIC-20 in the early '80s. My first job was at Logica, for a few years, then my first move was to UBS, where I met Harry. I was at UBS for over a decade, doing the things that you need to do to progress your career, so doing less and less the things that I liked doing, like building software and using computers, and more and more management, building and running teams. Then this opportunity came up to go and work at a start-up, so from UBS with tens of thousands of employees, and departments within departments, to a four-person start-up. A bit of a change.
MO: How did you find that transition?
JH: Personally, I'd just become very tired of the big corporate environment. It just felt like we weren’t achieving anything.
HL: For example, if you wanted to create a database, you had to fill out forms in triplicate. In any big organisation, spinning up test infrastructure, or even production structure, can take quite a while. Moving to a start-up, a small company, has been such an eye opener. To any of your readers, I would strongly recommend it. I didn't consider it when I was taking on my first job, but it's something I should have done.
MO: What made that possible?
HL: From day one, we had a CTO in Rob Harrop - one of the authors of the Java Spring Framework – who had made great initial IT choices. Straight out of the gate, we were on the cloud and AWS. I can’t imagine doing a start-up 20 years ago without cloud, it has been a complete game changer.
MO: Tell me more about the kind of tech stack you use at Bamboo.
HL: We always like to try and make sure we're running on the latest version of any frameworks, or databases that we're using. At the moment, we're running Ruby on Rails as our main service stack with a Postgres database. A Postgres database managed by AWS, of course, RDS in this instance. We have just found that combination to be an incredibly agile platform to develop on. Rails is famous for being a very quick platform to develop on to begin with, and we have just found that has continued. In comparison to our decade we both spent using Java, this was a breath of fresh air in terms of iteration, ease of testing, ease of debugging, getting new joiners on. It's been very useful.
JH: While our backend technology choices, of AWS, Postgres, Ruby and Rails, are all well ingrained, it’s a bit more fluid on the frontend, just because the rate of change is just so crazy. We started out using Knockout, back in 2011-2012, and it’s still going, but the industry has moved on. We tried Angular but React is the one that we're primarily using now for front end development.
"We want to deploy it every day, we want to do one every few hours. We want continuous deployment on every commit, ultimately"
MO: Sounds like a multifaceted approach?
JH: Yeah, a term that you start to hear is this “polyglot” approach. I think that's great, and that's interesting, and it's good to be aware of different programming languages, and different paradigms of programming. I'm a big fan of functional programming, and the ideas of functional programming, immutable data, stateless functions, and the mindset of functional programming. But, at the same time, every technology choice that you make comes with a cost in terms of tooling, in terms of cognitive overhead, of learning both the language syntax, but also all of the other stuff that goes with it. It's not free to just pick and choose and say, "Oh, we'll have some Node there, and Java here."
MO: What kind of developers work well at Bamboo?
HL: I've always looked for a passion for technology that goes beyond that of their job. For example, if someone has an active GitHub account that demonstrates that they are contributing to other open-source projects, have their own, or are just trying other languages. That just speaks volumes. Running their own Raspberry Pi at home, things like that. It shows it means more to them than just their nine to five.
JH: We work for a financial services company, and obviously that's what we're paid to do, so the number one thing is to deliver working software that people actually want, but it's kind of almost irrelevant what it is that we're building. It's about the how it's built, and the process behind that, to deliver what the end users want.
HL: And as anyone who's worked in software development knows, writing software is probably only about 10% of your job. The rest of it is fielding bug reports, understanding the problem, reproducing it, then you write the fix, and you test it, deploy it, monitor it, everything else in between. We absolutely make sure that is reflected in our culture. Everyone who joins the dev team immediately gets at least read access to all of our production logging and error reporting systems. As soon as we can, we get them onto the production rota. I think people do want to deliver good working software, and it helps if they have some skin in the game to see it going well.
MO: I imagine this gets reflected in your release cycles?
HL: it's worth noting that at UBS, we had release cycles of about three months. Christmas was cancelled, everyone in. And then we tried to bring it down to scrum level and release every two weeks. At Bamboo, that just is not good enough at all. We want to deploy it every day, we want to do one every few hours. We want continuous deployment on every commit, ultimately, but we're not there yet. Scrum is too slow for us, so we're using a hybrid approach. Getting the working features ready and delivering them as soon as they're tested.
JH: Yeah. It is a bit of a cliché - and I feel a bit embarrassed to say it – but agile is something that you are, not something that you do. Let’s say, you're in a large organisation, and you’ve ‘gone agile,’ suddenly everyone there is doing scrum work. But if you're doing the same waterfall process and deploying every three months, you can't really justify saying you're agile. But if you deliver working software incrementally to get feedback from users on whether you're giving them what they want, if you respond to change, embrace change, and if you focus on the automation to be efficient in terms of how you can deliver software, I think then you can say that you're agile. I feel that's what we do.
MO: So, you’re comfortable with wearing that ‘agile’ badge?
JH: I feel comfortable saying that we are an agile company, as well as an agile development team, because we do deliver a lot of stuff very quickly, but also sustainably. There's only a certain number of hours a day you can focus effectively on deep work.
MO: Where does DevOps fit into things?
JH: For a while, we went through a strategy of thinking of DevOps as a kind of role, which is basically just an infra person. It actually didn't work, because we tried to keep them integrated into the team, but you don't really want a team where only one person can do a particular tranche of work. We practice DevOps, in that we both build our app and we run it in production, so, ultimately, if it falls over, we get PagerDuty pinging our phone to fix it. I think that's the right way of doing it, because Development and Operations are not discrete things. You want your processes to be as similar as possible in development, in your test environments, and production. Because we're as responsible for development as we are for our testing environment, as well as production, we have the same processes for orchestrating them, or as much as possible.
HL: And the same people.
JH: And the same people, exactly. We have a support rota, which can be quite onerous, but we do as much as we can to automate that. If it breaks in production, we should be the ones to fix it. And we are the ones who fix it. If the pipeline stops, production is broken, we fix it. I feel that's the right way to embrace DevOps. It's not a role, it's a way of operating.
MO: How would you describe your relationship with Client Server?
JH: I don’t have the numbers at hand, but certainly the majority of the people who we've hired have been through Client Server. The longest serving members of our team are the ones we’ve hired through Client Server; it’s been really effective.
HL: We plan to double the size of the dev team in the next two years and I’m sure Client Server will be a big part of that.
MO: Where do you both see Bamboo in the next five years?
HL: We are a very data heavy company. Machine learning is probably just starting to enter its trough of disillusionment, but we will be looking to use it with our ever-expanding datasets in the near future. For me, the reason I'm still here is that I get to work with incredibly smart people. The dev team we have here is easily the best team I've seen. Some of them have very few years of experience, but, like I said earlier, that's not the kind of thing we necessarily mandate, and we don't necessarily look for explicitly in new hires.
JH: If we need to make a decision, we make it, and make it quickly. It's a small company, and the development team is central to that. I think that's a good combination for somebody to join and learn a lot. Especially with the exposure that we give them to everything from building software, automated testing, automation in general, all the way through operationally running and supporting the application. It's just a lot of stuff that you get to learn by doing that.
Driven by technology, powered by people
Let's start the conversation
Follow Client Server on LinkedIn, Twitter, Facebook and Instagram.