Hey, everyone, in this video, we're going to be discussing tips for troubleshooting in programming. The biggest tip that I've got is to hire someone to do it for you, because it can be really frustrating. And I'm an impatient woman. But our team of software developers our experience in incorporating different test plans automated testing, manual testing throughout the process. And making sure that they use hypothesis testing as well, to ensure that each of the functions performed exactly as intended. And we do try to find robust design. So what are some of the non ideal conditions and what can go wrong, so that we can build that those in those situations into the features of the software? So using debuggers, there are pros and cons in this regard. You see exactly what your program does, and it shows you everything about the program. They can be useful for very basic simple what's of code if you're an entry level programmer or you're just trying to get the hang of things initially. But if you're building complex, data driven systems where you're gaining data from a wide range of sources. Geospatial information systems, Rf technologies, encrypted data, normalizing raw data sets and then trying to tie in data science with various sorts of complex graphic geos, graphical user interfaces and data modeling software. Using debuggers can be a real pain, so that's when using different tools that will allow for a lot more automated testing. But then also, strong manual testing between integrations will be key, and you need to do that a lot more often than a lot of software developers do, and earlier in the process. Because when you're pulling from all these different data sets, which are connected, sometimes connected to different servers, and you're operating in various different environments. Sometimes it can be very, very difficult to figure out what the exact problem is and then come up with a game plan of how to fix it. Here's an example of a debugging interface. So down the bottom, where you see where it says X watch, it's got the different panels where you can take a look. The variables, stacks, traces, templates, nodes, values. There are, I've used similar tools to this, which are, yeah, open source tools and open source tools definitely make it easier in different ways to be able to go through and debug the software in a cost effective sort of manner. But then you sometimes realize that the labor costs associated outweigh what it would have been to pay for a license. So one, this is why it's important when you do start to use open source technologies. Where are you going to be spending the money? Because ultimately a lot of it you get what you pay for. So either you're going to put the money into the licenses for the technology, which may be better. Or you may end up putting a lot of those resources into labor costs. So where do you weigh the pros and cons of different approaches? For me, I have switched away from paying labor costs and more towards licensing different tools because, I don't know to play well with others. No, I'm fine, but, it makes it easier to have a leaner shop to automate processes on the background in the back end and to ensure that quality controls are in place. Print statements and logging systems allows you to inspect data values and variables. This is especially useful when you're developing a design of experiments by testing the different variables and looking at the projected outcome for different shifts in the specifications of the independent variables that you plug in. And tracking the flow of data is, especially when you start to look at having secured systems and tying in cybersecurity principles into your software that can be also useful and being able to tie in. Also, malware analysis, software tools and running it through different programs can be useful. And make sure you do your research when you're selecting a tool on how different languages show up in different debuggers and different platforms. Because sometimes it might be a legitimate code, but it might be getting flagged as an error, and then you spend a lot more time doing manual work. So with bug trackers, initially, a text file can work. When you're looking at tracking and making modifications, it's also good to take, right. Make sure that you're examining or keeping track of the previous iterations of the software and using a tool such as subversion or maven for branching and being able to go back a step if you realize that a modification that's been made isn't working. Or if you realize that different variables are much better approaches because ultimately you do want your company and your product or concept to be versatile, adaptable and to be able to meet the customer's needs. And what the customer's needs are maybe something completely different than where they are 6 months from now. So being able to adapt and still get paid [LAUGH] Is a that's a really important for the feasibility of your company. So don't just look at the concept itself as an isolated sort of product. It's all part of a larger system, which has to do with your corporate operations and the ability to keep your cash flow going. Linter, perform static analysis on codes to recognize problem before the code is compiled or run can be used for style enforcement. This style enforcement is especially useful when you've got a fairly large development team where there is a science to it. And when you've got people creating the same function bit different ways, it can make the maintenance of the code very difficult and creates a lot more opportunities for errors because the software might not be picking up places where to make specific changes. So having uniformity and development styles in your team is key, and if you're not a software developer, then that's okay. You can find people find a good technical person who can help you with these principles ahead of time and who can analyze the code. And help come up with test plans and try not to be overwhelmed by it if it's not your specialty, because business is my forte and getting out the prototypes. But as far as the back end coding, I've got people for that and they're awesome at it. And I definitely depend on senior engineers to be able to go over the technical specifications, run the hypothesis testing and make sure that we hit all of the right marks because, you need to know what's in your wheelhouse and what's not. And going through code is definitely not something, I want in my wheelhouse, so back to version control software. It's good for individual or collaborative projects, when you start developing yourself if you do have an idea for software or building an application. And this applies to both new developers or people who are experienced. It's pretty common for people to take a very relaxed approach to the to the development of their prototypes. However, I like to develop a document everything from the very beginning. Because if we look at prototyping just from how we create the product or service that we're going to bring the market and not how it integrates with your business operations and your cash flow, then that's when we start to have a lot of inefficiencies. Redundancies in operations, quality control issues. The price gets all out of whack and way higher, and you're not able to be price competitively as you could be. Even if you are priced, your profit margins aren't going to be as great as you would appreciate. So keep track of things from the beginning. Keep different variations of the software because you may find okay. I've moved a bit too far in the wrong direction with this aspect, I need to pivot, move back and shift. Developing modules again, applying a lean UX methodology to software development applications providing services is. It's really the ideal way of being able to ensure that you can deliver what the customer wants and provides them with something that they are happy to pay for. Because again, when you start a company, it's not just about the product or concept. It's about the customer and what the customer wants to pay for. And once you're able to get the MVP out there and get that generating cash flow, then you can start to expand and reach into areas where your initial interest, may have been. So, from my experience, I really enjoy working with startups and launching new companies. And I'm passionate about brand new sorts of opportunities that arrived from shifting conditions and economic factors. Socio economic, all these funding that come out and but the thing is, there's not a lot of money in that. And well, not as much as there is in the field that I chose to go into. So, in order to get generating cash flow without investors, I took my company and IT, by doing software as a service and that generated the cash flow where then I could go back and start to look into developing new tools and expanding into markets. But establishing that cost for in the beginning gave me a lot more flexibility without having to depend on investors and answer to people, I always answered to the customer. Okay, documentation and code comments, again, even if initially, when you start playing around with some code and different ideas and building a prototype, keep documentation because you may feel that you've actually got something special. And then when you bring you more developers and you're trying to engage more people in the project, the truth of the matter is no one knows what you're thinking except for you. And it's never a good idea to expect people to be able to read your mind, or understand where you're coming from with different things. And this was a big learning experience for me because up until I started having W 2 employees, everyone was 10 99 and I did a lot of work myself. And then when I started, when I decided I wanted to, I decided I wanted an island by my 40th birthday, but when I expanded, I then assumed that everyone knew what I was thinking. But the truth of the matter was, I wasn't they weren't able to read my mind. So I then had to get used to developing out user experience, matt scripts, giving people an idea of how I would respond in a certain situation, how I would course correct set things right, what the price range would be and how I'd negotiate different aspects. So that way, my employees were able to effectively do what I did, how I did it without making assumptions. So keep documentation not just for your software but also for your processes, so that when you do start to grow and scale up, your people are able to hit the ground running instead of just like, what is this madwoman on about? I happened to be that mad woman someone's, okay, so developing modules apply a lean UX or agile methodology. Traditionally, a lot of those are used for software programs, but I found developing in modules when delivering a service. Or building out the corporate operations for your company, and how that integrates with the procurement process and supply chain and research and development. Developing in a modular system across the whole organization allows for better integration points and adaptions, as you need to scale up or scale down. And keeping good records and documentation is absolutely key. And I can tell you this from experience when you bring on overhead labor and people to help you. If they don't have the tools and resources that they need in order to do their job. You will absolutely feel it when you're if you're spending your own money on that, I guess that's where having investors may be a good idea. But for me, that was painful when I wasn't prepared enough bringing people on. And so, definitely make sure that you document out your processes, have good quantitative decision making trees branching and a way to bring everyone back into the process of going from A to Z. And that will also ensure that your quality controls are solid and in place as well, and that the customer can depend on what you're on the product or service you're offering. Thanks, bye
