 in Europe and the U.S. called Goju Conferences and actually Q-Con Fort from that. So the same mafia were along, all involved in doing these things. A group of people that really care that people keep advancing and since there aren't any CEOs or CIOs in the room, the real mission of Yao is to basically knock those people out of those positions and put people in there to understand what software is about. And we've been doing this for 10 years in Australia, 20 years in Europe. And we now have many, a couple of whom are mentioned there, Nigel Dalton from realestate.com, amazing company, 800 people doing agile teams, doing VR, all sorts of really advanced techniques. It's a great place and even the lawyers and the finance people use story cards. It's a very, very interesting environment. So we've been successful with part of the revolution, but the journey goes on. We like to compliment user groups. Special thanks to Stanley Yao and the team from Agile Singapore. We've agreed to essentially partner with them. They're kind of exhausted from doing Agile Singapore. And we're interested in having something that had the technical side of Agile as well as the other side of Agile. They've done a fantastic job by the privilege of being at the conference here last October. And so we're hoping to earn your respect and do as good a job as they've done because they've made a fantastic contribution to the community. We have a bunch of other conferences. There's Call for Papers. Our big conferences, we invite the speakers. For our smaller conferences, we have a few speakers that contribute. We have a conference on data. If you want to speak at Sydney, we actually pay contributions for speakers to get there because we understand you can't just go to a conference and maybe your boss is too cheap. And we want to help out. We want to change that too. And we have a connected conference shortly after that, which is basically on mobile and internet of things. But you didn't come to hear any more marketing. So what I'm going to do is talk to you about 10 ways to accelerate software development. This talk actually, just a quick outline, but the background for this talk is basically I'm old and every once in a while people get me to talk about all the old things, right? Today I'm doing vector functional programming and I wish you guys would wake up and stop using that stupid Scala and closure and all these slow, inefficient, gratuitously bulky languages, but perhaps you'll catch on if an old guy could do it. What's wrong with you, young, smart people? You still have a Java virtual machine. You'll never do big data with that. Hadoop, you've got to be joking. HDFS, the world's most inefficient file system. Oh well, I'm sorry if I already upset you. But I was an old professor and still am, so I'd like to poke the students a bit. So basically what people ask me to do this talk, that's my first comment. If you have projects in your organization, just forget it. Go someplace else. Agile Lean is about building products. And a product culture is very different than a project culture. And if you don't get that then don't worry about it. So I've been doing software for actually over four decades. And everything I've learned I've learned by working with other smart people, many of them students. I always hire second year students because second year students are not biased by anything. They're very malleable. So you can teach them how to build software your wrong way. And then you can hire them afterwards. And in Canada we have some called co-op education where students work for four months and get paid a decent, a good salary and then they go to school for four months. So they take, they do a five, takes five years to do a four years degree but they graduate with two full years of experience. And you know, but for that probably our Canadian education system will be as bad as many of the other computer science programs are on the world. Fortunately in Singapore you have some very good programs. But I'm sure there's other some places that are challenged. So basically we used all sorts of different things. We built all sorts of different applications from embedded devices and pen computers, IBM's Java virtual machines, the Eclipse IDE. You know, I'm sorry I was starting to object because that was a bad idea. I started the Agile Alliance that was also a bad idea. So I'm not sure why you won't hear anymore. I'm sure you won't do vector functional programming because that's too weird which is good for me because I don't have to compete with all your really smart guys. And basically the interesting thing is I learned all these things but every five years we changed the way we did things. Which is really depressing because Agile hasn't changed in its entire lifetime and most of you people are still doing object-oriented programming which is 30 years old. Oh my God. But Java is the new cobalt. C-sharp has better clothes but it's still the same. So basically I want to share with you kind of 10 things that let us develop software because when you're competing with really bright people like you you have to cheat. There's a lot of smart people. Most people think they all live in California but the smart people are actually randomly distributed around the world. Many of the best in the world are probably in this audience or in this city. The big thing is that no matter what anybody says when the CEO hears Agile what they hear is agility. Agile has nothing to do with agility. So in the end what people really want to do is be able to do things faster. They want to change them, they want to build them up. So if you focus on doing things fast that's going to get you a very good place with most companies. The other thing you need to realize is that companies only have a quarterly clock because they have to purport to the market or look at their numbers every quarter. So if you can deliver significant value and I stress value, not code then you're going to make a difference. And typically if you deliver value three times in my experience in any organization all of a sudden you get a lot more influence. This is known for many of my very simple words shut up and ship and when you ship you get to speak. So the danger is when you're doing your new startup if you spend all your time telling everybody how great it is and everybody will tell you are you going to do this and you say yeah we're going to include that because you'll never ship or what your ship will be a really ugly duckling. So there is no silver bullet and if you try and go fast and don't have a way to manage things you're just going to make a mess. That's where technical debt comes from. Before Agile nobody had any technical debt. Now everybody goes along and things are great for the first three, five, six sprints and then they're all begging for technical debt cards. Where did that technical debt come from? All from us because we didn't know what we were doing but we hacked the code anyway. Now we have to refactor it. And of course you're lying because it's not refactoring because it was refactoring you'd have all the tests and it'd be equivalents preserving with all the tests and so on but you don't. So refactoring is really a guide to say we really have to throw this mess out and rewrite it, isn't it? And there are no serious refactoring tools. Refactoring is a nice trick. I've worked with Bob Martin for many years. Very entertaining but none of his programs are big enough to even worry about refactoring. Serious legacies, object-oriented legacies are almost impossible to refactor. Michael Feathers is great Michael Feathers runs away whenever he sees, oh my god this thing is so big. So there's a lot of things which I call the sort of naive agile. This is like story points, right? Story points are training wheels for people who one day will actually learn that business is running dollars in time. So we need to try and get to that because we're going to deliver, you have to deliver to the business. So the big thing we want to do is actually write less code and less dependencies because that's the only way we can go faster. But there's no secret here. Basically what I want to do is get more functionality out of less code. If I can find a trick to do that, I'm going to be able to go faster. And of course I also have to be able to test that because 50% of my effort is going to be tested and I'm not going to be doing it with selenium. So we have a very simple principle called value-driven development. It's going to be a DDD or anything like that. That would be a terrible name. So the way we work is we basically essentially do something called build-up value change. So we find a place in the business where we can essentially make a big difference. An impact of like 2 million to 10 or 20 million dollars. Something that somebody actually up there cares about. We're not looking for a product. We're not looking for a product owner or a bunch of people. We're looking for something that matters. Something that's clearly visible in the value chain. So lean is the way to think top down. Agile is how individual teams work. And enterprise agile is an oxymoron. And I did large, I transformed Cognos. I did the Cognos transformation. I did a big chunk of IBM. I did Siemens Medical. Enough time in the hellhole trying to transform big organizations. Then I went back to R&D and saved myself. We quickly envision a solution. And then we typically find we have to find some way that is different to solve this problem. Because that's the only way we can really make the money. By the way, many years ago we discovered a process which we called Just In Time Software. Just In Time Software basically guarantees that if we don't deliver it on the day we promised to you, you don't pay us. We needed something to differentiate our company, right? So we basically invented this thing Just In Time Software and told people about it. And they said, you guys are crazy. We said, nah, we can do it. And then we found out how hard it was. But the nice thing is when you actually send something out if you have a vision as an entrepreneur you learn how to do everything and actually deliver this up in a method. We built 10, 15 products on time, including the Java Virtual Machines without access to the Suncast Source Code, the Eclipse IDE. All those things were built in less than a year. With far too many people in the case of the Eclipse IDE it looks like it. You do ship your organization or Conway's Law. I can show you all the personalities and locations in the Eclipse Code base if you want to know. The other big thing is we innovate but the big thing lots of people who are looking at a new way to do things don't do is validate it at scale. So they say, oh, look, we're going to try we think Scala is going to be better. You know, anybody can make that mistake. Type checking, sort of like Haskell except it doesn't really work. But you know, that's okay. Most of the time you get errors and sometimes you get this big long thing sorry, I'll pick everyone's favorite button. So the big thing we do is we validate this very quickly at scale because scale is really what you do. And then we have to ship it in three to four months. Sometimes we fail and sometimes it's five months but it's never six or eight. That means you have to be good at estimating. So when we are innovating we look for particular places to insert and what most people do is focus on the code. Changing codes really are. The big lie in software is that software is easy to change. You tell your friends we could do that, that would be easy. It's easy for the green field. Look, I did my website with Ruby on Rails. Oh, now I want to scale it. Now I want to do this. I want to change this. The technical debt cards are coming out like that, no? But it turns out that the places that are really high value are to look here. All the places where you've got interfaces to data. Because data is the goal to the corporation. And most of the time is the data, you can't get the data from where you have it to where you want it to be. And most programmers like it that way because they hate data. But how many people want a program in SQL? See, zero. They're all going to be unemployed because the future is going to be query. Programming in five years I predict will be largely query. If you're doing functional programming what you're really doing is writing query. Yeah, but look, let's scale. There are better than this. You're like general programming, let's scale. Perhaps. For you. But what about if we want to spread this so that normal people could do it? I think people here are normal. And I'll say this mainly is a brain block. It's nothing fancy about Haskell. How many people have found Haskell easy? Tried it? I rest my case. Okay, how many people try it? I don't want to go off on it. Why don't we take it in the question. Your point's well made. I'm picking some extremes for the thought experiment. Not because they're necessarily 100% true. Okay. So if you look at these points these are easy places to insert things and improve flow because typically if you know Don Ryerson's book which is the only really, really good book in lean, the book called Flow basically what you really want to be able to do is optimize these value chains and improve flow. If you have to you can go over and look over here in the code. Small computational bottlenecks you can do you can take some Martin Thompson style analysis reprogramming a small subset of Java get the performance up there use C++ with the atomics find out how to use Haskell so you can make it fast which is a bit of a challenge but can be done. Or points of high variability places where there's lots of change or points where a large number of defects anything any seriously defective model module what you want to do is cut it out. In general any code that survives three releases is going to bite you. If you're in release seven of some code you know it really stinks. So in general you're constantly doing this and in many cases not refactoring it's replacing. And in the reasonable language it's easier to replace than it is to try and refactor. Sorry about all that object coupling inheritance and all those bad ideas that we told you about many years ago. I too was a sinful sinner but now I'm totally immutable. So we just assume that you've got a healthy software environment. If you don't have small teams and do things the right way if you don't continue as best just give up. I have no help for you if you're not in that world except I can give you some counseling. I counsel a lot of executives who think that they can drink the agile Kool-Aid. Oh you're all the agile. IBM transitioned 200,000 people in one year by getting very pop and dick and all the people came in they sprayed a hose over everyone and said you are agile. Garbage. Okay so now let's get on. So basically I'm going through the life cycle from beginning to end and I'm just throwing out a technique which we found useful. None of these what I claim are original I wish I could attribute them all in many cases different people at different times we work with refine them the answer is if we wrote any of this down as a process it would be completely obsolete because every five years you just toss out everything you knew and you adopt new techniques. So the first thing is something we call extreme design. I learned this as a young engineering graduate one of my classmates started a hardware company said oh my god we have to build software I was a university professor and he convinced me to leave for a couple of years and his software organization and if you know how most hardware engineers write software it's kind of like many people write spreadsheets but it works and in many cases the software is fairly small so it's not really too big a problem they do believe in testing so but they had this crazy idea they would take four or five engineers and the marketing department said we'd like to bid on this project we'd like to get this business so they'd give you essentially the RFP the document they were going to bid on and they said okay would you please go out and tell us how much it's going to cost and how long it's going to take to build this and I'm three or four years out of school they provided dinner a big whiteboard and a lot of paper to write on and the first thing was actually a side-looking radar I had no idea what a radar was but I had no idea what a side-looking radar was or anything else I'm just like this is like completely nonsense surprisingly you sort of take the pieces apart someone explains how it works and guess what in a couple of hours you've figured out all the things you know about this you've actually figured out what the hardware pieces are what the boards are what the key cloud software components are in a couple of hours and you have some people there that have done some of the things before so they said okay it's done this much software that's probably how long it's going to take us we can see which we were now the hardware is going to take sort of this long and so after this sort of four hours and eating dinner we would actually go back to the marketing department with an estimate now what's an estimate an estimate is a distribution who gives single-point estimates you're all losers no one should estimate with a single point an estimate is a distribution so the easy way is what's your high bid what's your low bid how long is it going to take someone to put a man on Mars well Nita will tell us that answer but you can probably say 20 to 50 years the nice thing about a safe range is that it is safe because you've got to express that there's risk so we didn't get the right answer but we basically provided so this became very very important we figured out what we didn't know what we didn't know and what sort of technology and practice we used and sometimes people would go I remember the first time I worked in a GED medical scanner MRI scanner they were using objective seeds very early days in object technology there was a meeting for four hours while I debated whether or not sending messages was too expensive to use object technology unfortunately it was a break for lunch and they had a summer student that I met in the hallway I said would you please go down to the lab write something that sends 10 million messages and time it and pass me a note through the door and we were able to kill this whole discussion of a whole lot of people who didn't know what they were talking about because they didn't do an experiment so we experimented and we converted and we estimated the code and from this we actually ended up building a lot of things so basically the first rule of estimates is use two or three point estimates and in the end everything's in dollars and days so why not use them once you get used to money and once you get used to days they're not so bad that's how the company works anyway and besides the day when you do your story points up there somewhere poor guy's got to convert all your story points into dollars and days anyway so great your story points because you're afraid but the real issue that you're afraid is because you can't give the distribution and the big problem is people tell executives you know November and then deliver in March because you don't expose them to the risk and that's very important now if you're doing a big project and you're guaranteed it's going to be delivered on time so we're basically building you know the virtual machine and the ID and we're guaranteeing that's going to be delivered in a year and it fixed price to ID reasonably challenging given that Java had just been out for a couple years we didn't really know Java all that much we didn't have the source code because we wanted a clean room version we didn't want to end it on Sun now Oracle so you really want some other way to qualify this this is why you use activity based estimates so if you take the product that you're building I think this one came from an insurance company so I'm sorry if it's boring but basically you sort of say okay consider this thing to be a bunch of parts there's some Java code classes methods there's some APIs there's various kinds of tables replacing rating tables there's some workflow processes there's some data it's going to be probably relational tables there's some rules maybe a rule engine maybe simple decision tables forms, screens, printed things that's kind of what most insurance systems are made up of and if you keep the data or metrics for this I didn't say the word Kokomo then you basically have kind of typical distributions for what it took to do this another project or if you've never programmed in Java before you get somebody else in who has the experience because there's kind of metrics of work for how long it takes you to build a class in C++ versus Java versus C-sharp they're pretty close to those two but if you're the first time you're doing Scala you may want to know kind of what the metrics are like there so when you do this you've got your sort of story estimate in ranges really big featured estimates of it and then you have your activities by looking at kind of what's the manufacturing going to take how many of these things are there API's take are harder to write than Java classes so they take longer even a BA once they know or a product owner once they know that an API is hard they go oh as soon as the developer mentions they need an API they go find another feature they want instead because they know they're going to get taxed for three months for an API so they actually start making business decisions without even knowing much about the technology because they have a sense of the cost of the complexity of doing this and what executives get then is a risk window basically this is what the story estimate is this is what the activity estimate is and if the executive bets this point they will probably be a loser they'll never bet this point because that's not what executives do so they'll end up somewhere in here but this works for very very large projects that are fixed time guaranteed delivery and the more you do it the better you get at and the more you keep statistics on how you do it and learn from your data the better okay so enough of that so the big thing we found particularly with agile teams is they build the wrong thing and since code is so hard to fix what we want to do is find a way not to do this so we use an activity we call envisioning or just enough design and there's a bunch of things in here these all come from product engineering by the way many of them are not in any agile books because agile doesn't realize that there's a whole thing called product engineering that existed before agile existed and we all know that basically on the front of the card is the story on the back of the card is acceptance test acceptance criteria you all know that right this is how high up the jump that actually we did that at object mentor or something acceptance criteria is actually trademark Dave Thomas and not that I care so you know this is a classic example you've got the horrible waterfall calculator but then you've got the agile you know Bob Martin calculator that's why I like to poke jokes at you and so you know basically you build up one thing everybody writes a test you build this now if you're actually building a real calculator you have to make the plastics and the software together this doesn't work out too well because you get a calculator that you can do and you say we'll ship the first release and everybody thinks this is a useless calculator I need to do multiplication and division so what you really want to do is do just enough design to shorten this and we basically have a rule that we have to build every product three times so we get it wrong the first time really wrong but we do it really cheap we get it better the second time but still wrong it's usually too slow and too big and then the third time it's usually okay and then you have to throw it away and start over again that's the depressing part so this is an example it's a large, it's now an IBM product but it's a system that basically globally checks websites for large corporations to make sure they're access compliant, secure everything you want to do to check like global corporate websites make sure they're language enabled all those sorts of things and it's a very impressive product actually I think it's owned by IBM today built by a company called Watchfire in Ottawa where I live and it's built by a great team of Canadian engineers and has a user interface that looks like it very complicated, very hard to use so they had to build a new user interface because no one could use the product and so they said would you help us now fortunately the engineers were all busy fighting over which UI framework to use so we had a lot of time to actually work on this we had a couple months so basically we built a low fidelity prototype interaction model very simple, three different models basically two different visual forms different navigation and these little red dots are things you can click on and explore what it looks like we then basically did a concept prototype which basically went from 8 pages to 48 pages this is a very complicated product there's a lot of configuration three internal designs, two external ones we actually put it on an external visible part of the website really upset the company because I never wanted to show people what the UX looked like before it was built, after all why you want customers giving you input there are lots of UX silos inside companies everybody else posts their intermediate designs up on what they're doing, their iterations but the UX people they wait until the last one and then they put it up and say the UI is done maybe UX people are not like that but basically the UX silo is often as bad as a data silo in many organizations the last one is very complete three more iterations 148 pages external sessions less than 2% of the overall effort customers loved it how was this built it was really built by one guy over a period of a couple of months because he had to wait for people to come back it's built with interactive power how many story cards will that take billions can the customer really interact with it we've built many things including complete IDEs and so on just the only reason we use powerpoint is so we don't have to argue about them buying iRise or something else having a tool fight it does have authentic timing in it so it isn't completely fake when you actually click the page it says show me all the servers around the world we actually know we went and measured the time in the product to do that so you click something like that you'll see the appropriate delay so it's authentic in terms of the experience it doesn't give you instant response to show me 10,000 servers and that means you typically will change the UI so you'll show people servers and a given geography or things like that so you don't have to wait for the whole thing the easiest way to build things is not to write very much the software at all the best way to do envisioning is basically to take the three products that you want to take out in the market your three competitors and put those products together and say I like what's in this one I like what's in this one I like what's in this one and I don't want this and here's my other idea that's called delta analysis much easier than doing anything else they already wrote this back for you and often we actually build the product on top of somebody else's product we do the mock up, we stick things in front of it so people can see it and they say they like it we can build things very quickly this way and sometimes if we need to write code we'll write it in something fast pick your favorite scripting language so we can actually do that but we'll also test the hardware too so we want to know okay we're going to use IPv6 how hard is that going to be we'll actually go and do an IPv6 test so we do lots and lots of little experiments so we gain a ton of knowledge and then we can refine the estimates because we've actually tried to build this so that's envisioning it's a way to see where you're going and it basically means that you get the best wrong answer as opposed to just starting from a bunch of requirements architecture to me architecture equals APIs I don't believe in non-functional requirements anyways if you have a non-functional requirement security, performance then you should have a story for and you should have an acceptance criteria if your performance group is at the back end of your process along with your testing and you just don't do non-functional requirements the key secret with non-functional requirements is get rid of them make them quantifiable so you can test them so basically we all know architecture is a rule not a job except for enterprise architects I don't know what they do it's basically expressed in the code so you should be able to get all the diagrams any other thing you want from the code so what you do is you version your APIs into the code you can do this in any language you may have to have a common convention if the language doesn't support packages or interfaces or whatever but you can do it and that means you can actually say what's the architecture and the code will tell you I can't tell you how many comments I go into and you say so what's the architecture of this application there's arm waving somebody says well we did some uml diagram somewhere or whatever it is and there's a picture on the wall but it's really wrong because we did that a long time ago of course we're agile so we don't need any documentation anyway because we're just going to go away and let somebody else fix this code after we're done here's the story part smoke some dope protocols are very important because they were described in API and one of the things that people really understand is the protocol is really essentially a set of messages and what you really want to test is the protocol as a class signature or the function signature but basically for a file the protocol is open read write star close that's a perfect question you can actually put counters in the code to verify this and if Haskell and other people ever figured out how to do session types properly you'll actually be able to have them type checked that's currently beyond the current state of practice with regards to type checking but it's a really good technique what we try and do is figure out what the key APIs are we don't get it all right but we try and figure out what the key components are I'm talking about reasonably large things now I'm making major products obviously you're doing a single app or something like that you don't need to do this stuff when you get to build these things the good news is machines are really fast so once again basically really bad software is going to be saved by hardware right so instead of having this big monolith now which you can't refactor you'll have a whole lot of microservices and if you do it wrong like many people you'll have what I call dependency preserving microservices where the version signatures between all the messages is such that you still can't build independently this is usually the first mistake of people doing microservices we broke up the model it's all curious everything is in microservices but we still can't release any piece individually you'll miss the point so we want isolation and we can do that because hardware is cheap lots of processes in the old days it wasn't that people didn't know this was a good idea it's just that the hardware didn't support it the simplest kind of services one way data flow Fred talks a lot about those those are easy to do they're easy to build simple message you know pushing messages on the bus kind of an event model or data flow model you can also look at this new basically a much easier simpler way to do these things instead of having to deploy a whole bunch of VMs and a whole lot of services which is why did you see my good Fred Nadian Krakow now who's architect for Amazon basically he's talking about no ops but instead of having dev ops everybody learning how to spin up all the VMs and startle these microservices basically you just flip functions into it into a service you can just invoke so for simple data flow calculations you can just do that with lambdas and you're limited having to do all this sorry if you're just learning about this you know it'll still be here for a couple of years until no ops comes away but you know it's just too hard to do all this stuff occasionally disconnected the only thing hard and mobile is occasionally disconnected right mobile is wonderful except you don't have reliable sessions and so the solution here is replication and sync it's very well known that many people don't architect their mobile applications from the beginning to replication replication sync and so it gets very difficult if you really want to build complicated systems so you want to get into microservices which are messaging both ways and doing this you have just stepped into an area that's much more complicated than you think so my recommendation is if you can try and use simple data flow microservices when you get in this world you really need to know about a secret of state machines distributed state machines and that's going to take you on a journey that's a little harder to do so if you want to build something maximally concurrent high performance you're now basically doing what the guys who designed telecom switches do and if you want to really understand microservices even though you really want to program in a little language called Go look at Erlang and Erlang OTP because it is the exemplar for how to build reliable fault tolerant distributed systems and particularly the principle no exceptions and Erlang it's wonderful when a process or a service gets an exception it just fails and then the Erlang supervises our hierarchy does the recovery spins up another one and so on this is also why why do you use weird languages because they have the best ideas and so slowly many of these ideals will migrate in but a lot of things that you can do in Java look simple but when you get into architecting these complicated things you'll see that you need the kind of actor principles that are in Erlang and things like that keep it simple that's always true so this came up the last few times and it does a language and tooling matter the answer is sometimes the answer is if you can really do things like an order of magnitude faster then it matters but using C sharp versus Java it's kind of the same thing so often it really doesn't I know you want to use Emacs versus Vim or an IDE but among equal programmers these things don't tend to make a huge huge difference obviously you do if somebody takes you and forces you to do it because you've got I know where the hotkeys are in Emacs and then I got oh that was an IDE it's adorable or beautiful I'm an IDE builder you wouldn't expect me to like using Emacs but I do what you do for customers isn't necessarily what you do for yourself so these things are negative but some languages are really good at a certain kind of application and if you happen to be doing something that's you're really building a distributed system even if you're going to build it in some other language because you thought that was safer or whatever we could build it in Java because it's the wisdom of the organization it's really easy to get to have a program but you can get any good ones the problem of plenty is there not many good ones so good people in any language are hard but organizations like to believe that if they choose a widely used programming language things will be better little knowing how great it would be if they programmed in Haskell which has a very robust system and so on and the other one is like if you're programming in Haskell programming it's still a big way whether you're programming in Java or programming in Java I'm not quite sure that I agree that's the point here what you're really saying is that the people who study Haskell often have very strong degrees and are very bright and talented so there's some self-selection I'm not sure it's because they never necessarily did Haskell look at the self-applications what do you think? if you don't have coding guidelines and a tool to check your code it's crazy because you can't do JavaScript unless you have standards if you've got 20 JavaScript programmers you have a nightmare if you can't standardize them unless you want to be like Facebook or whatever it is they have a whole infrastructure for time to deal with the PHP mess and the JavaScript mess they do a very good job for it it's the second place to start 20-star engineers who produce very different styles and put them together obviously I'll talk later about testing because how many people know what property-based testing is? oh good, okay you got nothing outside of this talk? go look at property-based testing I'll talk about it later test versus types it's always a debate in languages that you can write fast in basically you're asserting properties the assertion of the properties essentially is an abortion of a type constraint however they're not going to be complete so in general the most important thing is you agree on what the tools are that your team uses and if you have some very special purpose thing they'll be using a strange language or how we call it an exotic language since I program in a language called Q which is very exotic the other thing that software people seem to not like is data the bad news is all we have in the future world is data but programs are going to be much more important and much smaller in many cases because they're just computing over data in fact they're doing queries like functional programming language or some dialect that we said query language so most applications are still just doing crime you never know it because there's layers of caches and rest services and all sorts of interference in the way so first of all this should be obvious but some people actually think that Jason is a good idea hopefully no one in this room please make sure your data has a schema and maybe version it I won't tell you how many companies where their data pipeline the UI people keep adding new Jason attributes in the middle that be in on the side so they have to know every time that Jason was changed and changed their pipeline to do the analysis so please if you're going to use some other kind of it please have a version and a schema so you know when it's changed and also a way to more from the previous representation to the next representation or else you'll never be able to process it if you know how many people know about your models and your relationship models if you care about data you should know what these are because the semantics matters relational tables lose semantics in many cases and there are really good query languages that go against the model make everything query using modern so the only API most things should write first as a query API you go along and say oh I got these REST services 100, 200 REST services all with a really nice name get this, put that find this most APIs the most important one is query write a general query API and it will be much, much faster whenever you see text convert it to binary do not allow the text to go past that point do you want to be fast text takes up 10 times the space sorry that's 30 times because you've got HDFS so you have to replicate it at least 3 times so it's now 30 times bigger don't put DFS do you only want it half time bigger maybe it doesn't use different distribution for redundant so it's now only one but it's still huge but the real problem is the one thing we can't do easily in parallel is parse text so you now pay a major execution cost and this is for all of you horrible people who use noSQL you all loved it as programmers because you didn't have to know anything you could just shove it in there but may you have to write all the programs that have to read that data and have to parse it over and over and over again and burn up all those cycles get rid of text get the data in the binary as fast as possible and if you want a very good efficient serialization program instead of thrift buffers or thrift or Google protocol buffers this is SBE done by Martin Thompson it's much faster than many of these things for serialization between Java C++ C sharp and so on and get rid of the infrastructure data for me to speak up there's a very old architecture which all the things microservices, lambda architecture pubs up basically were started in the financial industry many many years ago now once they get to California new names like lambda architecture and make up something about Kafka and tell you it's really new because it's really just a logging system and then they implement it in Java so it can be much slower than the real implementation why is Java bad because it can't actually reference more than 24 gigs of memory in any easy way you can get around it but the Java VMs today are designed to work on reference types if you have lots of big data you need value types referencing garbage collectors therefore are constrained to go to 24 to 32 gigs so this is causing Spark to be completely rewritten because they have to use a non Java standard architecture now value types of course are coming to Java 12 or something some year if they ever get Java 9 so there's a very simple architecture of mutable data which is called, and the lambda architecture is called an RDB a real time database and a batch database and if you want to know a consistent state what you do is you send the query to both those databases and you get the exact answer consistent at that point in time and on a regular basis the real time database is applied to the historical or mutable databases that immutable data is added so at that point it becomes 100% consistent which is typically maybe a couple of points during the day depending on your body and the financial industry is guaranteed overnight because there are windows but there is no stop being processed very simple scalable architecture because you can set up it's immutable which is claimed to be a thing from functional programming but immutable data existed long before functional programming tried to claim it and the other thing is get rid of as many data caches as possible a cache is a bet with the devil but you bet that you're going to be right and then you have to worry about clearing it, resetting it today there's modern in-memory databases that handle this stuff instead of you manually figuring out how should I put this in memcache or redis and then put it back into Postgres or whatever get yourself a real in-memory database so you can do this properly and basically traffic and records and tables we all know that no one should use an ORM ORM is just a way to slow down data and waste memory and raise the garbage collector so you want to traffic in static data and you want to minimize the number of data conversions especially text the other thing that's very important is that programmers are really expensive software is really expensive and hardware is really cheap and you know really fast hardware it doesn't talk back it doesn't complain it doesn't have technical debt cards it doesn't whine so this is actually old but if you go to Dell online site you can buy a box for $15,000 which is a lot cheaper than I can pay a programmer even in Singapore and you know I get a terabyte of RAM 100 terabytes of disk and 64 cores which size is it which size is it which size is it it's not cheap go to Dell so you know things become really interesting when you get machines like this you need fewer programmers because you're not working with several representations for many people their entire data fits in that one terabyte guess what queries are pretty fast programs are very simple you don't even need complicated indexing things like that clearly you can use indexing basically all the interesting things in memory there is a new technology coming called NVME memory 3D cross-point memory both of these are from Intel one's a little faster, one's a little slower this is cheap that's expensive for me it's cheap because programmers are really expensive but this memory is available now we've just done a benchmark and we were six times faster than the fastest stack benchmark NVME memory and 3D cross-point memory are non-volatile byte addressable off the bus faster than SSD not as fast as RAM so we're now seeing a memory tier and within three to five years it will not be any spinning rust there'll be no disk rust this is the way if you've got HDFS you fix it but you put big NVME arrays in front of it and then you make it faster so there is a solution if you've got a Hadoop cluster you just put it in front and say it's just a cache a silicon cache I fixed my Hadoop mistake that's all right the other thing is decompression and encryption is actually on board in the hardware it's faster to send messages each family how you doing it's faster to send messages between processors than it is to store between processors this is a high speed message bus now you've got 64 cores basically data compression and encryption is free because they're actually running on the processor so it's now possible to do encryption encryption is still a little challenge but that's going to get fixed we have to change some OS's and things like that so you can do much simpler than this do much simpler than this and it's very easy now you can start doing self-serve computing because you can actually give people out we're talking about a petabyte of memory in a rack like this petabyte worse for security a USB stick with 10 terabytes but now all these challenges of provisioning and who's going to query the data and so on data like the box so this is going to revolutionize the way people do analytics and looking at data and it allows us to take really nice sort of functional programming query oriented programming models and make them the norm so that people can do this without a lot of complexity okay so now some really old tricks when I graduated from university there were these people called systems programmers and systems programmers were the you know they were like the Unix today they'd be like the Unix kernel guys or whatever it is and they did amazing things they all programmed an assembler machine code basically with key word syntax but they had this technique you know they were table driven programmers so it took me a while to understand what I mean they actually encoded all of their operating systems their databases their applications into a whole set of connected tables so essentially what they were doing is interpreting a set of tables and this has a whole lot of things first of all normal people can do it so you can actually specify the requirements it's very dense expression so the tables are very dense it's easy to recreate and refactor you can do them in a spreadsheet they're modular because you can break them up you can actually check them there's rule checkers that will check whether they're consistent or conflicting for different kinds of tables so you can debug them they can be automated very efficiently with a very simple fast interpreter or you can compile them if you really want speed but in general that's not needed and the nice thing is how often you'd like to say we'd like to do a hot deployment of this change in my application so it's just data you just update the data it's deployed meanwhile you're busy fixing your CI pipeline and everything on your continuous deployment so you can get things up to Amazon when all somebody else to do is actually write to a file why do you make it so hard put this jar over here put it in there change all its if statements in my code so hard I don't know why people do this it's a really old idea and I don't think they tell people though it's another type of table decision table this is really good for doing complicated rules the insurance situation I mentioned was basically you know you can specify your complete insurance system between spreadsheets and decision tables you can document the requirements for what the insurance system can do I don't have time to go through this contact encoding and a very simple interpreter to execute these and I've used these in real time control library systems and normal things it's another type of table called a state table or a state diagram most people study those they're equivalent to regular expressions so everybody's done something simple you know it's an A followed by a 3D, followed by a C these are used and also if you have a complicated UX even if you're using RX manage to figure out RX there is a little learning curve basically you have to learn functional programming and a few other things but if you have a complicated UI and you want to hold the mouse down and drag it over this and not debug all the horrible things are the events bubbling up or bubbling down and JavaScript and did I catch it here or catch it there and you can actually define for all the UI and interaction models what's going to happen and when you fill in that chart you'll see all the cases that you don't cover in your code so this is a very powerful technique you want to build asynchronous communicating processes then you have to build distributed state machines unfortunately most people in modern computer science don't teach any of these and it's really sad they're very compact they're easy to implement they're very fast to change and the tables can be directly compiled in the code this is another example of the table but it's got a different evaluation model everyone loves to love and loves to hate spreadsheets but spreadsheets are actually a very simple model for people to use I've worked with a company called Xerox Special Information Systems many years ago and they built a spreadsheet the analyst the spreadsheet serves analysts for a particular agency and it's the only spreadsheet that can conjugate Russian verbs and analyze satellite but all the different users can use this spreadsheet because they understand the model so it's a very powerful model and today on Modern Hardware the spreadsheets we build have trillions of rows in a cell so you can actually run your business on a spreadsheet so it's a very simple way to do this you basically have to take the graph check that it doesn't have a cycle and then just line the things up there's a technique called a topological sort which does that you can also do it on demand but you might as well sort them because it will be faster and then you can evaluate these things imagine that now what you could do of course is you could write it in a spreadsheet or a table and then you could write 10,000 stupid cucumber tests that are going to be wrong that you have to maintain and then have that all implemented in Java and waste all your money in time please many of these things can be automated right from the requirements and the user can change the table so instead of the poor BA suffering learning when some buy so because the programmer doesn't want to understand anything about the domain which is ridiculous they don't use cucumber go teach them about your domain when we have people in finance we teach them finance and options and then we teach them coding we do it together so they can talk to the different students otherwise you're just a programming robot here's like cucumber make it work and you always fragile test fragile cucumber fragile unit test time to go back please no more but for the right job so you can automate all these things and when you automate them you can actually do this so here's an example, it's a real system and actually somebody who may have heard of Kent Beck the guy who invented XB can't work on this system originally in small talk but now it's in Java it really doesn't matter there's not much difference between small talk and Java except one's easy to use they are similar so this is a company having the base in Chicago and they do the benefit calculations for a whole lot of other companies so if you work for a DBS and they give you, for example in America they give you a little card and say DBS loves you, if you have any questions about your benefits call this 1-800 number and we'll take care of you and what happens is someone answers and says hi I'm from DBS Benefits, I'm here to help people they actually work for this company they basically outsource almost everybody's benefit but benefit calculations are very complicated in the United States for example if you live in Colorado you get the first three days of hunting season off there's all sorts of goofy rules like this fully done Canadian more rude than anybody else so basically Kent was in here and of course they had small talk which is really fast you can refactor really easily that's where the refactoring was easy and then when you're in Java it gets much harder and basically so they captured the requirements because they'd actually be negotiating meetings with all the guys smoking big cigars and drinking in those days negotiating with the unions and so on and the analysts are working out and the spreadsheets what the benefits are going to be and when the pays are going to get out and all these things and then they come out and they had 100 cobalt programmers because it ran on the mainframe still running on the mainframe and they were saying it's just too slow to get this done so of course we went in with the latest this was before this was actually before Kent wrote the book XP actually this wasn't that long before and basically they did sort of Agile and OO and they got a 10-50% speeder you all know why would anybody do that much change we're going to retrain all these cobalt programmers in the small doc programmers to get 10% why not everybody else is doing it 10% is a big deal for people who can't get anything done Agile basically makes it so that people who couldn't get any software done now can barely get something done I hope this is going to be a record on that but I'm known for being pretty outrageous so basically this is a very big IBM customer at the time and we had basically we had small doc that would run on the mainframe or the workstation or whatever and everyone's sort of dying we're not the miracle drug what do we do we can't very astutely say look they've already written everything down in the spreadsheets we're trying to take all the stuff from the spreadsheets which often have bugs in them and re-write that and code tons of code suppose we could just execute the spreadsheet so they wrote a spreadsheet interpreter in small doc it's in Java today still running so the cobalt program and everything like that just run no problem multiple languages work even on the mainframe they wrote a spreadsheet balader because we're bugs two guys wrote this all the other people were already deployed somewhat productivity two small applications I can't tell you how many times we've used this trick many times okay how many people have to deal with enterprise applications congratulations you get to talk to SAP BW for so and so so one of the easiest ways to do this the big thing you want to do is if you have to talk to most existing applications when they say they've got APIs they basically had no APIs and then what they do is they come along and drill holes in them and put in APIs names and sort them alphabetically so you can't figure out what they are all these big systems are like this and usually the API gives you half of what you need to know and usually it does it slowly so you have to write all these interfaces and service to all these APIs this is called enterprise integration and lots of people do it the API field agrees give them another 100 APIs and the applications will come you're wishing so the first thing I do is I actually read the data physically from the disk a lot of people don't like that so it turns out that the disk formats are actually very stable there's not much difference between an Oracle page and a TotalDB page you never heard of its old database almost all databases the physical page format is pretty well known and everybody's afraid to change it and nobody encrypts it maybe they will the legislation changes you can actually write software that sits in the Xanarrays and read all the disks blazingly fast put it in memory and we just get at the data it's what APIs did we use? zero that's why it's fast the other thing is you can make read-only replicas for something so you put everything in Mongo because it was easy and then you found out people wanted to report from it so then you can write another program that replicates it into MySQL and you can use crystal reports or anything else or anything like that we made it really fast for us now we made it too slow for them so we have a fix install another tool replicate it this is one of my favorites it turns out that almost every all software out there whether it's written by old company IBM, DEC Univac or new company has even IBM's oldest products actually will actually give you all the journals and everything NRSS are added for that so once you've done this you can now consume it with WebTool there is no API there's one API called REST Anatom or another thing is a query SBI and often if you have a really ugly old database or an old store this will be you trying to get your data out of Mongo in the future so what you want to make it usable in Mongo so what you do is you buy an OEM ODBC driver and you put it into Mongo so you can take things that look like SQL queries and execute them in Mongo do all the parsing behind the scenes so you won't have to make all the users suffer for the fact that you use Mongo or any other blob store not hanging on Mongo specifically and profitable so you do this then you can basically handle it really simple again all we did was democratize the data here's an example big industrial factory control 300 million dollars with a factory control equipment you know these companies I've published people like Rockwell and ADB they make all sorts of special control systems they program them in a specialized language called ladder logic which has some really interesting properties about it about correctness and so on so it's not it has a nice thing the programs you write are deterministic which is very very important in process control but they actually make everything non-standard they take the pins on the bus and switch them around so they're non-standard so you can't plug anybody else's boards and do all sorts of nasty things like that so they patent that as some reason that their system is better because they put the pins backwards because somehow there's some benefit of doing this this is the best of proprietary so you've got all this equipment and now what are you going to do well of course what you do is you have a team that's going to rewrite everything or you're going to buy all new equipment it's not going to happen so the solution is pretty obvious the first thing you do is you basically stick a TCP IP card because they all have proprietary buses and messaging and so on you stick a TCP IP card into the main controller so it can talk to the bus on one side and it's proprietary format and talk to you TCP IP so now I can talk to it what should I talk to it in well if I just take all those messages and expose them through a web interface I'll build my whole control room with a bunch of websters assuming they understand how to do web sockets asynchronous stuff good ones will so coming up to the end testing testing is still hard really hard it all starts with a second criteria includingilities if you don't have performance requirements you won't have performance you don't have usability requirements so you can test how many clicks before I get the patient in the hospital I won't say who this was for but it took 50 clicks 50 plea strokes to get a patient into the door in the emergency room even when they were bleeding all over the floor I think they need an acceptance criteria and those run every bill and if the performance changes or the usability changes it takes the bill you can't deploy there is a technique called property based testing that I want to talk about and I'll talk about the others and then I'll be done going on too long anyways my apology property based testing was invented by a wonderful guy called John Hughes with John Hughes last week was done for Haskell it's called QuickCheck QuickCheck does is you assert essentially this program will satisfy these properties so you build simple models which are in the beginning just kind of just equational statements and then you say I'd like to run this on my desktop 10,000 times and in my build 100,000 times and what it does is it takes that test specification and it has generators for each of the types if you have fancier types then you get to add your own generators and it generates current values from those generators and does all the tests now randomized testing has been around for a long time and the good news is it definitely finds bugs the bad news is it gives you a huge list of things that fail so if you generate a million tests you probably end up with 10,000 failures and people go well I got to look through the false positives I got to figure out what I did is it has something called shrink so what it does is when you get the failing test it finds the smallest sequence of operations that fails and this has been used to find serious bugs in things like React which is one of the best distributed systems 90% coverage written by PhDs John worked on and found like 8 critical bugs and something with 95% code coverage LevelDB which is in your browser done by Google super smart guys they found a sequence of 24 operations that calls LevelDB to fail at first it was sort of contested that's not really true Google issued a patch a couple weeks later a couple weeks later found a sequence of 32 operations that caused it to fail so you need to move beyond unit testing towards property based testing maybe you can kind of think of it it's like a unit test but basically it gives you as many as you ask for because a unit test did it only asserts one value whereas this is going to suit many so you can sort of take baby steps as saying it's a way to go from getting more coverage out of a unit test when we wrote quick check for our environment people converted in a week they just stopped writing unit tests it's really good and there is a way because although it is functional you can actually use state so if you extend it you can actually use state it was used to test all the Volvo automotive protocols John's doing another project now basically self-driving cars this stuff is very very handy and if you see that slide that's the John's thing that talks about that it's a great talk on testing and all that stuff I know ThoughtWorks did Selenium wonderful Selenium is and all these things but when you're building complicated UIs by the time I get Selenium done I've already changed the UI five times so I want it to be true if you're just doing the banking screen enter your bank account and so on you can definitely do it on the other hand it shouldn't be that hard to test that so what we do we're building complicated UIs is basically every time we get very much UI code that goes in we measure the amount of code I forget what the current threshold is we freeze the code base for three days maybe just one day everybody switches and works in everybody else's code because that way they actually find out what other people are doing we do pairing some of the time not all the time but when other people have to use the product you're building they actually understand what it is they get zillions of bugs so the JIRA or your bug list goes way up and up hundreds so it goes like this because you get all these things off by a pixel this menu of things missing all these things for which you could never write tests even if you wanted to within two or three days all those bugs get closed and they're typically never coming back when you do this frequently enough the quality of UI improves I'm not claiming it's best practice but the best thing I know for constantly changing sophisticated UI's if you can show me how to automatically test this I'll be happy and I will advertise your name and lights every place I go but this is the best practice that I know for doing it the other thing which is an old way is to actually have two people write the same program it's a different kind of pairing so you have essentially independent implementations so a couple places where it's really effective for instance if you're doing something that's algorithms Eric Meyer and Brian Beckman do this all the time I know several of the people David leaves they basically write the stuff in Mathematica so they've got this and they generate examples from the Mathematica and then they compare that with the actual implementations say C-sharper Java to independent models and Mathematica is really cool with Mathematica obviously the other is for doing big operations on databases like major transformations like I've done a lot of database restructuring high performance database restructuring means you have to swizzle things fairly cleverly you can't actually use the database itself it's not under the hood so we have an independent test or implementation of that it's very very effective and they're often much cheaper than trying to write a lot of complicated tests particularly for things like data there's a lot of invariance in the data so all you have to do is essentially test the invariance this is just an example and we'll finish here this is a company that we talked to basically they had a manufacturing product very very successful they happened to build it on an old database you know they built it on top of you know gemstone as an old database gemfire or maybe they built it on top of db2 pick whatever database you like to hide hey couch dbd whatever it is and of course the first thing is they couldn't report this wasn't a normal relational they're queryable database so none of the customers could report all their end users wanted to report so we already learned this trick you see I really don't know very much I just keep using the same tricks so the first thing is we implemented an odbc interface to their old database doesn't do everything an sql could do but it does most of the things that people need for reporting went to a user group meeting you know three months usually when there's users screaming we want to get off of this product we want to convert but we really like the what the stuff it does but we want we're worried about the vendor technology and the fact we can't report from it they announced you can now use you know your favorite crystal reports whatever it is the fans go wild they even place a few orders companies gone from being in rack and ruin having a chance but we still got to get the data out how are we going to get the data out well basically we need to get this locked in data so we basically brought in an expert systems integrator and we did a high performance bulk transfer from the old database to the new database this is something that I made my living at in the late 70s early 80s so we can move any data anything else restructuring the database at disk speed essentially the database refactoring but it's very complicated it can be quite tricky so rather than try and test this code we actually had a separate company develop an independent test and comparison program that basically verifies the properties of the connection of the data the financial information is in it check some of the data and so on see all done in three months so you'll see that I'm really an old dog I'm not going to use tricks but often if you think out of the box and you say look if anybody else is going to do this they're going to need a lot of smart people and we don't have that many smart people so what we need to do is find a smart way where we can write less code and do it and using tables getting to use query query is the gateway drug to functional programming so I talk about collection-oriented programming I'm not going to say monad in the audience but the future is going to be about writing programs today the people who write optimizing compilers really complicated where they used to have tree walking find all the data where the dead spots allocate the registers they do that with queries they write in a language called data log which is an equivalent to SQL just a different syntax and if you're a closure person excited because the atomic uses table but more and more things you can do with query and when you can do very powerful query you don't have to have all this complicated stuff you don't have to save all this state you can just have immutable data and work on it very quickly thank you very much I've probably gotten way over time it's a privilege to be with you and I hope there's at least one thing like property-based testing that you can take away with you thank you a lot I hope we'll see you next time I'm happy to take questions or corrective remarks he's already got enough so he has to wait till the other people so on the screen you'll see a couple of questions that already have been submitted so we're doing a Q&A session tonight through pigeonhole so if you want to just jump on to pigeonhole.at slash yownight you can vote for questions that are already on there or you can submit your own so you can put your name up there and then we'll start the Q&A session Sarah Gage is actually going to help us facilitate that Sarah Gage you want to jump to the part well my job is easy I'll just read the questions today that's about it I've heard he actually changes the question it makes it harder right so Dave the most question is how do you validate the scale the answer is we run it we run it in the production environment so I don't know this test but when I test I test in production but I assume you have a quick way to revert to the previous session and typically we're not actually mutating so we're in the production path so we're running against the production data the other thing we do is take it back often we don't need to the data is stable enough we also can take a backup copy of the data last weeks or whatever it is because what we're testing is can we run this fast enough will we get the answers right things like that so you can also do it against the backup I have a follow up on this I don't know who asked the question but did you mean the performance scale or did you mean the organization scale no specificity alright my view of the way companies change is you basically establish small teams like this that do these things and you get one and it works and so then you've got these sort of SWAT teams that you can put on important problems systemic transformation is expensive it's a nice idea but it doesn't deliver value in my point of view to the organization spending a whole lot on a big agile transformation is a good thing to get the health of the organization to have people consistent testing in principle when you're playing your agile don't have a CI environment at all which is crazy Java is enough Java is correct and by the way you can vote for the questions that you want to pop on top and answer it quicker on that you're always wrong so Dave if tables are so much better why are cucumber style tools more popular than fitness style tools good marketing for one thing I think fitness only has one kind of table it was a very simplistic tool the tables I'm talking about actually have meaning in the domain and are usable in the domain so there are actually domain tools that people who are analysts are people who specify things use like spreadsheets, decision tables, state tables those are tables which have meaning and can be directly interpreted I think it's really just marketing and developers like syntax so they like the idea of another language cucumber is fine it's just extremely verbose I mean BDD is a great idea Dan and Coco are both good friends of mine Coco will be here in September but my point is why spec by example when I can just run the example so I'm programming by example if I can give you the spreadsheet and run it why do I want to convert it to test so what about the stable bookkeeping that the TVB is supposed to promote I can I test the spreadsheet interpreter so that works so I test that with conventional tests, I can write cucumber tests so I test that with regular tests property based tests but once that's correct all I'm doing is interpreting the table so I'm not changing anything so there's no religion and the thing is tested and it's much smaller maybe the program's over this yes it's been tested the interpreter has been tested so all you're doing is basically interpreting what do I think about the spring boot I think it's really interesting I was just with Josh Long and Perth during one of our several speaker dinners I got an update I think I think it's a really interesting way to go and I think what they're doing if you believe the portable, this is once again Java's portable provided to use spring I think it's very interesting I think it's a very nice framework personally I like to use sort of Martin Thompson subset of Java so I actually prefer just to write small, really small applications and to have a lot of those be kind of interpreters and I could use spring boot for doing that but I don't find the one thing I learned from opportunity programming is that frameworks are a bad idea they inject dependencies into your program but I think of the frameworks out there it's quite clean and the fact you can do it on multiple platforms I think it's very nice so I think spring boot and spring cloud are really quite interesting unfortunately I don't have the program in Java anymore so unfortunately okay so how should bigger product companies do HR since you said enterprise at Java is an oxymoron we'd love to hear more about your experience with IBM some of their results seem great well the marketing department can make anything spin I think on the transformation side for organizations anything you can do in a big organization to change the culture so you get people working together and so on significant so again an agile transformation 10% improvement in a big company is a lot to the bottom line giving a quality of life to people building software giving predictability to the organization these are all big benefits it just turns out that the CEOs that I work for expected a lot more what they really expected was agility and so the problem is agile doesn't bring the productivity and doesn't bring the flexibility, changeability and so on you've got a whole bunch of applications and tables they're inquiries people can change those even people that are not professional developers so it's really about how quickly can you flip things and turn them and I think the fact that many people are still doing OO and still doing unit testing despite the fact that there's been better things for 10 years is kind of disappointing but you're going to die an obligatory programmer please look at any, I'm old so I programmed an every new program by the way, anybody heard of structure analysis in line and your granddad do that do these data flow diagrams everything like that, remember that they're called microservices that's what they were they had the right idea but the wrong implementation except in Japan where they actually run the data flow diagrams as separate processes in some of the banks they're the only people I know in the world who actually took data flow and implemented it as microservices in the 70s okay, why do you recommend that eliminate as much data cash as possible so caching is the one trick pony for performance the problem is cash management is tricky and as soon as you get into maintaining server side database cash mid-tier cash client side cash you have to maintain all the consistency between these and so caching can get quite complicated so if you can basically have something that's fast enough so you can just take giving the data which is what you can do with most in-memory databases you have the full power of a database that can select and get the thing and so you can just use queries against it and you don't need the intermediate cash obviously caches can help but in general they give you inconsistency and complexity and when you get a cash problem they're really hard to debug and they're hard to test okay so by the way please keep the questions coming and the words up okay so software engineering courses fail as fail as as the focus is so much on object oriented and object oriented so I am still an adjunct professor and in the courses that we have we always insist that basically we have what we call the neat and the scruffy in the neat stuff we teach people like what computation is about so if you've read the wizard book that's what Bob Martin calls it if you didn't know it it's called Structure and Interpretation of Computer Programs Abelson and Sussman if you read that book you will think differently about computation if you make it through Haskell you will think about it differently but if you don't understand that computation is about essentially environments where the bindings are and moving the processor together so what's the difference between object oriented programming and functional programming object oriented programming it's like you're trying to be sustained in object oriented programming but in terms of how the programming name would you value that's a one question I wanted to answer that question so the difference is if you understand computation is that basically in one case you basically get the function the method name and you have to go look up in the environment that's called object oriented programming in the other case you get the environment and you find the function you get the function and the environment you have to look up the environment and the lexical scope but if you actually understand what a metacircular interpreter is you can find all the differences between all these different programming languages so if you teach something like the wizard book or there's a equivalent in Haskell you can do it in other languages like what evaluation is really and then the next person comes along and says oh this is go, what's it like you just look at it and say okay the type system is like this here's how it does the binding oh it uses csv for messaging I sort of know what it is so that's why some people can quickly go from one thing to another because they know there's not much difference between these types there's some control statements there's some operations there's regulation order there's scope rules and so any worthwhile department in computer science will teach that ideally in second or third year in America we tend to teach scheme I'm in North America I'm Canadian in Europe in certain areas it's often Haskell some other places Miranda or other things but basically seeing different kinds of computational models seeing what prologue is like in prologue you don't really have variables you have binding chains that you take but the evaluator is very easy to write so in one course we teach students how to implement prologue with object-oriented programming pure functional programming with no force evaluation thanks so which one is better for partial text searching database cache database or in memory with this you're searching well I mean I think if you search in the cache all you can see is what's in the cache so you really can't search the whole database you can only search what you put in the cache that's the author of the question one to specify anything else for this I may miss the question you probably put it in the cache because your database isn't possible what are technologies for directly interfacing and querying hardware directly you're talking about building hardware like VHDL design languages or you're talking about talking directly to like the Intel latest Intel chip so you're talking about doing low level programming against the actual hardware like the CQ and so on is that the question probably your example of factory controlling system so I mean most of the things that to get to low level I mean you're constrained by what language is run on the machine most of the time if you really want to get to the hardware you need to get something that generates instruction sequence that are predictable so you want to use a compiler or a language which you actually see the code that it generates because lots of things promise like in C in the old days you could say register in C and you actually put the result in a register now it just goes don't say that I know better I'll choose which register to use that makes it very hard to write a virtual machine because it's hard you can't write it in C because you can't control the register allocation so C isn't a very good low level language but unfortunately there is no language on which you can say cache A, B, C, D because caches are based on the statistical usage of the data so you have to know a lot more about your algorithm and today the new assembler is called LLVM bitcode so you really almost every machine, every compiler will now generate or interpretive of that will generate LLVM bitcode which is kind of portable machine code or portable language so if you want to do that I would say look at that but if you're working in old hardware like process control basically you have to find probably it's the C compiler that you can use and then you turn on used to be called the listing option and you actually see the machine code that's generated and you code very carefully because if you do anything fancy a compiler often spills things of registers so you don't write anything complicated and usually you can do that if you're on a modern hardware and you can use Java and you read Martin Thompson's mechanical sympathy blog he'll show you how you can do really high performance stuff in Java but you have to use the Java intrinsic same with C++14 C++14 has stuff to deal with concurrency and cache lines and things like that but it gets pretty specialized and that's one of the reasons why you want people moving away from doing that because most programmers do not have the sophistication to do that and the hardware changes for instance the new hardware has vector instructions on it now so there's 512 bit the current hardware is I guess 256 or 128 the next generation so you can actually do vector instructions so you can do an add 16 or 64 words at one thing it's very hard for you to figure out how to generate that instruction the only way you can do that is by having control of the machine and that probably means you're going to have to wait for the C compiler two years after the hardware came out in our case we control the generation of the machine code on new hardware within a couple of months but that's because we generate all our own stuff but if you rely on the C compiler the Java compiler is going to take a year or two for them to catch up they've got to change the JIT a bunch of things or the C++ compiler this hardware is changing quite a bit my advice is unless you really know how to on small machines like if it's an arm or a raspberry pi you're fine you can just do it with C or mind you raspberry pi is overkill for most applications it's really a desktop with a lousy screen keyboard you want a real microcontroller you know go work on a pick or something like that because those are cheap and you can use them and you can put them up in your lamp posts and other things like that and they're very inexpensive but you see you need real programmers for those because there are 16 bits and you can't use Java C++ so you have to be a real programmer maybe a programmer with tables alright last question so far how do you assert if an organization has the trust culture that you're at? how do I assert? it's pretty easy you walk into an organization you can usually smell software burning so the first thing is you can listen to the police deep you can listen to the continuous build you can look at what the teams look like how they're reacting, how they're having fun you can talk to the management and do they believe in the tooth fairy you know often executives believe in the tooth fairy you know they they don't really understand software I was an IBM vice president I can tell you out of I don't know how many I think we were 200 vice presidents just to want to make sure that was really significant 200 of us and most of them got paid more than I did and basically but I would say generously there were 10 people at that level who actually understood that's why we have this revolution in Yao we want to get you people up the ladder so that in a generation from now or half a generation the leaders and there are already many companies I was at SG Power a great organization I know many of you know them a few of them worked here are here you see the teams working at Pivotal you see the teams working at ThoughtWorks and their customers these people get it but we've got a big journey but if we can network together and we can learn from the best in the industry and share our techniques in five years Singapore will be a different place because you guys will change it our privilege is hopefully to be able to share a little experience and bring some people that have done things wrong before and share what we've done wrong maybe a few things we've done right and try and convince you that you can do it but you'll have to take some risks doing the things that I'm talking about are risky but when they work and I tell you if you do this three times in the organization you will find out that the whole organization shares if you screw up then you'll be out but no risk it, no biscuit right but if you want software to be better those of you who are really talented need to take those risks many of you are changing organizations and the privilege to visit some this week and hopefully more but you can just tell whether it's trusted do the executives ever travel from that place in the sky to where the software people and walk around and talk to them or do they only go by hoping that no one gets in with a t-shirt and smell it it's a test I've had to take executives billion dollar corporations and push, stop on the developer floors and walk around with them but many of them are afraid because they don't understand what they're doing so one of the things you have to do is take the time to explain to other people what you're doing and take your patience many people, the world changes a lot and people who are older in software have a lot of skills they know how to do designs but we come in and go oh you're a bonehead you're developing a job I can't believe anybody uses that old stuff anymore I'm just using what you used on the football program your time will come so what you have to do is respect those different technical cultures because they can tell you a lot about high performance transfection process if you want things to go past you don't use threads threads are a really bad idea and you run them through a single process that's how you get performance that's how high performance systems work they don't use threads and you don't have to worry about semaphores peeing and being on things getting cocked up in threadlocks and all those sort of things you just keep it simple and fast those are things that someone old can show you you can show them how cool it is to do this and look how expressive it is now and my code is so much simpler and it's so much cleaner so technical cultures really put barriers in and they're much harder to deal with than working between Japan or Singapore and Canada so if you reach out to the other remember most of the people the people who do all those people in HR that don't listen to you or the people who make you do stupid reports they didn't make those up they got people soft God forbid and now the whole world is driven by people soft you can't even redefine a group because they control the LDAP it's really ridiculous but you just have to think that these people are kind of an API and the only way you can speak to them is by sending them spreadsheets or Microsoft project so just respect the API don't reach in the organization you can't change their code just respect the organizational API have your automatic build produce Microsoft project or whatever they want I mean when I do that the finance office comes out and hugs me and says wow you're so great because all the rest of the agile people told us to get stuff we're stupid and brain dead you just give us Microsoft project and everything like that and all I did was just take it and give them what they needed it's not their fault that they need Microsoft or Microsoft project or people soft or Primavera or whatever these arcane tools are so part of it is trying to respect those people in the other organization trying to understand what motivates them how can you help them when you go to the DBA it's hard to change database it's not like doing Ruby code so when you go get lots of space put lots of extra tables in make some planes in the building it's not simple refactoring there is some physics involved databases are like that too so when you renovate a building you always try and get more space all that comes to what they do is get the biggest empty space they can and then they lose it as they grow and talk too much no worries do you think Ethereum blockchain would disrupt the software space with their smart contracts and apps what do our companies have joined Ethereum Enterprise many have joined and many have left that's a fact I think Ethereum is a really good thing blockchain is an amazing very interesting thing we have a company that implemented a complete Bitcoin exchange it was implemented in a few months it's actually trades derivatives and other instruments using Bitcoin I don't know whether Ethereum will disrupt I think blockchain definitely will disrupt in the end I think blockchain is going to be an API that I talked to the thing for blockchain to work it has to be widely used and so that means there are going to be some winners and some losers I just like to know which one it is because otherwise I'll have to write five different APIs and the APIs for blockchains are really terrible right now Ethereum is a better one so I think it will make a difference for some people in business maybe it will put me out of business because I do fast data maybe they won't need it anymore but there are still lots of issues with blockchain and one of the issues very simply is how many people think there aren't governments or individuals that can get enough computers to actually take over the blockchain I know a company that does analytics on blockchain they actually know over 30% of the blockchain when you know that percentage of the blockchain notes you now can statistically predict a lot of things that are going on so we don't know really how secure it is now obviously in a closed loop so if it's all the banks or all the container shipping companies are using it and secure and they can do that that probably works but I don't think it will I still think people are going to want to do things and some of the blockchains are computationally pretty expensive all right thank you is google protocol buffer better than jason in terms of speed for transportation of data over wire like jason are better than xml well jason has smaller brackets I mean google if you're in objects then google protocol buffers if you don't know about sp is considered to be fairly fast it's not actually that fast so if you're using an object language then protocol buffers is often the way you want to do it obviously if you already got jason in your store then you can do it in general I don't like sending text around so and by the way when I said query anybody heard of facebook graphql so for many years I've been insisting that basically rest is a broken idea you have all these rest endpoints in the end all you really want to do is query the web and get your answers back you heard me query query and facebook ql is a first attempt to do that so instead of a whole lot of rest endpoints you have a query 180 i obviously updates a different issue so I believe that's the way things are going to go and we're going to end up getting rid of a lot of these rest endpoints and all the complicated maintenance and testing and everything like that because in the end most of the things people are doing are just getting data and if you put the query inside the client you don't even have to have all the complicated bubbling you can just look at the time stamps on the versions you can delta the things that have changed on your windows and just update the relevant stuff so I think we're not really there with where ui is going to go it reacts very interesting but it's still hellishly complicated to build uis when all you really do is have a collection on the server and a subset of a collection in your phone and you click on things you want and you do all this stuff to do some an application that's really really simple so I think we'll head back one where do I see the future of technology last question please anonymous where do I see the future of technology well I think I've told you basically CPUs and memory are going to be free a lot of this complicated stuff I don't believe distributed computing is really hard to do right if you're a fan of distributed databases because there are times when you need them please look at jasmine or don't call me maybe google that jasmine don't call me maybe don't call me maybe comes from carly ray simon the song that my granddaughters like to sing and but called kingsbury does he breaks every distributed database system in existence usually most of them once or twice a year distributed computing is really hard to do right in many cases it's easier just to keep the new stuff plus the old stuff and use those google gave up on it there's something called google spanner google spanner was done for adwords because google it was way too complicated to dry it and do it with distributed computing distributed computing is wonderful when it works when it breaks it's really hard to debug people doing react and things like that they're really smart people there are people that do it but google spanner basically uses atomic clocks again hardware is cheap put an atomic clock in each of your data centers around the world synchronization we carry time in our database in nanoseconds we believe it will go to picoseconds in five years but atomic clocks are cheap so you can say that having oh my entity server is too slow I can't do that it's hardware so I think in many cases things will be much simpler and you start looking at programming as query you'll be surprised what you can do you don't need a lot of complicated data structures one of the things this hardware does is you get rewarded for just going through things linearly that's why I use vectors because hardware is rectangular and I have no indeeds no objects, no anything like that just native types and they flow into the caches and more and more people are figuring that out and with compression you can actually do this on the fly so I think programming is going to become much simpler and when you give tools like we do self-serve analytics so we can work on trillions of rows and write the code visually so normal people can do it not smart people like you then you can change the dynamic because then you can let people work on the data yourself and when you can replicate that data into big memory boxes the whole way you do computing changes and we have to make things much simpler and we need a breakthrough in the UI I have an analytics product and 70% of the code is JavaScript and we use the little JavaScript as possible to keep things very simple but very fragile and that's relative to our other code so we need to change so I think the work that Facebook is doing is like that so I think those things are going to happen computers are just going to get faster and smaller I'm not worried about machine learning writing any programs while I'm alive maybe for some of you younger it might be an issue but machine learning is an important tool but machine learning is good at looking at yesterday's data it's not very good at predicting the future so one of the I built this analytics environment for cyber analysts people looking for problems in cyberspace and in cyberspace the bad guys don't actually use the same algorithm they used the last time so machine learning can figure out what that was but it's like fitting a regression formula in the last 10 years of economic data and using the predictive future so humans are still going to be involved in the loop and surveillance in the financial markets all more and more things require a human looking at a visual seeing a pattern and say ok, machine learning, go find all this pattern but the machine learning doesn't find it, it doesn't write the programs yet, I think that's a fair way to work but machine learning is an interesting tool on the hand it's kind of a specialized tool it doesn't work for everything but I think it's very important to become familiar with it Google TensorFlow is really pretty easy to use but not everybody has an application I think security is a nightmare we're going to have to change that I think everything will become encrypted and I think I think you'll see IoT devices being mandatory provided with certificates or time-expired tokens or capabilities so that we can finally have some sort of security there I think that's going to happen a lot faster because the IoT industry is not going to exist unless it steps up and solves its own problem automotive is already heavily threatened by the problems of automotive security I think we'll see a lot more breakthroughs there in terms of security and separation and isolation helps out a lot and having people program in safe languages helps a lot and that's where you can get at the machine need to be taken away from people except for those that need them and while I do think formal proofs and everything like that are a great idea we're not going to see that mainstream for some time there's some incredible stuff done about why wouldn't we because it's just too hard right now it takes a team of PhDs to prove very simple things anything interesting but most of them are boring and simple so we can prove it ourselves there's a whole lot of skills you have to have to actually prove programs correct and most people don't have them you clearly have the skills to do all these things but I don't think that applies if you just look up the Yao talk by Catherine Fisher who ran the DARPA program in security and is one of the leading people in the world she'll tell you that it's going to be some time but you don't need a lot of people who are proving to write proofers or work with proofers to prove not just setting up the stuff and just annotating it and getting the information into the prover it's really hard you don't need many people so thanks to her engineer and one guy who can write a prover so I really believe that you think that the rest of the world is in a different planet sorry please look at Catherine she's the world expert she's reporting from her I'm not a security expert but I've tried to use verifiable stuff and many things it's very time consuming and very hard alright thank you very much Dave thanks everyone