David M. West was our special guest.
Video is here.
His great book on object-oriented programming: Object Thinking
Transcript
[00:00:00] Yegor: Okay. Now we are fully ready. So, I prepared so many questions. First Iâll do some introduction, and then we start, okay? Hi everybody, this is Shift-M podcast and our next episode which weâre delivering after a quite a long delay, but this time our guest is David West, you definitely know who is David, he will make a quick introduction about himself and then weâre gonna have a lot of questions for him. It should take about an hour, maybe a little bit more. So David, thanks for coming and the microphone is yours, say a few words about yourself, please.
[00:00:46] David: Hi, Iâm a retired professor of Computer Science and Business and I have a background in Cultural Anthropology and Asian Philosophy. If you see, these three racks of the books behind me are all Asian philosophic books, but living in Southern Utah, it just snowed last night. I have known Yegor for a long time and itâs been a very welcome partnership, so Iâm very happy to be here.
[00:01:21] Yegor: Okay, thatâs great, thanks. We all know you for the books you wrote about object oriented programming, but this time the podcast is about management and more global questions than programming. So I will try to ask you things which are not directly related to object oriented programming, more about management and philosophy of software engineering, that kind of stuff. And I would like to start with the question, a simple one, who did you vote for, just a few days ago?
[00:01:51] David: Voting in America is secret. Now, I actually did not vote for either Biden nor Trump, I think that both of them are evil, and you know I am not a big fan of government, so I cast a protest vote.
[00:02:15] Yegor: Did you vote the last time, four years ago?
[00:02:20] David: Vote for Trump? No, I would never vote for either of the two major candidates. I voted, yes, but not for the democrat or republican candidates. My personal opinion, the biggest problem with the United States is the two-party system, you know, the only thing worse is a one-party system, you know. But no, neither side is good for the country, soâŠ
[00:02:55] Yegor: Interesting. And do you think something is happening right now with the country, with the society, or it was like this always?
[00:03:07] David: What youâre seeing is a pushback, the country has always been far more conservative than people would like to believe, and by conservative I donât mean racist and misogynistic, I mean, you know, that they have a system of values that are not popular, you know, being religious for instance, and the last, oh I donât know, for the last 15-20 years there has been a lot of governmental interference and these other ways of life. So right now where Iâm living for example is a ranching and farming country, and the federal government is famous for coming in and telling these ranchers what they can and canât do with their land. And these are people that have been doing this for generations they know what theyâre doing, and so when the government comes in and says âNo, no, no, you canât do this, you canât do thatâ, it bothers them a lot. And so the 68 million people who voted for Trump are mostly that kind of group of people, theyâre just tired of being pushed around by the government. So itâs a protest, none of these people like Trump, you know, most of them really think heâs a terrible person, but they donât like government. So theyâre voting against government, they arenât voting for Trump.
[00:05:06] Yegor: And what about tech people, programmers, engineers, how does this all affect us, what do you think? What is changing now in the tech world, aside from farmers?
[00:05:18] David: Yeah, well I think that the only good thing that might come from Biden with regard to technology is that in the United States the Internet has been given over to the rich people, so one of Trumpâs appointees, Ajit Pai, basically destroyed the Net Neutrality Act, so that it allowed the big ISPs to charge more for whatever they wanted, and, you know, play favorites with technology - thatâll go away under Biden, so thatâs a good thing. The lawsuit against Google will probably go away, too, which is a bad thing, you know, Google and Facebook, and, well, not that bad. Google and Amazon are not that bad, Facebookâs got to go. So anyway, no, technology is going to be given a free reign still for another four years.
[00:06:32] Yegor: So you think that these social networks, because youâre saying Facebook is gonna go, so you think this is social networks which are now in charge of the personal information, of everything, we talk to each other, this is not a good thing, right? According toâŠ
[00:06:47] David: No, itâs not a good thing. The whole idea of old newspapers and press and stuff is that you had a person who was responsible, an editorial of content, who could be held accountable if they did weird things, on the Internet you donât, in social media you donât, you also donât have anybody that you can trust, you know, the editor of the newspaper is someone who has a code of ethics, you know, they police themselves to some degree, they try to be fair and so on. You canât say that about Mark, Mark Zuckerberg, I mean, heâs not a good person, and so to have him in charge of the media content is not a good thing for anybody.
[00:07:47] Yegor: But are you in general in favor of more control over peopleâs life or less control?
[00:07:53] David: Oh Iâm absolutely less.
[00:07:57] Yegor: And if we talk about management, if we move to a software world people, letâs say programmers, they work in a company, in the team, so youâre in favor of what kind of management, where people are under strict control and rules and discipline, or when they are more free, like now this agile idea, or you know flat organizations, democracy?
[00:08:18] David: Yeah, okay, so this is a double-edged sword, so if you go back to when Kent Beck first was writing about extreme programming, and he was basically saying âLet us do our jobs, let us get rid of all of this oppressive management, weâll do the right thingâ which is is absolutely correct, but that comes with a cost, that if youâre going to be given your freedom, you damn well better be responsible, you know, so Kent was talking about you have to do continuous improvement of you as a person, as a programmer, as a team player, you know, all these different kinds of things, and a lot of people, particularly in the programming world, donât have that set of skills, they were never taught how to work in a team. I go to conferences and I ask people what they read, and⊠nothing. I mean you know the programmers may read a manual here and there, thereâs a a few of them that are enlightened and will listen to your podcast, or read your books, or read my books, or whatever, but those are a very small minority, so those people, I mean, they donât deserve to be free, they are keeping up their half of the bargain, they arenât being responsible.
[00:09:53] Yegor: So what do we do with those people, with the majority, because the majority is irresponsible, youâre right, definitely, so how the management should deal with that situation?
[00:10:05] David: There is a school of management, itâs called Servant Leadership, itâs very daoist in in practice, this all sounds, you know, very mystical and so on, but the management should itself adopt the role of âOkay, Iâm not in charge, Iâm not forcing people to do this or forcing people to do that, I am setting an example of what, you know, would be good for them to do, I am very carefully aware and watching them, and i, you know, will say good things to people, who are doing the right thing and say constructive things to people who are not doing the right thing, and then I go and make sure that people have what they need. If you look again, you look at Kent Beckâs stuff talking about coaching and contrast that with Scrum master, you know, a Scrum master is a controller, a coach, the way that Kent Beck wrote about it is one of these servant leaders, heâs there to serve the team, not to control the team, not to run the team, but to help the team do what it needs to do. And thereâs a whole raft of the books, my business management books are over there, there I have a number of titles on my shelf about this kind of servant leadership, of, you know, being supportive, being constructive and getting rid of the control aspect, and that itâll work, itâll take a lot longer time, so if youâre a manager worrying about your quarterly performance review, itâs not going to work for you. But if you take a little bit longer view and say, you know, âWhatâs going to be best for my company, my team, my division a year from nowâ - itâll make a huge difference.
[00:12:19] Yegor: Does it apply to all professions or only for tech people, this attitude?
[00:12:25] David: All professions.
[00:12:26] Yegor: All professions?
[00:12:27] David: Yes.
[00:12:28] Yegor: If you look at people who are doing like, I donât know, people building houses, or farmers, or I donât know, some other professions, they kind of, you know, they always need some control, some, I donât know, some force to kind of push them forward, because people by definition, I think, most of them are lazy, and they donât really like to work, they like to do nothing, maybe, thatâs my understanding of in general people, there are exceptions of course, but in general people are not really happy to do the work.
[00:12:58] David: I go back in the United States, 50⊠no, a little bit more than that, probably 75-80 years, this was an era of what was called âscientific managementâ, and the proponents of this scientific management had the view that you just said - people are generally lazy, you know, this is the very classist approach, the people who were writing these books, of course, were professors and senior managers, and they thought that the blue-collar worker was just, you know, a lazy slug, and if you didnât control them, you were going to get crap. Well that was wrong, I mean that thatâs just as wrong as just saying âOh well letâs love everybody and let them do what they want and good things will happenâ, i mean those are the two sides, youâve got to find a balance in the middle. When you have something like building a house, or building a dam, or a bridge, or something of this sort, thatâs where most of our current ideas about management come from. Itâs people have looked to these big engineering firms and sais âOh, wow, lookâ, you know, they can put up a three rivers dam in China in 5 years and it has billions of gallons of water, and this and that, isnât this wonderful? Well, yes and no. You probably couldnât, well, I donât know, theyâll say, âWell you couldnât possibly have done this without doing this kind of command and control managementâ, well the Egyptians built the pyramids, they didnât have this stuff, but then also you have the case that building houses, and you have building houses, you have these big large builders, and theyâll go out and theyâll put up 100 houses, 300 houses a year, I mean, they build a lot of houses, and they have these very strict rigid management things, they have deadlines, they have this team does this, and then this team is going to be here 30 minutes later to do this, and itâs all very coordinated and scheduled and so on, but the quality of those houses is crap, I mean, you know, they theyâre built to last 20 years, which is the length of a mortgage, and then they start falling apart, and theyâre hard to maintain. Sounds a little bit like software, you know, you build something thatâs good enough to last until you get your next job, and then it all falls apart after youâve left, because the quality is not there, because you have to give people some integrity, if you want really quality work out of them. You canât treat them as slaves, you canât treat them, you know, as cogs in a machine. They are people.
[00:16:24] Yegor: Do you know that currently the situation on the market is that we need more and more programmers, the demand is growing and growing, and most countries cannot supply that amount of programmers right now, so if you look at especially European countries, Iâm not sure about America, but if you look at European countries, they have like double the size of the demand, itâs double the size of the supply of young programmers on the market, and at the same time the salaries for programmers growing every year, much faster than the growth of economy, much faster than any other profession, so many people say that now is the market of programmers, not the market of companies, not the market of projects, but market of programmers, so programmers dictate the rules, programmers tell their employers what to do and how the projects will be run. So in this situation, donât you think that giving even more freedom to programmers could be dangerous, I mean strategically, because theyâre already in charge, they already get too much
[00:17:25] David: Oh, they already get too much, this is for sure. Okay. Youâre absolutely right that there is this huge demand, but at the same time, if you go and you look at what management is saying about all of this kind of stuff, they arenât happy, theyâre really not happy and the biggest reason that theyâre not happy is that theyâre spending all of this money and they arenât getting any return on that investment, you know, you look at the IT budget of these companies and itâs huge, itâs a huge amount of money, but you look at what that budget goes for 80% of it, 80% of the IT budget for big companies goes to maintenance, keeping stuff running, you know, if it was written well in the first place that would software doesnât wear out, why do you need maintenance? Because it was crap and this isnât sustainable. You get to the point where youâre spending so much of your money just to keep the IT up and running, that it becomes a real problem for management, so you look at business experts, Kotter, heâs from Harvard and he writes a lot about management, and he is one of many who are talking right now that IT is the biggest impediment, not only do they not get anything from IT, but IT is holding them back from doing what they would need and want to do as a business, and so this burgeoning market for programmers is going to disappear pretty quick when these companies start saying âOh, weâve got to find an alternative, weâve got to find something differentâ, and they wonât look to the IT professionals to find it, you know they donât trust IT management any more than the programmers trust IT management, you know, IT management this big huge group in the middle is⊠theyâre a threatened species, I think.
[00:20:08] Yegor: These maintainability problems, I think, are coming from⊠what for example you were talking in your book in Object Thinking, that theyâre coming from the lack of structure in the heads of programmers, the programmers just think differently, they have no clear idea of what theyâre doing, and thatâs why they create all this unmaintainable code which they get money for, but then they walk away and somebody, some other programmers, join the team and they need to deal with this mess and the amount of mess is growing, and this legacy software is everywhere, and youâre absolutely right, we only maintain what other people created. So maybe we need to be more programmable, give them less freedom? Iâm just philosophically asking.
[00:20:47] David: Yes, and I have to be a little bit philosophical here for a minute. There is, you know, all of these huge billions and trillions and quadrillions of lines of code out there are not good you know itâs stuff that programmers each with their own style, idiosyncratic ways of doing things have built all of this stuff and it doesnât work together nicely, it doesnât do anything else, so you could say: âOkay, well, what we need to do is we need to impose structure, weâll have everybody write in a single language, weâll pick Java, just for fun, and nobody can write any programs anymore except in Java, and it has to be Java version 17.2. Canât be earlier or later, it has to be just 17.2 period. And weâre going to create a manual of style like they do for for language for natural language for English, for instance, will have a strong and white manual or weâll have the, you know, a Thesaurus and a Websterâs dictionary, and if you donât conform to those, your code doesnât get accepted, you know, okay? You could do that, itâs not going to work, because the problem is deeper than that, the problem comes from a fundamental flaw in the whole idea of programming in general, so if you go back to the Turing computer, the Turing machine. Very simple device, read-write head and an infinite tape, an infinite tape of ones and zeros, and your program and your data is all stored on that tape, well, itâs infinite. And this means that not only is there a one way of writing a program, so that it adds two plus two equals four, thereâs actually an infinite number of ways of writing a program that two plus two equals four. And thereâs an infinite number of ways of doing it wrong. Two plus two comes up with five, seven, 57, 42, you know, whatever. I mean thereâs an infinite number of ways of doing that wrong, and there is no objective way of saying this way is better than that way. You can come up with criteria that says âOh well, over here I did it in one line of code, and over here I did it in 10 lines of codeâ, well, okay, what does that prove? Not much, you know, maybe this one line of code was APL which nobody can read, you know, and thereâs 10 lines of code with Smalltalk which is a really cool language. Itâs just a lot of fun to play with. Itâs an arbitrary, a conclusion. And so you have no objective way of saying âThis is a good way to write a program, this is a bad way of writing a programâ, so how are you going to come up with those style manuals, how are you going to come up with the libraries of things that are going to work? I mean weâve been trying this for 75 years and it doesnât work, and so we take programming at this level and we say âWell we canât decide anything at this level so weâll build something on top, but weâll build a framework on top of it, and now you have to write in this framework and that imposes a little bit of discipline, but you still have you know the French cases and the exceptions and things of this sort, so then you put something else on top of that and then you say âOh well, this is actually kind of hard for people to do, programmers arenât very bright and you know we need to control them and we need to do something else, so weâll put this management tool on top of that and then weâll put some kind of process management tool on top of thatâ, and so you keep doing this and so today to be a programmer you canât be a programmer, I canât go out and write in COBOL, which is the first language I ever learned COBOL Assembler, I canât write a COBOL program today. I have to be a full stack developer, I have to go into Eclipse or IntelliJ or something of this sort and I have to use JIRA, and I have to use this and I have to use that, and Iâm probably using a framework of some sort or another, and and all of it just adds more arbitrary complexity to the whole thing, so youâre building a Jenga tower, itâs going to collapse. And weâve already seen examples of that. Youâve heard the case of when the three lines of code that broke the Internet?
[00:26:37] Yegor: Iâm not sure I remember, can you tell about it?
[00:26:40] David: Okay. Yeah, so there was a guy, he was Eastern European or his name was at least, I donât know him, but his name was Eastern European, he wrote a bit of code called âleft-padâ, and it was like four or five lines of code and he put it out there in one of these open source libraries, and then he got into a dispute with the people that had that library up, they wanted him to change a name or do something, and he didnât want to, and so he took his code down, you know, he just removed it from the library, and within hours Netflix, I canât remember a number of them, I think it was even Facebook but a whole bunch of these big programs all of a sudden crashed, because they had wrote the program that used this library and used this framework which used this library, which used this framework, which ultimately used left-pad. Left-pad wasnât there anymore, you know, out there in these open source directories, and so all the software built on top of it crashed, and what they did to resolve that, is that the company that owned the library the open source library, put the code back over the authorâs objection, because all these big companies, you know, weâre putting pressure âOh, you know, weâve got to have this code, weâve got to have this codeâ and so they stole this guyâs work from him, you know, took it away from him and gave it to all these big companies just to keep things running, which is not a very nice thing to do, I mean you wouldnât like people stealing your work, I donât think.
[00:28:48] Yegor: Yeah, thatâs for sure, itâs an interesting story, but you know what they say now, and I also feel that because I was a programmer also like some time ago, but I remember when I was a kid and I was in school, then it was actually possible for me to kind of see all the problems which computers have, because there were so few computers and there were so few problems, but now itâs almost impossible to be a programmer everywhere, you need to be more niche programmer, if youâre the Java programmer, then you know very little about databases, for example, or if youâre Java, you know very little about networking and so on and so forth, so now it seems that the total area, the domain of programming, of computer science is getting so big that itâs necessary to build this pyramid, like you said, this pyramid of dependencies, when I just work on this level, on this layer, and I donât care whatâs beneath me, I just rely on this layer and I donât know how this layer works, I donât want to know, so I go up, and up, and up, and then people start creating these domain specific languages, probably you heard about them, like languages which are very specific for very small problem to solve, and some programmers, they only learn this language and if you ask them how this language works, they donât have an answer, they donât know whatâs beneath, like how it goes down to bytes and bits and all that stuff, so some people say itâs good, some people say itâs good that we are becoming, you know, less smart probably, because we donât see the full pyramid and programmers are becoming more like a commodity profession, like we just train you to use this domain specific language, youâre the programmer and thatâs enough, so you donât need to be really a scientist, you donât need to understand deep, so thatâs whatâs going on now, and what do you think about that?
[00:30:32] David: Well, so you can build this complexity, you can achieve results, you could probably, and if you did this in a really disciplined fashion, if you really force programmers to toe the line and follow the standards and things of this sort. You could build really really really good programs, does that mean that youâve solved the problem for the business? No. If you go into computer science departments, there are still people getting PhDâs in how to prove that a program is correct, mathematically prove that this program is correct. And yeah, okay, thatâs nice, you know, you can prove that, yes, this program works and will always work and will never fail, and is the most efficient algorithm and takes up the least CPU time and so on and so forth, but so what? You know weâre talking about management, Iâm a manager and Iâve got a problem over here, Iâve got to process these customers or Iâve got to deal with this business issue, and itâs a problem for me to get that done. And I give it to you as a good software engineer and you come back and you write a program and you say âYou know, this program is right, it conforms to all these kinds of thingsâ and the manager looks at you and says âYeah, but it doesnât solve my problemâ. Thatâs where the real issue is and thatâs whatâs getting really worse, is that the manager lives in a world, in a complex world, you know, and and itâs a large world, I mean itâs a global world, so youâre building these long large-scale complex systems, these systems have to be adaptable, they have to respond to change, very rapid kind of change. And it creates a really interesting set of problems, the programmer, heâs living over here in this nice formal world, you know, the computer, I mean the computer has rules, you know, itâs all nice and clear and cut, the program canât deal with ambiguity, you know, everything has to be black and white in the computer and so you become a master of this mechanical world over here, and it doesnât matter how good you get at building machines, what the business person, what the manager needs, he needs something like a human, like a really intelligent human being, you know, someone who can deal with complexity, who can deal with ambiguity, who can fill in between the lines, you know, all these things that a computer canât do, and donât tell me that AI is gonna solve that, because itâs not, but you know, youâve got a mismatch, a long long time ago we used to talk about the impedance mismatch between objects and databases relational databases, you know, âOh I can do all these really wonderful things over here in objectsâ, then if my objects have to talk to a relational database all of a sudden, it takes four times as long to write a program as it did before, because there are two different philosophical worlds, there are two different kinds of domains, so when weâre done talking, Iâll send you a link, itâs just a short little book, it was put out by Carnegie Mellon, itâs called⊠anyhow, itâs about building complex adaptive systems, large-scale complex adaptive systems, Carnegie Mellon University was commissioned to do this study. Carnegie Mellon is where the software engineering institute is responsible for all the standards and stuff for software engineering is located. The study was funded by the US department of Defense so thatâs not necessarily a good thing, but they were looking at what are the challenges and what are the problems of these large-scale adaptive systems, complex adaptive systems, and they basically came to the conclusion that everything we know about software engineering is not gonna help us, because itâs a different world, this world of complexity and so on is a very different world, itâs like a biological world, so everything we know about machines doesnât tell us digitally about growing a plant, or creating an animal, or creating an intelligent human being, you know, it doesnât tell us any of that stuff. And so itâs very interesting reading, itâs a very worthwhile reading, and itâs very short, but it lays out this philosophical problem of programmers and software engineers and computer scientists live in a world that is totally apart from the world that the business lives in, and business management lives in, and they two are compatible, so youâre gonna have to invent a new bridge that by the way is what Iâm currently trying to do, is to invent this new bridge, so book number 3 will be on that.
[00:37:11] Yegor: And thatâs really interesting and that leads me to the next question: how do you think managers should understand who is a good programmer, who is not a good programmer, who is high performer, who is low performer? By what - by lines of code, by bytes, by probably youâre going to say by the amount of business problems they solve? But usually programmers, theyâre staying quite far away from actual business problems, even though we think and we hope that programmers gonna in the end solve those business problems, but in reality if you look at the real projects, programmers are basically still writing, you know, lines of code and theyâre dealing with objects and classes, not with real life problems, and then eventually, somehow this connection happens, this bridge youâre talking about. But if Iâm a manager and I have a team of 5 programmers and I deal with real programming, so what is the right way to measure the performance of these people, because there are many opinions about this, some people say that we need to use like explicit metrics and basically count lines of code, some people say that completely just get away from all metrics and donât measure people by number, so where are you standing in this?
[00:38:21] David: Okay, so letâs go back in history, letâs go back to 1975, and letâs listen to a guy named James Martin. So James Martin is one of the largest names in the 70s writing about computing and about what we would call IT, about business computing, things of this sort. He is also the big proponent of databases, he was the leading proponent of a transition from what was functional programming or⊠not functional, but procedural programming to data based kind of programming. The idea was that procedures, the way we do things changes, but the data stays the same, the data is more stable, and so he was a big advocate of this data centric approach to doing things, but he also considered he was looking at this problem of management, how do you deal with teams, and so on. And the first thing he said was âWell youâve got to get rid of the human resources department and, you know, the compliance departmentâ, because human resources is there to make sure that everybody is treated fairly, and so they do things like they say âOh, youâre a programmer one, youâre a programmer two, youâre a programmer three, and your wage has to be based on your job category, not what you do, but your job categoryâ, and you canât come in and say âOh, this person is much more efficient or much more productive than this person over here, letâs give him twice the salaryâ, you canât do that because human resources is âNo, no, you know, you either have to promote them up to a programmer 15 which doesnât exist, or you have to pay him the same as everybody elseâ, so I mean that thatâs number one, you have to get rid of that kind of mindset. Okay, the second thing is that you look at a guy named Robert Glass, who is also writing in this period of time and he has a bunch of things that he wrote about productivity and management and things of this sort, and itâs a very known fact, I mean this has been true from pretty much from day one, that the individual difference between programmers can be as high as a hundred to one. You know this programmer over here can be a hundred times more productive and effective than this person over here. We know that and weâve known that from day one, but we arenât allowed to acknowledge that. so James Martin in 1975 he proposed, you know, SWAT teams, he says, you know, take a group of programmers, give them their own little special office over here, you know, with closed doors in city cubicles, you know, give them a coffee machine, give them a popcorn machine, you know, make their work nice and then let them basically manage themselves, this is the same thing Kent Beck said 25 years later, you know, let them manage themselves, but make it all very-very public, so that just like in Scrum and in XPT, you have these charts up on the wall, that shows what everybodyâs doing and whatâs effective, and you can walk into a room and you can look around, you can say âOh you know every pair that has broken the build had Dave in itâ, if Dave wasnât in the pair, they never broke the build, well that means Daveâs got to go. And this is stuff that we all know, kind of tacitly, but weâre too polite to ever say anything, but if itâs sitting up there on the wall and itâs public, you know even Dave, heâs gonna look up here, he says âYou know, Iâd better start looking for another line of work, Iâm holding this team backâ, you know, assuming that Iâm honest a little bit with myself. And so this is how you⊠you donât really measure, well you do, youâre measuring productivity, but in terms of business value, you know, is the customer using your work, are they happy about it, do they send little notes down to the manager saying âHey, your team really came through for me this weekâ, you know, and then you gradually add things in, like, âYeah, we added business value and it only took us six weeks instead of six monthsâ. So you start building from that and coming up with these alternative metrics and I forget now Kent Beck has at least one paper that he wrote that suggested the metrics that should be used for an Agile or for an XPT, you know, to judge their productivity and rate. And they were not the same things that Scrum uses, you know, Scrum metrics are not that good, I donât think, butâŠ
[00:44:28] Yegor: You said that we are too polite right now to demonstrate people their metrics and, like you said, to let our HR department pay them different money for people who are 100 times more performance, so pay them 100 times more money than other people, and this kind of gets me back to the start of our discussion. So we are now too polite, but maybe weâre too polite only for the tech people, only in the area of tech people, because if you look at the, letâs say, farmers, or you look at the people who build houses, weâre not too polite to them, because we are working with them for hundreds and hundreds of years, and we show them the metrics, and we show them how much they make every day and weâre not being too polite, so maybe something is wrong with the tech industry right now, this politeness is kind of damaging us a little bit, no?
[00:45:18] David: Yes. In the late 90s and the early 2000s, there was a huge movement in software, the quality movement, and software quality, lots of conferences, lots of journals, things to this sort, and the idea was that yeah, we needed to deal with this kind of thing, you know, the software weâre building is really bad, it doesnât do what itâs supposed to do, so we need to improve quality. And there were two very different kinds of schools of thought, and this is in the management process, this isnât in software necessarily. One of them was Six Sigma - the idea of imposing all of these kinds of controls so that we are correct or we do things down to, you know, Six Sigma level of quality. We have one failure in every what hundred thousand, whatever, Sex Sigma comes out to be. Well the other one was in the United States, at least that was never quite as popular, was the Malcolm Baldrige approach to doing things, Malcolm Baldrige was a government official, but he also was a business management MBA kind of person, wrote a lot about management. And Baldrige talked about this need for openness and transparency, because, you know, with Six Sigma youâre not doing anything at all to expose or to make public or to hold people accountable, youâre trying to make the process as a substitute for the people. Well, Malcolm Baldrige did the exact opposite and he did a lot of work, or a lot of people did work following his approach in education, so they would go into a grade school classroom, so this is not software, this is, you know, an average grade school classroom, and what they would do is that they would put up on the wall, it was oftentimes anonymous, you donât put names up on the wall, but you put up all the grades for an assignment or all the course grades for this term, that they would be up on the wall in various ways, you could put peopleâs work, actual work up on the walls. Youâll take their name off of it, put the work up on the wall, so that all the kids in this classroom are seeing all of this stuff, and again itâs not telling them anything, they didnât know itâs making it public, so when I was the teacher I would sit in the class and I would give out team assignments. Team assignments are horribly unpopular at the university, because the university is built on individual competition, thereâs only so many Aâs and everybody wants their A, so youâre always out to them, so you give a team assignment and say âOkay, everybody on the team is going to get the same gradeâ. Boy do students hate that. I mean they really really hate that. But you give them that assignment, and the students in the team, they know exactly who is contributing to the team effort, who is just kind of slacking and riding along, because they know that theyâre going to get the same grade, so they donât have to really work hard, I mean they know this. So when I would give team assignments I would also have them do something that you know posted each individual effort, so that I could see as the project was going forward I could see, oh, this person checked in this, this person did that, this person did that, and just making it public. Everybody performed better. You didnât have slackers ever, because they didnât want to be embarrassed, and you know if itâs quiet, if itâs tacit, they donât get embarrassed, but if itâs public, they do. So yeah, transparency is really important getting rid of this politeness, itâs really important.
[00:49:41] Yegor: Thatâs really interesting. And what do you think, shifting a little bit more to the personality of programmers, who do you think, what is it for you a talented programmer, and who is lacking talent? How would you define that talent of programming?
[00:50:05] David: So again, Iâll go back to the days that I was teaching, which is when I not only had to try to recognize talented programmers, I had to give them fair grades and so the kind of skills that a talented programmer would have is that number one, they would have at least one interest outside of programming, theyâd be musicians, they would be hobbyists, like the maker movement, you know, people that like to build things with their hands, maybe they would even be a potter or they would be something else, but they would have some interest other than programming. They probably were fairly well-read, you know, they would read fiction, they would read books on science or they would read other kinds of things, not as much as I do, but they would at least read these different kinds of things, and so when they would sit down with something, they would sit down and they would have a problem, they had to solve, but they didnât have a single way of doing it, the kind of formal logic puzzles that are given oftentimes as tests for programmers before you hire them, you know, Google is famous for doing this kinds of things, these logic puzzles, well, these people would sit down and they could probably do most of those logic puzzles, but they also said âI was reading this last week in this other area, and that gives me the idea, that gives me a metaphor, you know, it doesnât give me the answer, but it gives just a different way of looking at how the problem might be solvedâ, so they have this kind of breadth of understanding outside of programming, that gives them perspective, that gives them the ability to see things, to analyze, to look at whatâs there with an open mind a little bit, and discover. This might be an interesting way of approaching this problem.
[00:52:41] Yegor: And letâs say you are the manager, you have a team of programmers, letâs say 10 people, and you clearly see that only 2 of them are actually talented, and the rest of them are not really that much talented and interested. What would you do, you would try to fix these 8 people, or you would try to change them to different people?
[00:53:08] David: I would try to motivate them to improve themselves, so you canât do anything to another person, you look at the world of addiction, or alcoholism, or something like this, now you canât fix an alcoholic, they have to get to the point where theyâre ready to fix themselves, itâs the same thing with programmers. If you come in with the programmer and you say, you point out âLook, this is really a cool way that this was done over hereâ, and you provide constructive criticism - âWell did you think about doing this kind of thing, what would you do if you had to do it this way instead of that way?â I mean, you ask these kinds of open-ended questions and if they donât respond to them, they arenât ready to be a good programmer, and so you use your 30-day probationary period to get rid of them and bring in somebody new, who is. I mean, if you think about it and if you are willing to give yourself some time as a manager, as the manager of programmers, you can say âOkay, right now we need a thousand programmers in this shotâ, because the way things are done and because of the hole that weâve dug ourselves into. Well, if I had a hundred programmers who were all like Yegor, we could get all the work done and probably at a higher level quality and everything else, so I sit there and I said âMy goal this year is to take my thousand programmers and reduce them down to a hundredâ and I tell them, I say âYou know, this is the goal, itâs that we want people who have this skill set, this kind of knowledge, this kind of breadth of understanding, this kind of quirky way of thinking, this way of working cooperatively with each otherâ, and you say, you know, at the end of the year âA hundred of you are going to be here and youâre all going to earn, you know, five times what youâre making nowâ which, you know, will make the IT manager happy because Iâm still cutting his budget significantly. But, you know, itâs up to you, you change, this is the goal, this is the objective, this is what you have to be as the person, and then I could set a bunch of independent goals, so I had a program at New Mexico Highlands University that I was teaching, it was an apprenticeship program, and I actually had the opportunity to apply a lot of these different kinds of rules and so on. We had people come into this program, they werenât cherry-picked, we had one kid come into the program with his girlfriend, his pregnant girlfriend, this was his third child by the third different woman, he was 20 years old, he did not know how to do cut and paste, I mean he literally couldnât go into a word processing program and do cut and paste. And this was in September. So in January he was leading a team, he was teaching them how to use the J2EE framework, we were writing production code for the stage engineers office, it was a system that they had set off to China or somewhere and came back and didnât work of course and so his team was doing this and he was teaching these people how to use the J2EE framework and Java in 6 months, so I mean this stuff works, this stuff really works, but in that class, in addition to doing their programming assignments, they also had, well, we did, and this kid in particular, he did a really cool review of a movie called âHeroâ. âHeroâ is one of these kung fu kind of movies out of China, lots of color pageantry, and people flying through the air and slicing swords, and so on. But the hero of the movie, he wants to assassinate this warlord, and he gets to the point where he can in fact assassinate the warlord, but then he chooses not to, because they are looking at a piece of calligraphy and the warlord is explaining the meaning of this calligraphy and the guy says âOh, this is not somebody I want to killâ, but anyway this kid was the only one in the class that did that movie review and got the point of the movie correctly. We had writersâ workshops, so people had to write a material, but then they sat in a group and they critiqued each otherâs work, just like if I donât know, if youâve ever been into a PLoP Conference, but this pattern language is a programming, and itâs based around a writersâ workshop instead of being a competitive conference, you submit a paper and then everybody critiques and helps you make the paper better. And this technique was called a writersâ workshop. Well, we did that kind of thing, in one year we had we had 20-something students in that first year, 12 of them had papers accepted at peer review conferences, you know, like at that time it was OOPSLA and the first couple of years of the Agile Conference in the US, both of those conferences had better than an 80% rejection rate, so they rejected 80-some-odd percent of the papers submitted to them, well I had 12 students that got papers accepted to those conferences, and the room was like an Agile room, we had hard floors roller chairs, islands with computer workstations, but youâd sit there and youâd watch these people during the day and theyâd be working on this code over here and they would run into a problem and all of a sudden theyâre sliding their chair across the floor and talking to this other person over here who they know has better skills than they do or can answer the question for them and thereâs all this freedom and movement around the room, and I mean, it worked really really well, and I think you could do the same thing in a business setting. But it takes a manager whoâs not into command and control and it takes people who are willing to work. Now, these kids were motivated twice, number one they were getting paid for their work, but only if the customer accepted it, and they were getting a grade, you know, they were going to get a degree, and so they had the motivation to do something. Maybe thatâs what you should do with your programmers, you should have your programmers and say âOh, well if you have met these kinds of goals, your salary is going to go up 5% if you havenât, itâs going to go down 5%â.
[01:01:32] Yegor: The HR will not allow me to do that.
[01:01:37] David: Thatâs true.
[01:01:38] Yegor: Now weâre getting to very interesting question. Weâre talking about talented programmers and Iâm sure you agree that talented programmers and talented individuals, they usually have their own individual thinking, and they have their own ideas and concepts, and you know what happens to people who read your book, and then they read my books, and they start writing code this way, they in most cases get fired. And thatâs whatâs happening on the market, because the majority, the mainstream Java development and all other object oriented development, itâs going one way and when they read the alternative way, even though this way may look better, and it is, I believe it is better, but when they start to apply this thinking in their daily work, then very often they write me emails about that. I know these stories.
[01:02:27] David: Oh, yeah. Yeah!
[01:02:28] Yegor: Sometimes they get fired, sometimes they donât even have any chance to get a job, because when they mention your name or sometimes my name on the interview, the hiring manager immediately says âOkay, we know these stories, bye-bye, this is not the way object oriented programming worksâ. So whatâs your advice, what to do to these young people who want to stay, you know, in companies, they want to make money, but at the same time they have their own thinking?
[01:03:00] David: Yeah, this is a real problem, and itâs not just a problem with management and, you know, within the IT world, itâs a problem with the social structure, so way way back, when I first started teaching objects, so this is 1991-1992, I would tell my students, I said âYou know, this is the right way of doing things, this is a good way of doing it, this is a really really fun way of doing thingsâ, and they would see that and then I would say âYou know, youâre going to have a huge problem convincing management, when you leave the school and you go out and you get your jobâ, actually most of these people already had jobs because that was a requirement to get into my program, but, âYou know, when you go back to the office on Monday, youâre going to encounter all of these kinds of resistanceâ. I sais âThe only real way youâre going to get something done is that pick out three or four of your friends in this class that you know are good, that have reallyfigured this stuff out and are doing it right, form your own little company and start doing things and be the entrepreneur, and you donât even have to be like todayâs people, where they want to make an IPO and sell out and be a billionaire, but you start your own company where the four or five of you are doing what you want to do the way you want to do it, do it well and you know pretty soon someoneâs gonna notice and you get enough people doing this kind of thingâ, but that doesnât work because youâve got kids at home, youâve got a wife that wants, you know, a new Mercedes, you know, most cultures in the world are not cooperative. Something like this might work in China and probably is working in China without us knowing about it, but in the West, with our individualism, it just doesnât work, I mean, the social pressures are against it. So, no, I donât know, I donât have really good advice for people, I know that most of them are unhappy or unemployed, theyâre employed and unhappy or theyâre unemployed. And, you know, itâs sad, I mean, itâs really a bad problem, and I donât know what to do about it, except again, right now I decided to quit talking to the IT world for the most part, I am focusing my efforts on business management, because if I can show them that âOh, there is a better way, there is an easier way of doing thingsâ, theyâll fire their IT management, and hire a whole bunch of people like you and I, you know, to do this work for them. But thatâs where the key is, I mean, thatâs where the money is, so that thing has to be convinced, this is the business management, and itâs not going to be that hard. If you look at the business press and the management press, the books to set the people in that field have been written, and the journal articles, and so on, theyâve been talking about agility and chaos since the 1980s. The software world didnât start doing this stuff until after 2000. So, you have to learn to talk their language, put it in âYou know, hereâs the business case for doing things this way, hereâs what youâre going to gain as a business, and, I mean, I donât know if itâs going to work any better than the stuff I did for software, but thatâs where my efforts areâ. Itâs that because thatâs who needs to be convinced, the people with the money.
[01:07:35] Yegor: And my next question is probably related to this one, so whatâs your motivation for writing books? Why do you do this, aside from money? I donât think thereâs a lot of money there, but still.
[01:07:46] David: No. The biggest motivation, just like it is with teaching, you know, when I was teaching a class, I have a hundred people go through my classes every semester, and if one of them comes up and says âWow, this is the best class I ever tookâ, âWow, this is the best book I ever readâ, I mean yeah, itâs, you know, 10 people, and itâs not going to be the best seller list, but itâs enough, itâs enough.
[01:08:32] Yegor: So you care about whatâs going to happen after, or this is your joy, this is your fun that understanding that some people may get out of your semester and say that?
[01:08:43] David: Yeah, so my motivation for writing the book is the people that come and say âYeah, this matters, this made a difference to me as a personâ and then letting them know that âYeah, Iâm there, Iâm really happy that this helped, go out, try to do it, try to apply it, when you have problems, you know, send me questions and stuffâ, I mean, Iâm always open to receiving these kinds of things, so I get a sense of engagement with people and I can kind of share their suffering, I can share their joy when they have a success or whatever. I mean, weâre talking about motivation, there is a part of me that also would like to change the world. I really would like to find that lever and change the world for the better.
[01:09:45] Yegor: You did actually a lot.
[01:09:50] David: I hope so. The company that was co-founded in Netherlands, you know, before co-op would send me home, that was our mission statement, was to change the world, and so we were doing things, we were doing things with Smalltalk, we were doing things with Pure Objects in terms of the products and stuff we were developing, we also only would work with companies that were engaged in making the world a better place. So our first client was a company called C Rangers, which is a a non-profit company, and they are basically building shifts and teaching people marine biology and conservation and all these kinds of skills, and then they go out and they work with governments to kind of monitor whatâs going on in the oceans, they also provide services like maintenance, offshore, windmill farms and things of this sort, but I mean theyâre committed to making a real difference in the world, they are not just making a profit, thereâs a whole group of people, theyâre called B Corporations, B Corp, and these are companies like Patagonia, the people that make the outerwear, the hiking outerwear and so on, their mission statement is to make the world a better place for, you know, conservation or to make the world a better place with people. Thereâs another whole thing again in the management area, theyâre called Teal organizations, and the book was reinventing the organization and itâs about how you build companies that have empowered employees that work collaboratively together, sort of competitively together, that decision making is pushed down to the employee level instead of being isolated up at the management level, so working with these kinds of companies is another way of making a difference, and you will also find that those kinds of companies are really open to some of these other ideas weâve talked about today, servant leadership, empowered employees letting people self-manage to some degree or another, and they have mechanisms in place to support that, so thatâs another thing. I would give this advice, you know, is quit working for who youâre working for, and find one of these people, and go to work for them. A lot of these people, since theyâre not totally profit motivated, you may take a salary cut you know 10% 20%-something, like that, but you know youâll get it back eventually plus the fact youâll have a whole lot more fun working.
[01:13:15] Yegor: That makes sense and I actually want to ask you about the book because sometimes I recommend to these people who are really interested in pursuing the idea of the true, the proper object orientation in programming and actually think about also publishing something, maybe not a book, it is a big word, but maybe publishing some articles or speaking at conferences, so making ideas more public and that way itâs easier to defend them in front of your team, which is you know quite conservative and donât accept new ideas. So do you think itâs a good strategy in general?
[01:13:51] David: Yes⊠can you edit this out, Iâve gotta let my dog out?
[01:13:55] Yegor: Okay.
[01:14:03] David: Sorry about that. No, yes, you have to, you know, be bold, you have to tell people what you believe, you have to show people what works, or what has worked for you, and not be shy about it. So publishing papers, articles, trying to speak at conferences, organizing conferences⊠All of these things are very worthwhile, and I would recommend them, they can be difficult for people to do user group. So one of the things that we did with objects, back when I was first starting this stuff and before the book, is that we founded the Object Technology User Group in Minneapolis, Minnesota, which is where I was teaching at that time. And, you know, at first it was just people getting together and talking about this, but also talking about how they were doing it at work and things of this sort. We organized the conference, current object practice and experience conference in 1994, and we invited everybody, we had Rebecca Wirfs-Brock, we had Richard Gabriel, we had Kent Beck we had Ward Cunningham, I mean, anybody who was, anybody, except Grady Booch and Ivar Jacobson turned us down, they wouldnât come, but everybody else who had written books or whatever, came to this conference and were speakers at the conference, but half of the conference was just people from companies saying âOh wow, this is what we were doing with objectsâ, we had a company from Texas that came in and showed us how they had to write a code for a MacroSwitch with like a 10 millisecond switching budget, I mean, that was their time budget, and they had two teams, one of them writing in Smalltalk, and one of them writing in C++. Well, the Smalltalk team finished their program in six months, the C++ team was still working a year and a half later and never did finish, but the problem was, well, how was Smalltalk ever going to make this time budget? Well, they wrote the program, got it to work, got it to do what it was supposed to have to do, and then they did a little trick, they pre-compiled the methods, so instead of sending a message to an object and have the object ask the class for a copy of it and so on, they just did that pre-compilation, so the call of the message went to the object and the response came back immediately, and they were able to do their time budget, just with a simple little trick. But I mean those are the kinds of things that really inspire people and yeah, itâs cool to stand in front of 500 people and have your ideas acknowledged and stuff, I highly recommend it.
[01:17:34] Yegor: Okay. Okay, thatâs great, weâre a little bit running out of time, so my last question is - what is happiness for you? How would you define that?
[01:17:41] David: Whatever I define is happiness?
[01:17:44] Yegor: Yes.
[01:17:45] David: Having enough. So that Iâm not worried, or constantly, you know, wondering, or caring, or concerned about where my next sandwich is gonna come from or whatever, but, you know, having friends, having enough. So I donât need to be an influencer with 10 thousand or 10 million Facebook friends or whatever, you know, I have a couple dozen high quality friends like yourself, thatâs enough, so happiness for me is enough, having enough.
[01:18:35] Yegor: Okay, that sounds like a great answer. Thank you very much for the talk, it was reallyâŠ
[01:18:39] David: Thank you for the invitation, I hope weâre entertaining for your listeners.
[01:18:44] Yegor: Definitely, definitely. All right, thanks a lot! Bye David!
[01:18:48] David: All right. Bye!
