You. Hi everybody. Welcome CTO. This talk at Conf 42. My name is Liran Haimovitch, and I'm the CTO and co founder of Rookout. Today I'll be talking about software understandability and what it means for us as software engineers. I'm an advocate of modern software methodologies such as agile, DevOps and Lean, which taught me a lot about understandability and the importance of that. And before founding, Rookout spent about a decade doing cybersecurity as a software engineer, team leader, product manager, and group manager. Rookout is a platform for live data collection and debugging, and rookout lets you collect any type of data on the fly with no extra coding, redeployments and restarts. Working with engineers or using rookout to debug various problems to learn more about their software and CTO get things done, we became exposed the concept of understandability, and understandability is so very important. I'm sure many of you software engineers are familiar with the mundane tasks of the basic stuff, like read a JSON from file and parse it and verify it, or solve a data structure. And those are so basic stuff we've been doing since day one, since the first lessons in intro to computer sciences. And yet, if you gain the similar task in a very large system, in a very complex system, sort a data structure within a database or within an output, all of a sudden, the same very simple task can take days or even weeks, because there are so many intricacies and so many connections, and quite often what's making it so complex. It's not even that the task itself is complex or long. It's the fact that you actually have to spend so much time trying to understand how to do it, trying to understand where to do it, and trying to understand how does it comprise with the entire system, and that's understandability. How do we manage the complexity of the tasks? How do we walk our way through it? I love this quote by George Bernard Chow where he's saying imagination is the beginning of creates you imagine what you desire, you will what you imagine, and at last, you create what you will. Now, this quote is nowhere true, has much as it is in software engineering. Imagination is truly the limit for so much of what we can do. There is so much, it always surprises me how much we can achieve using software engineering. And yet we get this report by the DJ who's saying 68 of organizations experience flying blind or trying slow. So while imagination might be the limit of what we can do, sometimes we find ourselves achieving it very very slowly, and that's a big problem. You either fly slow because you're trying to keep things certain, trying to slowly understand, or you fly blind without understanding, tracking potentially dangerous changes without knowing the impact. This is where software understandability comes into play. The term understandability we draw from the finance industry, but it was originally about having service providers such as insurance providers and pensions funds empower their consumers to read the reports they're sending out. And drawing upon that definition, we define understandability as the concept that a system should be presented so that can engineer can easily comprehend it, essentially how hard or easy it is for you to understand the system in front of you. Now keep in mind, a software application is comprehend of many things. Obviously you have source code and that's the first thing you're going to think of. But there is so much more that goes into creating an application as it makes into having the application run. You have the configuration and state whether it's stored in a database or in a file or anywhere else. You have the runtime environment, whether it's a cloud environment. Youre have the various node or Java functions that are running your application. Are you using spring boot? Are you using micronaut? Are you running within a weblogic server? There are so many different options, as I'm sure you arent all well familiar with. Each of those make a very significant difference to how the same code plays out. We have the service dependencies, whether it's open youre and closed source dependencies within our code, or it can be other dependencies, other microservices within our organization, or even third party dependencies such as stripe. Potentially most important, hardest to predict inputs and outputs of the system. Our system doesn't walk in a void, and the way our clients interact with it are going to make a huge difference. Think about it. You're seeing an endpoint that receives JSon as an input. That JSon can be virtually anything, and only by knowing the expected input of the system can you truly make sense of the function that handles that input. Only by truly understand all of those five elements can we understand our software and operate it and maintain it accordingly. How do we know if a software is understandable or not? So there are four criteria we're drawing again from the finance industry. The software has to be complete. The information we have has to be complete. We need to have full access, CTO, the source code to input examples and so on and so forth. We need information to be concise. Just because there are a million lines of code doesn't mean we can go tough, all of them. We need some sort of summary, shorter presentations that we can go through. We also need information to be clear. We need those summaries. We need those snapshots to be made very clear. We obviously want the full source code as well to be cleared and documented, and we want everything to be organized. We want to be able to shift from the short summary to deeper summaries to the source code itself. We want to be able to easily shift from source code to input samples that show us how it's going to be used and to example configuration that shows how it's going to be configured in production. Once we have documentation on the system, once we have the information about the system available in a complete, concise, clear and organized manner, then we can go ahead and say the system is understandable. You might be wondering about a few other terms out there that you might have heard that might come to term, so let's think them through. Understandability is closely related, but it's not complexity. Obviously a more complex system is going to be harder to understand, and a less complex system is going to be easier to understand. And yet at the same time think about this way. I can provide you with a script that Java application is going to be about reading a file. I can either provide you with a jar. Ready? Here's the jar. Go ahead and tell me what it's doing, or I can provide you with the jar and the youre code and documentation and input examples. Obviously it's going to be much, much easier to understand the same application with the full package, even though it's just as complex. Second, we can think about readability youre we want the source code to be readable of youre. We want the documentation to be readable. And that's going to have a clear impact, a very big impact on the clarity criteria which we've just defined. But just because something is readable doesn't mean it's complete, doesn't mean it's concise, doesn't necessarily mean it's organized. And there is much beyond readability to understandability. And last but not least, we have observability. Observability is a term used often to define how we monitor the system in production. How do we know if it's up or down, if it's serving our customers or not? And understandability goes a step back. It's not about just whether the system is up or down, whether it's working properly. It's about how it's working, why it's working, and what's it doing all of those three elements very much interact with understandability more often than not. By improving complexity, readability and observability, we're going to improve understandability as well. But that's not always an option and that's not always the best approach to improve understandability. How do we go about improving understandability? There are five key ways I like to point out for improving understandability. The first, which I kind of briefly touched on, is minimizing complexity by creating a less complex application that is going to be less to understand, making everybody lives easier from the first time we were introduced to software engineers through any experience, everything we're taught in many ways is but minimizing complexity. So you start out by cutting back on requirements. The less you have to do, the less complex it's going to be. This applies to both functional requirements, what the system is going to do, as well as to nonfunctional requirements, how it's going to do it, nonfunctional requirements such has availability, security, performance, arent all going to have a significant impact on complexity as well. Hire the best developers. Better developers are going to find simpler solutions to the same problem, reducing the complexity of the solution. Utilize the highest level building blocks by using cloud, by using open source software, by using prepared solutions, you are offloading much of the complexity to somebody else and creating a simpler, neater solution. Overall with better abstractions, apply software engineering principles such as encapsulation, such as abstractions are all there exactly for that purpose, to minimize complexity and to make it more manageable. And last but not least, practice agile and DevOps. Build a software step by step to make sure you only introduce complexity where it's necessary and avoid over engineering and over planning, while at the same time make sure to reduce tech debt and keep the system understandable. Keep the system simple as issues crop up. And by going through all of those five elements, you're going to minimize complexity. Unfortunately, there is a big drawback here. All of those are very, fairly easy to do or fairly straightforward to do when you're developing a new systems, and you can take all of those into account. But unfortunately, when you were working with an existing system, one that has been around for 510 or even 20 years, making those changes is so much harder. I mean, you can't cut back on requirements on a system that has been written for 20 years, and you can't change the engineering team who originally wrote it. Naturally, you can and should strive to make those changes long term, even for existing software. As long as you're tracking with it. But that's a much harder journey. So what we can do is we can create knowledge, we can curate knowledge, we can build the knowledge around what's already there to make it easier to understand, to make the knowledge accessible. Start out by learning about the system. Chat with your colleagues. Find previous engineers who work on the system who formally walked in the system and learn from them. Buy them a cup of coffee, read through the source code, go through production, collect has much information as you can. As you collect this information, make sure to document it, write it down, record your conversations, whatever it takes, so that both for yourself and for others, some of that knowledge is going to be captured in a way that's easier to understand. And then go ahead and share that information. Give talks, write it, create tutorials, have meetups, whatever you need to do internally so that knowledge spreads. And keep in mind that as you share the knowledge, youre probably going to get feedback, you're going CTo get corrections, youre going CTO get new insights and you might even get new questions that should be answered. But over time, as you practice these three steps, learning, documenting and sharing, you're going to create a body of knowledge. And this body of knowledge is going to significantly help you handling that complexity and making things more understandable. Third on our list, we have development environments. Nothing allows us better to understand things than blind able to take them apart and put them back together in a sandbox. Now, development environments have a few important criteria to make them effective. The first, you have to replicate your tech stack. If youre using Java twelve in production, which you probably shouldn't because it's not a long term support version. So let's say Java Eleven. If you're using Java eleven in production, make youre to use Java Eleven in the development environment. Don't go for Java 14 or Java eight. They're going to behave differently. Use the same companies, the same open source, comprehend the same operating system, use the same database, everything you can replicate, replicate it. If you can replicate the scale, do that as well. Second, use high quality test data. We've mentioned it before, configuration, state, input and output. The more youre can get them from the production environment, the better it's going to be for you. The more you're going to learn about how the system is actually going to operate rather than just running the code with dummy data and getting results that may or may not matter. Keep in mind that today, with compliance and security, using production data for testing and development is a big problem and there are ways to generate fake data and there are ways to buy data and create it, but it's a big problem for many of our customers. And keep in mind that this is not a one time process. Environments drift as you introduce new databases to production. As you make upgrades to production, you have to make those in the development environments as well. As you create new APIs, you need to make sure those APIs have input examples has well, the way the software is used changes, you have to adapt the input samples you use to reflect that as well. And overall, this can be quite a lot of work, both setting up the development environment and maintaining it. It can take a lot of effort, but it's a great tool that will help you improve the understandability of your software. Next, we have observability tools. As I mentioned, observability tools show us the state of the system and not so much exactly what it's doing and why, but it can definitely provide us with some insights in what's going on that we can use. And so if your organization uses observability tools such as logging, tracing, metrics and error tracking, then you should definitely ask to have access to them so that you'll be able CTO use them. They're not going to provide you with all the information you need. But often if you're asking yourself what's happening, a log or a metric or an exception you can track, that can all provide you with some visibility into what's going on and help youre make better educated guests. Now last and definitely not least, we have tools that are always there to help us understand our software better. I like to categorize them as understandability tools, but I guess most of you would categorize them as debuggers. Traditional debuggers have always been about enabling us to understand our software. You run your application and then the debuggers allow you CTO take it step by step and see what's going on. They allow you to go back and see what's going on. They even allow you to inject variables, change values, and so you can literally explore the application as it's running and truly understand its inert. Unfortunately, traditional debuggers are not so good today for many of youre environments. If youre working on kubernetes, if youre working on serverless, if you're working on a very large monolithic applications, if you want to see what's going on in production, traditional debuggers are not going to be there for you. Fortunately, next generation debuggers such as rookout allow you to take the debugger experience and use it anywhere. Next generation debuggers support debugging in kubernetes, in serverless, in production, regardless of the scale, regardless of the size. Using nonbreaking breakpoints, you can go anywhere you want and see exactly how your code is behaving. Now, whether you prefer the traditional debuggers or the next generation debuggers, those are definitely the best options for engineers looking to quickly understand their software. And I think the biggest benefits of that is how easy it is to set up youre can get started in a matter of minutes and get real insight into existing applications without overly worrying about what's going on. I hope this talk has been beneficial for you. I hope you learned a bit about the importance of understandability as well as what can be done to improve it and why you should care. And I would love to hear from you whether on Twitter or on GitHub. So please reach out to me and I would love to continue CTO discussion and maybe show you a bit about truecode. Thank you very much.