Similarities and Differences in Software and Hardware Development: David Almassian with Tetracore
As the Director of Engineering at Tetracore, David Almassian sheds light on how the team process is crucial to creating a final product which requires both hardware and software development. We will get in to the details of how the methods of developing each differ and overlap within Tetracore, as well as how they compare to industry standards.
Carlos: Alright, David, thank you so much for coming on the show. It’s been a long while since we did our pre interview I think in December, but I’m excited to have you on the show. How you’ve been today?
David: I’m doing great. Thanks for having me on the show. This should be an interesting conversation. I hope you’re doing well. Are you in Miami?
Carlos: Yeah, I am in Miami now. Had a bit of a holiday by the end of the year. Well, if you’re listening to this we are talking in February 13th, and time flies. We had our first call some time by close to the end of the year. After that I was off for about a week and then came back. It’s been a whirlwind of a year but I’m sure that everybody in IT can relate.
Alright, so David, in our conversation last time. I think one of the big, we found a very interesting subject which was trying to contrast all these difference that we’ve spoken about between building software as a software company that is only producing software and then company like you guys, like Tetracore, that is building software but also the hardware and how the product is all in one. I think the subject today that’s going to be talking about specifically about that. So before we get into that, how about you give us a little bit of introduction about yourself, so tell me about how you got into tech and what it is that you do at Tetracore?
David: Sure. Well, I’ve always been pretty interested in Science. And actually believe it or not the company where I work with now, the way I got my intro into the company is that the CEO of the company who founded the company, I interned for him in High School when he was at the Naval Medical Research Center. So in high school I was doing sequencing experiments with him. I mean at that time sequencing was a lot less events than it is now, but it was pretty cutting edge stuff. So back then I got to see not only the biology lab but they are really interesting equipment and the software that was running to do the DNA sequencing and then analysis afterwards. I think that really sparked my interest.
Carlos: It is interesting because to work in your industry, let’s say you’ve worked in IT but on the side, I say in a loose way; but let’s call it in the tech side of the company. Let’s say if you worked in IT it could be said that you’re working with exchange servers and backups. So that sort of that role which is crucial for production that is someone industry agnostic type of role. But the role that you’re in where you’re managing different engineering groups to develop a product for this industry somewhat have to be or at least have to have some context on this industry. What do you think about that?
David: I think Yes and No. I think for me personally, you know, I have it contexted because I was mentioning this internship I had in High School, and then in College and in Grad School. When I went to Stanford I got to buy informatics which is something people would categorize as big data these days. But at that time it was relatively a new field that was doing kind of Math and Statistics, and data analysis and also software engineering around all the interesting data is being generated by biological problems. On a personal level I did come from that background and I have pretty deep understanding about it because I work with people who have much deeper understanding about you and I do. But I have a good foundation in Biology. At the same time if we hire new mechanical engineer or electrical engineer or software engineer, having some biological understanding is certainly a plus. But I would say 99% of the time that people that we bring on are not going to have any of that background when they join the company engineering team.
Carlos: Now that makes sense. I mean, otherwise you potentially couldn’t hire if you brought in a mechanical engineer who don’t have any experience within this field it will be very hard to hire for. I think we’re going to go there in a second about team building and the way that you have to organize teams in a company like you guys. So before we get into that, so in college, how did you end up, you know, right now as we said you are Director of Engineering. You are the forefront of building products, how did you get there? if you follow the software engineer kind of track it’s not as easy to fall into the sort of role that you’re in. Of course it’s interesting that the person that you work for right now you used to work for back in the day.
David: Yes, so I mean, I think when I was in college in grad school I was really interested in this bioinformatics. But that also led me to take a lot of cutting edge courses and machine learning and data analysis, and that’s kind of where I first went with my career. I worked for Beckman Coulter and I work on their hematology analyzers. And so the team was really applying at that time machine learning algorithms to these analyzer problems. Actually the Beckman Coulter team I work with was in Miami so I live in Miami for about three years working with them. From there I ended up moving to Tetracore. My first role at Tetracore was really developing software. The company historically is In Vitro Diagnostics company so they made all these tests; both DNA based test and immunology based test to detect whatever that it is that is out there in the world that you might be looking for whether it’s an animal, illness, or an environmental pathogen. But they decided that they wanted to move into also building diagnostic platforms, and so they wanted to build a hardware and software to run those test in addition to building the test which they are already been building these biological essays for 15 years at that point. And so that kind of what attracted me about the role at Tetracore is that they really wanted to take the company in a different direction and start to build out an engineering team.
Carlos: So to be clear nowadays you guys are not selling… clients, your are selling products. Tell me a little bit about that.
David: Yes. We sell what is called Real-Time PCR Thermocycler. That’s the main product that my team works on. And the unique thing about Tetracore is that we’ve made the process very easy so typically someone running Real-Time PCR and might be doing it in a laboratory and using specialized fluid equipment called pipettes to move tiny volumes of liquid in the microliters. And so kind of what we did we have developed a platform that allows someone who is minimally trained to run this Real-Time PCR technology either in the lab or in the field. And so all these has to do with swap something, snap some, and run it in our cartridge, and there is kind of some Chemistry in there and there is also some mechanical engineering work that went into kind of a self metering application where you can be very imprecise about say how much volume you put in the sample reservoir but you can always end up metering the same volume into the reaction chamber. Yeah, I think that is about what you’re looking for.
Carlos: Yeah, because I think if you think about it we have part of our main subject today is the kind of the contrast between the two types of team makeup. So you guys have a completely different kind of makeup, as you just said, there are software engineers but there are also electrical engineers and mechanical engineers. And you are at the head of making all of those groups work in order to deliver one product. Right? The business needs it whether, you know what I mean, there is not many options, right? There is no too many tones of grays. It’s black or white. I am really curious about the process. What’s the makeup of this sort of teams and how do these three teams come to the other. And how does, maybe you can run us through at a high level of where you’re building a product from a scratch at a high level, right? How do these three teams work together to accomplish this feat.
David: That’s a good question. So from a high level, let’s say we’re building a new product and the first thing we’re going to do is look the requirements and of course if the requirements are not well defined we are going to hone on those and try to understand from the biology team what it is they are really looking for in the next generation product or the marketing team or whoever is requesting the product. But when we’re developing new product, I’d say the first thing we do is an architecture phase. And that’s kind of a phase where we’re not building software architecture, we are kind of answering those requirements, gathering questions. That’s the point where all the disciplines, it’s going to be critical where all the disciplines get their input and work together because you need to understand that if you have a size constraint that’s not just some mechanical industry, that’s also an electrical constraint. And if you have a software architecture that you have in mind, that’s not just a software problem. You have to make sure that the electronics is running the right kind of R-chip that’s going to allow you to run Linux or whatever it is you need to do. I think that’s the phase where all the team members will be working together on a regular on a basis and refining a kind of an architecture. And out of that very quickly we’d move to prototyping because typically when you’re developing something new that’s interdisciplinary you’re going to have some risk areas, and so you want to resolve that risk as quickly as possible, whether that’s building a PCB or getting off the shelf development kit and writing some software for it, or 3D printing some parts. I think those are the first two phases we’d look at as an architecture phase and then some prototyping the riskiest parts of the design.
Carlos: This sounds right. I’m just taking a swab at this but imagine if all the teams did not get together at the beginning. And let’s say you have to deliver within a certain time period and you’re doing your prototyping. If all the teams don’t get together within that same time period it might be harder for them to work in a sort of parallel paths, right? I’m just taking a stab at it. But I am curious is this something that can be done in parallel or does it have to be done in a semi-waterfall way.
David: Certainly work can often be done in parallel. But I think when you’re looking at the initial phases of project like in architecture or initial prototyping I think those are going to be one of the critical times where all the teams are going to work together. After you nailed down the architecture and result, the risk from the initial prototypes then of course the software team and the electrical team and mechanical team can work more independently. But it’s really critical to, as I mentioned, the electrical has to meet with the mechanical. And you have to consider not only that it’s going to be made properly but this is something that’s going to be easy to assemble. You don’t want to make something that’s going to be bare for production down the line. If you decide in the software phase that you need, WIFI, or Ethernet or bluetooth or any particular technology. It’s critical that the electrical piece kind of scopes that in from the start so that you don’t get halfway through you schematic or halfway through your layout and then realized that the software team needs something that you didn’t planned for.
Carlos: So, as we are talking about there it makes me think again of what would a typical software team might look like in terms of these processes? But the biggest thing for me, as I mentioned in the beginning, is this sort of binary output whether it works or not, the requirement, yes or no. By the way, that’s just an idea. I don’t know if that’s accurate or not. You let me know if there are levels of completion but anyways I’ll let you answer that in a second. But in software for sure especially with web we are able to have phases, right? You know, we’re going to deliver a couple of features in a couple of sprints. But that’s not the same in hardware because again you need to deliver this appliance or this piece of hardware to the client in order for them to start using it. So what’s the biggest difference, if you could pick out, the biggest difference between your sort of team versus a web team that is not delivering any hardware? Would you pick out the biggest difference in terms of the way of delivery?
David: Well, just one ha. Yeah, I think there are a number of differences.
Carlos: Yes, you can give us as many as you want though, just trying to find like the biggest or maybe there is many that you can give us.
David: I’ll start with kind of what you’re talking about in terms of levels of completion. From the customer’s perspective there is not levels of completion. You need to have a piece of hardware. It has to stand up to the wear and tear from the mechanical standpoint. The PCBs have to generate the power and do any sensing that they need to do and the firmware needs to do what it’s going to do. But for each of those individual components we do consider the validation and testing for each of those. The electrical, circuit boards will have their own validation and testing. And the firmware would, and the software would, and the system would. And then in addition to the system from the engineering point of view there’s going to be a functional testing from the biology team as well in terms of validation. I think you just have more interdependence there so the interdependence comes into play as we are talking about earlier during the design phase. But it’s also going to come to play during the validation phase where you’re going to validate the individual pieces individually but you also need to validate the system and perform a functional test. So I think that interdependence really drives a lot of things. It also drives I think more prototyping than you might have on a typical software team. And you can tell me that’s true enough but if you’re developing new product. If you don’t have the electronics build and you want to write a software you might need to has some version of firmware, so you’re going to have to come up with a strategy that either emulate the firmware completely and software or you’re going to buy a development kit with just kind of a bare integrate circuit on it and then write the firmware on that. That just kind of essentially emulate the sensing and the other actions that are requested of firmware. I think those kinds of things require a little bit of forethought and a little bit of creativity because what the interdependence. You can’t just go make an electrical change. You have to think about how that’s going to affect the mechanical team and you’re going to have to think about how that’s going to affect the software team. Same if you’re going to make software changes.
Carlos: Because of this, I’m sure that new requirements or again in a web based team, a new releases is something that happens in an Agile way. You could potentially push code every day. You can’t do that in your world, so how does user feedback or request for new features or improvements translate to the work that you do? Is this something that could have be, is it a firmware upgrade or is it a brand new appliance? How does this sort of change happen within your world because as I understand it’s not as easy, right? Or maybe it is, but how does that work?
David: Yeah, another good question. I think, you know, you’re right in some sense. We’re not going to push new code to the user every day. We’re not going to push that out to the user every day. For example, our internal team has somewhere on the order of a dozen of our instruments in the lab that they use for everything from a new development to QC, and things like that. We do push our software changes to the lab on a regular basis. The way we manage that changes if we’re going to push something to a customer instrument, we would pushing a stable branch to them; or internal users we’re pushing out the latest and greatest to them at least on weekly basis.
Carlos: Can you give me an example of what sort of updates or changes you at least can deliver within that sort of time frame. I’m curious about, for example, just to add on to that question is like is it could have be a speed improvement, is it a new type of test that now the system can run. You see what I mean? It’s like a big jump or is it performance upgrades. What sort of updates can you deliver to clients via that sort of update?
David: Yes, so all of these things, so what we’re pushing out internally into the lab might be a new, you know, we have sensors on there. We might push out a new compensation algorithm for the sensors so they are going to see that in the lab right away. We’re not going to push anything like that out to a customer until it’s been gone through a validation study internally. But when we have for example something like that we’ll get the Biology team involved early so they understand what’s driving the change and often they will actually be the drivers of the change where they will point out certain cases where something could be done better and we’ll implement that. But it could just as simple as just the user interface change. We had another user interface change where we have kind of a gadget interface for our minimally trained users. You read the barcode of the end of one of our cartridges and load it up and run it. You know, we’ve been out with the customer and we saw them just basically getting confused by the order in which the software was prompting than to do things. And this has been observed with several customers and so we decided we’re just going to change the user interface to match what the customer’s expectations are because there was no performance reason why things were being done in that particular order but something like that. Again, we push it out immediately into the internal testing environment but I think we’re more concerned about the system level validation and the functional validation. We don’t push things out to the customer that are say, just hot off the press.
Carlos: Got it, yeah. You need to have some sense of confidence or testing to make sure that whatever comes out is stable. With that said though, again I’m just trying to understand like some of the things that you guys do. Is there a case where you might release an update to one customer and then another. Are these like custom updates or is it all? I’m thinking of like firewall, right? I’ll upgrade my firmware but it’s the same firmware that everybody has. Is that different for you?
David: Oh yeah, no. We don’t do custom update. We are all running the same firmware and same software. You know, under the hood, as I said, we this barcode driven system. Once you read the barcode the system understands, the platform understands, or what thermal protocol to run, what optical sensing to use. You know, how the results should be interpreted and so all of that is encoded in the database driven by the barcode. And so from the customer’s perspective it really depends which test they get ship. If they get ship Test #1 and they read that barcode. The instrument will just do the right thing. And if they buy Test #2 and it reads that barcode the instrument will do something different under the hood but the user interface components will look the same to the user.
Carlos: Got you. You know, David, this has been a very interesting conversation with you because I haven’t had this sort of exposure to building software and hardware. And of course, in the short timeframe you’ve at least been able to showcase some of the issues or some of the things that you need to take into consideration versus other teams. Again, the interoperability of all the moving parts of a… We know that these systems are like living and breathing systems even if they are not, but these are like alive systems; and the different makeup of the team, how teams need to work together. But aside of that the very low level of margin of error that you guys have. You do have the ability to update in the same way that we have the ability to update our web application. Again, because you’re in the life sciences world or in the biotechnology to be more specific, there is that sense of things need to be production ready, need to function. So anyways, this has been a very interesting episode. One of the biggest takeaways from me is if you’re able to do this with a multi discipline team (engineering team). It think it’s a lesson for all of us that are building web applications or more basic software systems to see that’s it’s possible, right, because you’re doing it at a different level of complexity. You are adding all these different teams. Anyways, for me it’s a very interesting insight that you’ve been able to share with us.
David: Well, thank you. It’s been an interesting conversation.
Carlos: Alright, so David, we’re reaching the end of our episode here so the last question that I have for you. Actually, I have two questions. One is I want to know if you had any resources that you thought might be interest to our listeners that you could share with us.
David: There is a book that I read not too long ago. It’s called “The Creative Confidence” and it’s by the idea founders, people who have started the Stanford d.school. And I think it’s pretty interesting book about design thinking and touches on some of the topics we covered like prototyping. And I think it’s a good read.
Carlos: Thank you for that. I’m going to check that book out. I think I mentioned it to you earlier that in our pre-interview that a lot of the output of this is honestly I’m running a tons and initially book recommendations are the best recommendation because we can touch on the high level subject here but then once we go into more in-depth content we get to learn more. So David, and my last question is, how can people find you? Let’s say if anybody wants to get in touch, has a question, and how can they find Tetracore, and on top of that if you guys are hiring? Let us know I’m sure that some of the people listening to the episode might be interested.
David: You can find more about Tetracore at our website which is tetracore.com. We are located in Rockville, Maryland. We are not hiring right this minute. We did just bring on another mechanical engineer basically this month. But we hope to be hiring again in the future and if we are we will certainly be posting those openings.
Carlos: Alright. Well, David, thank you so much once again for coming on the show. I really hope to catch up soon and talk a little bit more about the contrast between hardware and software team versus only a software team. This has been great.
David: Yeah, great. Thanks for the opportunity to be part of the podcast and it was a great conversation.
Carlos: Thank you so much.