Three first names. I should have been a rock star like, you know, David Lee Roth or something that would have been fantastic, but no, no, I had to go into computer science and what I was thinking. I am the director of software engineering for IBM. I've been with IBM for 17 years. It's crazy even to say that sometimes. And I'm also an IBM Distinguished Engineer. There are about 300 of us in the company which doesn't sound that impressive until you realize there are 483,000 employees in IBM. A couple of interesting things that what I do, I and my team build software for companies that allow their employees to collaborate and work together better. It's a pretty cool job. We help people actually do their jobs far better than they could do them by themselves. I've been in this field for a long time. I started off actually coding this weird product called Lotus Notes, somebody might have heard of. And at the time I worked for this guy named Ray Ozzie that some of you older guys might know who Ray Ozzie is. Ray Ozzie, by the way, Bill Gates, the founder of Microsoft or co-founder of Microsoft, once said Ray Ozzie was the best programmer he ever met. And I would agree with him. Ray Ozzie was amazing. So I'm here to talk to you about something I identified literally about eight months ago. And it's that software engineering in general and more specifically software engineering in building software for companies, for enterprises is dramatically changing. In fact, it's changing at such a rapid pace that most of the vendors that make this software can't even keep up. So I'd like to start off talking to you about something that maybe is a little bit subtly different than you normally hear from some IBM executive.  You know, they're the animal, they get scared, they bullpook this, make themselves look larger. They're also a delicacy in Japan. Now, the bad thing about eating puffer fish is it's poisonous. And about two out of a hundred end up either in the hospital or dead from eating it. So I have a little story for you. It takes me back to sort of my past. I grew up in the 1980s and in early 1990, I was a Sega guy. I had a Sega Genesis for those from Europe or in Asia, a Sega Mega Drive. And I hated Nintendo with a passion, unbeknownst to man. I couldn't stand them. What's really interesting is Sega by 1992 had a 50% market share in the North American market against Nintendo from virtually nothing to begin with. Their marketing director was a gentleman named Al Nielsen. And Al was really confused because he had a 50% market share in the United States and Canada and Mexico. But the market share in Japan was 10% against Nintendo. What was happening? So he flew over to Japan to meet with his colleagues and peers in Japanese marketing. And they talked and such and I'm sure they had a wonderful time in the office. But afterwards, they went to get sushi. It's Japan, why not, right? So they sat down at the sushi restaurant and his Japanese colleagues, Al's Japanese colleagues, started giggling. And they said, we've ordered you something special just for you. And you know what it is, puffer fish. So with ceremony it came down, plopped in front of him. Soy sauce was prepared, really fresh wasabi. Diced up the real wasabi, not the stuff that we normally eat. The wasabi's not really green by the way, FYI. And Al thought about it for a moment. Okay, two out of 100, seems like reasonable odds. So he takes his chopsticks, comes down, dips it in the soy sauce. He's put a little wasabi in because it's better that way. And he says, it's good. And then he picked up the plate and he offered it to his hosts from Japanese marketing. The ones with a 10% market share.  And then he realized why they only had a 10% market share in Japan. They were unwilling to take any risks. They were unwilling to try, they were unwilling to fail. And that might have been fine in 1985, seven years before that, and they were doing reasonably well. But it is not fine at that time where you want to win in the marketplace, where you want to move forward in the marketplace. I tell you this story because I had an epiphany about building software in August. I actually got the current job I have, the first of August. So I've had it for almost nine months now. That's frightening. I could have had a child by now. Sometimes it feels like I had a child by now. But I was in San Francisco three weeks ago in front of a couple hundred people. And I put this slide up and you could have heard the gasp in the room. I mean, these are all IBM customers and they're looking at this line going, you have no interest in building software for us? Yeah, why are we paying all this support for you? And even worse, the product that I build is $150 million business for IBM, which is really impressive until you consider that IBM makes $80 billion a year, which makes me an apostrophe. However, I put this up and I said that I don't have a great deal of interest in making software for you. I really don't. However, I have a great deal of interest in making software with you. And this fundamentally changes everything that you think about in building software. Now, some of you saw the presentation before talking about open source and bringing open source into the enterprise and how that really changes things. I want to go one step further in software engineering. I want to literally in real time build software with my customers and partners. And that's what I've set out to do since August 1st. Something that, by the way, has never been done before that I am aware of in enterprise software development. Certainly never in IBM. I have like 50 lawyers chasing me around every day in IBM to try to stop me. And not very successful so far. And this leads us to something that is very interesting.  There is an English term for this, vergence. It's not convergence. It's called vergence. And I'm seeing this right now in software. So we heard about open source and how open source is really changing the enterprise. Well, what if it's not just open source? What if it's also customers' needs are changing dramatically and a faster and faster rate that other vendors simply can't keep up with it?  Well, I believe that's true. I believe we have reached a vergence. But there's some really interesting reasons for that. And the first one, and frankly, my favorite, is how. We do not often talk about the how in software, right? We don't talk about how it was built. We don't talk about the people that built it. Why? If you hire a plumber to come into your house, you're probably going to check out to see what tools he uses and what products he's going to use inside your home lest you wake up in the middle of the night with your toilet flooding your bathroom. The how is actually really, really, really important in software engineering. The people that build software, to me, are far more important than the code itself. If you look at Andy Hertzfeld and his cast of crazies, less than, by the way, 50 people who built the original Macintosh, and that's hardware and software, by the way. If you look at those people, those were the best of the best of the best. They were a community. They cared about each other. They played together. They coded together. They worked all night if they had to, and they slept all day if they needed to. The how is really, really important. And that stretches into things like we were talking about waterfall in the last session. I think waterfall, frankly, is evil and must be destroyed at all costs. I would take a bonfire to it. Heck, I'd use one of those fire bombs the American military has and drop it on it. It has, frankly, devastated our ability to iterate and go faster in software engineering. So agile is really important, but there's some other things around the how that you should realize. So when I took control of Connections Engineering, which is like 239 engineers, so it's a relatively large engineering team, scattered in several different labs all around the world, from Boston, Massachusetts, to Shanghai, to Beijing, to Austin, Texas, to Raleigh, Durham, to Dublin, Ireland, and Haifa in Israel. So you can imagine I never sleep. But we had a lot of engineers I like to call eye-shaped engineers. They were really, really good at one thing and understood nothing else about the product in which they were effectively engineers for. I do not believe in eye-shaped engineers. I'll give you a great example. My first week in this new job, I'm on a build call First of all, we no longer have build calls. I don't even understand what a build call is. But we had one to be on the phone while the software is building. Like you really need 30 people on the phone listening and watching the software being built. But whatever, I'm sure it was an IBM process for some reason.  And all of a sudden, something perks my interest. And they said, well, the build has to stop. Say what? Why is the build stopping? Well, we need Travis. Now I'm thinking in my mind the CI tool. We need Travis. Why do we need Travis to do a build? Maybe we need Travis. They were talking about a person. This one guy is Travis. And literally, he's the only guy who knew that code out of 239 engineers. That's insane. This is why I'm telling you that how is really, really, really important in software development. What you really want in an organization are T-shaped individuals. I'm really good at one thing, but I know everything about my product. I'll give you another antidote so you can kind of understand why I-shaped engineering doesn't scale. The product that I produce is effectively social networking and social communities for businesses. So it has all sorts of features. It's got blogging capabilities and wikis and forums and communities and file storage and profiles. All the kinds of things you can normally think about that a social system would have. But I had a blog team when I took my job in a wiki team in a forum team. Now keep in mind, all of these systems share the same database and have the same navigation. So when you looked at the product on August 1st of last year and you went from blogs to wikis, the fonts changed. The thickness of the bars changed. And it looked like there was 20 different products in this one product, which is by the way not an inexpensive product to buy for a company. Why? They never even looked at the other parts of the product. Oh no, I'm a blog guy. Blogs looks great. I do not believe again in I-shaped engineers. I believe in T-shaped engineers. The other thing that's really interesting about the how is being willing to fail. So I've banned a phrase in my engineering organization. The phrase in English is I have concerns. The next person in my organization who says I have concerns, congratulations. You now own the problem. What you need are people who are willing to try things. They see a problem? Great. Go and figure out some solutions for it. Don't come to me and expect me to solve your problems. And this gets into my last sort of rant on why how is important.  I am a really good coder. But there's no way I can possibly keep track of 239 engineers and watch their code. I have to empower you and you and you to go and do what I think is right. And what you think is right. And if I can't trust you, I need to go find other engineers. I believe firmly in software engineering. I want the 23-year-old art history major who minored in computer science and is an amazingly talented individual. I want her making the decision on what the Lent file looks like. Not me. Not my senior technical leaders. The person who's doing the coding. And so that's what we're doing. The how is very, very important. And you think about the things I just talked about. These are all things that have changed like the last 18 to 24 months in software engineering development, specifically for the enterprise. So I've ranted about how, but I'm going to go on a further rant on the Ivory Tower. This is how software development has worked for the enterprise for the last 30 years. I get your requirements. I listen to you as a, you're my customer, that's great.  And then silence. And I go up in my Ivory Tower with my magical coders and we build something that we sort of kind of think is actually what you want, but we're not really sure because we don't ask you. And we build our code and maybe, just maybe, we'll give you a beta to give us your feedback. And when you say, well, this doesn't work or this stinks or this isn't what I wanted, say, well, it's too late. Sorry, we're beta. That doesn't work in today's pace of enterprises. Oh, you may say, wait, the cloud, the cloud solves all these problems. That makes it worse.  Awesome. I don't believe in the Ivory Tower. Here's what I believe in and what I'm doing and changing and what I advise if any of you are working in software engineering and you have customers, bring them in to your scrum teams. You may think I'm out of my mind, I'm not. So today, for the first time, at least in IBM history, not sure about the rest of my competitors, whether it's Microsoft or Google or Oracle, whomever. If you come to my stand-ups, and you've got to remember, I have 239 engineers, I've got something like 50 scrum teams. You come to my stand-ups, there are customers on those calls. I know by the way, those customers are the pigs, for those of you who know agile terminology.   Chicken says, great, I'll make the eggs. Chicken makes the eggs. The pig says, I'm going to make the bacon. Now who's committed? Not the chicken.  Those are the chickens, and who gets to talk, the pigs. So on my stand-ups, it's the pigs that are talking. Oh by the way, the pigs are the people who coded it and the people who are going to buy it and pay for it. So, but I also have my customers and my business partners on our playbacks. Do you guys know what an agile playback is? So, agile playback is after our two-week iteration as a squad, as a scrum team, we do a show. But the show's for the team. The show's not like some, you know, fancy PowerPoints with animations of puffer fish, which by the way, is so much fun to do. I highly encourage it. But a playback is, here's the user story that I was trying to accomplish with the customer wanted, what my marketing team wanted, what my product team wanted. Here's the story. Here's the code. Here's it running. Ding, ding, ding. And then the last thing of those four steps are, here's my definition of done. DoD, doesn't span for Department of Defense by the way. And in the DoD it says, thou shalt have the following things. Thou shalt have 90% automation of test. I have no testers in my organization, by the way. I have 239 engineers. There are no testers. Thou shalt not have anything that does not have an API. And oh, by the way, that includes markup. Everything has to have an API in my product. So you have those four things you go through. But I have customers on the call and I have a fifth thing that I've added. I actually added it in January and I terrified my engineers by doing this. I told them, okay, we've gone two months now with customers joining our standups and business partners and customers joining our playbacks. Here's a new part of the definition of done. If the customer looks at the user story and the code you wrote and it running and they don't say the following, looks good, did exactly what you said you were going to do, and I would pay money for it. They don't say those three things. It's not done. It's not done. Go do another iteration on it. Sorry. So no more ivory towers. No more going up and coding for six months, nine months, 12 months. God help me, 18 months. And then coming down and go, look, it's beautiful.  It's not what I asked for. We're not doing that anymore. I have no betas. They don't need them. You're my customer. You can see the code being written day by day if you want to. We talked a lot about open and the previous presenter had a lot of conversations and comments about open. I want to sort of go a little further in my concept of open. I believe, as I said before, everything has to be an API. Anything can be extended. Anything can be changed. Anything should be modifiable. I don't care where it's deployed, by the way. I also believe that anyone should be able to see my source. Now, I'm using Battles right now to try to open up even more of what IBM Connections is, which is the product that my team makes. But I will tell you this, for the first time in IBM history, there is no closed source repository for IBM Connections. There are 483,000 IBMers. Every single one of them can do a pull request. I now have tech sailors. These are technical folks who have helped the salespeople. I have them issuing patches. They didn't work for me. I've had people that work in other divisions that I didn't even know we made this product, because in IBM it's hard to keep track, right? That are sending me new code. And some of it's really good. And they follow the same DOD steps because they're all public. So just look at what I've done. I've now taken a 230-plus-sized organization, and I've effectively doubled or tripled or quadrupled what it can do. The fact that you work in a particular team and you work for a particular product is frankly irrelevant. If you're an engineer in an organization, you should be able to do anything that you want to do. You should be able to work off a common backlog. That, to me, is what open really means. And by the way, my next step on this is I'm opening it up to my customers and partners. And I'm going to let them submit pull requests. Why not? So a couple other things on openness that I really believe in is sort of two phrases around integration. One is integrate in. So any product you make for the enterprise, you should be able to integrate inside of it other stuff. So if you think about companies, they have HR systems. They've got payroll systems. They've got inventory systems. They've just got so much stuff. If you can't allow that stuff to go into the product that you're writing, your product's useless, frankly. Your product actually can't solve their business problems. There's a phrase in computer science called sovereign pivots.   That is where they have to change their screen to some other screen to do their job. They hate it. I've actually seen this probably the funniest thing I've ever seen in computer science. I'll share the story with you. I'm not going to tell you which bank it was, but everyone knows there are five big banks in China, right? I was in Shanghai a couple of years ago and we made another product that we make in my division in IBM. And this product helps people build inside companies, build really cool integration websites. And you know what product it is. So I'm sitting there and I wanted to know what's your user story like? How do you do your job during the day? I wanted to sit down with a customer service representative, a CSR, sort of understand how they did their job. And they said, oh yeah, that's great, sure. Sit down here. You can see how we do our job. And I watched them and they received a phone call and they had a little cheat sheet over to their left and they hit alt-tab four times. There was that screen. The internet information. Oh, you need that? Alt-tab three times. Those are sovereign pivots. And you laugh, but believe it or not, that is what we do to our end users when we don't integrate in. The other part of integration is integrate out. So I highly encourage you as you build software that you allow the software you create to not have to be sovereign itself. In other words, the software that you build, yes, may have a user experience. Yes, may have a mobile app. And that's all great and wonderful and all. But other people should be able to build stuff with your stuff. And if they can't, again, what's the point? What are you really trying to do? You're building a point solution. You're not building a platform that other people can extend and work on. Openness means an awful lot to me. Yes, yes, yes, it means open source too. We have a process in IBM to handle open source. Almost all of what I'm building right now, and if you ever get bored, you can look up IBM and Pink, which is the code name for the next version of Connections I'm building. There is no proprietary software in Pink at all. Not a line. There is no, if you know IBM products, there's no WebSphere. There's no Tivoli. There's no DB2. Nothing. So I do believe quite a bit in Openness. The other thing that's changed, by the way, that's really fundamentally changing everything that's going on are deployment models. So everybody thought, all right, everyone in the world is going to go to the public cloud and no one's ever going to have software on-premises again. How has that worked out? Not at all. It's been a colossal disaster. Yeah. So now what you've got is you've got a bunch of vendors who are trying to do a little bit of both. And I'm not really sure what to call it because hybrid just seems a bit overblown of a term. Don't believe me? Two years ago, Microsoft announced they were not going to do another on-premises release of SharePoint, and they literally had a revolt of their users. What's causing this deployment model change? Well, German data privacy laws. So if you're aware, inside Germany, certain kinds of data have to stay in country. Can't leave. In some cases, they can't leave the premises.  I have a very large customer in Kuala Lumpur who uses my product, right, and they have to keep their Malaysian data in Malaysia and their Indonesian data in Indonesia and their Thai data in Thailand. So it's not just isolated to Germany. And these things are actually growing, not decreasing. And yet I look at this, unlike everybody else, as an opportunity. Deployment models, as they change, will allow you to do some interesting things in technology if you're smart enough to do it. The first thing is, your workloads should never be tied to a deployment model.  And it should be easy and drop right in. You should be able to take your container, Kubernetes runs, everybody's happy. But you should also be able to do that with your data. That, to me, is real hybrid. What if the profile data of a particular user that's required in German data privacy laws has to stay on-premises? What if they can sit there but the workload that runs it is running in Amsterdam, or London, or the U.S.? There's nothing technically stopping us from doing these kinds of things. Yeah, it's hard, but it can be done. Yeah, it's hard to make it perform it, but it can be done. You know, anything can be done in IT. It takes two things, time and money. I can make a shoe come out of this monitor if you give me enough time and money. So, I want you to think about those two things are really causing companies to really change the way they're building software. The deployment models around where are the workloads and where are the data. So, you think, this is great, Jason. I'm so excited. Look at all these things that are happening. What the heck does this mean for me and why do I care? Well, everything that I've just talked about kind of leads us into eating the puffer fish. To be able to frankly survive in this new world and build really compelling software for businesses and in some cases for consumers and keep up, you've got to be bold. You've got to be willing to change things.   I love React, I love Angular, I love React, I love Angular. I could care less. It's the time to go and re-look at everything that you do and if it doesn't make any sense anymore, blow it up. Blow it up. Break it. Try something else. I told my team they were very, very, very insistent. We want to do a bake-off between Angular and React.js. Again, I could care less. They did their little bake-off. They made their recommendation. They went with React. I said, that's great. But a year from now, I'm going to make you do this again. What do you mean? Well, in a year from now, I'm sure there'll be something else and it might be better. And if it is, you know what? We're going to go do that. Don't get wedded to the old way of doing things. That actually leads to poor quality, defects. The product that I inherited, this is embarrassing for me to say this, the product I inherited on August 1st, 2016, its primary UI framework used Dojo. I kid you not. And instead of changing, they kept finding ways around the limitations of Dojo because they were so wedded to the fact that it had to be Dojo.  It's really bad jQuery that someone decided it'd be really neat to make JavaScript object oriented. Anyway, now's the time to be disruptive. Now's the time to be bold. Now's the time to change. All of those things I just talked about are going to force you as software engineering teams to change what you do continuously and constantly. And it's OK. Get comfortable with it. It'll be all right. My third week on the job, I went to Dublin. I have about 90 engineers. And I spent like 45 minutes on stage talking to platitudes and, you know, here's what we do and whatever else. And here's who I am and telling them stories about myself. And then I told them, I hate to tell all of you this, but going forward I am banning Java. You could have heard a pen drop in the room. These are all IBM engineers used to J2E, which was actually invented in IBM. Used to WebSphere and all this technology. And I said to them, and I had to repeat it, I am banning Java. We will not write a line of Java going forward.  And my point, by the way, I'm a great Java developer, right? I love Java. I've met James Gosling. He's a nice guy. But Java's slow. It's expensive. You know, I can go and hire like 30 Node.js developers and buy LaRus in Minsk for like $28 an hour. Do you know how much it costs to get a really good Java developer? Like $150. They're expensive. You know why? Java's hard. So be willing to question the things that you're doing. Be willing to ban stuff. Be willing to just be, you know, look, sorry, I know this is great and cool and all, but we're going to go do something else. Second thing is communities. I went back to my line of talking about that we're going to build software with people. Start building communities inside and outside of your organizations. I'm doing this now. I have an interesting legacy of communities. Any of you ever heard of OpenSocial before, the foundation? Yeah. So I was, actually I was the senior board member on the OpenSocial foundation. So we did some very cool things like activity streams. I'm sure all of you have heard of. But one of the interesting things I learned about working with Google and OpenSocial and LinkedIn and Yahoo, whoever owns Yahoo now, I can't keep track. And even MySpace. Seriously, they were there. But one of the things interesting that I learned about it is if you bring people together, whether they're from different vendors, or you bring people together from, you know, different vacations or different industries, you can do some pretty amazing things if you all have a common goal in mind. And that's what OpenSocial actually did. Just did an amazing set of accomplishments. A lot of that stuff is now transitioned to the W3C. And we're off on a whole new mission. But build communities. Build different groups inside your organization and outside your organization that'll allow you to accomplish more than you can today. Again, going back to what I was talking about before, that the how really, really, really matters and the code doesn't matter quite as much as the how. Communities allow you to really kind of force function the how. You can build whole cultures in these communities to drive the outcomes that you're looking to drive. Omnipresent. Again, going back to your software. Your software needs to be able to run anywhere and everywhere. One of the definitions of done for IBM Connections Pink is that every microservice has to be able to run on a Raspberry Pi. And if it doesn't, it's not done. Sorry.  Why would you do that Jason?  You may think, oh, you're just being clever and cool. Well, I'm being clever and cool. But ignoring that for the moment, I'm doing it for a reason. And I'll give you an example. One of my favorite customers that's a very large airline based in Changi. I can't tell you who they are. They're very large airline based in Changi. But they have a challenge is that most of their aircraft maintenance is in Davao in the Philippines. Not a lot of bandwidth in Davao. Really bad latency in Davao. What happens when you have very little bandwidth and really high latency? You have extremely poor performance. My product that I sell to that airline I can't talk about takes almost 40 seconds for the home page to load in Davao. Would you use a system that takes 40 seconds for a home page to load? I can start counting. One, two. I can promise you wouldn't want to do it. Why? Well, it was developed for a wonderful Web 2.0 world that has 158 XHR calls in it. And for engineers in North America, oh, this is no big deal. But imagine this. Imagine that little Raspberry Pi and we park it in Davao. And imagine the microservices that it provides are that user experience. And imagine that King bundled with, let's say, you know, Redis that was doing cashing. Well, now the performance in Davao, whoa, it's an awful lot faster. This is why I say your software needs to be able to run anywhere. And the data needs to be anywhere. Omnipresence, huge change. I don't believe in versions of software. I don't believe in versions in general, but I don't believe in versions in software. They were great when we needed to dilineate things back in the late 80s and early 90s to understand the next capability of a particular system. But I actually believe software today needs to be more of a journey, not a destination. So the product that I'm building right now will never be done. Ever. And I think that's great. I'm willing to disrupt, add new features, add new capabilities, bring new pieces to bear. And I'm not going to have to worry the customer about things like upgrades. There is no upgrade.  I'm going to push down to somebody's environment, wherever you're using your software, and it's just going to work. If you make things a journey for your engineers and they don't have to worry about, I've got to hit this arbitrary date for some arbitrary version that we have to fix, have to ship because marketing and legal said we have to ship it on this date. For a particular reason, you free them. Now they can start thinking about truly innovating. They can really plan out their agile sprints. They can do some amazing things, and they'll be willing to try stuff.  And actually, it'll get in production in mid-April. But I'll tell you what it does, it's pretty cool. Stefan knows what it is. We call it inside IBM Muse, M-U-S-E. And we noticed there's a real problem with clouds that provide things like email and collaboration and stuff like that, right? So, you know, Google has one, Microsoft has one. We have one. There's all sorts of them, right? The biggest problem is, what if I wanted my company colors? And what if I want to do, I was talking about integrating in, to look up the number in SAP that I have on-prem to kind of give me some more information on this little EIN number. You can't do that, right? The cloud is sort of fixed. If you look at my competitors in the market space and they're fantastic people, you can't take Gmail and completely change it so it looks like Outlook. And I understand why they don't want to do that. I totally get it. But what we've done is we've realized that people want the cloud their way.  So you guys know what grease monkey is? I'm assuming everybody knows what grease monkey is, right? So we are now allowing our customers to literally hack our software deliberately. And we are opening up the pathways so they can go in and change things and do whatever they want with it. And then it will run through a series of CICD Selenium tests to make sure they don't break anything. They can drop their changes in to get.  And it's got these buttons over here and it's got pretty little pictures and instead of having square pictures of their employees, they're round. So little things like that become possible when you stop looking at software as a version and you start looking at it as a journey and we are all going on together. So, eat the puffer fish. Be willing to disrupt things. Remember that your software has to be anywhere and everywhere. Break the rules. Take some risks. Try different things. Be incremental. Don't tie. There's a great phrase in IBM. There's a lot of bad phrase in IBM, but I've always loved this one. Boil the ocean. It's a phrase in IBM that means sort of do anything and everything at all costs to solve this problem. I don't believe in boiling the ocean. Let's boil a teaspoon. See if that works. Maybe we'll try it again. Maybe even we'll boil a cup. But being incremental. Be willing to accept and embrace change inside your organizations. Remember that the how is far more important than the code that you're delivering to your customers. Passion is really important. I had a customer tell me based in Stuttgart in Germany. He said to me, he listened to this exact same talk and he said, so Jason, what you're really saying is if I have two vendors and they build the exact same piece of software for me and they tick off all the same functionality, what you're saying to me is I should buy the one that the team went out and had beer together, had a good time together, were passionate about what they're doing and cared about each other and not the team that just kicked the box. I said, absolutely you should. Because at the end of the day, that's going to be a much better product than this one. Even if they're functionally the same, they're going to have more of a feel to them. Almost a tactile experience. I brought up Andy Hertzfeld in the very first Macintosh before. It was not a good machine. At 128k, it could barely start, frankly. Finder 1.0 had a defect in it that you went into Finder and if you had too many files, it would literally just go into an endless cycle or an endless loop. It had problems. But wow, you could feel it. It almost buzzed with excitement. It had energy. It had passion behind it. That's what I talk about the how. That's really important. You can do that to your own software and even though they're functionally equivalent, the guys that had a good time and really cared about what they're doing, their products could be infinitely better. The last thing on here, disruption. Go and break stuff. I have the number one collaboration product in the world that I own. We are the market leader. If you look at Gardner, you look at Forester, we're number one in the quadrants and I'm literally rewriting it from the ground up, even though we're number one. And I am willing to do that because I want to not just be number one now, I want to be number one 10 years from now. And so should you. So I've thrown a lot at you but to sum it up, eat the puffer fish. I heard it tastes really good. So thank you guys very much. Yes, sir? Is that like your client in your agile process? What role, what people in the client? Who's the client? That's a great question. No, it's a really good question. So of course when I made this offer, I made it to my customers, my clients, IT organizations. They're CIO's office, right? And so the first couple of these meetings, they brought their engineers. That was okay. But then one of my customers did something really interesting. They brought a guy from HR to these stand-ups and specifically to the playbacks. And I'll never forget this. I got a phone call from the CIO of this company and he said to me, you've done something for me by having me in this agile process that I haven't been able to do in five years with his own internal customers, HR and sales and such. The HR person had told him, wow, I had no idea it was so hard to build software. I always thought this was really easy. When I asked for your button, I didn't understand why it took so long. But what's interesting is since he had the courage to bring the guy from HR, now a lot of my other customers are bringing sales people in. They're bringing in people from, you know, finance and what have you. So it sort of started off mostly just IT, but now it's like a nice mix of everybody who uses my product at the company. So I had no idea software was so hard to build. Yes, sir. Treat the, how deep the thinking goes on limiting the version of software. How has it been changed, dealing with compatibility with the systems, with the support arrangements that all that sort of stuff that you need to develop. Notice the software that you're having has some questions that keep supporting all versions and all versions of the business, right? Sure. That's a good question. The first thing is we have adopted purely Docker containers for our future, right? So Docker Enterprise has very clear requirements. In fact, they just forked like Thursday of last week, if I recall correctly, into sort of the community edition and their enterprise edition. So they have very clearly set requirements from a server side perspective. And we simply say we support those and nothing else. And if you want something else, well, I'm sorry, it doesn't work. The same thing we're doing with database. Today, my product, God help me. We support three versions of Oracle, two versions of Microsoft SQL Server and DB2. That's unsustainable, right? My competitors don't support 12 different databases or what have you, right? So now we have a really new choice for our customers. It's Mongo or Mongo, right? And we make very clear, you know, this is the Mongo version that we support and test on. And if you don't have those, sorry. The third thing I'm doing, you brought up clients and this is an interesting conversation. I am abandoning the browser. I think the browser is the crappiest app platform I have ever seen. In fact, it's this bad, I'll tell you, the last release of my product that had a version which actually comes out in a week. Then we're not having any more versions. We're going into the pink world. I have to support five different browsers from four different vendors. Microsoft has two, as you know, right? Right? I have to deal with the fact that two of those vendors hate each other so much they fork the same open source project, WebKit. That's Google and Apple, by the way. Right? Do you imagine doing accessibility on five different browsers and how much that costs me? It's insane. So, we're going to Electron. You guys know what Electron is? Electron allows you to continue using web technologies but wrappers it and allows you to access native features on the desktop operating system. So Electron is an open source project. IBM is a sponsor of it. It's a great community. But I'm going to have a Windows app and I'm going to have a Mac app and I'm going to only support browser for read-only. That's it. It's unsustainable. I can't add new features or functions. I'm spending 60% of my time making things accessible. By the way, I believe in accessibility. I just only want to do it once. I don't want to do it five times. So, long-winded answer, but that's what we're doing. Yes, ma'am? First of all, what I see in my view it's not it's not that I can't produce a result. It's not my method of being wrong. How we do it. I do want and all inclusive developer and client kind of leadership. However, often, one of the questions that come up is I can't sign an open-ended contract with you because it is a journey and it's no end point. I must tell my boss or boss that there is some kind of ending and that's one very common question that I get. So, would you also let me in this kind of situation? Absolutely. Even if we counter propose a time and material kind of contract basis, right? They're still not happy with it because on top of that, they would say yeah, about everything that you do and I do and you want to know. Customers hate T&M. They hate time and material contracts. They hate them. So, I'll tell you what I'm doing. Doesn't mean it will help you but this is what I'm doing. So, today in IBM, our traditional licensing model is you have a license and perpetuity for the version that you purchase from IBM and we are obligated by IBM law or if that is that we have to support that particular version for eight years and you wonder why I'm tired. So, that's current steady state and what happens is after the first year of purchase the customer is required to buy something called SNS and IBM. Subscription license, effectively, right? And if they keep buying this then when the next version comes out they're entitled to it and then your clock starts ticking again. With Pink, we're not doing that. So, that's sort of the current world that we're in. With Pink, we're treating every deployment as if it's a cloud deployment. Whether it's on-premises in a customer's private cloud running Docker and Kubernetes or it's in my public cloud. You pay a fee per user per month. You can either sign a two-year contract three-year content and get better terms or you can pay month-to-month. But when that subscription ends you no longer have access to the software you can no longer use it you are no longer licensed for it and there's no eight-year support agreement because there's no version. You just bought Pink. I'm not sure that solves your particular problem but that's what I'm doing. I can promise you, my customers when they first hear this I'll tell you the second thing we're doing because the add-on to what you asked me is okay, how do you deal with upgrades and maintenance in that model? So, if my customer has a private cloud or my business partner has a private cloud and they're reselling Pink, it's a solution again Pink has all these collaboration things in it they have two choices you can either be live literally in my CICD stream meaning that if I fix a security patch right now in ten minutes you have it or you stay one-quarter behind those are your two choices no in-between no I don't want that patch you either get it live when I'm patching my own cloud or you can wait a quarter that's it yes sir no a quarter no because otherwise I'm supporting one-to-n number of microservices so when the quarter comes there's a release, do you want to stay on that? awesome, now some of my customers like I have a lot of banks as you can imagine IBM has a lot of banks as customers but they want to do security stands bring in Delight and Touche to do whatever it is that they do with going to analysis and that's awesome but they can do that in three months so that's why we give them that one-quarter behind option in the pipeline long-winded answer there's not a so I'll be honest with you there's a great phrase by one of the founders in my country I grew up in Miami in the United States and one of the founders in my country was a gentleman named John Adams and on the 2nd of July 1776 when there was a boat and we finally decided to say bye bye to Britain we probably used the middle finger too but I'm not going to do that right now he said something that was very poignant he said we are about to take a leap into the dark and I will tell you with pink and I'm going to be very honest with you I'm going to take a leap into the dark and I may be wrong at what I'm trying to do but I firmly believe that this is the right path forward and it's going to be a little scary and we may fall but invite me back next year and I'll tell you what I learned any other questions? everyone was saying who's that guy in the wheelchair yeah who's the guy in the wheelchair it looks like somebody's been hitting him yes sir you gave everything an API now the question is is it null or empty because you never know I'm missing with your shirt and I'm just wondering what that means what's the alternative to not giving everything an API well bad coding so I'll give you an example in my product today there are a number of functions by a user that the actual end function back to the back end is a form post kind of hard to automate a form post so when I go to say that everything is an API I mean literally every particular action that has to be performed is an API we're also adding a scripting language to make it easier for people to kind of change things or build things funny enough based on Lotus Notes at Formule Language we'll leave that away hey what's old is new again but even those particular functions like at now in Formule Language gives you the current date time that's actually an end point it's actually a rest end point so literally everything is going to be an API including and you know Amazon is very famous for this and Amazon everything is an API too including their markup so when you start getting the markup that's pulled down and that is an API end point even broken down into pieces so that's going to be true of Pankin I can steal stuff from Jeff why not he doesn't mind maybe he'll send me an Alexa I don't know I'd be cool anything else I'm curious about what I would go and do if there were things to ask oh now I really want to know come on let's hear that one can you have a team of two hundred and three from the data there's no more Java how many of them actually nine quit nine left how about two hundred and three and nine left and the rest the rest of them went off and learned loopback like the world's most awesome framework around express and node loopback is awesome open source project is fantastic so they stopped at the beginning of the journey and they just decided yeah so I did something crazy certainly in IBM I know you're not surprised now I gave them four weeks off my entire team and I said go learn loopback go learn document databases go learn all these things and build me some experiments now now you can imagine my boss was not very happy with me doing this but whatever right the idiot hired me I mean he's going to have to deal with it I did I haven't been fired yet I'm shocked actually Jason be honest the main reason why your engineers say that they were so happy to get rid of you I'm not touching that not touching that one but here's the cool thing that came out of that one they realized now Jason's right if we adopt these other technologies we can go faster right it's not that easy to build a really solid API and job it takes some work I mean once you build them they're fantastic right but it's not that easy to do and get it right it is dumb stupid simple to do it in loopback I mean I can do it in three or four lines of code and you're done so they learned that but here's the coolest thing that came out of it one of the experiments they built is something called live grid and it's basically this really cool little environment where it allows end users to build apps using those little app formula languages but the really cool thing about that they did was it not only builds a little app like I can keep tracking my sales opportunities or whatever else as a sales guy or whatever but it dynamically provisions and builds APIs for you so it figures out what you're trying to build and it goes and constructs API endpoints for you so that other apps can consume the capabilities of that app and they can chain themselves together that all came out of that four weeks and we're shipping in September so you know nine people quitting bye bye yes sir I know I'm running out of time I'll try to hurry if I get it right you're quite a fan of Nord right? are you using it in that program? oh yeah and for me it's the mother of dependency nightmares it is are you doing anything about it? because I see there's a nice talk of a guy who said if you are hungry you walk down this street and you find you stumble over a hamburger would you just pick up and eat it? you'd be surprised but I did it it's cool right I've seen a lot of people importing all the libraries that have anything that they might want to use and don't care about it I see projects actually getting aware of it and then saying okay before we import anything let's look at what they have done what we like and how we implement it for us so that we don't get another dependency but it's quite some work it is so one of the things we've done not saying I've solved this problem because we have our own internal NPM and all of the libraries in those NPMs I have code scanned, I have license and gone through legal approval on and those are the libraries we can use when you start to need another library it actually kicks off a workflow that goes okay here's the new dependency here's the things we need to do and it's got to go through all that process IBM has more lawyers than engineers so it takes a little while for us to make these decisions before that library can actually be used not saying it solves the problem but it certainly mitigates it that that dependency is okay right from the get-go or that has GPL v3 on it and I can't touch it I literally can't but that's how we're mitigating it for now the other language you're using is I don't know if people are aware of this but Microsoft excuse me IBM and Apple are very close I think you guys probably know this right and we actually partnered on open sourcing Swift and so a lot of my business logic has actually written in Swift because Node is great for endpoints it's lousy for business logic but Swift is fantastic for business logic so a lot of the business logic we're doing in Swift which is the opposite of Node we have a dependency problem right you know it's sort of the anti-node pattern but a very cool language and I'll finish with this I know we're out of time but again economy is a scale if I can have my business logic written in Swift going back to my T-shaped engineers that means all my iOS developers who work on my mobile app guess what they can now write business logic kind of hard to do that with Java and anyone who tells me here that Android uses Java I have no idea what the hell that is but it's not Java anyway thank you guys very much for your time really appreciate it