What we talked about
David West traces a clear line from his first job in 1968:the year “software engineering” was coined:through today’s AI-fueled hype cycles, arguing that our industry’s chronic unhappiness comes from being cut off from users and meaning. In this candid conversation, he recalls mainframes, 80-column cards, and 24-hour feedback loops that forced upfront thinking, then contrasts that era with modern “vibe coding,” where speed often replaces theory. West contends that most IT failures stem from treating business and technology as separate machines rather than a single complex adaptive system grounded in human integrity, shared context, and story.
Show notes
David West started writing code in 1968 for a bank, when programmers were just domain experts who happened to know COBOL, and debugging meant sorting through a stack of hexadecimal fan-fold paper as thick as your forearm. More than fifty years later, he argues that the profession is structurally unhappy, and that AI is just the latest chapter in a long story of trying to replace human programmers rather than empower them.
What we covered
- When West began in 1968, programmers were bankers or scientists first and code writers second, domain expertise came before technical skill. The separation of software development into its own discipline abandoned that integration entirely, and the outsourcing era made it worse by shipping specifications to teams with no context about the end user or the culture.
- Software developers are “not overwhelmingly happy” as a profession, West argues, because they have no clear sense that what they do means anything. The distance from the end user is so great that most teams never know whether their systems made anyone’s life better, and objectively, he says, those systems often make lives worse.
- The history of software development is a repeated pattern of trying to eliminate the human programmer: from CASE tools in the 1970s and 80s to Rational’s “round-trip engineering” with UML, to offshoring, to AI today. Each iteration treats developers as unreliable and interchangeable rather than as skilled, thinking human beings.
- LLMs cannot provide meaning to language because meaning requires context, cultural, situational, personal, that no model has. West gave the example of the sentence “The man saw the woman in the park with the telescope,” which is grammatically clear but semantically ambiguous in four or five ways. Only context resolves it, and context is precisely what AI lacks. The same applies to code: most code in existence is bad, so a model trained on it cannot exceed the quality of what it has learned from.
- West is writing a book that proposes treating business and IT as a single complex adaptive system rather than two separate machines. The target audience is not the mainstream software development community, which he predicts will hate the book, but conscious capitalists and B corporations already committed to the idea that business should serve people, planet, and purpose alongside profit.
- His prescription for accountability in software teams goes back to Kent Beck’s original Extreme Programming: trust developers to self-organize and self-manage, give them a coach rather than a hierarchy, and expect continuous improvement from both sides. Management didn’t trust developers enough to do this, and developers took refuge in routine rather than principles. Neither half of the equation was ever really implemented.
About David
David West is an author, mentor, consultant, and retired professor whose career in software development began in 1968, the year the discipline was formally named. He has lived through every major wave of computing, from mainframes and expert systems to objects, Agile, and domain-driven design, and is completing his third book, a manifesto proposing a radical rethink of how business and IT should be built together.
- LinkedIn: https://www.linkedin.com/in/david-west-6135682
- Website: http://davewest.us
Episode 77 of the PreVetted Podcast.
Full transcript
David West (00:00) this is not a happy profession. Software developers are not overwhelmingly happy or satisfied with their life for a variety of reasons. One of which is that they have no clear sense that what they do means anything. We’re so separated in most places from the end user, from the customer, that we have no idea if it made their lives better or worse.
Federico Ramallo (00:02) Ha ha ha!
David West (00:20) Objectively speaking, we consistently make it worse. the systems that we build and get delivered to our customers are not friendly. They are not, you know, sometimes they’re next to unusable. But nevertheless, we do it.
Federico Ramallo (00:24) Hahaha!
Welcome back to the PreVetted Podcast, where we spotlight extraordinary people and remarkable talent reshaping our world. Today we’re joined by David West. He’s an author, mentor, consultant, and retired professor whose career in software began in 1968, the very year “software engineer” was coined. He’s lived through every boom, bust, and big idea from early AI.
David West (00:38) Come back
Today we’re joined by David West, he’s an author, mentor, consultant, and retail professor. His career in software began in 1960, the very year software engineers coined. He lived through every boom, bust, and big from early AI
and expert systems to objects, agile, and BDD. Always with a clear eye view of hype versus reality.
Federico Ramallo (01:05) and expert systems to objects, Agile and DDD, always with a clear-eyed view of hype versus reality.
So, ⁓ Davies’ latest work proposes a radical rethink, treat business and IT as a single complex adaptive system, design software as autonomous elements, and ground change in shared theory built through stories and human integrity, not just…
David West (01:16) So, David’s latest work proposes a radical rethink. Through business and IT as a single complex adaptive system, design suffers autonomous elements and ground change in shared theory built through stories and human integrity, not just
Federico Ramallo (01:34) artifacts and roadmaps. So it’s a manifesto that challenges the cost, brilliness and inhumanity of today’s IT and points to a more humane,
David West (01:35) RFAs and problems. So, it’s a manifesto that challenges the cost, goodness, and humanity of today’s IT and points to a more
Federico Ramallo (01:45) resilient path. David, welcome to the show.
David West (01:49) Thank you, glad to be here.
Federico Ramallo (01:50) Awesome, awesome. So I’m honored to have you today.
David West (01:53) Ha
Federico Ramallo (01:53) So you started in 1968,
David West (01:55) Yes.
Yes, I was working in a bank. Oh, yeah. Okay. I was working in a bank. My original title was computer operator and I was reported with a rep promoted within a couple of weeks to operator programmer. Uh, there was no such thing as a programmer title. Uh, when I started in 1968, uh, let alone developers or anything like that. Uh, programmers were domain experts who just knew how to write code.
Federico Ramallo (01:58) What did suffer meant? god.
David West (02:27) So bankers that wrote COBOL or scientists that wrote FORTRAN, there was no separate discipline in 1968. That’s the year they decided to create one.
Federico Ramallo (02:36) Right, right, it was the interface was all paper, right? You would send paper to the mainframe and then you would get results eventually, right?
David West (02:45) Yes,
we had these big 80 column pieces of paper and you had to print out your program on the paper, give it to a key puncher who would convert into Hollerith cards, which were then fed into the computer and then the program would run or not run. If it didn’t run, you got a core dump, which was a stack of fan fold printer paper about this thick.
Federico Ramallo (02:58) Right.
David West (03:08) that was literally all the hexadecimal that was in the core at the time that your program failed. So that was your only way to debug your program was to go through this great big huge hex file, hexadecimal file to try and find out where things went wrong. It was interesting.
Federico Ramallo (03:25) Wow, wow, I mean I used to play with those type of paper where I would remove the edges, you know, with the holes. ⁓ It was a lot of fun.
David West (03:33) Yep. Yep.
Yes, and being a bank we had to keep all of our computer printout for seven years and so we had warehouses full of boxes of paper, you know, with all of the printouts from the computer that had to be kept for taxes or auditing or whatever. I don’t know for sure, but ⁓ it was a lot of paper.
Federico Ramallo (03:57) wow.
I visited a few former paper storage and they had to build specific buildings because the weight of the paper was so much that it would bend the flooring of the buildings.
David West (04:13) Yes,
yes, they had to have steel frame concrete floors.
Federico Ramallo (04:18) Yes, they had to reinforce it. And then they had the humidity issue and the fire risk issue.
David West (04:24) Right,
right. And the odds that anyone ever went back and looked at any of that was about zero.
Federico Ramallo (04:32) Hahaha
Right. Right. when I when I hear people talk about how AI makes life easier for everybody and kind of reduces the knowledge bar. Right. I kind of remember about those those initial ages where the knowledge bar was so high because you had to basically every time you have to try something.
You have to plan it ahead as much time possible because the any mistake was enormous, right?
David West (05:01) any mistake was enormous,
Yes, yes, so turn around, you if you write a program, you’d submit it. If it came back with an error, you had a whole day because you couldn’t resubmit it until the next day. know, so turnaround time for testing a program was 24 hours. So that made things very, very, very slow unless you were very careful up front.
Federico Ramallo (05:23) Right, right. And myself, I live the transition from compiled coding to interpreted coding. And the idea was, well, you can try many times before you actually launch the code, right? But I think that there is a value on this cost for trial because that means that
You have to be more conscious about what you’re doing rather than just blindly exploring what you’re trying to do, right?
David West (05:51) Yes, there is a lot to be said for having a theory, having an idea in your head of what you’re trying to accomplish so that you have something to map the output against. You can try and see, well, where’s the difference to what I thought was going to happen and what happened? Now, if you have no idea what’s going to happen, you’re just literally hacking. That’s not very efficient.
Federico Ramallo (06:13) Right. Right.
David West (06:14) It’s whole lot more
fun. And with some tools like when I programmed in Smalltalk years later, it was a huge amount of fun. You still wanted to go in with some kind of an idea of where you were going, but the ability to see and correct errors in real time.
Federico Ramallo (06:18) Hahaha!
David West (06:35) made the whole programming that much more engaging. I mean, you felt like you were having a conversation with the computer. And as long as you were keeping up your smart side of that conversation, you know, it worked really well. Yeah, that’s the interpretive coding that you were talking about.
Federico Ramallo (06:50) Right, right. ⁓
Right. I can see the value of this idea of lowering the technical bar, but my thinking is, in particular with how the new AI tools are coming up, I believe that having core knowledge of what’s going on and being able to plan ahead becomes much more relevant today than it was before, right?
David West (06:56) can see the…
Yes.
Definitely.
Federico Ramallo (07:17) So tell us a little bit about your manifesto.
David West (07:20) so I’ve, I’ve had a long career. as you said in the introduction, I have seen just about everything that was touted as the next best thing in software development. but I have also seen, you know, constant failures, you know, a new idea will come along and it’s, this is going to revolutionize the world. And then a year later, you know, nobody’s heard of it.
again. And we don’t teach history in computer science or software development. So people keep reinventing the same things over and over and over again, because they have no sense of what was done even five years ago. The other thing that I noticed in my professional career, and then also when I was teaching and interacting with former students,
who are professionals is that this is not a happy profession. Software developers are not overwhelmingly happy or satisfied with their life for a variety of reasons. One of which is that they have no clear sense that what they do means anything. We’re so separated in most places from the end user, from the customer, that we have no idea if it made their lives better or worse.
Federico Ramallo (08:07) Ha ha ha!
David West (08:25) Objectively speaking, we consistently make it worse. You know, the systems that we build and get delivered to our customers are not friendly. They are not, you know, sometimes they’re next to unusable. But nevertheless, we do it. The other reason that people don’t like the profession or don’t like they they don’t see respect for themselves or for their skills.
Federico Ramallo (08:29) Hahaha!
David West (08:49) as human beings, as people, as thinking people. So from the very, very beginning, all the way back to 1970s, the idea was it’s kind of a behind the scenes idea, but this undercurrent of human beings are unreliable, programmers are unreliable. We have to keep them in rigid control. So we’ll give them very detailed methods that dictate, you know, what they do at each step to
keep them in control. And then if we can at all possible, let’s get rid of them entirely. So we started building tools to help programmers do their work. And then the big thing in the seventies and eighties was computer assisted software engineering. The whole family of tools that were supposed to make programmers basically irrelevant, human programmers irrelevant. You we wanted the machines to do this.
When objects came along and Rational was a big company in object oriented tools, they created what they called round trip engineering. The idea was you could sit down and create a UML diagram. It would automatically generate code. You could read old code and it would create the UML diagram, which you could then change and it would regenerate code. So there was no need for a human programmer in that loop.
And now today we say, we’ll let the AI do it. We don’t need the human programmers anymore. We can do AI to replace them. In between, we did things like, a programmer is just a commodity. We can go and get it from the cheapest place possible. We can outsource it. We can offshore it. We can do whatever we want to do to find the cheapest one because
Programmer X at $10 an hour is exactly the same thing as programmer Y at $50 an hour. So why pay 50 if you can pay 10? I mean, there’s just total disrespect for the human being. So that has prompted me to say, okay, this is fundamentally wrong. Human beings are pretty exceptional creatures. We have a lot of abilities. We have a lot of skills.
Why aren’t we taking advantage of those instead of denigrating them and trying to replace them with poor substitutes? And AI is only partially intelligent. If it’s intelligent at all, it’s only partially intelligent compared to a human being. It can only do math. But so that
That prompted me to say, we need to reinvent, we need to rethink what we’re doing. And then I came across a movement in business, actually several movements in alternative business, where they say that a business shouldn’t just be about profit. You should also care about the people in the business. You should care about being socially responsible in your community. You should care about the planet, be sustainable.
Conscious Capitalism an example of this, B corporations are an example of this. And so I says, these people are already committed to doing some of the things that I think IT should be. So let’s combine the two. Let’s look at where mistakes were made in the past, see if we can come up with a different foundation or different basis. And then what could we do or how could we develop?
How can we make an alternative business successful with an alternative IT?
Federico Ramallo (12:20) Very interesting, very interesting. The more I think about when people talk about AI replacing engineers, the more I’m thinking about these core competencies because I don’t think that AI can make abstractions of business and human problems.
in abstractions on objects or following design patterns, things like that. It’s not able to do that yet. And that’s why when people talk about vibe coding, the quality of the code is really bad. I mean, it can do what you’re asking to do, but then ask them for a small modification and the whole thing breaks, right?
David West (13:02) Yes, that’s one thing. something that the mass adopters of this AI coding totally ignore the fact that the people who are really, really good at it were really, really, really, really good programmers before they started using AI to help them. So if your skills are up here,
and you want to use AI to help do some of the tedious stuff down here, great, it works wonderful. But if your skills are down here and you’re trying to use AI to get to here, it’s not gonna happen. It’s not gonna make you better.
Federico Ramallo (13:39) Right.
Yeah, and there is this, you were talking about how humans are inherently unreliable, right? And I think that the way that we learn is about experience and mistakes, experience and mistakes, right? And then going through the theory, which sounds abstract, but allow us to have the foundational knowledge to understand what is going on on what we’re doing, right?
So, but there’s still a, in that learning process, there is a lot of trial and error that we have to do, right?
David West (14:06) There is a learning process, there is a lot of trial and error that we have to do,
right? And if you delegate to an AI tool to build something,
Federico Ramallo (14:16) And if you delegate to an AI tool to build something.
then it might work, but you don’t get the knowledge. You don’t understand why.
David West (14:22) then it might work but you don’t get the knowledge, you don’t understand
why. Yes. Right, that’s exactly the case.
You know, take something really simple. So the big thing now are these large language models that deal with language. Okay. So let’s take an example from language. There’s a, there’s this whole category of sentences are called garden path sentences because they are very difficult to parse. An example is the man saw the woman in the park with the telescope. Perfectly grammatical sentence.
What does it mean? You know, either the man or the woman could be in the park. The man could be using the telescope. The woman could be, you know, the man’s watching the woman that has the telescope using a telescope. I mean, there’s no way to tell from the sentence all by itself what it means. What you need is you need context. So if I came up, you know, if I asked an AI, which I have,
You know, I’ve asked, uh, you know, Claude, you know, to parse this sentence, tell me what it means. And he says, well, it could mean this. could mean that. And I say, could it mean that the park has the telescope? And he says, you know, the, says, no, I don’t see how, cause there’s no, there’s nothing in the sentence that would imply the park has the telescope. And I said, well, what if the preceding cell sentence was I was visiting my friends in, um, Los Angeles.
which has a famous park, Mount Palomar, which has a huge telescope in it. So, yeah, know, given that context, then that meaning is possible. And then you can say, well, what other kinds of things might give meaning, you know, provide context to help you interpret a sentence? Your culture. So we could make, I could make, I could craft a sentence and I could mention Dilbert.
in that sentence. Well that only makes sense if you’ve read to Adam’s cartoons, know, the Dilbert cartoons. So if it’s not part of your culture it doesn’t have any meaning. And this happens all the time when we go from our native language to a language that is foreign to us. You know, I mean there are all kinds of innuendos in French.
Federico Ramallo (16:26) Right.
David West (16:43) or Romanian or German or whatever that I’m never going to get because I don’t share that culture and an AI doesn’t have anybody’s culture. So all it has is the text and can do predictive modeling on the text patterns. You know, it can’t do interpretations or find meaning because it doesn’t have all the context.
Federico Ramallo (16:56) Right.
Interesting. Yeah, I mean, even if you give the LLM all Dilbert’s comics, all the content, there’s still a lot of the jokes has innuendos or references to the culture that it’s not on the body of the comics, right?
David West (17:24) Yes.
Yes. Yeah. So, um, um, you know, and AI is really, really good at writing a business letter because that’s such a constrained environment and you have to be so precise in your meaning in order to communicate. Um, but if it would be terrible at writing a novel or being a standup comedian, you know,
Federico Ramallo (17:53) Right. I saw an LLM simulating Seinfeld. So it’s basically a 24-7 Seinfeld show, just talking the way that he would talk. And sometimes it’s funny, sometimes it just misses the mark.
David West (18:04) Mm-hmm.
Federico Ramallo (18:11) right?
So basically, my conclusion to that is it can emulate, use some word patterns, but won’t understand the second level of “why’s”.
David West (18:12) Thank you.
emulate, use some word patterns but want to understand the second level of why’s.
Yes, yes. And if you circle back to code, you know, using an LLM to write code, which a lot of people are doing, consider the training set. Billions and billions and billions of lines of code out there, right?
Federico Ramallo (18:27) Right. Yeah.
David West (18:46) How much of it is any good? So how can you expect your, your AI to exceed the level, you know, it’s doing predictive modeling on what’s there. So how can it do anything better than what’s there? And most of the code out there is really bad.
Federico Ramallo (19:02) Yes, yes, and it’s a trade off, right? When you’re writing code, it’s a trade off of speed, quality, behavior of what you’re trying to build. And then there is this, you don’t know what you don’t know, right? When you’re building the code. yeah, for me it’s a process I’ve been coding for 20 plus years.
David West (19:03) ⁓ It’s a trailer
Yeah, for me it’s process I’ve been coding for.
Federico Ramallo (19:26) And every time I look at my old code, I felt ashamed of what I wrote, which means that I learned, I’m in a knowledge position.
David West (19:31) ashamed of what Yes!
Yes. Knowledge position. Yes.
I do the same thing with my writing. I’ll go back and I’ll read papers that I wrote when I was in college or something. Boy, you were an idiot.
Yeah. But occasionally you do come across something that’s really good too.
Federico Ramallo (19:52) Right, right, and when we’re providing all that information to the AI, the AI cannot have a distinction between what is good and what is not good, right?
Yeah, and that’s why I usually say that it doesn’t have this concept of abstractions yet. Maybe in the future it will, right?
I like your idea of being able to…
David West (20:13) video.
Federico Ramallo (20:14) to translate these conscious capitalisms into IT because I’ve seen that…
David West (20:15) I’ve that
Federico Ramallo (20:23) companies with a mission to change the communities to have a social impact.
David West (20:23) companies with a mission to change the communities, to have a social impact
Federico Ramallo (20:31) has been a much more interesting concept for me to pursue.
David West (20:31) has been a much more interesting concept for me to pursue. Yes, it’s a, I guess I first came across some of this stuff when I was in Europe.
And we were interacting with a lot of companies in Europe that were certified B corporations, benefit corporations. And there’s a company called B Labs, which does an audit of your company and its practices in order to, you know, certify you as a benefits corporation. And you look at all the things that they’re concerned about. They’re concerned about their people. You know, are we making
Are employees’ lives better? Are we giving them meaningful work? They go home at the end of the day saying, wow, I accomplished something and I’m really happy that I did it. They look at their practices and say, you know, is this good for the planet? Am I, you know, using paper cups and plastic cups and stuff in my cafeteria or am I using glass and re-washing it?
Federico Ramallo (21:16) You
David West (21:29) which one is better for the planet. And those kinds of things matter. I mean, it makes everything better for all of us. And the technology should be able to do that. If you go back to the 1960s when computers were first start, you know, appearing and becoming commonplace, there was a large movement, perhaps most famous in that was Douglas Engelbart.
And he was saying, okay, let’s use these computers to ennoble and to enhance human beings, to augment human intelligence, not replace it, but to augment it. You know, let’s use this to make us better people. Even Steve Jobs more contemporarily, you know, when he was talking about the, Mac, he was talking about computers or a bicycle for the mind.
They are a tool that help your mind go faster. You know, just the same way a bicycle can help you get travel distance across the landscape faster. A computer should be able to help your mind go farther and faster than before. It shouldn’t be something that replaces you. And conscious capitalism and some of these alternative businesses are already committed to that. You know, they’re saying let’s make our people and our world better.
And let’s use technology to help us do that.
Federico Ramallo (22:46) Amazing. Yeah, I like the idea. ⁓
David West (22:49) idea
Federico Ramallo (22:49) The concept of using the technology to help us become a better versions of ourselves and augment what we do, I think is inspiring.
David West (22:51) in the technology.
Federico Ramallo (22:59) It’s interesting you mentioned how that you mentioned that there is this idea of engineers becoming commodity and becoming could be outsourced offshore, right? To the lowest possible cost, right?
David West (23:01) you mentioned.
This is idea of engineers becoming commodity.
be outsourced to the lowest possible cost.
Federico Ramallo (23:15) And here probably I am.
I’m pursuing an oxymoron, anyways. ⁓ So because I’m running a nearshore company where I build engineering teams in Mexico for companies in the US.
David West (23:17) I’m pursuing an oxymoron but anyways… So, because I’m running
near company where we, I build engineering teams in Mexico for companies in the US.
But ⁓ one of my ⁓ missions is to ⁓ change the life of 500 engineers in Mexico.
Federico Ramallo (23:36) But one of my missions is to change the life of 500 engineers in Mexico.
And I work towards working with the teams to have more ownership, to understand what is the value that they’re adding to the users, what is the impact that they are
David West (23:49) I work towards working with the teams to have more ownership to understand what is the value that they’re adding to the users, right? What is the impact that they are
adding to the users? So how much are they changing their lives through the software that we built, right? So…
Federico Ramallo (24:03) adding to the users. So how much are they changing their lives through the software that we built? ⁓ So
trying to do more than the traditional outsource vendor engineer would do.
David West (24:15) trying to do more than the traditional outsource vendor engineer would do, right?
Mm-hmm. there is a need for talent in the industry. The talent definitely exists.
more than, you know, in the United States or wherever your home base happened to be. The talent is worldwide. I mean, it’s out there. The problem is not in the people or the talent. The problem is the way we try to make use of that. So, you know, in 1968, when I was, you know, first started writing programs, I had to take training classes, but in banking.
I mean, the idea was to make me know as much about the domain as possible. So when I was writing code, I knew, you know, how it was going to be used, who was going to use it, where it was going to be used. And I could see the impact. By the time software engineering became an established discipline in academia, there was so much to know about computing and software development that we totally abandoned the domain. We said, give us some specs and we’ll write the spec.
And that’s all we’re going to do. And of course, it didn’t work because the users didn’t know how to write specs. We didn’t know how to read them. So they got separated. Fast forward to the outsourcing era, and we’re doing the same thing in spades. We’re taking the specifications and shipping them off to India where they have no clue about what is going on, you know.
with the customers or people over here. We don’t either. The people that sending the work overseas don’t know either. And so you have people doing things to an imaginary specification. I mean, they’re building a castle in the air and they’re doing it right. They’re doing it well. Some of the best software developers in the world are in India.
That doesn’t mean that their program, when it gets back here and starts to be used, is gonna be worth anything because they didn’t have the context, you know, that was necessary to make a usable product. It made a great product, know, accurate as all get out, but you know, it wasn’t usable. And it’s not their fault. It’s the way that we try to make, you know, the workflow.
Federico Ramallo (26:29) Right, right. What I’ve seen is people, for instance, putting a dot on the interface because there was a misprint on the document, right? And it was a little speck of ink on the drawing, right? Nobody asked why, you know? And they take the instructions literally, right?
David West (26:36) a dot on the interface.
misprint on the document. was a little speck. Yeah.
Drawing, right? Nobody asked why, you know. And they take the instructions literally, right? Yes,
yes. So I had one of my academic programs I started when I was in New Mexico was an apprenticeship program. And we took students and put them to work on projects for real world customers.
One of them was the state engineer’s office and they had contracted with a company who had offshored to India. They got this big block of software back that was technically correct, but they couldn’t use it. And so one of the projects that my students were working on was fixing this, you know, making it usable.
And you could go through the code. And I mean, the code was flawless. You know, it was error free. It just didn’t do what the user was expecting it to do because the things were just taken literally. mean, absolutely literally. What else could they do? I mean, they had no access to anything except the specifications. So.
Federico Ramallo (27:54) Right, right, they had to work with only the information from the specs, right?
David West (28:01) Yes.
Federico Ramallo (28:02) Yeah, so one of the things that I implement, one of the changes that I implemented is this idea of from playing mini-golf to product owners to converting the, rather than giving us a product requirements with a lot of specs to turn that into a storytelling, right? So instead of becoming this boring meeting for everybody where the engineers will not want to join to…
David West (28:22) this boring meeting for everybody where the engineers would not want to join to
everybody wanted to join because it was a fun activity, right? Right. We were learning about the user.
Federico Ramallo (28:27) everybody wanted to join because it was a fun activity, right? We were learning about the users, we were
learning about the whys, and it was this engaging story, right?
David West (28:38) It was this engaging story, right?
Yes, yes, that’s, you know, the word story means a whole lot to me because that’s the way that human beings have learned to communicate with each other since we invented language. Even before that, I mean, when you look at cave art, that’s a story.
You know, it’s hard to interpret if you’re not a cave person, but it’s a story. It’s capturing the story of a hunt or some other ritual or whatever. But then when we have language, we tell each other stories and that’s how we learn our culture. That’s how we learn 90 % of what we know. It’s not stuff we learned in school, it’s stuff that we heard via stories. You know, a movie, a bedtime story from our parents.
you know, all different kinds of ways. But story, our brains are actually hardwired for story. And that’s how we make context. That’s how we make connections. Is we put all this together in this big web. And, you know, that’s what makes us intelligent. And you don’t have any of that when you try to write it down in the specifications.
You you’re missing all of that other stuff.
Federico Ramallo (29:50) Right, you.
you lost the spirit of the soul of what you’re building.
David West (29:53) Yes.
Yes. Yeah. So when I was in high school, I was taking Probability and I was having, you know, a fair amount of difficulty with that until one day I came across a story of how probability was invented. And the guy Fermat and a couple of his colleagues, Pascal, I think was one of them. They were playing a card game like poker.
and it got interrupted midway through the game. So there’s all this money in the pot and they wanted to figure out, how can we divide that up fairly? And so they had to invent probability of what’s the likelihood of this hand or that hand being the eventual winner so that we could figure out how to split up this pot. That’s how probability was invented. Now that story, all of a sudden it clicked and I says, oh, that’s what we’re doing.
And the equations made a whole lot more sense to me after that.
Federico Ramallo (30:53) Wow, I didn’t know that. That’s amazing.
David West (30:55) Yeah.
So I’m a terrible mathematician, but I love reading about it.
Federico Ramallo (30:57) Yeah, because I always had issues with probability.
Right.
I always had issues with probability because it’s this idea of non-deterministic. So it’s like, well, we know it’s probably, we have this level of probability, but we don’t really know, right?
So the other thing we’ve done on my teams is
this idea of using the trade-offs of understanding the value for the users, then we can prioritize which expected behavior should we spend more time building automated tests because that’s more valuable for a user.
David West (31:18) this idea of using the trade-offs…
understanding the value for the users, then we can prioritize which expected behavior should we spend more time building automated tests because that’s more valuable for a user.
Federico Ramallo (31:37) And the best example I give is if you go to an ATM to take cash out.
David West (31:37) And the best example I give is if you go to an ATM to take cash
out.
Federico Ramallo (31:43) We should spend a lot of time making sure that the cash goes out when you want, right?
David West (31:43) We should spend a lot of time making…
Federico Ramallo (31:47) if the welcome message fails or whatever, doesn’t matter because that’s not critical for the user expectation.
David West (31:48) If the welcome message fails or whatever, doesn’t matter because that’s not critical for the user expectation.
Yes. Yes.
And that’s, that’s, you know, an area where serendipitously the people writing the code and developing those interfaces, they probably used an ATM. And so they’re bringing to bear a whole lot of knowledge that, if I’m writing a, an accounting system or something like that, I probably don’t have that background knowledge. So I am not going to do anywhere near as well.
writing an accounting system as I would or a control system or something of that sort or an electronic cockpit. know, because I’ve never flown, well, I have flown a plane, but I’ve never flown a big jet with all of those buttons and dials and stuff. So how am I going to know what what the pilot is likely to encounter or not encounter?
Federico Ramallo (32:41) Right, you have this disconnect and as you mentioned before, you have this lack of context, right? Cultural context.
David West (32:47) Yes.
Federico Ramallo (32:49) Interesting. So you mentioned that you are about to publish your third book, Rethinking Business and IT. Does this come from the manifesto? And you’re implementing some of the ideas there. Can you tell us little bit more about the book?
David West (32:55) your third book, right? Working Business and IT. Does this come from the manifesto?
Okay, the ⁓
The inspiration for the book was again, you know, this idea that there’s a new category of business that might be receptive to ideas that are radically different within the profession, the software development profession. We’ve had a lot of really, really good ideas over the years that basically get ignored or they get subsumed and corrupted and co-opted. Objects would be one agile is one.
a domain driven design is one, even all the way back to the seventies and structured analysis and design where they were telling you to go out and understand the system that exists before you try to build something to replace it or to interfere with it. These ideas are there, but they get ignored. And so I’m saying, okay, now it’s time to just bite the bullet, quit trying to change people’s minds.
Let’s find a new audience, these conscious capitalists, what’s give them a totally different way of approaching and thinking about things. You know, one that’s based on complex systems. Software engineering is only good if your system is a deterministic or a mechanical kind of system where you can predict what’s going to happen. When you can know what all of the elements and all the relations are in detail, then you can use engineering to build it.
You know, if we didn’t have physics and finite mesh analysis, we couldn’t build bridges with engineering. But we do. So we can do that. We don’t have anything equivalent for a business or for a biological system, you for complex systems. So we’ll recognize complex systems. We’ll reinvent how we develop an understanding of those complex systems sufficiently that we dare to make changes to them.
And then how do we go about making those changes that are consistent with the nature of that system? So those are the kind of the three pillars, I guess, of the book is founded on. then that to be the first three or four chapters going into that stuff. And then the rest of it is detailed how, including when we get down to software, how do we build software?
a single system element or a single small application at a time, you know, the way that biological systems work. We don’t try and come in and engineer an entire ecology at once. You know, we’ll add this animal and see what effect it has. We’ll add this plant and see what effect it has. And we evolve and we adapt and we have to be able to do software the same way. So it’s really different.
And I would predict that everybody in the software engineering community, mainstream software development is going to hate this book. But I hope the Conscious Capital people like it. Because I think it’ll do them a world of good.
Federico Ramallo (35:51) Hahaha.
Hahaha
Right, right, very interesting. I was thinking about, you were talking about building bridges and I remember this story of…
builder, an engineer that was assigned to build the bridge. So he built a bridge and then he realizes after he finished building the bridge that the bridge was built incorrectly. And he goes back to his house, to his wife, and he shares that news with her. And the story goes that during the night she goes and burned the bridge, right?
David West (36:24) she goes and burn the bridge.
Federico Ramallo (36:26) So that’s why
the next day, you know, she says, well, the bridge is burned down, so he has to build it again, right?
David West (36:31) says well the bridge is burned down so he has to build it again.
Yep. Yep.
Federico Ramallo (36:36) And then everybody kind
of buys the story, right? And then he builds it instead of, builds again instead of having to tell to the whole town that he made a mistake, right?
David West (36:39) He builds it instead of having to tell the whole town that he made a mistake,
right? Right. Right.
Federico Ramallo (36:48) So when I’m thinking about software, there is no debris, right? If you build it wrong, you can always do it better, right? Or change it. There is no byproduct, ⁓ right?
David West (36:50) thinking about software ⁓ there is no there is no debris right if you build it wrong
You can always do it better, right? Or change it. There is no byproduct, right?
Yes, in a sense, yes.
Yeah. Your bridge story reminded me of, Cray computing. had a lot of stories. did a, anthropology study at Cray computing years and years ago. but one of their stories was about Seymour Cray himself. And every year he had spent all winter long building a boat and then he’d sail it all summer and learn how it worked and how it performed and whatever. And then come fall, he would have a big party and he had burned the boat to the ground.
so that that winter he would take the lessons that he learned and start all over again and build next year’s better. He didn’t try to fix the existing boat because it was, you and that’s way it is with software. You we spend a lot of time trying to fix a broken thing instead of saying, okay, let’s bite the bullet and, you know, go back and make better presuppositions and do it right this time.
We’re not allowed that luxury in software.
Federico Ramallo (38:12) Right, those mistakes are not noticeable, Usually you don’t see them, right?
David West (38:18) Yes. Yeah. and, yeah, even worse is we have this team over here that build it wrong and we have this team over here trying to fix it. And, you know, it’s an impossible situation, you know.
Federico Ramallo (38:31) I have a friend who used to work at a tireing factory, big warehouse full of tires. And if he made a mistake on the vulcanization process, the temperature was not correct, the mixture was not right. I there were so many factors that could go wrong. You could have a perfectly looking tire that you could not sell because if you use it at speed
David West (38:45) mixture was not right. mean, there were some
Because if you use it at speed
Federico Ramallo (38:58) it could explode, right?
David West (38:58) it could explode,
Federico Ramallo (38:59) So he had to rent warehouses to hide the faulty product.
David West (39:00) had to rent to hide the faulty products.
Yes.
Federico Ramallo (39:04) We need something like that for software, right?
David West (39:05) We need something like that for software, right? Yep.
Yeah. So I did a lot of consulting in the corporate world and you know, it’s a familiar story. A company will start a project. They’ll say, we’re gonna take three years and $3 million and build this system. They get a year into it and it’s failing and they’re behind schedule so they cancel it. And then when management has changed enough,
that nobody remembers the failure. They say, let’s start again and try and do it again. But because nobody remembers what went wrong the last time, they probably repeat the same mistakes again. So it’s amazing.
Federico Ramallo (39:38) Hahaha
Yeah, and as a consultant, you can see those issues and you can fly above the internal politics and the internal egos because you’re just coming out fresh and being able to say, this is wrong, this is wrong, know, point out the issues with no restrictions, right?
David West (39:57) yeah.
Yeah.
Yeah. until recently, if you were a software developer, you had it really well. It didn’t matter how many mistakes you made, because you could just quit and go to work at another company tomorrow and nobody, know, I mean, the demand was so great. So that, mean, that’s the worst thing about AI for developers or for bad developers is the fact that
Federico Ramallo (40:22) Ha
David West (40:30) they can’t easily switch jobs, you know. They can get replaced easily, but they can’t switch jobs. so accountability is starting to creep in a little bit for some.
Federico Ramallo (40:40) how do you think the industry should change in order to track ownership and accountability more on software engineers?
David West (40:42) changing.
Okay, actually Kent Beck and his original XP gave you the clue. know, again, respect your developers for being intelligent human beings who take responsibility for what they do. Let them self-organize, let them self-manage, give them a coach, which is basically someone who provides resources to them and brings things to their attention that they need to know about because…
the coach is an external observer, but to let the team be responsible for their own work. And then, you know, that’s all that’s needed. But the flip side of that too, is that the developers have to calm us to continually improve, continually get better, you know, both as a team and as individuals. And neither side of that equation
was ever really implemented. Management didn’t trust the developers. The developers were lazy and didn’t try to get better. You know, they took refuge in routine and practices and things of this sort instead of thinking about the principles. And so I think the answer has been there. That’s one of the more recent instances of people pointing this out.
but you can go through the whole history of software development. James Martin in the 1970s wanted to do the same thing. He wanted to create specialized teams, put them in a room all by themselves, give them self-control and expect continuous improvement of them. So the idea has been there all along, but you’ve got to have management accepting, delegating the authority.
And then you’ve got to have the developers taking responsibility for being better. And until you have that, you’re not going to get very far at all.
Federico Ramallo (42:31) Mason.
Right, Wow, so much to think about.
So we’re running out of time, but we have a few more minutes. Would you like to share some final insights before we wrap it up?
David West (42:46) I guess just one kind of general one that.
And it pertains to AI, it pertains to software development, it pertains to a lot of things and this notion of what makes human beings and human intelligence different. And you could find some of the answers in work that’s far outside of software development. A book called The Master and His Emissary by McGillchrist.
is a book about right brain, left brain thinking. But the premise is that, you know, we as human beings, we think with our whole brain, our entire brain all the time. But we do have specializations, you know, the right brain, so to speak, or we’ll just say half of the brain is concerned with connection to the universe, to the world around us, you know, being aware of what’s going on around us.
The other half of our brain is focused on how do we manipulate the world? How do we do different kinds of things? And that part of the brain, how to make use of the world has gained dominance so that we have almost lost most of the other skills. So we know how to build atomic bombs. We don’t know how to live a peaceful society.
We know how to write code, but we don’t know how to write code that’s useful. We know how to mimic human intelligence or least verbal intelligence, written intelligence, but we don’t know how to make a human being or how to enhance or use the technology to leverage human beings. And it’s because we aren’t whole. As human beings, we have to recognize both parts of ourselves and quit
saying this part doesn’t matter only this part matters. You know because this part makes us money and gets us rich and you know builds machines that everybody says “ooh” and “ah” over. You know this side is is much more important but it gets ignored and so we have political chaos we have wars we have you know all these other things so be a human being. That was ⁓
Federico Ramallo (44:46) Bye.
Ha ha ha ha.
David West (44:50) That was actually a headline of an op-ed editorial. I’m forgetting his last name now. It was the New York Times op-ed editorial. And the title of it was, In the Age of AI, Major in Being Human.
Now the problem is we don’t have any human majors. We don’t have a major that teaches you how to be a human being. But that’s what’s really needed is we need to know how to be better people.
Federico Ramallo (45:14) Right. Right.
David West (45:16) Otherwise the machines will destroy us because…
Federico Ramallo (45:18) Right, if we want to emulate the machines, then it’s going to be a losing battle for us.
David West (45:22) Yeah.
Yes, yes.
Federico Ramallo (45:25) Amazing. David, I truly appreciated you being here today. I think we learned a lot and it’s been fun to have a great conversation with you.
David West (45:26) I appreciate it.
I appreciate the opportunity and I had a good time as well.
Federico Ramallo (45:37) Thank you.