Hi, everyone. Welcome. My name is Dan Tina Ratner. Uh I'll be here for, for here today and we're gonna talk about software and hardware, two sides of the same coin uh to get us started a little bit about my background.So I'm the co-founder and CEO of all spy at IO. Um I have a background in mechanical engineering and also uh work experience as a PM where when I was at Amazon before I went back to grad school and I did a dual degree program at Harvard and a Mass in Computer Science and an MB A. That's where I met my co-founder, uh our CTO here at Spice and our conversations about the industry and the problems in the space and the opportunity led us to launch the company. So All Spice is a state founded um startup. So we're venture backed, we've been in market about a year and a half and we focus on applying software principles to hardware development. Um It's a B to B company A model and we have customers uh from aerospace to medical devices and a variety of industries in between. Um a little bit more of what we are doing is we think of the um software and the hardware world converging and hardware products becoming software products as well.

And com hardware companies becoming software companies at the same time, which also means hardware engineers and software engineers becoming more collaborative with each other and sharing a lot of principles and best practices between the two. So the way we see that come together is through revision control, through collaboration and through automation. This is inspired because the way we built hardware has changed over time. So traditional hardware design timelines were used to be very long. So um maybe a couple of decades ago, taking a product to market will take about five years and people will do 34 iterations um prototypes in between. So a year long cycle for each of those to launch a product, a hardware product at the end of it recently, what we've seen is the cost and the time required to prototype has gone significantly down, which means engineers and hardware engineering teams are doing more and more product iterations at a higher frequency.

So products today take anywhere from 12 to 24 months to get to market and sometimes even faster than that. And teams do 5789 iterations or prototypes in between those two. The problem we see is that a lot of this uh iterations are still happening in legacy or obsolete data management systems that were put in place for when teams had five years to take something to market. And nowadays they have to do things as fast, but they have the same tools to do so than they did when things took longer. So there's a variety of tools, anything from design to word processors, PDF and email and PLM tools. And the problem is that none of these talk to each other. So we see kind of on the other side of the coin in the software space. There's also an incredible ecosystem of lots of tools and best in class specialty tools. The difference between these two is that those tools have perfect connections with each other. So having a variety of tools isn't as much of a problem because they can talk to each other perfectly. There's no information lost, they use API S and all of that is trans transferred smoothly. When you you go to the hardware side, the difference is the way you transfer information from example, from a design tool to your next tool that you need to use. It.

Everything gets produced down to the lowest denominator, which typically is a PDF and email thread, a spreadsheet, right? And this is causing a lot of problems for these teams and there's different trends that are forcing these teams to become more and more agile. A similar transformation that software went through about 10 years ago. This process has a lot of manual tasks which are error prone. Um Think about it when you're trying to, um when a typical example is people have to manually um create a list of all the changes between their last design and their new design. This could take hours of time and it becomes a little bit of a playing. Whereas wild game where you have to put two images side by side and try to identify what's different, which you can imagine. It makes it very easy for things to fall through the cracks. There's a lot of manual exports, there's disconnected, disconnected data and all of these teams live in isolation. There's also the iteration speed, which is um this a lot of the systems were established for water form methodologies. And as teams become more and more agile over time, there's not a lot of real time feedback and they have a hard time adapting to um to changes in the environment.

So a typical example for that will be in, in the past, it takes you, it took you three weeks to validate a new component. So you have a design and one of your components goes out of stock or you need a um you need to qualify a new part, may take you three weeks to set up a meeting with someone, get everyone's input, go through all of your checks and then release that at the end of it. Nowadays, it's like your entire cycle may take that long. So if you're spending that much time to qualify a part, you can't really keep pace. And before maybe you didn't need to because manufacturing will take that long. But nowadays, with 3D printing and with fast P CV shops, teams have to respond more quickly to changes in the environment. And the third side is the communication. So different teams and schedules people working remotely or we see a lot of distributed teams with specialties.

So um sometimes by design and sometimes by, by chance, if you think about it, like having to design a board or having to, to work on a design that um requires a very specific skill. And the expert on that leaves in 3000 miles away from you, you suddenly may have a distributed team, even if it's not how your company will set up to do. So we see a lot of this specialty design getting outsourced or going to experts and they need to kind of keep everyone in the same, same pace, same place. So as we, these teams converge, we see the hardware industry looking at software for a lot of best practices and software has some of the similar problems and they figured out ways to manage those issues, right? And the biggest influence we see between these two teams is the share of workflow methodologies in which in in our particular case, we see it as like the adoption of git based workflows. So get is a protocol that's very um well understood and adopted in the software space that is becoming more and more popular with hardware engineers. As hardware engineers start working with software teams more and more or sometimes being themselves part time software engineers, right?

So some people may be doing it 5% of their time for a small project, or some people may be doing it 50% of their time for writing. Far more. So this kind of workflows the what they allow these teams to do is to better organize their own information and make it easy to collaborate with the rest of the stakeholders. So hardware is a very collaborative process where there is a variety of stakeholders that participate.

So we work with electrical engineers, there's also mechanical engineers test manufacturing and then there's the other side of the house where once things are ready to get um manufacture, they go into purchasing planning C MS, applications, suppliers and everything in between.

So when we think about the, um we, we see that there's a lot of influences between the two disciplines, but there, there's some things that are similar and there's some things that are different. So some of the things that we see uh similar is the trend towards agile development, which has been uh influenced by first, the technology that allows these teams to move quickly and also consumer demands and products. So think of like uh if a product, a new hardware product, let's say the new iphone took five years to to get to market. By the time you launch it, the technology that's in it, it's already obsolete if it's, if it's such a slow and long process to get to market. So these companies are becoming more agile, they need to move faster, they need to release faster. And there's also the need for flexible and quick iterations. And the biggest impact here has been coming from the um supply chain disruptions from the past couple of years. We we hear from a lot of teams that feel like they're playing whack a mole where um the when you start a design, all of the components or all the parts that you're putting inside of it may or may not be available by the time you complete your design.

So you almost have to start designing within that flexibility to be able to accommodate like 34 or 57 different changes along the way. So having that flexible infrastructure that helps you kind of navigate those processes is really, really important. And the same happened in software, right.

On the other side, some of the the differences that we noticed as these two workflows converge to being the same. The first one is around UIs and things evolving for text versus facial information. So the biggest fundamental difference between hardware development and software development is the the format of your output, right? As a software developer, you're working on tax based code, that's kind of your day to day your main format. That's the hard developer, most people operate in visual vector drawings, right? So think of like two D images, 3d images and those could be a circuit board, it could be a schematic, it could be a component. So adapting the workflows from one place to the other, it's one of the biggest differences and then the other big difference between the two disciplines is the the cost of mistakes. So the the cost of of an error in software could be high. The cost of an error in hardware is exponentially higher because we're talking about physical and real world manufacturing. So compiling the wrong version of a board, it could mean anything from a couple of $1000 on rework and faulty prototypes to like millions of dollars in having to organize a new factory depending on how soon or late in the process you catch this mistake.

So the the hardware teams need to be as flexible as the software teams, but they also need to have higher checks and, and kind of and, and guard rails to prevent some of these mistakes from making it through because of the nature of how expensive they are they are. So um kind of going back to like the biggest difference in like when we think about the formats between the two text versus images, um we can talk about kind of like how things translate between the two spaces. So how do things look in one versus the other. So when, when you talk about software development and peer reviews, we talk about pull requests. When we talk about it in hardware, we talk about design reviews. But um this processes may seem different in um high level, but they're actually a lot more similar than, than a lot of people realize. So the equivalent of in find feedback for software, it could be uh snippets in hardware. So two D kind of drawings around that um commits in software have an equivalent in links to locations in hardware. There are C I CD tests for software in hardware. We can run tests as well uh depths between the 21 in text based data, the other one in vic visual vector schematics um and then color coding things from one end to the other as well.

And um if we follow the evolution of of software that what we see as a feature of hardware development as well, it's following a similar path. So where first came revision control, then came collaboration and then came automation. Revision control has existed for some time in hardware and it's getting a lot, a lot better collaboration. It's where the industry is at right now. And there's a lot of effort going into making that process smoother for all of the stakeholders. So what comes next to us in our mind is automation. What does automation mean in both of those in software we're talking about C I and continuous integration unit tests that you can run on your code on a regular basis. Our our kind of thinking and what we we work on is how does that translate to hardware, right? What does that mean into the hardware space? And what does an automated test look like in that? So Howard today has a lot of testing built in place. The way that happens, the majority of the times is at the end of a design process. Once when everything is completed, the shift that we see is from going from doing things when your design is completed, when it's really hard to go back and implement those changes, shifting those tests to be set up at the beginning and you set them up once and then they run with you with the rest of the process so that you can catch this information, not at the end when it's too late to make changes, but at this thing as this thing happening throughout the design process.

So that's one of the big kind of trends and and features that we see in the hardware space. The other one is addressing cross-disciplinary needs the same way that hardware has a lot of disconnected tools that don't really work well with each other. The same happens at the stakeholder level where there is a lot of integration that needs to happen between the different teams and where information falls through the cracks or problems happen. Because things fall through the cracks. And so think about electrical engineering, to mechanical engineering, uh interfaces, electrical engineering to far more, far more to operations, mechanical to operations. And all of this different when I was talking about the different people involved in hardware development when these teams need to work with each other.

Um There's a lot of, of, of error prone areas at the at those like intersection points. So working beyond like your specific in in field to more of like the broader product level, that's another area where higher development um is gonna get better over time. And then kind of the the third area to address is solving supply chain challenges that have grapple been grappling being distributed for the past several years. Um The other big difference between the software and the hardware side being that physical manufacturing component where when you're done with your design, you're not done quite yet. Um in software, you may compile and ship your product and um does have his complexity in the hardware space.

We enter an entire new process of physical manufacturing that comes with his own challenges along the way. So giving the teams the ability to have both viability and flexibility to respond to changes in the supply chain side is kind of like they are their big area for the future of hardware development. So with that, when I are closed for today, I wanna thank everyone for your time and um offer if you have any questions about the future of hardware and software and kind of how these two disciplines are coming together. When are they coming together and how and versus when they're not feel free to send me an email, uh you can email us at info at all. Do IO or you can email me personally at Valentina at all A O I'll be happy to chat and answer any of your questions. So that's all for today. Thank you so much for joining. I appreciate your, your time and hope you enjoy the session and the rest of the conference.