Good morning. My name is Atul Jitnis and as you can see, I'm neither lean nor agile. In fact, I asked myself what I'm doing over here until I realized that most development, everyone here is talking about development of software or products of some sort. And the end result is a product. And that I may be neither lean nor agile nor am I actually a developer anymore. But that is something I know a little bit about, especially here in India and that's what I'm going to be talking about for the next hour or so. So the first thing you should know is I don't write code. I absolutely haven't written any code since maybe the mid-1990s. The reason is because I don't write code, I write people. Which does not necessarily mean that I go around telling people the meaning of life and things like that. Instead, what I do is I mentor people, especially developers, when they want to develop something or the other, especially products which are supposed to go out into the mass market. What I'm going to be doing today is I'm going to take you through a brief history of the product market as I have perceived it over the past few years. Look at the current state and look at what needs to be done. Now why am I doing this? The reason why I'm doing this is because some of you will have noticed, in fact many people have noticed, there aren't really too many products coming out of India. Now one thing upfront, especially because I see a lot of people who are from outside India, let me make it clear that my focus is on India. I specifically focus on developers in India who want to develop products and tackle both the Indian as well as the international markets. So let me talk about the early days. Why am I qualified to talk about this at all? The reason is because India has gone through various phases as far as product development is concerned. And these phases have unfortunately not always been positive. There have been negative phases as well. In fact, we are just coming out of a negative phase. But there was a very strong phase, a positive phase which was in the mid-1980s. This is about the time when I got started on this. I came to Bangalore in 1986 and as usually a young graduate started looking for things to do. And one of the things that I wanted to do very badly was develop software products. The problem was you have to understand what India was like in the 1980s. Software was not something people bought. Software was something that people got along with their hardware. And it was really a shame that when you try to create a piece of software and try to sell it to someone, they say why should I pay money for software? It's really discouraging especially if you are a product developer. So we decided to take an approach that was slightly different from what you would have expected. This next photograph is going to take at least one person in the room slightly off by surprise. So this is us in 1987. And you will notice that there are posters hanging behind there. Talking about each of our little products, there's some more on this side. That's my wife. We had just gotten married that year and there's about half of me on the right side. And my partners at that time, partners and my mentors, I was very lucky to have really good people working with me all the time. The one thing that we realized is what we needed very badly is exposure. We needed people to not only want to use our products, but we needed people to know about us in first place. And then be willing to spend whatever money we were asking for our products. You can see we have a very customer oriented, like you can see the poster over there which says we are not number one. And below that it says our customers are. So very Apple style approach long before Apple came into the picture. But what was important and what was the, I would call the stunt that we had to pull to get people to even want to use our software. Was that we decided to take each of these packages, price them at 100 rupees, which was at that time something like about $10. And put them on a single disc kit, manual with a printed manual along with that. And our catch phrase was that if you cannot afford to buy our software, you're either completely broke or a total criminal. Surprisingly, this worked. And this is the stall that you see over there was at an exhibition that took place in the Taj hotel nearby. And we couldn't keep up with people wanting to buy our software, which was a really weird kind of situation. Like I had described people weren't buying software in those days, but they wanted to buy our software. And then companies started ordering, you know, we got one order from, I remember this, I get a letter sitting in the office. I opened that letter and it's a purchase order for 500 copies of each of our pieces of software from a company in Goa. That was mind boggling. You know, we probably spent more money on replacing floppy disk drives for copying those software packages onto the floppy. Then we were making in the bargain. But that wasn't important. Important for us was people wanted our software. And more important, they wanted our software. We were clearly an Indian company. And it really worked out well. If it wouldn't have happened, what we did at that time wouldn't have worked. A lot of us would have been in a very different situation today. I probably wouldn't be so lean and agile as I am now. But it gave us an, you know, encouragement. It gave us what we needed to do to move on to 1989. In 1989, we had now more packages. We were selling more packages. And it was really great.  Banks were picking up our packages by the hundreds. People were constantly sending in orders. We weren't really making that much money yet. In 1989, we participated in another exhibition, which was at that time the biggest computer-oriented exhibition that took place in India. Which called the Computer Society of India Annual Expo. Which was that year in Bangalore. And we took a stall. We took two stalls actually. And we were showing our stuff over there. And one problem that we had at that time was that we needed to gather information. As we were gathering information, market information, people coming in, putting in inquiries and all that. We really didn't want to have somebody sit over there and then, you know, type in all the stuff or, you know, take the visiting cards or get people to write in the address book and all that. So we had a machine in the corner where people would go and either type in their requirements, quickly put in their stuff. In those days, hardly anyone had an email address. I think in the entire exhibition, I was the only person who had an email address at that time. So we didn't ask people for the email address, but we did ask them for their telephone numbers, fax numbers, things like that. They would type all that stuff in. And then somebody comes to me and asks, how are you doing this? What are you doing? What's happening to this data? So is it all going on to the disk over there? And we said, no, I mean, there's a telephone line over here. And we have got a system running in the office. And what's happening in the office is, I mean, you're actually connected to our office over there. You know, as you're typing in the stuff over there, it gets saved over there. What we had running over there was what was known popularly in those days as oblivious. Now, we didn't think that much of it. It was a necessity. We required it. We needed it. And this is where you have an example how what you thought would happen is not really what would happen. We finished the exhibition on the fifth day. It was a five-day long exhibition. And we were pretty dead by the end of that. And the next day morning, we come to the office. Outside our office door was a gentleman. We were on the first floor. He was sitting on the steps. Baldish gentleman was a bit confused on what was he doing over there, but clearly somebody who was from the enterprise side of life. And he said, are you the Constellation guys? Yeah. You were doing something at the exhibition over the past five days. And we want that. So I asked, what is it? What is this about? Turns out this gentleman was from a company called ABB, one of the largest electrical equipment giants worldwide. And they had a problem. They had dealers all over the world, distributors, but those people were all electronically connected. But in India, there were two things that they didn't have. Functional telephone lines and any system that was available locally that could allow their distributors and dealers in India to connect back to ABB, put in orders or get information that they required, do database searches, catalog searches and things like that. That's what they wanted. And our little system was called CIX, it was called Cyber Information Exchange, big name, whatever. It was called a BBS. And we said, well, yeah, we have that system. He said, will you sell it to us? And you know something? We didn't realize that we had a product on our hands because that software that was running over there was something we had developed in-house for ourselves because we needed it. But we never realized that somebody else would need it as well. What happened that morning changed our lives completely. So by 1990, which was literally a month later, this exhibition was in November 1989, and a month later, we had an agreement with ABB to set up their stuff. What we didn't have was a name, so we gave it a name, we called it CyberNet.  And we figured out that they needed a lot more than just the software, but then the hardware was missing and they needed modems. And then the telephone lines went really up to scratch over here. People used to laugh when we used to say, oh, we are doing stuff over Indian telephone lines. They said you can't hold a proper telephone conversation over Indian telephone lines. What are you going to do sending data? But things were changing, technology was changing in those days and you were getting error correcting modems and a lot of stuff was happening at that time, which made this feasible. Over the next few years, we were supplying software to virtually every single large company in the country. Whether you're talking about ABB, who was our first guy, I'm an automated ACC, the largest cement producer in the country, CyberMedia, the largest, you know, the people who choose data quest, et cetera. Stock exchanges, Indian Aluminium, there was a huge long list. And what that experience taught us was there's a market everywhere and people were willing to pay for products. As long as those products did what you, you know, solve the problem for them. Now over the, during that time, we weren't the only ones who were producing products and who were trying to crack into the product market. One other company, actually there were two other companies whom you may have known, heard of before, and one of them was a company called Tali. Bharat Goenka, who had a very similar situation, developed an accounting system for a client who needed something in Calcutta. And the way he created that product, he suddenly found a lot of people wanting to do precisely the same thing that he had done over there and he, what was earlier known as PFA, the Putronics Financial Accountant became Tali, India's best selling product to this day. I mean this product doesn't have any competition in India. And now it's, well, you know, it's being sold in the UK, in South Africa, in various places. It had all sorts of things that people had never seen before. You didn't have to remember any codes, you didn't have to do anything. You could just type out in plain English what it was, oh, 5,000 rupees towards, et cetera, et cetera. You just type it out in plain English and the system would figure out what needed to be done. He did this, he had created this because there was a need for it because his client in Calcutta didn't have trained computer people over there. They could type, they could speak English, but they weren't going to be sitting down and learning codes and, you know, see 3,000, 512, 5,000, slash, slash, slash. You know, that's how accounting systems used to run in those days. So he had to find a way in which people could use his software without having to learn something that would put them off completely. And that's how Tali was created. On the other side of the spectrum, there was a company called Knoxware. They did something that was rather amazing. If you look at the time of the 1990s, it is famous for something else as well. It's famous for the concept of computer viruses. Now, a lot of people came up with, I think, and most of these viruses what they used to do right at the boot sector of the machine, and that was the end of it.  And after that, the virus could do whatever. You shove in a floppy or you had another disk or you connected to anything, it would go and infect the other machines as well. Knoxware faced exactly the same problem. Now, they were doing something else at that time. They were the IT division of another company, but they needed to protect themselves. So they came up with a completely different solution. Lots of us have heard about the concept of anti-virus software, which is still being used today and slowing down machines all over the world. What Knoxware did is they realized that since most of the viruses used to go and sit in the boot sector, and infect the boot sector, you have to be able to protect the machine before it even boots. So what Knoxware did is they created an add-on card with a ROM on it and with some software on it, which would be invoked before the machine booted. Now, again, this was something they had done for themselves, but I was a personal witness to see how that thing, it was such a problem for people. There was no such thing as an uninfected PC anymore, anywhere in India, especially with the amount of pirated software that's going around. And when they came up with the solution that worked, it didn't slow down the machine, it would just sit over there, but every time a virus would try to go and infect the boot sector or install itself, it was there to stop the thing and make sure it didn't happen. These people started... There was a huge demand for this, and people started asking for these cards called the Knox card in such great quantities that this company couldn't keep up with the demand. In fact, at one point, they almost went bankrupt for a simple reason, they couldn't produce the product fast enough. Now, again, remember, this is a time when people still weren't buying software. Now, you remember the 100 rupees thing that we were selling at one time? We went from 100 rupees per application. The application which I talked about earlier, CyberNet, which was a corporate communications host, it went from 100 rupees to 100,000 rupees. And people were still willing to buy it, so much for the concept of people not wanting to buy software in India. Unfortunately, those were the heydays of Indian products. What we saw coming after that was a severe decline. Almost every software or technical product company in the country, except very few, like Tali, went out of business, started doing something else, and that something else was rather scary. So what happened basically is that between 1995 and 2000, 2001, we had something that all of you are very familiar with, it's known as the bubble, where people abroad, in the US, in Europe, suddenly saw a market for technical products, technology products, which they could, as long as they could produce something, they would get something known as funding. And funding was the big game. It wasn't revenues, it was funding. And so we went through the five years of 1995 to 2001, and then the bubble burst. And all of a sudden... Now what happened in India in the meantime is everyone stopped doing what they were doing, and they were catering to companies abroad, because they needed to have products or needed to have something or the other, and they didn't have the wherewithal or the resources abroad to get the stuff done. So they were looking at countries like India to get the stuff done. And when the bubble burst, which was unfortunately, though it's not exactly because of this, but around the 9-11 time in 2001, that we actually came to a situation where there suddenly wasn't any business anymore. You see, what had happened is a completely new and, I would say, rather ghastly thing had happened to the concept of product development in India. It had given way to something known as outsourcing. And outsourcing was the death of products in India for almost 10 years. Why? Because the Indian government decided to encourage software exports. Of course, there was no software export as such. What was really happening is cheap labor. So I have friends who used to sit and they used to get instructions from their managers saying, okay, give me 600 lines of code by morning. Okay, what are the 600 lines of code supposed to do? That doesn't matter. We get paid by the line of code. Now you can, if that was the state of what developers were being exposed to at that time, you can imagine what was happening to products around here. They just knows that I didn't disappear. Almost every single product company was out and was no longer doing anything. Pretty sad situation, even worse. It created something that we are feeling the repercussions of even today. You see, because outsourcing was so popular, a number of international companies started setting up their businesses or their branches here in India so that they could get stuff done under their control. The Yahoo's, the Amazon, just about every big name you can think of came over here, including Microsoft set up in Hyderabad, Yahoo set up in Bangalore, and they started hiring as if there was no tomorrow. They started hiring people at A in same salaries and B, virtually no qualifications. Because what they were doing is they were hiring fresh graduates out of college. They were hiring them even while they were still in their final year of engineering, giving them a career path, which of course is always welcome. People always like to earn money, especially here in India. And I remember this one time when I was in 2001, 2002, my wife and I had gone to dinner at Windsor Manor. And when we stepped out, I went to get my car and there were three people standing next to me, very young guys. One of them I knew. He didn't recognize me but I knew him because I had given a talk in his college. He had just graduated the year before. So this guy goes and gets his car. A really fancy car. One of those big, you know, flashy things, fully loaded as they say. And he got in his car and wave goodbye to his friends and his friends then went and got their cars equally flashy. That was the amount of money that was going into getting people to drop everything else that they had planned for their lives and go and write code. But not create products. They would be given instructions. Do this. Okay, don't ask any questions. Don't ask where this code is supposed to go, what it is supposed to do, what's a big picture of things. Within the next five years, what happened very, very sadly is that people lost the whole idea of what a product is all about. I know. I have dealt with these people. It is one of the biggest tragedies I saw happening. India had the largest pool of technically qualified English-speaking people in the world. And I'm talking about a pool larger than it was available in the USA or in Europe. English-speaking. Yet there wasn't a single product being developed in the country. Every time you go and ask people, why are you wasting your time writing code for other people? Why aren't you creating something on your own? The answer would be, well, got your money. And anyway, we don't know anything about this product development and all that. People abroad know better. What we saw was a development of a mindset that told these people that they don't know enough to do anything. That was really sad because what you saw was a bunch of really talented people. And I know. I have dealt with them. I've gone and spoken at their colleges. I've gone and taught at their colleges. I have dealt with them in various user groups. I was very heavily involved in the free and open source software and the Linux thing. I was dealing with these people. Some of these people are really brilliant, but they would refuse to use those brains to create products. That brings us to what I would call the present, which is unfortunately not that much better, but things have certainly changed a lot. What happened in 2005 is that the whole concept of mobility started. Mobile applications. And there was suddenly a market for something that wasn't PC-oriented. What happened between the 1980s and the mid-2000s was that all software development was basically PC-oriented. And that was completely ruled by the world abroad. But when it came to mobile stuff, we were in a situation that was slightly different from what people were used to in the US. We leapfrogged the entire concept of mobile communications. We never had an analog cellular system, for example, over here. We went directly for digital. We went from landlines where you could barely make a phone call, never mind being able to get data across, to cellular communications on GSM within one year. Today, the concept of a landline is almost dead around here. The only reason why people still get landlines is because they want to get an internet connection, a terrestrial internet connection, ADSL or whatever. Even that is becoming kind of a rarity. But what came along with this entire thing was the awareness that here is a market that we understood better. It was technologies that we knew better and there were opportunities over here that were begging to be exploited. In 2005, I began seeing people slowly working two shifts, daytime working at Yahoo, Google, Amazon, whatever, and at night, sitting at home and developing mobile products. All of a sudden, I was heavily involved with mobile stuff already for the past five years. In those days, I used to use a Palm OS-based phone which had, to its distinction, a lot of applications available for it. I was surprised to find out that many of these applications were being developed, products were being developed by companies here in India. This was something I wasn't going to let go. I had spent the past 10 years or so in consulting, but I always had this itch getting back into product development which I had kind of abandoned by the mid-1990s. I didn't get back into it. I joined a company at that time which was developing products. The basic itch was I wanted to create products. Not only did I want to create products, I wanted to see other people to do so as well because I realized something over time. As people were developing each little small application, they were gaining more and more confidence. They were gaining confidence that they could do something that other people wanted. The same kind of thing that I experienced in the late 1980s and which completely disappeared after that, they were beginning to experience that. Today, we have got people sitting virtually on every corner. You can't throw a stone in Bangalore without hitting a mobile software developer. Every second one of them has got ambitions or is already in the process of creating products of their own. Now, how do you take it from there? The problem was that people had lost the art of product development. Also, there were a lot of stories that were coming in from abroad or even in the Indian commercial markets. I would say they had lost sight of the rules of engagement. The rules of engagement are fairly clear. Unfortunately, you'll be surprised how few people actually understand this. First of all, when you develop a product, it isn't just about creating a piece of technology and dumping it out there. It's about revenues. You'll be surprised how many people disregard this completely. Oh, that's not necessary. I will be putting out my product for free so I don't have to worry about revenues. I wonder how they plan to pay the bills. But this is the primary thing. It's about revenues. And if you're talking about revenues, it means that what I did in 1987 is still true today. You've got to reach out to your markets. You've got to have a way of reaching people so that they will want the stuff that you are creating. And then they will spend money on it. But a lot of people didn't know that. The other thing is it's about use. It's not good enough that somebody, even let's say he spends money and buys your software. Unless people use your product, your product isn't going to evolve in any way because you're not going to get any feedback. If they just buy it, play around with it for a little while and then go and do something else, what you're going to end up with is a situation where people don't tell you, hey, this is a great product. It would be good if it could do this. Or there's a bug over here. It would be great if this could be fixed. That kind of feedback, which not only results in better products, but also results in encouragement. I would say it is not something that you can put a revenue stamp on. You can't say that this is money in the bank, but it is money in the heart for a developer to know that someone is using your product and really enjoying the use of the product. And the most important part is it's about users. Unfortunately, and this is still true today and this is 2012, a majority of the products that are being developed in India are being developed by people who understand the technology really well. I mean, really, really well. But they develop products which only they can understand. They say it's so simple. You do this over here and in case you can't do this, then you just go and change the XML over here and... When I got back into the product development game in 2005-2006, I had to undergo a transformation which was really hard, really, really, really hard. And unfortunately, not enough people are doing that today. In 2005, I was one of those hothead techies who would have an answer for everything. I was this Linux freak. I had a technical answer for just about everything. What I wasn't was a typical user. And over the next three years, I had to teach myself to think like a user to understand how users perceive a product. It is only then that the products that I and the company I was working for at that time became something that people wanted. You have to be able to think like a user. You have to understand what users want. They don't have the time or the inclination or the desire to learn the technicalities of whatever your software or your product is doing. They just want to get on with their job. And if it does that, they will use that software more and more and they will probably recommend it to someone.  And this is what we saw over the years. A lot of people producing products that were great functionally but unusable. The usability and keeping users in mind was very, very important. Unfortunately, it's still not happening. One of the things that we need to desperately drive home to people is it is not about the developers, it's about users. And there's one more very important thing. It's not about funding. Now, I don't have to tell you just how insane the market has been. People float a new product, come up with an idea or something or the other and the first thing they go is look for funding. I saw yesterday in the evening, I saw a news item that went out that such and such a company got $7.5 million in funding. Congratulations! Congratulations for what? Why were people congratulating a company that got $7.5 million in funding? That wasn't an achievement. The achievement would be if you use the $7.5 million, just create something really insanely great, get lots of users to spend money on that, earn massive amount of revenues and the people who have invested the money in yours, they have lent you the $7.5 million. They make a killing in returns. Then we can say congratulations. But in this particular case, the company actually has a few people in it whom I know, so I just got in touch with them saying, so what are you guys going to be doing with this? Oh, I don't know. Now, first of all, you've got to relax. Finally, our ship has come home. Wow. I don't see that company going very far. I think that company is going to be out of business in the next 18 months. They have no clue what they're dealing with. They think that funding is what it was all about. This is probably the most dangerous thing facing Indian product developers today. This misconception that it's about funding. Even worse, most product conferences that I attend are about VCs, getting funding, angel funding, seed funding. Then total silence when it comes to the concept of developing the product, getting it to market, marketing in it, expanding your market, iterating, iterating, iterating. All those things that make a great product, none of these conferences talk about it. The next item on the agenda after getting your funding is exit strategies. How weird can you get? This is yet another bubble. No products are going to come out of this. What happens is I make myself highly unpopular by talking to, I come across a lot of young software developers, a lot of product developers, and I make myself really unpopular with them by sitting down with them saying, okay, let's talk about what your product does. No, we will do about that data. That's not so important. I said, guys, you're dead. Either I get checked out of the office at that point in time, or they will listen to me grudgingly, but nobody wants to hear what I have got to say. A very few people, and those few people who do listen, they are probably going to create insanely great products and push them out there. But the rest of the people are going to die. They're just going to disappear. I know this is a really harsh thing to say. I'm not building too many fans with this, but reality is that most of the product development that's happening in India today is not about products, but it's about funding. Go on for a while. Make as much money as you can. You have your exit, if possible. If not, well, you have lived your life, and let's go on to the next product idea. The concept of ideas rather than, you know, everyone, it's very easy to come up with an idea. Oh, this is what this software will do or this is what this product will do. The what is not important. Anyone can come up with a what. Anyone can say this is what software is supposed to do or this is what the idea... Oh, we will create a social network for doctors, medical practitioners. So the real question they should be asking is not what, but how? If they have an answer to the how, they're getting somewhere. If they don't have an answer for the how, they're not going anywhere. Definitely not getting anywhere. Also this insane concept of piggybacking on other products. Over the last six months, we saw Google terminating a huge number of their own projects, which is their right to do. I mean, they didn't see any future for the product or for the service, whatever. They decided to terminate it. And people were up in arms saying, but my product, my service depends on that service and now they're terminating and I'll go dead.  People need to understand that they need to build products which are self-sufficient, which means you've got to think beyond just fancy screens and what button does this and what button does that. But you have to think about the back ends as well. You might start off with by using some free service, some map service or whatever, but eventually you're either going to have to pay for that service or the service might just disappear. What happens to you then? This is another thing that needs to be driven home to people around here. And finally, the most important thing is, I mentioned this before, so it's about users. It's more than that. When people develop products, especially here in India, they're dealing with a user mindset that's quite different from what they're dealing with abroad. But that doesn't change the rules. Those three rules which I said earlier, it's about revenues, it's about users, it's about users. Those rules remain the same. However, the implementation may be different. You have to consider, for example, in India, if you create a mobile product, that your end user does not necessarily have the skills to be able to use your application simply because it's written in English. We've got 26 official languages in India. Let's not get started on different dialects and whatnot. So there are issues which you need to address over there. Localization, easy localization, which is very important, which too few people pay attention to. I also keep telling people that pay attention to your local markets. Don't pay attention just to, oh, I'm going to take this product, I'm going to sell it in the US. Most of the people don't actually have an idea of what it takes to market a product in the US. I have done this and I bear scars to this day on how hard it is to market a product in the US or in Europe. Actually, it's a little easier in Europe. In the US, it's insane because, A, you're dealing with a huge amount of competition, a huge lack of awareness, which requires huge amount of marketing efforts and a market spend, advertising and whatnot. It's not enough to just create a product, push it out there and say, oh, it's a great product, people will use it, not going to happen. What I advise people to do is first become strong locally. Try to cater to your local markets because if you create a product that can easily be localized, for example, in different languages in India and you've got lots of choices over here. That means you have a product that can not only sell well here in India, but is very easily adaptable to markets outside India. China is the single largest mobile market in the world and it is growing insanely fast. That's a market you want to address, but if you have an application that only works in English, you're out in the cold. This is an example of things that people need to pay attention to today. Indian developers need to pay attention to because if you do that, you create what would be a truly international product, international class which addresses things that are unique to specific markets, to each market. I remember in 2006, we were pushing out a product called Mundo IM, which was a great success in the US and also in the UK and completely flopped in France and Germany because the product was not localizable. It literally had to be written from scratch again just so that strings were isolated, prompts were not hardwired into the code and that somebody could take all the strings then and convert them into whatever language was there for the local market. I actually had to sit and do the German version of that because I speak German. We had a terrible time adapting it for the French market and each market was a new challenge simply because we had not thought of all these things earlier. The thing about India and products coming out of India is that we've got massive amount of scope. Labour costs, development costs in the rest of the world have gone through the roof. It's simply not possible for people to dedicate resources the way we have them over here but the important thing for people to understand over here, to realize over here is that we shouldn't be just developing software for someone else. It's not your product unless it carries your name and your identity along with it. Create products over here that when they go out into the market people say this is a product which is developed in India and is bound to be good. When we achieve that then we have really truly arrived in the product market. India has got huge scope in that, lots of qualified people who need guidance. That guidance comes from within companies that they work for. It comes from the colleges. There's a lot of revamping that needs to be done over here to make sure that these people have their mindsets but if it's done right then we are not going to talk about software superpower which people keep talking about India. India is a software superpower. Nobody cares if India is a software superpower because the piece of software that you're using in the US or in Germany or in France doesn't say made in India. It doesn't tell you that it's from India. What you want is India to be a product superpower. People recognize that and say this is good stuff. This is the kind of stuff that I have been pushing forward. This is the kind of stuff that I really enjoy doing and even at my current stage which is twice the size and age that I was when I started. The photograph I showed you was 25 years ago. Even at this age I still get fired up every time and come and say let's do this. Let's create this really great, insanely great product. It's possible to do that. I know it's possible to do it because I've done it before. It's a topic I can keep talking about but I'm going to be running out of time. So if you do have any questions this is the easiest way to reach me. I'm really insanely active on Twitter. This is how you can reach me. On my website is also over there in case you want to send me an email or something, feel free. If you have any questions right now by all means do ask. Otherwise I'll be around. Thank you.


The Comptroller General of the Nigerian Security and Civil Defense Corps, NSCDC, Hamid Audi, has warned against the continued attacks on offices of the Independent National Electoral Commission, INEC, in parts of the country, vowing that his men have been put on red alert. Speaking at a two-day capacity building workshop in Abuja for all state commandants and corps strategic managers ahead of the general elections, the Comptroller General said his agency would ensure that voters domestic observers, election sensitive materials and electoral officers safety and security were well coordinated. With less than five weeks to go for general elections, the Corps will soon release a reverse standard operational guidelines on election duties and other salient election security rules for personnel, which is aimed at ensuring safe and secured electoral process nationwide. In addition to fiscal security, a strategic management workshop will also develop a common policy guideline that can be used in deepening the capacity of Corps personnel as his officers are meant to comply with global standards of election security management. Already, the Interagency Monetary Committee on Election Security Access has produced a reverse code of conduct and rules of engagement for security personnel on electoral duty. It is expedient, therefore, that we become conversant with these updated documents as strategic commanders. I relate the knowledge to our respective support needs. President Muhammad Abu-Hari has committed


Oops It's going on everyone Sam here with late in sports cards We're ripping two boxes of 22 top Star Wars chrome black hobby for Paul B. It's good luck here, Paul. Let's do it That's Obi-Wan Kenobi a massage ventress and blue Q that is four out of 75 So there on the blue. We've got auto is gonna be a zoo That is Christopher Shawn voice of Asu grads on that very nice boss nice way to start it Grow goo nice one there and green body Rook that is 47 of 99 is Sabin red or Sabine red Sabine red. I remembered it. I remembered it. Nice Sabine red. That is Tia so car voice of Sabine red Thank you, there you go Paul congrats on your hits there Paul. Thanks as always for the support buddy Do appreciate it get them right out to you man


So, we started this, we went on this journey because we were talking of optimization with inequality constraints and the first kind of problem in that the first kind of the simplest sort of you can say problem of optimization with inequality constraints is when you are minimizing a linear function over linear inequality constraints. So, minimizing C transpose x where the x is of your variable subject to the constraint that A x is less than equal to b. So, what are you doing here? You have your objective now is a linear function, the constraints are what are the constraints? The constraints are linear inequalities, what do it is a common region for that lies in all of these inequalities. So, it is a common region of all of these half spaces. So, the feasible region is a polyhedron. So, we are optimizing a linear function over a polyhedron and that is what is called a linear optimization or a linear program. A linear program as so you have a linear objective, the polyhedral feasible region. So, this sort of problem is what is called a linear program. So, let us look at what we, let us try to see what we can say about solutions of a linear program. So, firstly, the way this problem has been posed, we are optimizing a linear function over a polyhedral region, a polyhedral feasible region. Can you show me how this problem can be transformed into a problem that looks like this. So, how do I transform it from this to this, can does not everyone understand what it means to transform? So, we would like to transform, you would like to take this a problem like this, do some transformation that we were that we had discussed earlier, introduce variables, change type of constraints, etc to whatever transformation you can to bring it to this sort of form. Now, when I say this form, I do not necessarily mean that I am only concerned about the form of the problem means this a here does not have to be the same a here. Similarly, this b and this b does not have to be the same, this c, this c does not have to be the same. In fact, this x and this x also does not have to be the same. But I should be able to recover the solution of one from the other. So, can you tell me how do I do this transformation? So, the first thing is we have seen was the introduction of slack variables that lets you convert inequality constraints into equality constraints. So, the first let us try to do this. So, first introduce a slack variable slack variable s and that then gives you this equivalent optimization. You are minimizing c transpose x over the constraint. Now, A x plus s equals b, s is greater than equal to 0. And now your object, your this the variables over which you are optimizing is both x and s. So, now, is this problem question now is, is this problem in the form of this problem? What is the difference in the form of these two problems? So, the key difference is that here only if you here remember what is the role of x in this on the problem on the left hand side, the role of x here is that of the decision variable. So, it is representing all the decision variables together. All of them are required to be greater than equal to 0 in this problem. Whereas, if you look at it on the if you look at the problem on the right hand side, the decision variables now comprise of both x and s. It is these together, but the problem only has some of them greater than equal to 0, which is the s component of it is greater than equal to 0. The rest are not we are not imposing greater than equal to 0. So, this is not in the same form as this. The problem on the left hand side has the form where all decision variables are greater than equal to 0. The right hand side has only some of them. So, we have to somehow do more work to get it to this form. Remember, focus is on form. Of course, x itself may be you cannot ask for x suddenly to be greater than equal to 0 because it may not be valid in this particular problem. So, you have to transform x into some other using some other variables in such a way that you get it to this sort of those variables end up having this sort of form. So, what would be the way to do that? So, one simple way of observing this is notice that x is just can is a real vector it can take any both it can have positive as well as negative components take any component of x then that is just a real number it can be positive or negative or 0. But every real number can be written as a difference of two positive numbers always. So, component wise I can always write x as the difference of two non-negative vectors. So, so I can do this change of variables I can replace x you can replace x by u minus v where u and v are both non-negative. Since u and v are non-negative the difference but I am looking at the difference the difference can take both positive values negative values can take 0. Every possible value of x can be generated as a difference u minus v where u and v are non-negative. So, if I make this transformation this will not change the this is this transformation is going to be equivalent. So, I can make this change in minimizing c transpose x now becomes minimizing my x gets replaced now by u minus v u minus v a as is going to be multiplied by u minus v plus s equals v. But I am going to keep u and v non-negative. So, so my I will have inequalities s greater than equal to 0 u greater than equal to 0 v greater than equal to 0. Now what are my variables now the decision variables of my optimization s which is earlier remains and in addition to that I have u and v also. So, I am now optimizing over u v and s. So, I can just write this whole thing in a eta form we write it like this minimizing over u v s this sort of function c minus c 0 s now question is this in the form of this problem on the problem that I was looking for yes it is in this form because all my variables are now non-negative I have equality constraints or the other constraints are all equality constraints and I have a linear objective. But you see in the process of getting to this form my x is completely disappeared. So, when you are changing the form of the problem you should be open to changing redefining your variables redefining your constraints introducing new variables etc. So, but focus should be on the form not on the on retaining the identity of particular variable. So, what it means is that what the conclusion from this is that if I give you any linear program like this which is optimizing a linear function over a polyhedron after some transformations I can bring it down to this sort of form now can you tell me if you can make this even more specific. So, I have brought the linear optimization problem to this form can you make it even more specific say more about remember the transformations I was we had discussed we had discussed things like eliminating constraints for example are there some constraints that you can trivially eliminate from here. So, look at we have equality linear equality constraints here. So, if there are rows of A that are linear combinations of some other rows of A then it has to be that then you can eliminate those. So, if there is a row of A here look at the matrix A there is some row here that is happens to be a linear combination of these two other rows and you have B on the right hand side here the corresponding B here is your B this is B this is A. Now, when I do row transformations I can we are using row transformations I can basically eliminate make these all of these 0 when I am doing row transformations what am I doing I am take multiplying this row by some multiplying this the rows by some constants adding them to other rows and subtracting them from other rows etc right. So, by doing that I end up eliminating this make this entire row 0 so it is as good as not present what should happen to this after those transformations if these equations are consistent this should also become 0 right otherwise these equations are not consistent in which case there is the feasible region itself is empty right. So, if this with this and this with this and the original form of these three equations if they are consistent then after these rows transformations not only should this disappear this should also become 0 right. So, in short that entire constraint should become irrelevant. So, if the feasible region is non-empty then without loss of generality I can do these transformations and get rid of all these linearly dependent additional constraints. Now, is this changing the geometry of the problem? Is it changing the feasible region? It is changing the number of constraints, but it is not changing the feasible region right because the feasible region is the set of x's that satisfy these constraints and the same x's that satisfied your earlier set of constraints continue to satisfy the reduced set of constraints also because you have only removed the linearly some linearly dependent constraints correct. So, the feasible region does not change but constraints get removed no x the dimension of x remains the same it is only the number of constraints which is changing right. So, remember feasible region is a region in space constraints are just an algebraic way of representing them there are many redundant ways by which you can represent the same region and we are removing all this redundancy by getting rid of these dependent equations right. So, if the problem is feasible then I can do the above transformation then by row transformations we can reduce the problem to this form we get something like this you are minimizing a linear objective C transpose x again over the form of the constraints is still the same A x is equal to b x is greater than equal to 0 form of the constraints is still the same but what can we say I can now say that if I look at the rank of A that is then that has to be equal to the number of rows of A. So, A is full row rank. So, by doing so this is another further reduction so I had a general problem like this where I had an equality constraint A x equal to b and x is greater than equal to 0 I have now said well that also I can be more specific I can take A to be full row rank can you be even more specific then is there any further further reduction possible this A is not no more the same A that you started with the A we started with is this the A we ended up with is this sort of A and this may have dependent linearly dependent row. So, question is that I asked was can is it possible to make this problem even more specific can you say something more sorry no x is greater than equal to 0 that is just a constraint. So, we can make it more specific make it more specific by to the point where we now begin to solve the problem. So, but that is not what we are trying to do we still want to read we do not want to dive deep and begin you know solving the problem but we want to still looking at the form itself try to be more specific about it. So, instead of an arbitrary A now we have an A with which is full row rank what about b in the in all these transformations b has actually left been left untouched. So, b can actually be taken as greater than equal to 0 and this is without loss of generality can you tell me why so without loss of generality b can be taken as greater than equal to 0. So, if I if I try to do what you are saying which is that I write b as b1 minus b2 take the one of the as a difference of two non-negative b you will take one of them to the left hand side but it is not being multiplied by x. So, the point here is a very simple observation actually that here you have equality constraint. So, they remain valid even if I multiply any one of the rows by minus 1. So, if I have a b which is negative I can just multiply that particular row throughout by minus 1 the corresponding row of A will get multiplied by minus 1 b gets multiplied by minus 1 and I get back on positive b right. So, by doing this I can get without so without loss of generality I can assume b to be greater than equal to 0 right. So, what this means is so this gives us the final form that you can do minimize c transpose x A x equal to b x greater than equal to 0 b greater than equal to 0 A full row rank. This is what is called the standard form standard form of a linear program. Now, why care of why do all this the reason is because once you have a standard form standardization like this helps in creation of technology on top of it right. Once you have a standard form you can people can create methods for solving that particular problem of that particular form. If you have too many different forms then there is no fixed form you do not know which one to choose and so on right. So, you will see that many solvers usually assume that you are starting of your linear program in the standard form. So, they demand that you enter your problem in a standard form right. Of course, you can anything that is written in this sort of form is at the end of the day a special case of the first definition that I mentioned. It is a eventually a linear optimization of a linear objective over a polyhedral feasible region. So, if the solver demands that you write it in this form you can also write it in this form clearly. So, we will end here and we will continue next.