Inventory Management or the Art of Making Every Business Flow Effortless

Tiffany Chang: 0:00

I think now only the people who are in inventory are the hardcore nerds because we love inventory, and we love a challenge. It's the main issue. While the inventory app can focus a lot on a worker in a warehouse, the manufacturing will focus more on people working in a factory. We handle a lot of use cases, but there's so many that we can't possibly handle them all, so we try to keep it as broad as possible. For the most part, the hope is that whoever is reviewing will remember all the use cases. But since we're only human, of course, sometimes we miss them, and I often test it myself to see, okay, I bet they forgot about this particular use case, and then I'll try it, and I'll go. You didn't consider this? You need to fix your code. I feel like there's the expression in development that don't reinvent the wheel. It's the same idea of, well, someone else already invented this pretty good wheel. Let's just take it and tweak it and make it a little bit better. The nice thing for me with logistics is I like thinking of lots of different use cases and flows that work very well, and it's nice that we always have new challenges. So you never get bored as well.

Olivier Colson: 1:01

Welcome to another Tech and Dev episode. Today we'll discuss with Tiffany Chang, a developer on Odoo stock and manufacturing applications. From industry challenges to powerful integrations and dev anecdotes, we'll go over the story behind our stock and manufacturing application suite. Ready? Let's go. Hello, Tiffany.

Tiffany Chang: 1:20

Hello, Olivier.

Olivier Colson: 1:21

Nice to have you here. So who are you, and what are you doing at Odoo? Could you tell us?

Tiffany Chang: 1:26

Well, I'm Tiffany. I'm a developer. I've been at Odoo for about three and a half years, and I'm in the inventory group or the stock team. Okay.

Olivier Colson: 1:36

Inventory stock. What does that team do exactly?

Tiffany Chang: 1:39

So we handle all of the apps related to stock and making sure you have things in stock. So, for example, we do purchase, inventory, manufacturing, repair, PLM, and we also handle the delivery connectors and also quality.

Olivier Colson: 1:53

That's a lot of things.

Tiffany Chang: 1:54

It is.

Olivier Colson: 1:55

So you have a very, very broad scope. Why is it all handled by the same team?

Tiffany Chang: 1:59

So it's all handled by the same team because they all kind of related to each other. So, for example, if I want to make sure I have things in stock, it's important that I can automatically set a purchase order so that it'll resupply my stock, and the rest of the Odoo apps don't necessarily involve these things. It's usually just if something's in stock, it'll be able to do it. So they only care about their small connection with the inventory.

Olivier Colson: 2:21

Yeah, that's too connected actually to be, to be split, or at least it's good to keep things together.

Tiffany Chang: 2:27

Exactly.

Olivier Colson: 2:29

Okay. And how did you end up doing that? Because I already said that in another episode. But let's say it again. I mean, it's not the most sexy thing a developer would would would think about when starting his career, actually. So inventory management. Why this choice?

Tiffany Chang: 2:45

So it's a little funny for me because when I started, Odoo was recruiting a lot of developers, but it was still on a much smaller scale than now. And back then, our training program was we did the regular functional training like all of the other Odoo employees, and then we had a technical training that was very different from what we have now. We have all these nice tutorials on the documentation website. Back then it was just.

Olivier Colson: 3:08

An ancient time where you had to improvise a lot.

Tiffany Chang: 3:10

Yeah, there was like one document where it was just build a module and then we just had to follow it. But it wasn't very clear. And you make lots of mistakes and then in the end, when you're done, someone's just like, Oh, you finished? All right, good. Go to a team now. And back then, Anthony, he wanted us to be on different teams to experience different things. So it was supposed to be you went on one functional team and then you were supposed to go to the JS framework team because he wanted us to all have more of a JS background.

Olivier Colson: 3:36

From the way you were saying it, you didn't do that.

Tiffany Chang: 3:38

I'm very happy to say I did not do it because they changed their mind, and then they also want everyone to either be in logistics or in accounting. And I got put on the logistics team, and then I never left.

Olivier Colson: 3:51

So you, you, you were convinced. Love at first sight. Yes. Yep. All right. Could you explain a bit more, functionally speaking, what each of the apps you are in charge of are doing?

Tiffany Chang: 4:03

Yes. So purchase, I think, is a little self-explanatory. But if not, it involves buying things from vendors. So normally, when you have just purchase installed, you're not necessarily keeping track of things that are in stock. So for example, we have the product type consumable. So it means you know that you're buying, let's say, screws, but you don't care how many you have in stock. So you'll just say, okay, I'm spending this much of this vendor and I have bought this much from them. But then when you go to sell them, you don't necessarily care. Okay, do I have screws in stock or do I just sell screws in general.

Olivier Colson: 4:38

Because it's just too small to track, actually. And it would just wouldn't make sense, I guess, to track every screw you have in stock.

Tiffany Chang: 4:46

Yes. But then once you install inventory, then you can say, okay, I care how much of these things I have in stock, so then I can make sure I don't sell tables when I have no more tables in stock. Or you can also track different types of tables, things like that. And then so inventory. That's what inventory does is it helps you keep track of what you have in stock, essentially. And also if you have things like, for example, the receipts. So when do you receive things in stock, and when do you send things out? And you can also do more complicated things in that as well, such as if you have multiple locations and you want to keep track of, okay, I moved things from my loading dock onto shelf one. And then it's.

Olivier Colson: 5:21

Not just about I mean, if you're just a small shop selling a very limited number of things that don't take up too much space, you can have one room to store everything. But I guess when you grow bigger and for bigger businesses, it's not like that at all. And so it becomes more complex because you can have different locations where your items are, and you need to track what is where, what it went through, I guess as well. And that's where you need a software, actually.

Tiffany Chang: 5:48

Yes. It can also vary a little bit. So for example, I went to one customer's location where they have different things in stock, but they need to keep track of which shelf is it on because then it makes it easier for them to process, okay, I want to send out this package, and I need to know exactly what shelves to get each one of the items I need from.

Olivier Colson: 6:07

Sure. Because people are then more efficient to pack everything. And so, at the end of the day, you save money with that.

Tiffany Chang: 6:13

Yes. And also, for example, maybe you store specific things on specific shelves because one of the things that we include in the inventory app is being able to track things by serial number or by lot, which can be very important, for example, in the medical field. Sure. So you have to make sure that you're not grabbing the wrong lot and then sending the wrong lot because then you'll get in big trouble later on, I think, with auditing.

Olivier Colson: 6:34

Okay. So next app you want to talk about.

Tiffany Chang: 6:37

So the next major app that we handle is the manufacturing app, which is kind of like the purchase app, it helps you ensure that you have things in stock. So let's say going back to the table example, you want to make sure you've manufactured enough tables and you also need to know how do you manufacture your table and if you have different versions.

Olivier Colson: 6:52

When you make them. Yes, actually. Okay, So very, very vaguely. But that's the idea. So just so that people have an idea of what we're talking about.

Tiffany Chang: 7:01

Okay. Yeah. So to me, the names make it obvious, but I suppose manufacturing doesn't necessarily mean building things to some people, but yes, so the manufacturing app is all about building things. And while the inventory app can focus a lot on a worker in a warehouse, the manufacturing will focus more on people working in a factory.

Olivier Colson: 7:22

Okay. And then other apps you need to explain?

Tiffany Chang: 7:26

The other ones are smaller apps, so repair. I also think it's self-explanatory, but it involves repairing things. So that can be very useful in the manufacturing case. If, for example, you have certain tools that you use and they break and you need to make sure that you've repaired them. And also, if you provide repairs as a service to people and then the other smaller apps, we have the PLM, the product lifecycle management app.

Olivier Colson: 7:53

Okay. That's something you need to explain here. You can't say the name is self-explanatory. Yes, that's a barbaric name. What does it mean? What does it mean?

Tiffany Chang: 8:00

I think that app appeals more to engineers or people who do operations research because that's usually we have a certain design for a particular product that we manufacture or a certain way that we do things. Maybe there's a better way we can do it. So with the PLM app, you can create what's called an eco, an engineering change order, and with the eco that helps you keep track of, okay, let's say you have a table design and you want to make a new one and maybe you have two designers working on it at the same time. They can create their own separate ecos and then they can compare and say like, okay, your design makes it so we don't use this particular type of leg anymore. We now use these types of legs, or you now change the order of the steps in order to manufacture the table. Maybe it's more.

Olivier Colson: 8:44

Efficient, so it's ready to coordinate. I would say the R&D side of the table making and really compare what you did and, well, keep track of the different, I would say, branches that people have while changing pieces of the table or the material or color or whatever. Here.

Tiffany Chang: 9:01

Yes. So we also handle the quality app. That's usually an extra step that a lot of companies need to have because it's the quality control portion. So that tends to be very important, For example, in health care or engineering, where you need to make sure you meet specific specifications. So you can add in. For example, when you receive your goods, you can make sure that when goods come in that they meet certain measurements. So, for example, the screws are the correct width, okay? And you can even set it up so it works. Just like quality control works for strict factories where you test every fifth product because testing every single one sometimes just isn't possible.

Olivier Colson: 9:39

It's not, I mean, at least not always possible, I guess.

Tiffany Chang: 9:42

Yeah. Yeah. I have a little bit of a statistics background, so for me it's the idea of you do enough sampling to make sure that it's good.

Olivier Colson: 9:49

I think the only one left is the delivery connectors, but then I think it's pretty obvious.

Tiffany Chang: 9:53

So I could go into it a little bit in case we decide they are sexy enough to talk about. But the delivery. The connectors are everything involving, for example, Fedex, UPS, USPS. We handle that because usually you really need to know the weight of your items when you send the information to the shipper because otherwise, they have no idea how much to charge you if it's overweight if you're using the wrong type of packaging, things like that.

Olivier Colson: 10:16

So it's not just connecting to them actually. So you need to change the behavior of the software itself within Odoo, it will work a bit differently to fit the way they are communicating if you will.

Tiffany Chang: 10:26

So each delivery connector is slightly different because, for example, what UPS expects from us for formatting can differ from what Fedex wants. So, for example, sometimes the way that they need a number formatted for the customs form will differ from one connector to another. We have to make sure that it matches each one correctly.

Olivier Colson: 10:44

And so I guess it can become quickly very complex. And the problem there is that you have a lot of different connectors, and the more you want to support, the harder it becomes because you have to keep everything in line, right?

Tiffany Chang: 10:55

That's correct. And even more difficult is that sometimes the API changes, and then we have to update everything.

Olivier Colson: 11:02

And you discover it the day it breaks.

Tiffany Chang: 11:04

Usually, they send out warnings at least. But we did have to do a big refactoring for 16 because a lot of things changed and I think DHL completely changed their API and if we didn't change it, then all of our DHL connectors were going to break.

Olivier Colson: 11:17

Okay. Okay. Going a bit more into the details now. Could you give us a brief overview of the implementation actually of the stock app and the stock models? What are they what how does it work exactly?

Tiffany Chang: 11:28

We have a few main things that we handle. We have the same model for when you receive goods and for when you're sending out goods or when you're moving goods within your own warehouse or across your warehouses, things like that. But then on top of that, we also have a model to keep track of how much you actually have in stock of a particular product because we.

Olivier Colson: 11:46

Keep the name or the names.

Tiffany Chang: 11:47

Of these. Okay, So.

Olivier Colson: 11:49

Let's be technical. Let's be technical.

Tiffany Chang: 11:51

So the name of the model that handles things coming in, things, things going out, that's the stock pickings. Okay. Picking isn't a very intuitive name. I think so. That's why I prefer to just say the receipts or the deliveries. And then in addition to that, we have the stock quants. And so the stock quants are the actual amount that you have in stock because until you do the actual shipping or the actual receipt, it's still theoretical. So you don't want to accidentally sell something that's in theory going to happen but doesn't actually happen.

Olivier Colson: 12:20

Yeah, you want to make sure it is there. Yes. Okay.

Tiffany Chang: 12:23

And so for the models that handle the theoretical expected movements or the stock moves, and then even more specific than that is the stock move lines, which is why stock can sometimes get a little confusing for some people.

Olivier Colson: 12:37

Yeah. For developers working on Odoo but not working, especially, on the on the stock app. It's one of the ones with the most complex models. I guess I only had a look at it a few times because I didn't have many opportunities to do so. And indeed, it feels complex actually. But I guess it's because it is, and it's no harm. I mean, it's obviously it is.

Tiffany Chang: 12:58

Yes. We originally I think originally before I joined inventory, I think there was a problem with developers not wanting to join because it was too complicated or they would stay in the team for a little bit and then move on to did it change? It did change. I think now only the people who are in inventory are the hardcore nerds because we love inventory and we love a challenge. It's the main issue because we love it. Challenge is the main benefit because with some of the other apps, I think it's since it's a smaller scope, you tend to see the same thing over and over again. Whereas because we have so many apps and we have so many scopes, we handle both JavaScript and Python and SQL that you're able to try different things and not get bored.

Olivier Colson: 13:37

And does it often happen that someone comes in with a use case that you did not support and you're like, Oh, we need to add something for that?

Tiffany Chang: 13:45

Yes. So that's one of the other challenges that we have is that we handle a lot of use cases, but there's so many that we can't possibly handle them all. Everyone always comes up with their specific use case that they want to handle. And we say, well, if we do that, it's going to be extremely complicated, and then we're going to have huge technical debt. So we try to keep it as broad as possible. For the most part.

Olivier Colson: 14:07

When there's something you discover you need to implement, like actually we're talking about technical debt. Does it often happen that you have to like refactor a lot of the code because you need to make it more generic or how does it integrate? How does it fit actually in the code base then?

Tiffany Chang: 14:22

So we do have to refactor sometimes, but there's I guess maybe three cases that we usually have to handle. One is making it more scalable because often, with inventory, we have to deal with large amounts of records. So records being, yeah.

Olivier Colson: 14:34

I guess it's just like for accounting, you have to very quickly a very huge number of things in the database. And of course if it takes ten minutes to load every load every time, it's just not working. Yes.

Tiffany Chang: 14:46

Yeah. For example, it could be someone has decided, okay, we have all of these incoming receipts. Let's just validate 100 of them at the same time. We need to make sure we handle that quickly enough. Otherwise they're probably going to quit Odoo because it'll take them forever. Forever.

Olivier Colson: 14:59

I was saying ten minutes, but even 30s every time you need to send a table, if you if you're selling thousands of table to stay on this example, it's not going to be very well. It's not working.

Tiffany Chang: 15:11

Yeah, exactly. And then the other case of when we were doing refactoring is if it can be done better. So for example, we did a big refactoring for version 14 and with that we refactored it so you don't have to go to as many pages in order to set up how you are going to do your construction.

Olivier Colson: 15:28

What is the idea behind those simplifications? What are you touching exactly? Is it really for the user experience or for the performance?

Tiffany Chang: 15:36

In that case, it's usually for the user experience. Okay. So so for example, what way? For example, whenever I go back to version 13 and I'm trying to see, okay, I need to set up my, my Bom, my bill of material, which is how am I going to construct my particular product? I realized that I was having a really hard time just figuring out where do I need to click in order to set up the steps. And that was one of the things that we improved when we did the refactoring was now you create your Bom, you say, These are the operations I'm going to do, and then there's a button that you can click to immediately set up the steps and instead of having to go to another view.

Olivier Colson: 16:10

So you were switching between screens a little too much, and it was confusing the user.

Tiffany Chang: 16:15

Yes. And it was I think there was a term for it where you have to know the clicking order, you have to know exactly where to click in order to set up all the steps. And I think this is a very this is referred to like 90s programming style where everything is a dropdown menu, and you have to know exactly where to click. So you click all the options everywhere.

Olivier Colson: 16:34

Okay. So it's just confusing that and making it more modern where everything is properly set up with only a few things you can click on every time.

Tiffany Chang: 16:41

Yes, exactly.

Olivier Colson: 16:42

And when you're changing such a flow and or doing other kinds of optimizations a bit everywhere in your code base, how do you make sure that you're not breaking this or that use case? Because you were mentioning that there were a lot of different possible cases. How do you control that? Do you control that? So tell us the truth. We want to know.

Tiffany Chang: 17:02

The hope is that whoever is reviewing will remember all the use cases. But since we're only human, of course sometimes we miss them. But it is very typical where I'll do a review and I'll say, Oh, well, I think you forgot this case and oh, I think you forgot about this use case. And I often test it myself to see, okay, I bet they forgot about this particular use case and then I'll try and I'll go, You didn't consider this. You need to fix your code.

Olivier Colson: 17:25

So. So it's your experience talking?

Tiffany Chang: 17:27

Yes. But often I forget about use cases myself. So...

Olivier Colson: 17:31

And then what happens?

Tiffany Chang: 17:32

And then I have to go back and fix it later.

Olivier Colson: 17:35

I assume you have tests as well.

Tiffany Chang: 17:36

In the code? Yes, we do have tests, but sometimes it's hard to know what to test against if you don't know all the use cases or the other issue is or the other challenge is if you add in a new feature, you don't want to have to write ten tests every single time to handle all of the possible use cases, especially use cases that people don't really use very often.

Olivier Colson: 17:56

It's like it's a combinatory stuff. You have to rewrite the whole test, changing only a few things every for every possible combination of setups. Is that it?

Tiffany Chang: 18:04

Yes. And sometimes even then, depending on your future, you might still have to write a completely new test anyways.

Olivier Colson: 18:12

So if I get you well, writing a test for everything is just not possible. Because then you would. It would be impossible to maintain just the test.

Tiffany Chang: 18:19

That's correct.

Olivier Colson: 18:20

Okay. Makes sense.

Tiffany Chang: 18:21

Yes. And that's just for the python test. Then we also have the JavaScript tours which are even more complicated and confusing.

Olivier Colson: 18:29

Do you have a lot of JavaScript custom code in your module?

Tiffany Chang: 18:33

So we do within we have two main apps that do use it. One is manufacturing because we have to handle what we call the tablet view, which is what the builder uses when they're doing a work order. So a work order is kind of like the steps you have to do for your manufacturing order. So I should also clarify that the manufacturing order is the actual time you're building something. So let's say someone says, I want five tables, then you'll have a manufacturing order that says you're constructing a table. You have to make five of them. These are the components that you need in order to construct it.

Olivier Colson: 19:09

And essentially, you have some guy with a table and all the material receiving the order, and he has to follow the instructions to build the five tables, then.

Tiffany Chang: 19:18

Yes. So the work order.

Olivier Colson: 19:19

Screen, we're talking.

Tiffany Chang: 19:20

About.

Olivier Colson: 19:21

The screen. He is seeing.

Tiffany Chang: 19:22

The screen that that guy seeing is the work order. Okay. And that is actually, we expect that to be on an iPad, for example, where they can click through. So that has to be a custom JavaScript thing because it's kind of unique because it's a combination of two form views because we have the work order itself. So usually that will have information such as what are you constructing? If it has a serial number, what is the serial number going to be of the thing that you're constructing? And then on top of that, you can have the steps, which is a separate form, and then you can step through the different steps. So it's a different form view each time you go through a step.

Olivier Colson: 19:53

And I assume we need to have this nested mechanism again to avoid switching between screens and just to have everything at the same place and have something clearer and faster. For the guy working with it, because I think he has other things to do than just spend time clicking on buttons on the screen.

Tiffany Chang: 20:08

Yes, exactly. And also, it just makes it easier for them to click the buttons because you just the next step is the next button. And then the other main app we have in JavaScript is the Barcode app, which I didn't mention earlier, but it's essentially just the inventory app, but in a much more user-friendly JavaScript version. So you can use an actual barcode scanner. And the nice thing about the way that that as well as the manufacturing work orders.

Olivier Colson: 20:33

Just to make it clear for people because I saw demos of that, maybe Fabien doing that on stage at Odoo experience but maybe not everybody did just go and watch. But to quickly explain where do barcodes interact with stock? Exactly what are they used to? It's a bit a silly question, I know. But let's explain everything. Okay?

Tiffany Chang: 20:52

Yes. So you can think of it as when you go to a supermarket, and you go to buy something, they usually scan the barcode that's on the back. So it's the same exact barcodes. I can go into the specifics of different types of barcodes, but that's probably very boring. Okay. Yes. But the general idea is there is some barcode-like thing on your product, and Odoo can also produce those so that you can stick a label on something. So if you're selling something in a store, they can just scan the barcode. Or if you're in a warehouse and you want to say, okay, I'm shipping out five tables, then you can just scan those five barcodes very quickly and it'll automatically increment the amount for you so that you can send it.

Olivier Colson: 21:30

And this way, you don't have to encode everything. And every ,time you type the serial number, which is I guess what is actually encoded into the barcode.

Tiffany Chang: 21:38

It could be the serial number or just the product barcode. Yes.

Olivier Colson: 21:42

Okay. So you mentioned a bunch of the technical challenges that your team has to face every day. Are there other ones you didn't mention yet?

Tiffany Chang: 21:49

So another one would be going back to the barcode app is the fact that sometimes people don't have an Internet connection when they're doing their task. So with the barcode app, what we had to do was make sure that there was a caching system so that they can load, okay, I'm going to do these deliveries. They load it into their little iPad or iPhone or their super fancy barcode reader because there's some very fancy ones I've learned about since I started working for inventory, which is it's basically a smartphone that does barcode scanning. So they preload it and then they go to the warehouse, they can scan everything offline and then come back and then reconnect and then process it and everything will be in the database.

Olivier Colson: 22:28

Cool. So you need to synchronize everything and you need to handle this caching properly. Yes. Okay.

Tiffany Chang: 22:32

Another one. So we also have a similar thing with the tablet view for the work orders because the worker might also not have an internet connection in the factory.

Olivier Colson: 22:43

So you talked a bit about the fact that you need, to change things regularly between versions and refactor things. Could you give us a little of an historical view of your code base and what were the big milestone, the big changes that that that occurred since you entered or slightly before If you know, we can talk about the distant past if you want.

Tiffany Chang: 23:06

Well, unfortunately, I cannot speak to the distant past because I will see the commits and go, okay, things change because it's too complicated. Yes. There's no point in me learning the past as long as we don't repeat our mistakes. Of course. Sure. But so I already mentioned the big manufacturing refactoring that we did for version 14. And then since then, we've done smaller ones. I mentioned a little bit of how with the delivery connectors we had to refactor it to meet all the new APIs. But another one that we did was for the inventory adjustments, which is essentially someone going and checking what do they have in stock? Is it what they actually think it is and correcting it, things like that. And with that, what we did was originally, you had to do an extra step in order to do your inventory. And what was it before you had to say, I'm going to do an inventory with these specific products or all of my products and these locations, and then you would hit, okay, start my inventory, and then you would go through and do it. Now, I think one day Fabien saw like, Oh, this is how our competitor is doing it, so we should maybe do it that way too, because it's much better than what we're doing. And now you can just go to the inventory adjustments page and it'll automatically show you everything and then you can just filter accordingly to what you need to do your inventory on.

Olivier Colson: 24:20

It's interesting because you took inspiration from a competitor. I mean, business is business. You have to you have to sometimes.

Tiffany Chang: 24:27

Yeah. And if someone else is doing a good idea, then why not just copy it?

Olivier Colson: 24:32

Sure. I think it's important when you're developing something to stay open to ideas coming from people outside of your little bubble of your church. I don't know because, well, you might have very good ideas, but you probably are not the only one. And maybe someone had a better idea than you and thought about something you wouldn't have thought about.

Tiffany Chang: 24:54

Yeah. I feel like there's the expression in development. Don't reinvent the wheel. It's the same idea of, well, someone else already invented this pretty good wheel. Let's just take it and tweak it and make it a little bit better.

Olivier Colson: 25:05

Did it happen in other aspects of the modules that you had to take inspiration in other softwares like that?

Tiffany Chang: 25:11

Unfortunately, I'm not sure because that's more of a product owner thing than a developer thing. It's usually they tell us what to do and we're like, okay, I will do that.

Olivier Colson: 25:18

Maybe they saw something in another software and they were like, Oh, it's my idea. You don't know. Um.

Tiffany Chang: 25:25

I'm not sure. I do know that our product owners will sometimes go and see how people do it in the real world, and they say, okay, they're complaining that we're not doing this particular thing that we should do. Let's just do it.

Olivier Colson: 25:36

Do you get a lot of interaction with the community about things to change like that?

Tiffany Chang: 25:40

So we do get feedback. I usually don't look at the feedback myself because that's also again product owners. Sure, we do get bug fixes from the community, which is nice because sometimes they're looking at things that we're not necessarily looking at and I'm, I'm sure a lot of people will recognize me as replacing their code or being the annoying person saying, Could you change this? Can you make it a bit better? But yeah, that's.

Olivier Colson: 26:01

That's your role as a reviewer?

Tiffany Chang: 26:03

Yes, I'm usually one of the strict ones.

Olivier Colson: 26:05

So you're the one that everyone is complaining about Every time it's like, Oh, again, she asked me to change that and that and that. Ah, okay.

Tiffany Chang: 26:13

Yeah, I'm fine being the mean person because later on I'm going to beat it again at some point and I'm going to be annoyed if it's not good. But we do also sometimes get feedback as well, and sometimes they have use cases that we didn't even consider or they'll have a use case and we'll say, Oh well, we don't really handle that. You should maybe do it this way.

Olivier Colson: 26:32

And how do you validate the use cases? Is it like the product owner does his research or her research? I don't know and then gives the final feedback or you discuss it with the team first or.

Tiffany Chang: 26:44

Sometimes it's obvious and I just say we don't handle that. Other times I discuss it with my teammates. If it's something maybe more complicated than what I'm used to or it's part of the code that I don't touch as much, or I'll ask the product owner like, okay, does this make sense to do?

Olivier Colson: 26:59

Okay. Going back to the refactoring, is there another one you didn't mention yet?

Tiffany Chang: 27:03

Another one that I personally worked on was for the call to tenders and the purchase app was the call to tenders, which is when you want to buy something, but you want to see what different vendors will offer you in terms of price. And so it used to be that you had to create a call to tenders record and then you'd have to put the product and then you'd have to create each request for quotation separately. But now we've made it, so now it's just incorporated within a purchase order. So now you can just create a request for quotation, you can put in the product and then you can immediately click create an alternative. Okay? And that will let you choose another vendor and then it'll automatically plop in the same products so that you don't have to do it again. And then you can also add in extra products. So it could be that you want to see the price of different products from the same vendor, but you still want to compare one particular product or multiple products across different vendors. And now we also have a button so that you can compare them more easily within the same view. Before you had to kind of go back and forth between all the different requests for quotations and then see, okay, this guy is offering me this much, but I have to buy this many things like that, whereas now it'll just have it in one view and then you can click, I want this one, I don't want that one. Or when you go to confirm that you want to do that purchase order, then you can choose to cancel all the others or keep them and I'm going to change them later. Maybe I'll do something else or just pick specific products from it.

Olivier Colson: 28:26

This involves a lot of UI changes and really going deep into the interaction that the user will have with it. Did it require a lot of of back and forth prototyping discussions or was it because for this one I don't think it, it doesn't feel like it was obvious right to do it.

Tiffany Chang: 28:45

Yeah. But I think this is another one of those ones where Fabien was using it and said we can do this better. And then he said, Why are we doing this extra step? Let's just get rid of it and just do it all in one place. So and then I said, okay, I will do my best. And I did something and they were happy.

Olivier Colson: 28:59

Okay, good. First try. Yes, Well.

Tiffany Chang: 29:02

I'm a bit of a perfectionist, so I take a long time. But in the end, they're like, Oh yeah, it's pretty good.

Olivier Colson: 29:07

Good about your team now, how many people are doing all that?

Tiffany Chang: 29:12

So in our team we have 11 developers, including myself and two product owners.

Olivier Colson: 29:19

And that's not that much.

Tiffany Chang: 29:21

We also have other dedicated team members, for example, Bugfix and things like that as well.

Olivier Colson: 29:28

Okay. And how do you handle new people coming into the team? So you are saying that At Well, when you entered Odoo, it was a bit scary for newcomers to go into inventory and all that. How do you do now? So if I come and I have a newbie for you, I give it to you, it's yours. Do what you want. What is it good to work on?

Tiffany Chang: 29:49

So typically what we do for newbies is we put them on UI tests, UI, UX tests because they tend to be easier and it's more about finding where in the code they are and also if they do it wrong, it's not that big a deal.

Olivier Colson: 30:05

And yeah, it allows them getting more comfortable with the flows, I guess, and the models and just slightly, slightly starting touching it really from the inside and be like, okay, it's, it's not, it's not that dangerous in the end. Yes.

Tiffany Chang: 30:21

Often the challenge is figuring out where to go within the apps.

Olivier Colson: 30:24

You mentioned that there were two product owners handling the scope of your team. So first off, maybe we should start explaining what a product owner is because it's it's not self-explanatory. So what is a product owner?

Tiffany Chang: 30:37

So a product owner, they're typically the one who has more of the overarching view of what should the apps be doing. So they kind of focused on what should it functionally be doing and what does the customer want so that US developers can focus on the technical parts of how are we actually going to do this in the code?

Olivier Colson: 30:53

And just to be clear, your team is not the only one with product owners. Actually, every developer has at least one product owner working on his code that he can refer to and ask questions to, and that will say what needs to be done and explain the functional side of things. So it's very important. And so how does it work with yours?

Tiffany Chang: 31:16

So since we have two product owners, they split up the apps that they focus on. And for example, one of them says, We want to add in this new feature, but they haven't given enough details for me to implement it. Then I'll say, okay, well, how do we want to handle it in this case and what should it do? How should it look, things like that? Or I can also ask things such as, well, how would the customer do this? Because I have no idea how someone is going to be doing this manufacturing and they can say, Oh, well, in this case they would do something like this. And then at the end, they need to have their bar code and slap it on things like that. And for example, one of the things we had to do was print out the barcodes in a standard size. And we as developers, I have no idea that, okay, what.

Olivier Colson: 31:55

Is the standard size?

Tiffany Chang: 31:57

There's different ones, but there's one where it's four by 11 or I think it's four by 12 stickers. Maybe it might vary between the US and Europe as well.

Olivier Colson: 32:05

It's not something that everybody knows by heart. I agree.

Tiffany Chang: 32:08

Yes.

Olivier Colson: 32:09

Yeah. At least not when you're doing development. And that's true. That's the reason why we need product owners typically and I guess for yours there are like split by different apps because you're handling more than just one or how does it go?

Tiffany Chang: 32:23

Yes. So we have one product owner for handling everything involved with inventory. So inventory, purchase, and delivery connectors. And then we have another one that handles more of the manufacturing side. So manufacturing repairs, quality, things like that.

Olivier Colson: 32:37

And I think it's important like that. I don't know if it was like that when you entered Odoo, I guess not, because it was a long time ago and I'm not sure we had that many product owners.

Tiffany Chang: 32:46

Yes, back when I joined, we only had one product owner and they just handled all of the apps and they had to test every single task. And it was a lot of work for just one.

Olivier Colson: 32:54

It was necessary to spread the load a little bit. Yeah. And I mean, it's important because people don't always realize that, you know, when we're talking about apps, apps, apps, I'm talking about just development. But every app that Odoo is doing is handling a very different kind of business need. And so there is an industry with its own needs, its own challenges, and all different kinds of practices behind each of the apps. So it makes sense to have a product owner that can focus on each app and know what the different cases are. Otherwise, it's too much for just one human being. I guess so.

Tiffany Chang: 33:28

Yes, exactly.

Olivier Colson: 33:29

And so when a product owner is giving birth to a new task, how do you assign a developer to it?

Tiffany Chang: 33:37

So typically we look at how complex the problem is and then can the person handle it and are they interested in doing it? Because that's one of the nice things about the stock team is because we have so many different things that you can do and we're a very chill team. I think often once we feel like you're ready, you can just pick the task that you want to do.

Olivier Colson: 33:56

Okay, So it's really the developer is choosing what he's going to work on.

Tiffany Chang: 33:58

Yes, sometimes they might not be any fun tasks and you still have to do something you don't want to do, but at least you have some autonomy.

Olivier Colson: 34:06

And I guess doing it this way, you might also be more proud of the final result when you manage to solve the challenge, right?

Tiffany Chang: 34:15

Depending on how much you like your task. Yes.

Olivier Colson: 34:19

Even if it's like it. I mean, solving something you dislike is also also a victory. Yeah, sure. You're not convinced?

Tiffany Chang: 34:27

I've had my tasks that I really liked and my tasks that I really didn't like, so.

Olivier Colson: 34:30

Okay, so as a final word about all that, maybe it would be interesting to say why it's interesting to join your team. So I guess the autonomy and the fact that there are challenges and you can pick the things you're working, you're working on, are things you're going to talk about, are there other things why it's nice to work on on this field.

Tiffany Chang: 34:52

So for me personally, I think logistics is a bit of a nerdy topic, but I'm a big nerd.

Olivier Colson: 34:59

So you feel home? Yes.

Tiffany Chang: 35:01

Because the nice thing for me with logistics is I like thinking of lots of different use cases and flows that work very well because my background is more in math. So one of the things I was very good with when I studied math was I need to prove it for all these particular use cases. And once I prove it for all those we know, it's good. And I do essentially the same thing with logistics as well of, okay, let's make sure we handle all the use cases and then we know our code is good. We're going to be able to handle lots of use cases and people will be happy.

Olivier Colson: 35:30

Okay. That's interesting because people mentioning these kind of things usually will say, okay, I want to work on AI and do big computations and things like that. And it's very different here because it's really just engineering, but doing it step by step and having the structure. And if I get you. Well, that's, that's, that's the thing you like about it. For me.

Tiffany Chang: 35:47

Personally. Yes, that's good. And it's nice that we always have new challenges. So you never get bored as well.

Olivier Colson: 35:54

All right. Well, thank you very much for your answers. I guess we brushed a lot of different topics and I hope people really got the soul of the inventor team and the way you work and what you're producing, technically speaking. Thank you, Tiffany, for your answers.

Tiffany Chang: 36:10

Yeah, thanks for having me.

Olivier Colson: 36:12

And that's a wrap for this episode. Thank you for joining us. I hope you enjoyed this discussion about the way our developers manufacture our inventory suite. If you'd like to stay for further insightful tech and dev discussions, I suggest you listen to our episode about the accounting app. It was an exciting episode in the same vein as today's one. Until then, see you next time. Cheers.