 Hello everyone. I am Mishari Mukbil. I have a consultancy company called Simple. We help companies with digital transformation. What does that mean? That means if you're not using a calculator, it's probably about time you have one, like our Buddies in the Election Commission. So when I go through these projects with my clients, quite often it is after the fact that their software or IT project has failed spectacularly. And many people ask me why. Why are our software projects failing? So I had prepared this slide initially to show people, decision makers, why it is that they are in the condition that they are. So as geeks, I hope that also you get to learn a thing or two about how to communicate effectively to stakeholders. So computers, right? In the span of two or three generations, we went from this kind of setup to something very, very small. And the amount of CPU power in the computers has increased a billion times, right? I mean, there is nothing else that we have that has evolved so rapidly. For example, building a bridge. We have essentially been building bridges the same way for the last few thousand years. Can you imagine building software like that? It's as if all of a sudden within three generations we went from bricks to carbon nanotubes, right? So here's a quote, as you probably know about the US sanctions on Huawei, right? Look at this part. The company's software engineering is like something from 20 years ago. 20 years ago, we're still building bridges like we did 20 years ago, right? But then if you build software like you did 20 years ago, it is a major, major flaw, right? What else? When I went to university, my university had a $47 million software project that failed. Hertz as well has their own horror story. $32 million in a software project that failed. $440 million lost in 30 minutes. And of course, there is the Arianna 5 rocket disaster also because of defective software. And of course, our favorite blue screen in Microsoft. They make great products these days, by the way, since they support open source software. So there's been a lot of soul searching, right? We really don't know how to do software very well because there's no built up knowledge. There's no lore that passes on from one generation to the other because it's only been three generations. And with every generation, the technological leap has been light years ahead. However, we are starting to see some truths which seem to hold. So this is the Mythical Man Month. I recommend it to anyone who is about to embark on a software project. It was written in 1975 and much that is written in that book still holds true today. So if it has held true for 25 years, it's like the Old Testament or the works of Plato. It will in about, sorry, not 25 years, over 30 years. It will probably continue to hold true in another 30 years. So here are some highlights. Adding manpower to a late software project makes it later. As time passes, the system becomes less and less well ordered. Sooner or later, fixing ceases to gain any ground. Each forward step is matched by a backward one and at the end, a brand new from the ground, a redesign is necessary. So who's had to face this? Who has had to rewrite your software? Yes, don't be shy. It happens to the best of us. This was in 1995. You're not doing anything wrong. This is the very nature of writing software. The software architecture, the way that the software design and put together tends to reflect the organization that wrote it. So how do we solve some of these problems? The first thing that I always like to say is that when you embark on a software project is to focus on value. What do I mean? In a company, when you design software, there's probably a whole bunch of considerations about what features you need to work on first. Ultimately, I say the decisions become much easier if you start from the perspective of the customer or the final end user and work your way back. And that is why I absolutely love open source software because as a customer or as an end user, you can participate in the process of developing the software and making it work for you. Another thing that I always say that people should do is see it, touch it and do an MVP. This is a project that I worked on earlier, ELECT.IN.TH. From conception to finish, the project took nine days. One of the first things that we did in ELECT was to come out with a mock-up of the GUI. We put it out there and we tried to understand how using this product was like from the perspective of the users. Recently, I was looking at a software project where it has been three years and the end user has no idea of what the final product is going to look like. This should be up from day one, right? So an MVP is basically an incremental process like this. So you start from a basic beginning to see whether the concept works and you work your way up. Frequent direct feedback. This is also very important. There's a bunch of ways people do it. Before software engineering used to work in a waterfall process where the requirements came at the beginning and the verification came all the way at the end. That is a recipe for a failing software project. So there's a bunch of systems that people have talked about over the time. There is an Observe Orient Decide Act. There is... I can't remember which way this went. Check, act, plan, check two. So there's going to be a few feedback loops. The entire idea is that each iteration is very fast. It's one week, it's two weeks. But people need feedback about how the... Developers need feedback about how the software is working. Because at every cycle of the feedback loop, new ideas come out about how the software is used. And then priorities will change as you learn about what the tools can do for you, right? Ultimately, it should feel... The feedback loop should feel a little like a bicycle where the input comes in. And that in terms develops the software, which ultimately will take you towards the direction. So a really good software project really does feel a lot like riding a bicycle. This is important. Write code to test code. I barely ever see this done. So when you have your codes written, when you have your code up and running, you basically have no idea how it's doing. There's no metrics, no system to actually tell you about the health of your code, right? When you have machineries in factory, there's always some sort of gauge, a mechanical system that tests a mechanical system. But then in code, it's getting more popular. But then in the overall scheme of things, it's still pretty rare. And when you write code without any form of instrumentation, then it feels... It is very much like playing Jenga. You don't know which change in the code is going to bring your entire system crashing down, right? Embrace change. The reason I say this is because whenever code is written, whenever you have a software product, it's like the discovery of something like iron. You discover iron, you discover how to melt it, then all of a sudden you have a hammer. You can use that hammer to then develop other things. And so you may embark on a software project, and then suddenly you realize that you have the equivalent of a hammer that you can use, which you can then apply it to many other parts of your organization. So priorities are always changing when people see what good software can do for their teams and their organization. So which is why I always say be ready to change after you start seeing the MVP. Design for operations. Who here does operations? SK, I know you do. Yay. So the poor operations people are in charge of keeping everything up and running. And often the software developers and the operation people have not talked to each other. The RMIT system, for example, earlier, the software was written. Everything is fine. They deployed it, which means that the operation people took it and started running it. Then they realized that the entire system could only support seven simultaneous users in a university with several thousands. They deployed it, everything came crashing down. And they could never recover it for it. So if you actually design with operations in mind from the beginning, you can avoid that kind of failure. Also, I think that the night capital example is also an example of failure in operations as well. And lastly, what I always say is as much as possible, open all the sources. The reason for this is because when you build software and you make it open source, two things happen. First of all, you think about abstractions. You think about the things that are important for your organization and you think about the things that are just important in general. So what you get are these generic pieces of software which you can then release and you can attract other people to come in and help you develop your software, help you check it for bugs, and perhaps give you valuable feedback about how your third-party contractors writing the software are doing. It makes it secure. Yes, it's harder, but I think that the payoffs for what you get when you open your source code is huge. And which is why I absolutely love ForceAsia, right? Because it's just this environment of people who are getting together to write software, who are contributing software to the public, who are talking about software and who are really pushing the boundaries of what software can do and what it is all about. So lastly, so it is not all doom and gloom, right? You see in this room, there are probably a hundred pieces of software running from your watches to the laptops, to the projector screen, to the audio, video room. So gradually, Mark Anderson says, software is eating the world. And we have had many, many examples of successes in software projects, as we can see before you. So let's learn from it and let's create some great software, let's release it so everyone can benefit and learn from it. So with that, I conclude my talk. Thank you very much. Thank you, Charlie. Thank you very much.