Check out our latest news and articles.

Visit our Blog

Interview: Devendra Gera, Lead Infrastructure Engineer

Devendra Gera joined BaseCase as a software developer and later became Lead Infrastructure Engineer. We spoke about his role at at BaseCase, and the challenges of building powerful software that anyone can use.

What does BaseCase build?

BaseCase Interactive can be thought of as a combination of Excel, PowerPoint, a PDF writer, and Word, but built together in a way that they interact with each other and work together really well.

So, for example if you insert a chart generated in Excel into PowerPoint it will be a static chart, but in BaseCase you have lots of controls you can use to manipulate the chart.

The software potentially has a lot of applications, but we focus exclusively on the life sciences industry. It’s a sales and market access tool, with great technical capabilities for introducing health economic evidence to a discussion with payers or HCPs.

What’s unique about the software?

The fact that these elements work together gives rise to an emergent property - the whole is bigger than the sum of the parts. It lets you do many things that simply aren’t possible with any other software product out there.

What do you find particularly interesting about your role at BaseCase?

The unique aspects of my particular role are due to the fact that we deal with pharma companies - big corporations that have specific data security requirements. You could get similar exposure in one of these corporations, but I prefer the small/medium sized business environment.

This is a position that lets me do interesting work in a more dynamic, ‘startup’ environment. I enjoy having this mix of requirements and tasks, spanning both the young company and the big corporation.

Before you took the job, what was attractive about it for you?

I actually wasn’t looking for a job, I was looking for a contract position, but I stayed at BaseCase because the work is very interesting, and I enjoyed the work environment.

I found that the people in the company had skillsets that were complementary to mine, so I was able to learn a lot from them. They were great in areas that I was rubbish at, and I was able to contribute something that they were missing. As a result of working here I’ve learned a lot.

Do you have a philosophy when it comes to software engineering?

I strive to build things that do a single thing very well, that can work together to do a bigger task. This is because simple components fail less often, and they fail in simple ways that are easier to fix.

The other element of my approach is to build infrastructure that provides capabilities, but doesn’t dictate policy. So I try to build something that is extremely generic, that can work in a number of different ways. Then it is up to the user to decide how to use it.

For example, one thing we built in 2009 is the computation back end, or computation server. It’s still in use today, but in in very different ways. It’s a framework that we use for adding new, distributed capabilities to the system, and it’s allowed us to do things that weren’t even on the roadmap when it was developed.

When you started working here did you find anything surprising?

Yes, I found the focus on a single industry surprising. I asked the question, and I’ve seen pretty much everyone ask this question - ‘it’s a surprisingly useful set of tools, so why don’t you sell it to everyone?’.

The focus on the life sciences industry ties in with the ethos I mentioned earlier, that of doing a job very well, which runs through the software team. There’s a real determination to do the right things, to build the right tools, to do it properly.

What are some of the challenges connected with building the app development platform?

It’s a very high priority for us to be user-friendly, so anyone can use our software, without programming or technical ability. This presents a challenge because the software is very powerful. We’re constantly looking for ways to provide advanced capabilities without demanding technical skills from the user.

For example, our spreadsheet editor is generally bug-compatible with Excel. That means that we ensure the behavior of our editor is comparable with Excel, so users will have a familiar experience when they use BaseCase.

The problem with this is that it can limit your ability to improve those systems and provide new capabilities. The challenge is to remain user-friendly, while improving our product and weaning our users onto new and better systems in a gentle way.

Do you mean that the BaseCase Editor is superior to Excel?

Well, it depends. Excel is a very generic tool - you can use it for finance, household budgeting, a lot of things. They do a good job across many fields, but we do a great job for health economics and value communication.

How is a typical task or problem approached at BaseCase?

It depends on the problem. If the problem is big enough to touch many areas then more people get involved. We’re not a meetings-driven organization, but if a problem is big enough we’ll have a meeting or two, to decide on the solution and divide up the work. After that, the work is usually done on an individual level.

And you have autonomy to be creative, and find your own solutions?

Yes, within limits of course. I wouldn’t use exotic or unproven technologies, but if a component doesn’t touch anything else you have more freedom. If you build simple, separate components that work together, then the only parts that need to be compatible are the interfaces. The individual components can be essentially anything.

Within reason, we use a lot of technologies for these individual components. For example, we started using Erlang at the beginning, and that’s just used for one part of the system - the rest of the system has no idea what that component is built in or how it works, the only thing that matters to the rest of the system is the interface, which is built with standard HTTP and JSON.

I’ve done many small projects within BaseCase where the meeting we had was essentially just to decide on the interface, and then I came up with a solution that stuck with the interface, and my colleagues developed their own solutions for their elements.

Is this way of building software unique?

It is supposed to be the way of building software, but I’ve never seen it happen anywhere else.

Can you say a bit about the working environment at BaseCase?

The thing that’s unique to BaseCase is the combination of working at a small company, with the dynamics of a small company, and working for some of the largest corporations in the world. So you get exposed to the full spectrum of organizational structures.

On the one hand, we have a typical startup dynamic - a foosball table, beer nights on a Friday etc., - and on the other hand you have a lot of responsibility because we’re very successful. You get to develop software that’s plays a very important role for marketing and market access teams operating in a huge marketplace.

And the city? What is Berlin like?

It’s great. I live up in Prenzlauer Berg - it’s a very lively area, with a lot of restaurants and fun places to go to. There are lots of young people starting up independent cafes and shops, which creates a really great vibe. My German is improving now but most of the time you can get by on English because it’s so international.