John joined the meeting first today. He, Cory, and I went over some of his projects and where he is at. He has pushed up a number of smaller branches in the past few days. One of them had a number of JavaScript changes to the discount engine. He reported on that and then we switched over to servers and system admin stuff. John wants to document things but he is concerned with security keeping the procedures and processes out of the hands of those who shouldn't have them. We talked about some options for distributing and securing those documents.

John also reported on chasing other smaller bugs and putting out small fires. Going back to the key person, systems admin docs, currently, lots of things are hinging on certain key players and their knowledge. We need to capture that knowledge and put it in writing, as best we can. We also need to keep those documents in the high admin's hands vs public knowledge. Anyways, we will start going through things and collecting what we can, while having the security thoughts in front of us. We'll find a good mix.

After John finished, Alan checked in and let us know where he is at with his projects. He is still working on the new sub inventory object model code out in ecommerce land. He still has a few things left with that project. It's been a big lift. Also, he was saying that he currently can't pull that new code inside adilas (out of ecommerce land and into the main secure adilas platform) due to some legacy issues. Not insurmountable, but at least a decent amount of work.

One of the blockades is the number of black boxes and custom code that exist out there. We need to figure out a way to bring in the new code into the legacy system. Alan has a few ideas, but we may end up having modes (new and old) and being able to flip flop between those modes.

Some of the new stuff is more object oriented vs in-line code that runs from page to page but requires a certain step by step process or chain of events. Some of Alan's new stuff deals with objects and inheritance, less hits to the database, and all around more efficient code. It's all part of the process. You have to start somewhere and eventually, things tend to morph and/or mature, in logic and processes. It's all part of the game.

Alan was showing us and talking about some crazy tax calcs and recalcs and how the models and objects handle those changes. One of Alan's goals in this project is to stabilize some of the pieces and isolate the variables. In the new models, he watches and monitors things like quantities, target prices, costs, price per, rounding errors, taxes, etc. Pretty deep.

I thought that it was interesting to hear Alan say that one of the barriers to him finishing the project was the number of black boxes or custom code pieces that are out there. We love doing custom code and it really helps our users, however, there is a cost to that and it tends to hit our developers and how easily they can roll out those new changes. Basically, easier for the users, but potentially harder for our developers. Lots of moving pieces.

Cory and Alan were talking about MVP models for the new sub inventory pieces. We could jump off into super deep waters, but we need to get the project done. We can always circle back around.

After talking about sub inventory for awhile, the topic switched to Metrc (state tracking and compliance system). That 3rd party integration is more than a fulltime job. Anyways, they were talking about importing inventory, comparing inventories between systems, and other required interactions. Lots of moving pieces, plus you have two separate systems that work completely independent and we are trying to keep them synced up together. It can be very challenging. If they change something, we have to follow suite and/or create a bridge to what new requirements are needed. If we make a change, we have to make sure that we aren't breaking anything that already exists.

After Alan was done talking to Cory, he left and just Cory and I were left on the meeting. We started talking about how long certain projects take, how deep they are, and how they tend to morph from what was originally created into something completely new and different. This lead to some discussions on the complexity of being a public or publicly demanded company (our clients have a say in what we do, when, how much, why, etc.). Sometimes I wish that we were just developing our own little software solution and then we could just sell it to the public. Instead, we are building, changing, refining, and trying to please our clients along the way. That is ideal, but it also adds all kinds of pressure and other variables.

Cory and I got talking about real costs and what it takes to please people. We had a client that came up with an idea, it sounded easy, but has turned into a huge 4 month project and has cost us over $30,000. Sure they want it, but did they pay for it? Sadly, no, we are stuck with the bill. We tend to do that a lot. That hurts and especially if you keep doing it. We love to build and can get sucked into that very easily. Having said that, we are getting better at asking for seed monies, billing out the clients, and sharing the load. Sometimes we just need to vent a little bit.

As we were talking, my mind started to think about how hard it would be to fully rewrite the entire application that we are building. Don't get me wrong, I'd love to and I think we could come away with some huge benefits but there is a cost. Some of those costs are real costs with money, resources, talent, time, etc. What about the things that are harder to see like stress, pressure, demands, wear and tear, burnout, changes in physical ability, mental ability, and other unseen costs. What if we just try to build on what we have? That's what we are doing right now. What if we just kept going and didn't try to redo everything? Just keep refining, polishing, and tweaking things as needed. Still a lot of work, but it may be a better solution (at least right now). I was thinking about fracture (future project) and where we want to go with that project and those pieces.