CHM Live | The History (and the Future) of Software

well I'm delighted to be back here John thank you for such a warm welcome happy to be back at the museum software is the invisible thread and hardware is the Loom on which we weave the fabric of computing software in a way is a very fragile thing the most fragile of things perhaps because a single bit and the facade that you've created will fall apart and yet at the same time it is perhaps the most elegant of materials because from it I can weave tapestries that are beautiful elegant that move us software is perhaps the most durable of materials it can literally move virtual as well as real mountains it can move markets and perhaps even more impressively it can move the hearts and minds of individuals and yet at the same time software can also be a millstone around the neck of an organization or an individual because it will accumulate over time ossifying potentially that organization and making it difficult to move forward software has no mass but it does have weight in a sense software is also perhaps the most creative of mediums as with a blank page I can write every anything I can write the works of Shakespeare or I could write Fifty Shades of Grey I could write haiku if you're really creative you take that page and you make it fly and that's the wonderful things about software that it can reach many dimensions today I want to take you in a journey of software because I've grown up in the software space when I begin we had assembly language in punch cards and now Here I am today with literally outsourcing my brain to my pocket putting it in my in my smartphone and so there's been an amazing journey over those decades and I want to walk through that journey with you from the perspective of an anthropologist now imagine for a moment you're a social anthropologist you're not geek but you're stepping into Silicon Valley and what would you see an anthropologist is going to study the rituals the ceremonies the narratives the belief systems of a particular community and we're going to take that same journey now if I were to do this in software I could be here for multiple days but I'm going to pick a couple of those we're going to follow that journey looking at the narratives of the kinds of software people have built and the processes whereby people who built them we could also examine this from the perspective of languages from the perspective of individuals who have made a difference we could also take a look at it from the perspective of the tools we use to build these things save that for another lecture but we'll take those two particular threads so imagine yourself as a an anthropologist and I plunk you down into the offices of tumblr and here's what you see well putting my mindset on as the anthropologist I look around and say what curious individuals these are I might watch them for several days and I would see them come in the morning at various strange hours and eventually that all stand up and talk for a while and then they'd go back to their respective devices and toilet way and it would look like a very very boring kind of activity they would be curious symbols around this little smiley face I'm not sure how that advances my software development but it's there we'd also see a variety of tools different people are using different kinds of monitors and the like now there's something really interesting here that I wonder if you'll point up so it will give you an experiment as a cultural anthropologist look here and tell me one of the things it really stands out do you see it yes where do they hide the women where do they hide the women and it's true sadly so in this particular culture and academic tumbler just happened to be this one particular page on particular picture there are no women in this picture and yet as we will see women played a seminal role in the evolution of what we know today of software earlier I spoke about what software is as a material it's very very fragile like silk itself is very durable like like granite it is very fun jables it is with writing let's take a look at what software development is like for some developing software is like building a doghouse you just take whatever's in front of you you build it and you do it we sometimes call this agile programming if you fail you can always build a new doghouse if you really fail you can always buy a new dog sometimes software development is like building a house especially if it's your own house because now all of a sudden I've got some skin in the game I'm building something that I've got to live in literally eating my own dog food here and so the risk is higher the cost is higher and I'm going to do a little bit more planning because of that different risk perspective so it's kind of like building a house and in a way it's never done you get to a point of closure where you finally live into it you get a certificate of occupancy but ultimately even once you're inside there something always needs to be fixed a lot of software frankly is like managing a city imagine yourself inside Paris and realizing what I'd really like to do is put this Hyperloop straight through the middle of the city wouldn't that be nice to do problem is you piss off a lot of Parisians who are in the middle of the middle of that Hyperloop and so the reality is that you have many stakeholders in a situation like this and you can't always make the change now you could do as has been done in China in other places you say heck with it I'm just going to build a new city poof there it is and that works sometimes but by and large cities that have economic value and human value tend to grow organically in fact many of those cities in China are veritable ghost towns so we really want to do is to take a place like this like a Paris and slowly evolve it over time and such as the nature of large software intensive systems developing software is also like raising a child you make up stuff as you go along there are lots of people telling you how you should be doing it and the hardest problem probably is learning to let go old software doesn't die you have to kill it by the way developing software is like building a movie producing a movie you'll get together with some of your best friends and say let's go do a movie and you throw them together and you have this frenzy of activity and you build something and you release it and if it's successful you're allowed to build a sequel if you're really successful you have a whole franchise but most of they're a few franchises and we all migrate to them but there's still a lot of other software out there that entertains us and in movies it entertains us and delights us and fill some space in our world developing software is a lot like sex and you'll notice I don't have a picture we'll leave this to your imagination it's a lot like sex because it's both an art and there are mechanics associated with it furthermore you get better with practice and to paraphrase Richard Feynman sex like software development like research sometimes it produces good results but that's not always why we do it so let's go back in time I mentioned in the picture of tumblr there were no women present but actually as David Greer in his wonderful book has observed the first computers were women this is the time here we are in 1890 these are the Harvard computers the women who actually computed so we have your first this is a classic stand up scrum so now it is somewhat are standing around they're all talking to one another there's a manager who's not doing anything over to the side classic agile development and what we have here is the beginnings of the art and the science of software development the Harvard computers in this time were mostly women because it was not deemed to be an activity that was worthy of the time of men can't believe that and what they would primarily do would be to take raw data from the astronomers and then do raw calculations upon them so we begin to see the notion that this munging of information was best done in small teams of really bright people as we move forward we begin to see some automation come into play and here we see kind of an assembly line the very idea of the factories of software development come into play now keep in mind as we think of the shape of software in this timeframe we're still largely dealing with purely numerical systems we're just munching numbers and various algorithms but it was clearly discovered that there is indeed a factory that we can build here we put in raw data at one end each person does a little bit of computation passes it on to the other and we finally end up with something at the end very menial very mechanical but indeed it was valuable it produced some good results and so we begin to see the ideas of some degrees of formalism coming into the process now there were alternate models move ourselves to the 1930s we see VanDerveer Bush working on a differential analyzer and it's also a pipeline kind of thing we set up this system and we're going to come back to this when we talk about quantum computing toward the end we basically set up this machine we turn it on let it do its thing and we get some results it's kind of like how quantum computing is today but again it's the idea of a handful of people working around a machine to get some results move ourselves to the 1940s and now we see a really fundamental shift there was a classic book written in this time frame by Jay presper eckert I forget the exact title and it gets punched card methods in scientific computing that's the title great book go read it if you if you're really bored some night but he begins to outline the patterns that we have discovered in that time frame for how to take a scientific problem and begin to decompose it into its pieces so again we see another element of the puzzle come into play the idea of decomposing a larger system into its component pieces no women in this picture by the way but we see here a legion of men again in the pre as in the previous two pictures would work kind of in this pipeline you take some date in you'd operate upon it in one way with this machine pass it on to the next as we move now to the late 40s then there was another discovery another realization if you look closely the dapper young woman off to the right side that is grace Murray hopper and she of course was working on this machine and was perhaps the first to realize that there was something other than the machine itself with which we could begin to work still in this time praying were largely dealing with numeric systems we're largely dealing with the activities of software development really wasn't called software then as one of controlling the machine the distinction between hardware and software did not yet exist now if we moved to the bowels of Bletchley Park girl reads to Black's book by the way delightful book on on basically how she say Bletchley Park wonderful wonderful book and truly she did through her efforts but here we have one of the rare pictures that came from Colossus I told the story in my first lecture here on on woven on the loom of sorrow dealing with computing and warfare but to recap a little bit hibbett remember that this was the Colossus was born out of the work from Tommy flowers the engineer who took the ideas from Turing and others from the Tunney go watch the imitation game and you'll you'll see some pieces of it great movie by the way great acting compelling plot terrible history but it's it's fun it looked like you know Turing save the war he did do some fundamental things but it's people like Tommy flowers who actually built the Colossus and designer that made a real but what you saw in the Colossus was a discovery that we could indeed introduce ideas of loops and conditionals and run something against it using the ideas from from bool and Shannon I think Shannon was around this time which said it's possible to actually build a machine that does algorithm and that was the tremendous breakthrough that we saw with Colossus you would see in the little tape here that's where an encrypted message would be put in constantly running through and then we finally in a way find a relaxation algorithm off to the side here that would discover the potential settings of the Enigma and Lorenz machines keys or rotors but again still the fundamental problem was numeric a little bit symbolic but also the distinction between software and hardware was simply not there we had people operating machinery I think the true beginnings of programming happened with the women who programmed the ENIAC there's a delightful website and children's book in a small documentary called top secret Rosie's which tells this story a bit I urge you to go take a look at it we also talked about this in woven on the loom of sorrow but again here was the task you would have some men off to the side that would say we want to do this calculation and quite literally they would toss it over to the wall to this set of women who would try to figure out how do I arrange the plug boards to do those calculations so again the first computation was still largely numeric it was largely done still on the hardware itself and it was done by this team of really bright women who simply got together and figured out how do I do this in a way you can begin to see some of the beginning seeds of what we today we call agile methods you would have clear demonstrable results on a regular basis you would see a small team working together with it was sort of maniacal focus but nonetheless we were still dealing with just managing the machine now from this point on we can see a bit of a parallel path here we're going to look at the story of software from two ways I'm going to look at it from the people and the processes and we're going to look at it from the growth of software itself as a thing and along the way I want to share with you what I perceive is the major epochs of software but here we are in the let's put ourselves in the 50s for right now it was only in this time frame that the term software became illegitimate erm in fact the first time it was used appears to be in either 58 or 56 depending upon which source you take a look at and the first use of software was not as the stuff that runs on a machine but the stuff that was not Hardware mainly people so they were talking about methods associated with the personnel involved with the system it only came a little bit later the wind began to realize there was stuff that runs on the hardware that could be named unto itself so for right now has begin this part of the journey we're dealing with the problem is how do I manipulate a machine how do I command a machine to get results there's no software it's just managing the machine then of course came along john von neumann who had the brilliant realization and of course working with Eckert and Mauchly and the like who realized this notion of a stored-program computer changes the equation what if he said we take the ideas of controlling the machine and actually put it inside the machine itself this is one of the brilliant strange loops that software itself embodies I use a phrase here that comes from Hofstadter in his delightful book gödel Escher Bach and it reflects back to what I showed you earlier about taking the piece of paper and turning into an airplane one of the beautiful elegant things that moves me in software is the presence of these kinds of strange loops where we turn software unto itself and here is the first example of that where we turn our machines into themselves realizing that our machines can be controlled by programs within the machines if you look at the problems that that von Neumann was attending to they're very interesting ones because his first problems and involved how do i model the forces around a nuclear weapon because it was you know a little bit messy to try to blow these up all the time so let's model them he was also looking at weather forecasting he was also looking at artificial life things that we are still struggling with today so the roots of the problems that we faced back in the 50s still exists with us we're still trying to move the ball forward in each one of those I think it was in this time frame with the presence of the johniac and all that von Neumann was doing was the beginnings of understanding in the marketplace that there was this other thing out here and it was worthy of discipline unto itself so he saw the beginnings of hardware having this little bitty layer of software on top of it and we began to actually call it software in that space still most of the software was still in assembly language we saw a little bit of higher two languages but largely it was to control the machinery in ways that solved some problems the shape of our problems were relatively small we're dealing with applications it might be hundreds if not maybe a thousand or two lines lines of what we would call code today and most it was still new American nature although we begin to see the shift toward symbolic kind of computation in fact scientific work came a lot out of being woven out of the loom of sorrow from warfare it was business that drew us to the symbolic side of things we began to realize that these characters could represent not just numbers or tallies in a warehouse but they could represent people and so all of a sudden there was this second shift and our understanding of software that we had the notion that software could mean something there could be some semantics to it beyond just the underlying underlying mathematics so you see here a phase in which we had this curious combination of punch-card technology as well as more modern technology there's a hard drive off to the side here which probably by comparison sakes is far less than what I'm carrying in my pocket right now but we begin to see the discipline that there was indeed a set of people who could do the software versus could do the hardware and thus began the programming priesthood and what I mean by that is quite literally you would have a set of programmers over here who would devise their solutions they'd have little cards or little forms in which they'd write out their cards they carry them over to be key punched if you're dealing with a large organization the key punters would take that hand you your deck of cards you carry that deck of cards hopefully not tripping as you go there you would walk up to the machine room you would hand it to the person there behind the glass wall genuflecting as you go and you'd walk away these people would go behind the wall behind the curtain do their magic and then come back to you and say yay verily my son you have a syntax error or you have but we begin to see this dichotomy a growth of the software space and a growth of the hardware space but a separation between the two and the reason for this is the economics of the situation for very interesting because machines were more expensive than the humans and therefore it was important for us to optimize the use of the machines we would queue up the humans so that we could you know keep feeding things into this into the hardware monster to keep them as busy as we can because these were darn expensive devices and those humans were disposable but the separation begin so again we see a little bit more layer of software coming into play this is around the time where we saw the notion that sharing ideas of software was a good thing the first ideas of open source came to be with IBM share literally an organization meant to share algorithms share code with one another so we wouldn't have to keep doing it again from the hardware software perspective the other shift we saw is we begin to move away from these machines that were behind these glass walls and all of a sudden we could put devices on them that people from outside could begin to talk to them and also not just humans we found ways that we could take those machines and have instruments that are in the world begin to communicate with them and so the equation for how we were using the machines was different again so again we move from numeric on the cusp of symbolic and slowly but surely we're removing these machines out of their glass cathedrals and into the world a great example of that is sage which is perhaps in its time the largest software development project there was we spent billions upon billions of dollars and it was through the sage activity that I think we learned two things software is really hard and second there are some processes that work in some that don't in the sage era there was a tremendous amount of software built because all of a sudden we had these great machines and now we realize that they're fungibility their power came from the ability to separate the hardware from the software who began to see this wonderful path of the two diverging and software unto itself had economic value and it had value in the sense of the ability to not just control our machines but to adapt our machines it was from the sage experience that we also learned that there is this software crisis going on that the cost of building software was increasingly a limiting factor in being able to deliver systems of value and thus we saw this is later in the 60s when we had the NATO report come out on software engineering that declared the presence of a crisis and it's its impetus was a lot of what was coming out of defense systems in fact it is fair to say the premise we made in woven on the loom of sorrow that much of what we knew about software engineering and hardware came out of the world war two in the cold war the largest systems that anybody built were coming out of defense systems and in the case of the sage in particular there was a lot of software and this is an interesting system too because it was never used in anger we never really used the full capacity of the sage system but it was a system that made us feel good about having it really did we spent billions of dollars on a system that we never use in anger but its presence gave us something to defend against what the Soviet Union was doing at the time and of course the Soviet Union was progressing forward in a way that made what was happening in sage utterly obsolete that's the defense side of the world let's jump forward to the business side of the world today we have the googles Twitter's Facebook's of the world there are the dominant forces the you may see in the marketplace move yourself back to the 60s it was IBM and it was the 360 all over the place again it was economic factors that were beginning to drive the software equation the 360 itself existed because IBM wanted to preserve the software investment their customers had made and be able to upsell them across machinery and they viewed it as an opportunity to do hardware sales but the unbundling of software from hardware and the creation of an architecture that allowed the preservation of the software itself represented a fundamental shift in the industry because now all of a sudden software had real economic weight associated with it and this is where the the notions of structured methods came into play because here with a fundamental problem facing us is like in the defense world all of a sudden we were building larger and larger systems and the methods we use for simple systems just didn't scale up so what do we do well this is where waterfall methods came to be because if it works for building a warship if it works for ordering 10 million staples than by God it's gotta work for software right that was kind of the way of thinking and believe me I was in the midst of this time frame as well a little bit later time frame but the notion of waterfall methods still applied because it makes a lot of sense you analyze your requirements you design everything upfront and then you start building things because again the cost of these machines was still so high it made sense to push the thinking process earlier on in the process because changing it later on was very very expensive so the 360 changed the economics of things but it also changed the software side of things because all of a sudden we had more software and more software and yet more software and thus we had the crisis another woman onto the scene Margaret Hamilton here we are in the 60s Margaret is standing by a printout from some of the Apollo 11 guidance control software in fact go are in the exhibits and I think we've we've got one of the Apollo 11 guidance computer sitting there this is the software behind it there's some debate on matter there are some that say it was the NATO conference in 69 68 69 that declared the term software engineering it was intended to be a provocative term because we're talking about engineering the soft stuff there's reason to believe that it was Margaret that actually used that term before anybody else apparently she had used it in some of her internal writings at NASA and and NASA go back to the NASA archives and you'll see this and it appears to a predate of the NATO stuff so I'm going to go to the benefit of the doubt and I think it's Margaret that coined this term but the point of her term was that she saw that the very process of building software was an engineering process now what does that mean put your mindset on of an engineer and realize it this largely means building systems that optimally push back against the forces upon that system so if you look at software from an engineering point of view you look at the stakeholders on you you look at the forces on you quality performance functionality reliability security all the usually letís change ability as well and then you ask yourself how can I build a system that reasonably weighs against those because as we know in engineering systems there is no such thing as a perfect system there's just a good enough system what you began to see in this time frame too is the evolution of true formal software methods this is where the structured analysis methods came to be so some of the the greats of Tom DeMarco and Edie Jordan and Larry Constantine Harlan Mills and those are from sort of the the production side on the academic side we have Edgar Dykstra Parnas feareth CA our Mary Shaw and others who are beginning the notion of a theory of computation and a theory of software development and a theory of architecture not quite very yet but we were getting there so at least what Margaret began to realize and draw to the marketplace is that and certainly we saw this in Knuth work there is an art and there is a science there is a mechanics to what we're doing in software itself as a legitimate activity so our software and hardware systems begin to grow and grow our devices became larger our devices became smaller because of the revolution of the microprocessor now all of a sudden the equation changed for us as well we used to have these huge machines that were more expensive than the humans and now all of a sudden we were moving to machines that are about on parity to human and now I could make my machines personal I could literally spend the time to go in and me as an individual work and manipulate one machine we also saw the software problem beginning to grow and thus the growth of a variety of languages so we saw in conjunction with both methods and languages these two things growing up in the previous eras we had the algorithmic languages Fortran COBOL C to a degree and now we begin to see languages that were a little bit different they were languages like Simula that started to come onto the scene SPSS was around this time frame languages that helped us solve problems that were very difficult for us to express directly to the computer so the shift here that was happening in the mindset was the discovery of the power of abstraction the entire history of software engineering I would declare as one of a history of abstraction we move from the numeric to symbolic and now in this age we were starting to build as David Clerk nur would speak of it as mirror worlds we were starting to use our machines to build worlds unto themselves and now all of a sudden our software was not just numeric was not just managing some Bach symbols but it was actually creating our own worlds it was creating worlds into which we could step and the many computers helped us do that another curious thing happened is we began to shrink our machinery is that the things on the edge of our devices could start to have intelligence within them as well so no longer were these stupid devices but now the programming problem had shifted from being in the data center to being out on the edges another theme we're going to that's been repeated today this moved back and forth the pendulum swinging back and forth between centralization and decentralization because thus was born the PC in its various forms now this also changes the software equation because now all of a sudden we had the notion of the predecessor to the app I could build a standalone thing that could make a difference thus we see the creation of for example visicalc which really made the marketplace for the PCs in the business world built by a couple of guys and it will change the world this piece of software all of a sudden now you had a change in economics because a small set of people could now go off and write some software independently from a set of hardware that other people supplied and there was economic value in that so he saw continuing on the structured Neth methods and the like but by and large our applications were still Islands they were monolithic Singh's you would control from the top of the end and you controlled everything around it you control the entire ecosystem and that worked reasonably well this is the time frame of the operating system Wars because what happened is we discovered that in addition to the software it made a lot of sense rather than writing against individual hardware let's settle upon one or two different operating systems that give us that layer of abstraction again the growth of abstraction so now this is why we saw the operating system Wars in this time frame people were debating over whether or not is it Windows is it Unix is it whatever whatever Apple was trying to do here is this the right platform upon which to build and economics was very much changing in pushing and driving in the software marketplace we don't have those market we don't have those Wars anymore because quite frankly operating systems are down on the noise for us we're building things on top of them we'll come back to that but down in this timeframe here we were still largely building islands on top of one another until of course ARPA came along and said what happens if we tie these things together what happens if we take these devices that have intelligence and allow them to communicate so all of a sudden our software's problem shifted again no longer were we building things for one machine there were Islands but now all of a sudden we were building things that were in an ecosystem of lots of other piers and the question then is how do we architect things how do we deliver things that can leverage that value of interconnectivity we saw our networks grow and grow until we sort of have them today there was another shift because now all of a sudden it wasn't just these devices that never moved that were on the edge but now some of them were mobile how did that change the software equation all of a sudden we were now no longer building applications for a single machine we were building it for the context of multiple machines we were also building it for devices that were on the edge that had their whole intelligence that leveraged those things on the edge clearly we felt we were discovering that what we knew from the 60s and 70s in terms of how to develop software just wasn't working for us and so it was around this time you saw more of the language Wars coming into play this is jumping ahead of this particular time frame we saw this is why we had the creation of the ADA programming language the DoD realized there were too many languages around we need to reduce those to a small number so is there a way we can take modern software engineering techniques and put them in a language again a realization that language really does make a difference well consider the other languages that were popping up around that time we had Simula we had biana working out with a thing called of C with C with classes which morphed into C++ there was small talk around this time frame we saw a generation of languages that was very different and it grew from this shift in problems that we saw from numeric to symbolic to mirror worlds because now we were building languages that allowed us to build simulations very much what similar was all about and it led us into the object-oriented paradigm which of course ADA tried to adopt very quickly we realized the techniques of structured methods from Jordan DeMarco Constantine all these kind of folks just didn't work because they were the wrong abstraction and thus was born object-oriented design object-oriented analysis and I was I and my colleagues were deeply in the midst of that and that also led us to discover something new about the way software was developed that rather than having these big monolithic phases where I do analysis design implementation and delivered over the wall the industry was beginning to discover the ideas of continuous evolution the idea that there should be a punctuated equilibrium that rather than waiting to the end where things tend to break let's try to incrementally get milestones along the way and bring these things together such was the nature of software development in its its nasan state in the 80s and 90s timeframe but here's the other shift that began to happen as we saw these devices and from here to here these are the these are this is sort of the ARPANET as we saw way back when with devices that were in glass rooms all of a sudden we started seeing devices that were outside of the via the center's but then we also started seeing some of those devices that had intelligence unto themselves and some of those devices that were very very personal indeed and they were talking to things in the world thus was born the beginnings of the Internet of Things because all of a sudden we began to see that we could take ourselves out move our devices from where they were behind the walls and put them firmly into the world this also changed the nature of software development because now we were fundamentally dealing with systems that had to deal with the realities of the real world the real world is very very messy indeed there's another economic change that happened and that was the creation of the cloud why did the cloud come to be pure economics we see this enormous cost in our data centers and we realize there is tremendous commonality wouldn't it make sense therefore to begin to consolidate those ideas and get the patterns we have of each of these one-off data centers and put them into the clouds himself and thus we have Microsoft we have IBM we have Amazon all all building these cloud kind of things and that also changes the economics of software development because now all of a sudden I can build something that fits across a virtual machines that could literally be anywhere in the world and I have a different problem to deal with now in building Islands I didn't really have to worry about security so much but now I do and it becomes an important engineering factor that did not exist before prior to this timeframe I could build systems whose access I could trust because I actually had the key that allowed people into those machine rooms here the world is different as David Deutsch once also observed you can define a distributed system as one in which the failure of a system you didn't even know existed can cause your system to fail that's the true nature of a distributed system and so we were now building systems that were living in a fragile ecosystem in fact speaking of ecosystems the shift we began to see was also another economic one there's this idea of dominant design which says that in any discipline you're going to find a number of players that begin to go into the marketplace and after a while you will see consolidation around a particular set of them and so this is what the ecosystems are all about we see an ecosystem around Amazon we see an ecosystem around Google and Facebook and Twitter we see ecosystems in other places as well - that are industry specific so we're beginning to see the creation of these lines drawn that are economically driven by a small set of companies that also changes the software development perspective because within those ecosystems the ship that has been happening is taking those raw monolithic systems and component izing them what we did in Watson is exactly that strategy so when we won the Jeopardy challenge and we had you know taken Watson out of the laboratories and put into the world teaching it how to look at MRIs and x-rays to detect cancer dealing with all sorts of things in that regard we realized that one of the things we could do with the Watson platform is to refactor it and so we took it and refactored it into some 20s seven different different services in the decade past we had the operating system Wars now we have the micro service wars in which people are not are less worried about operating system because that's that's just a design choice by and large but now the real engineering choice is what set of services do I build myself on and we're finding that the companies who build these ecosystems are the ones who have economic value in dealing with them you may have some that are lost leaders that say we'll just give you all these services but because you're using them we get all your data yahaha and we can we can monetize it there are others who are trying to monetize the service themselves but again the focus is not on the operating system Wars but upon the service wars who controls the services into a particular ecosystem that's the component is Asian that's happening now that's where we are today and that's where you see sort of as a snapshot of software development so let's let's take let's take inventory of what we've got we tend to still build really large systems by and large these ecosystems are on the order of tens of millions if not many more lines of code if you read some of the works coming out of Google they will tell you that some 50 percent of their code bases or their files are touched every I think they said every month or every quarter some very small number that's a whole lot of code and so there is a set of people within these ecosystems whose sole responsibility is to keep feeding the beast much like we used to do with the operating systems keep adding services keep building that infrastructure keep drawing people in there's a lot of software development happening in that space another place where the software develop is taking place is especially what you see in the valley that's VC funded which says let's take those services I can't afford to build on my own but by god let's build a company on top of it that begins to use those services and so rather than building things of my own the infrastructures of my own I'll go off and get some time on a cloud I'll get a bunch of smart people together and we're doing things on the edge so what's happened is that software development by and large has broken itself up into three spaces we see development that's happening behind the services where a lot of C and C++ and now Java tends to go you see a lot of stuff on the outside of the services where a lot of JavaScript and scripting languages tend to go and that's what most of the press talks about because it's cool and it's sexy and everybody uses Google and Facebook and Twitter but there's a third piece that nobody ever talks about and that's the stuff that lives in the walls that's the stuff that lives in the devices in this room I'm looking right now and I see a whole bunch of devices up here and I got to believe there's a few million lines of code and some of the stuff that I'm seeing go to any rock concert you're probably going to see a set of lights that are run by a company called Vera light which has a fantastic operating system behind it originally built on the Macintosh platform lots of lines of code so there's a third set of software development going out there it's largely in the hard real-time near real-time space and they don't get nearly the amount of press that's going on but by and large we move from numeric to symbolic to mirror worlds and each of these places is a world unto itself let's project forward a little bit whereas it's headed software is becoming incredibly intimate because now no longer these devices just out in the world they are inside us they're becoming attached to us and the economics indeed changes again if I have if I do a Google search or if I'm writing the code for some some algorithm for Facebook to to bring up feeds please bring up if any of you face because we're out there please bring up a regular timeline feed for me please please please stop all this algorithm should but now we're dealing with a set of people who are building systems that touch us intimately and if I fail to build up the right feed in one of those cases nobody's probably going to notice if I miss a bit in my heart in my pacemaker somebody's going to die so we're dealing with very very different economics in this space so we're getting to see as I as I move forward here we're deeply in the midst of the Internet of Things that's great but what's happening is that intelligence is now moving out to the edge we're seeing the move from what we could do more so and our data centers out to the edge and cells for two reasons the first has to do with the pure ability that we can we now have the algorithms we now have the sensors the battery power etc that allows us to put more computational resources out to the edges of our system but the other reason for it goes back to the physics of data that if I have a wind turbine or if I have a turbine on and a jet on my aircraft I actually can't afford to take all the data that's being generated there and put it back to my to my data center if I'm out there on the Orion spacecraft and I've you know got a problem I can't report back to Mission Control because it's a 30-minute delay due to speed of light therefore I need to bring Mission Control with me this is the hal problem by the way truly is I think we know how to build a hell albeit a less dangerous killing type one but but the economics that the physics of data say that moving that amount of data is incredibly expensive and therefore it behooves us to push computation out to the edge so the shift were beginning to see is greater intelligence out to the edge in fact earlier I mentioned that the first computers were human well what's happening is that we're moving in the direction of the current computers are human there are three humans and three nonhumans on this the nonhumans are sitting here if you look at the work David Hanson and others have done we're we're leaping across the uncanny valley we absolutely are if you look at the direction that Microsoft is headed with their bots we've seen a lot of work in that space great great stuff what's happening is that we are now moving our software systems away from our hardware and back to the most natural form of communication we had which is like me talking to you it's conversation but it's not just my voice it's also my body language I pointed to people I'm nodding I'm winking and is therefore through force of action as well as force of influence that I am interacting with you now this leads us to neural networks we know today that the most efficient way to build a functioning neural network requires the activity of two unskilled individuals a waiting period of nine months and then crowd-sourced education this is this is the proven way to build a neural network so I absolutely celebrate what Google has done with deep mind and alphago and the like great great stuff but remember that there are some things that neural networks can't do I can't go to alphago and ask the question why did you make this move I can as a human because I've got many more millions upon millions of neural networks well we know how to do with convolutional neural networks today we don't quite have the capacity so here's the shift we are seeing we've been moving from systems that are largely deterministic to systems that we teach and that learn and that changes the life cycle altogether it used to be the case in my software development process adds or not I built something I'd have things I could test against it I can incremental II build something up in fact the googles Facebook's etc the world anybody who has these ecosystems have built really profoundly wonderful lifecycle tools that manage the build release delivery process there's a high degree of automation that goes on there that makes it possible for individuals to make changes on a daily basis to these kinds of things we've achieved that degree of automation in the infrastructure but not on those other two domains that I spoke up we've we've still got a ways to go but what's changing now is now I'm introducing neural networks now I'm introducing quantum systems now I'm introducing cognitive systems that are not necessarily built on on neural networks that I have to teach and then learn into this change of the development lifecycle because now all of a sudden I've got this component maybe it's an NL c or NLP kind of kind of component or maybe it's some vision recognition thing and I've got to train the classifier and I put it into my system the problem is then where do I do that in the life cycle because the very presence of that thing changes the delivery of what I'm doing and furthermore the training continues to happen after the delivery of that system we saw that with the the Microsoft bot that was released upon the world that was saying nasty things it's just like a child you teach them the best you can but you put them out in the world and by god they do some strange things so it is with our software so let's go back to first principles then that's that's the that's the present problem and that's the problem you all face or will certainly face and certainly your children will face how do I build software systems that I teach and that learn over time how does it change the life cycle now the one thing I can say about software development in general that transcends every one of the things I described there appears to be three overlapping phases of stuff that goes on there there is a period of discovery there is a period of invention and there's a period of execution and these three things overlap in our waterfall methods what you would see is these were non-overlapping and our agile methods we make them very much overlapping and where I think we're headed with our learning systems is I don't know this is why I need you to come up with the answer but what I do know also is an idea that comes from Herbert Simon that applies here as well we agile a speak of the notion of continuous integration it's not a new idea because it comes from nature we speak of it as punctuated equilibrium this is what Herbert Simon spoke of in the great book the sciences of the artificial and he observed that all complex systems tend to have stable intermediate forms and so let me offer the following to you no matter what kind of software you're developing no matter what it is there are really some fundamental principles that apply no matter what focus upon good abstractions have a clear separation of concerns and have this set of punctuated equilibrium have delivery of demonstrable things over time everything else has details it truly is but these appear to be the meta rules that cover the art and the science of software itself now each of you are in a different place in software and one of the things that that's hard for me to explain to people who are not in the software space is there are many different flavors of software you know the bane of our existence is you go up to somebody random person you tell them oh I'm into computers and they'll say oh can you fix my smartphone for me well yeah sure but that's not exactly what I do but I'll help them anyway I'm sure it's happened all of you so here's here's a mental model you might use when you try to explain to people what it means when you do software there are three axes you can consider remember the three I talk doubly talked about below the services on top of the services and outside in sort of the Internet of Things space here's another decomposition the first is the degree of formality associated with it like the dog house like the house like the city there are different amounts of stakeholders involved and therefore it is reasonable to consider different amounts of formality if I'm just building a dog house for myself yes sometimes I'm in the dog house then I just do it and there's no formality but if I'm changing a city there's formality another way is to consider the risk if if I do this and it fails in some way and nobody cares so what but on the other hand if I accidentally launch you know a global thermonuclear strike this is generally known as a bad idea and so I have higher risk and therefore that changes the kind of software I build and how I build it in the last is one of scale that I love having these debates with Agilent Kent Beck and I have had some delightful conversations in this space in terms of the the role of architecture and the reality is that is you move to larger and larger things I'll flat-out say agile methods don't scale up you've got to do some other things when you're starting to deal with hundreds of thousands if not a million lines of code or millions of lines of code you've got to approach it differently the great thing about being a software developer is this this is thinking back to the page we saw we saw earlier the basic premise of science says that we can look at the world observe it and we can reduce it to a set of understandable fundamental principles this is what the standard model is all about the premise of our domain is that the cosmos is computable we can take a small set of things we know about the world the notion of computability and we can build anything we can deal with numeric things we can do bill deal with symbolic things we can deal with our own kinds of worlds we as software developers are in a fundamentally different space and what this history has shown us is that the history of software development is just as fascinating as the history of Hardware walk these halls and go to the exhibits and look at it next time from the eyes of the lens of what software was running here because the stories of software are as vibrant and is full of avarice and delight and serendipity as they are with a hardware let me leave you with this at the beginning I said that software is the invisible thread and hardware is the Loom on which we weave the fabric of computing I'm going to frame in a different way software is the hidden writing and it whispers the stories of possibility to our hardware software is the hidden writing that whispers the stories of possibility to our hardware and here's the exciting thing we're the storytellers we are the ones who are in a place where we can tell those new stories we have the opportunity we have the privilege we have the responsibility to tell the stories that change the world or an exciting place to be thank you all very much what you guys get some good go-to written back here get some good code you probably wrote a bit of code and released it and it's out in the world already right let's talk nice thank you that was fun it was fun you see what I mean about him sitting at the intersection of the humanities and Technology that's a that's a very that's an English major thought that you left us with there in addition to all your Krauss and software so thanks for coming back you guys did a great job I've got I've got some amazing questions here far more than I can sure get ready to answer in the time available you'll be willing to do but let's try eat those questions with me and I'm a blogger them or tweet them or nice okay will do that's that's a great idea first what technologies do you use to build Watson and why oh let's see Watson was built well let's see how do I describe that it's mostly written in Java there are bits of other scripting language here and there but by and large it's Java that runs it from top to bottom we use Eclipse as most of the primary IDE that people tend to use we built a lot of our own tools the problem I mentioned of teachings of systems that learn traditional methods and tools don't work we found that to be true so we had to build a whole set of tools that would enable us to look inside a reasoning system and be able to ask why did it reason a certain way so I think we had a whole team it was going off in building nose the other thing I mentioned process wise it was a classic agile project David Ferrucci who led it had a war room where the 30 or so people would get together they'd see their little scoreboard that they'd look at every day we built a build and release process it would allow us to test against J archive on a daily basis so we could come in the next morning and see what worked and what didn't classic agile activity and also there's another great book I should mention by Jim Killeen called organizational patterns of agile development in which he looks at some of the patterns for what works and what doesn't David follow that as well too you got you've got this this thinker off to the side which is which is David you've got a couple of architects and you've got the people that orbit them and that's exactly how we structured it okay how many lines of code and Watson can you estimate the Watson jeopardy one was pushing around ten million lines of code if you add all the pieces we have now it's easily doubled or tripled those pieces right now amazing and also I could add we also have neural network stuff in it and I don't know how you count lines of code there you can count numbers of neurons but that that's not a very satisfying number you clearly got some attention with your comments on quantum computing so let me answer a couple will software I have to quote start over unquote within an era of quantum computing great question so I'm happy to report that I work in an organization IBM that actually has a lot of quantum computing scientists in it and as I interact with them they tell me the following it reminds me a lot of what VanDerveer Bush had to deal with you've got this different engine you set it up you turn it on and get results and that's a lot of what quantum computing is today you basically set your qubits up you put them in a certain configuration you wait for your result as it calculates in multiple dimensions and you get back there is some work going on to identify languages for quantum computing but they're completely non von neumann ditto with with artificial neural networks in the a n n space we're using a an ecosystem called cafe which is not so much a language but is more essaouira development system and basically the the situation is you define a convolutional neural network you shake it in certain ways and look at it again you shake it again and that's the development process around it but there aren't many languages for us so in the quantum case nobody seems to know mmm-hmm nobody really knows but I will observe that for at least the foreseeable future a lot of what's happening in quantum computing is still pretty much compartmentalized we see it doing certain computationally complex things but not the symbolic or mirror world things like we see that's not going to happen any time soon when we get really smart people on stage we often get a question like this and I'm always so happy when it happens what are good topics for computer science student to study that would be valuable in the next ten years wow that's a really good quick it's a really good question isn't it so I'm gonna answer that in two ways the first is make sure you get a good grounding in things that are outside your comfort zone that force yourself to go look outside your current sphere and go read things that are totally wild and crazy and I mean even out of the computer sciences go read herbert simon's book and the sciences the artificial go read Hofstetter go get yourself inspired by different ways of thinking I also say in general go look at the problems of computational thinking can you sort of refactor your brain and start thinking in different ways by looking at some of the stuff the jeannette wing and others has done the last thing I'd say is do something outside your comfort zone go build some crazy piece of software that makes you happy and learn from it yeah try something different yeah I mean that's why Jan and I are doing this crazy documentary it's changing up my brain yeah and I write books and I do these kinds of things because I want to learn and that's why I'm doing that's good how do you envision the future of AI you talked about it a bit I think some we're going to drill down here and and say will it eventually be smart enough to replace human workers including software engineers this is a question that probably is importance to a lot of people in this room you say that as if it's a bad thing actually we've got an effort that's looking at that I've seen several people that are asking the question what can we do to apply AI to the problem of software development itself the low-hanging fruit deals with testing that we see already some fruitful cases of using AI agents to help us in the testing process so that's a good thing the process of design well I've already seen some activities where people are looking at AI agents that can sort of sit in my pocket and nudge me saying hey have you considered using this pattern or hey have you looked to the software over here because it looks awfully similar to that that's where I think AI is going to move in problem with software development zone hmm do you if the two camps are human augmentation human replacement let's just as a sweeping generalization sure where do you think we're headed down that Fork well I don't think it's a fork okay because I believe human augmentation leads us to human replacement as I think I gave a lecture on this once on the notion of the computability of the mind and I have the premise that the mind is computable my lovely wife disagrees but that's okay she's wrong but you take a lot of that if you take a lot of that abuse this remember the doghouse thing I was talking yeah no wonder you're in the doghouse build a doghouse later today as you are so no no we have some great discussions so I'm of the mind of Rodney Brooks who views that there will be no singularity because by the time the singularity comes we ourselves will become robots so I think already I outsource my brain in my pocket in my smartphone already we see the beginnings of neural implants I've got an oculus rift on order and I'm jazzed about that kind of thing I'm actually working on some things in eldercare so literally I'm working with a team that's building software that I hope will keep me alive when I'm in my hundreds and hundreds and tens so I'm building software to keep me alive so all these things represent the path of human augmentation but the same time you have to ask yourself are we in fact building thing is it lead to a new species and if I want to go really far out I'd say we probably are that I see this symbiosis this dance between computing and humanity thus the name of our documentary that I think there is that weaving together that may lead us to that new species and I don't view that as a bad thing I do that as a natural part of evolution you seem to imply this question says that the operating system wars are over because what's now happening is we're building micro services on top of operating systems please explain further it is what you think why there is no need for a better operating system today ah well let me target let me tease that question apart it used to be that the choice of an operating system was a technical choice it is now an economic choice not a technical one because I have to make the decisions about do I have the right trained people does it work on the right platforms so the decision process has changed there was always room for something better and that's why I celebrate people building new operating systems new languages but the problem is one of economics that I see people working on new programming languages in particular and I really celebrate what they're doing but the chances of that programming language ever making a difference in the world is approaching zero unless you're an apple and you have people who build things like Swift that you can have this immediate platform on which you can do it but if you're off in the corner somewhere and you're building a language or an operating system that still does a better mousetrap the problem is people have beat their paths to another doorstep already so again it's not a technical win very rarely once at a time you're going to see a language or an operating system so when will win on technical expertise but it's the economics of software that are driving it now there are several questions here I was just sorting them again about the your your concept of the other and this question asks how do video games reflect on your view of this concept of the other well I'm I'm a halo player myself about video games I'm desperately waiting for my oculus rift to come to move into that particular world I mentioned the notion of the move from from numeric to symbolic to mirror worlds and video games are one great example of that because we create worlds under ourselves in those spaces and if you look at the evolution of software and video games I've had some delightful times to sit down with the people at Electronic Arts and there was a few years ago where I kept seeing them build these one-offs and I said why doesn't anybody go off and build a game engine that you use over and over again and the economics were such that it finally did shift in that direction so what you began to see in the gaming marketplace is a consolidation around a set of gaming engines around which people could build narratives so the same thing that happened in the outside software world happen inside the video game world as well hmm one final question tell us about software in 50 years there's a smiley face on that arm so well for those of you writing software in the back the people up in the front will be debugging at 50 years from now preferably soft ear for 50 years from now I'm going to answer that question from the perspective of shape of software process and language from the perspective of language 50 years from now we'll probably have some new languages but still there's going to be a lot of Java and C++ around and Swift around I hope somebody will have invented some new languages but the reality is like the granite example at the beginning of my lecture software lives on and on and on it's amazing to realize I think I use this analogy once there is software that the IRS uses today that was written in the 50s and 60s that's an assembly language and we still have it today so software you write today is still going to persist in 50 years from now so we'll see some new languages but they're still going to be a lot of old stuff I think in terms of processes we're going to probably do better at automating the process like what we've seen the Google's the Facebook's the Amazons the apples do for those circumstances that are reasonably well understood and we're doing lots and lots of iteration there's a great opportunity for automation in that regard I think we'll see that that move out as are the types of software I think we're going to build more and more software that that really leverages the distribution that we have even beyond what we have today and also leverages the kind of interfaces that we can only dream about the mental reality and the virtual reality things and the conversational things we have here so that's the shape of the software we have and that means there's a still a whole lot of soft to be written the parting thing I would say is no matter what future you might imagine it relies upon software that no one's built yet so there's a lot of fun stuff to do I'm going to give you the balance of these cards you can answer an elaborate well thank you just want to say that it's brilliant that we could have Grady here today because the tire Computer History Museum is pivoting towards software in fact it's one of the two major areas of expansion for us we're about eighteen million dollars into a 30 million dollar fundraising campaign that will launch among other things the Center for software history and the last remaining space on the ground floor that isn't open to the public is now under construction and on January 12 2017 if you happen to be a forward planner you're invited to come see the opening of a new exhibition called make software change the world which is going to be about 8,000 square feet it's going to be the most interactive thing we've ever done we're going to iterate on it as the years go by just a software iterates on itself and it will really be a kind of new era for the museum and you're helping lead that entire initiative so thank you very much great for being the influence that you are thank you thanks for having me have a great day everyone thank you all

Channel: Computer History Museum

Views: 50,777

Keywords: Grady Booch, Computer History Museum

Id: OdI7Ukf-Bf4

Length: 69min 28sec (4168 seconds)

Published: Thu May 12 2016