Development

[00:00:00]
>> Erik: Once you've created that workflow or that diagram, this is where you start the development process. [LAUGH] Do you see how much work it takes just to get to the development process? [LAUGH] At this point, you should be able to hand off your design or your architecture to another person and they make it without having to really ask you much at all.

[00:00:25]
This is really a principal engineer's job, which is think about it from a theory and a practice and a principal perspective. So that when you give something to the developer they can go, okay, well I understand what you want and I can pick the technologies because of your requirements.

[00:00:47]
And again, if you set those requirements really well and have really good scope, then you can actually put the whole responsibility of the technology on someone else, right? And then if that technology is chosen and maybe it's not accurate, then you can at least have a discussion with that person and be like, okay, I see where you're going with this, but maybe I wasn't accurate with my design or what I was trying to convey.

[00:01:11]
Here's how we can meet in the middle. But at this point, when you talk about developing the architecture, you should really be confident in what you're doing building or at least the components that are required to create what you're building.
>> Speaker 1: A question on the handoff.
>> Erik: Yeah.

[00:01:31]
>> Speaker 1: How much of the process do you think the individual contributors should, the IC, rehash everything that happened in step one in terms of, you're the principal you say go do this, here's everything.
>> Erik: Yeah, so as a principal engineer, you normally find yourself being spread across a lot of system, but you'll have like a main domain that you'll be focusing on.

[00:01:58]
Like in hippo, we have principal engineers that focus on our insurance again quoting and rate plans and all that stuff and like that's their job is to focus on that.
>> Speaker 1: Yeah, I guess I'm saying more like as the developer who's going to build it, do you think they should also obviously maybe part of it but how much research,

[00:02:23]
>> Erik: Right, okay.
>> Speaker 1: etc.
>> Erik: Yeah, so the way we we do it, where I work is, again, you should really not add any technology to the design. In the sense of like, are we using Amazon, are we using Google, whatever, unless that's a hard stop requirement. So it is part of the due diligence of the IC or your principle to make sure to think about any questions that the developer may have, right?

[00:02:52]
And so there can be sections in a proposal where there's a solutions section and it talks about, well, we thought about this, we thought about this we thought about this, but this is the approach we wanna take. Normally, there definitely can be developer input, but it's also kinda like there's too many cooks in the kitchen, right?

[00:03:14]
When you're starting to cook in architecture or something like that. Somebody has to sit down and spend, again, I just showed you like nine slides on thinking, somebody has to do that. But it is also up to the developer once they get that design to say, well, I see where you're going with this but I don't understand what you mean.

[00:03:38]
And then at that point, the IC should probably go back to the designs and address the developers concerns. So there's definitely a collaborative process, it shouldn't just be like, hand over, see you later, right? But a really good principal engineer will more than likely be able to hand off something and at least have a good guide for where they should go.

[00:03:59]
However, and this is also important, the developers shouldn't wait to bring up their concerns. If you get a design and you look at it and you go like, this doesn't make any sense. Then you should go directly to the IC or the principal and be like, hey, I just don't understand what you're trying to accomplish here.

[00:04:17]
Yeah, but I would say it's actually more time efficient to let them work separately, because you can get in conversations about technology and other stuff. And one of the things that I, [LAUGH] I'm even doing more now that I used to deal with when I was first dealing with that handoff was knowing when it's a technological conversation versus a design conversation.

[00:04:51]
And more often than not, I might be talking about the philosophy of approaching something, but then somebody being like, well, we can use S3 for that. No, don't, that's not for this right now, right? Let's define the philosophy and what we're trying to do, and then we can take the technical side.

[00:05:10]
But normally it's good to have those separated cuz then they can iterate individually. Does that answer your question? All right, cool, awesome. It is a tough handoff though, don't get me wrong. The culture around it, having good, like communication around it is what's really gonna make the success of that, yeah.

[00:05:33]
So after you develop the architecture, you should know how to test your architecture, right? It could mean that you're using tools to help put load onto the infrastructure or on the architecture so that you can emulate. It could also be creating integration tests or end-to-end tests. And that's something that we do at Hippo as well.

[00:06:00]
Whenever we deploy a service, we have integration tests that run on that environment after the service is deployed. So that we know we have good regression testing, we know that the environment is still working the way as expected. When you have tons of changes like that, you wanna be aware of how it could change underneath you and making sure that it's still meeting the requirements of the project.

[00:06:26]
And I'll be honest, we only started doing integration, we are probably like, I mean, we're probably like a 10-year-old company now or something like that. But we only started doing integration tests like two years ago [LAUGH]. So like a lot of the stuff I'm talking about is still very uncommon in most places.

[00:06:46]
But testing can make it so that developers can get stuff out quicker and have those red lights or those warnings show faster. So testing the architectures is really important for all edge cases that you can.
>> Erik: And then finally, deploy the architecture, so at this point, again, let's recap.

[00:07:12]
We started with research, right, we started with exploration, we started with putting our ideas down and putting them on paper, right? We then develop that system, we then tested that system. At this point, you should feel comfortable putting this in production, right? And if you don't, then you need to go back, you need to go back and address what stages you might have missed.

[00:07:38]
But it's really up until the point where you feel like, okay, yes, I feel confident that this system is doing what we want it to. We've tested it, we've addressed all the developer concerns, now it's ready to go to production. I can't tell you on how many occurrences I've had, where a lot of problems have happened just because some of those things were considered earlier on.

[00:08:04]
And I'm sure you guys have probably even dealt with that too at some point, where it was like, why wasn't this tested, why didn't we think of this? And it kind of becomes, well, maybe the IC or the principal forgot, right? Or maybe a developer didn't raise their opinions when they should have and now we're dealing with that problem, right?

[00:08:25]
So you should feel comfortable to deploy the architecture once you've gone through all those phases