Hey, a quick message, for those of you who are listening to this episode on Spotify, I have a small favor to ask Spotify. Now allows mobile users to rate podcast, I would really appreciate it. If you can take a quick, pause to go to the technique Journal podcast page, and leave your favorite show. Your best rating on Spotify. It will help me a lot to get this podcast to reach more people on the platform. Thanks a lot.
We want to write as little software as possible, and we wanted to have as much value as possible. I think that's an obvious thing. But if you actually focus on that, then you think a lot more about, how can I build that other kind of build that quickly? How can I have it maintainable when you evolve? And how can I try and focus on the things that are maximum value versus often? A project gets into all sorts of features and other stuff which really doesn't matter.
So, it means that you have to be close to your customer. Hey, everyone. My name is Henry Surya Widow. And you're listening to the technology, you know, podcast the show where I'll be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work.
So let's dive into our Journal. Hello, to all of you. My friends and my list. - welcome to the technology on our podcast, the show where you can learn about technical leadership and Excellence from my conversations, with great thought, leaders out there. And this is the episode number 93. Thanks for tuning in and
listening to this episode. If this is your first time listening to technology, you know, don't forget to subscribe and follow the show on your podcast app and social media on LinkedIn, Twitter, and Instagram.
And for those of you who enjoy this podcast and wanting to contribute to the creation of the Our episodes support me by subscribing as a patron at technology, not Dev slash Patron. My guest for today's episode is Dave, Thomas, Dave is the chairman of the dura Corp founder of your Australia and Lambda gem conferences and a go to conference fellow in this episode. They've shared about his personal research, which he currently refers as 42d on ideas that we can use to develop high
value software rapidly. He started by describing Being the current developers productivity challenges and touch on. The idea that big is not better relating to the size of the team and code base and how he finds the development tools are becoming more and more
complicated and complex. We then discussed on the importance of developers, understanding domain, knowledge leveraging tools, such as decision tables and spreadsheets, and we also discussed how the choice of programming language actually matters, who has the end they've shared about Using a data Centric approach to deal and build upon Legacy systems towards the end they've shared about using a data Centric approach to deal and build upon
Legacy systems. And also shared his perspective on query as the future of programming. I enjoyed my conversation with Dave. As always he shares very insightful perspectives especially taken from his vast experience. And I'm always amazed by the different exotic. Programming languages that he talks about if you So enjoyed this episode, please share it with your friends and colleagues who can also benefit from listening to this episode.
Leave a rating and review on your podcast app and share your comments or feedback about this episode on social media. It is my ultimate mission to make this podcast available to more people. And I need your help to support me towards fulfilling my mission. Before we continue to the conversation. Let's hear some words from our sponsor. Today's episode is proudly sponsored by skills matter. The Mobile community and events platform.
With more than 100,000 software professionals here members. Can organize their learning experiences around the technology topics. They care about most you get on-demand access to their latest content thought, leadership insights, as well as the exciting schedule of tech events
running across all time zones. So we're the devops our data science is your bus or you are a fan of functional programming or all things Cloud, you can make real connections with People who share your interests head on over to skills method or come to become part of the tech community that matters most to you. It's free to join and you will find it easy to keep up with the latest tech Trends. Are you looking for a new cool swag package?
You know now offers you some swags that you can purchase online these wax are printed on demand based on your preference and will be delivered safely to you all over the world where shipping is available. Check out all the cool tracks available. Bill by visiting technology, no dot f / shop, and don't forget to break yourself. Once you receive any of those threats, hello everyone. Welcome back to the new episode of the pycnogenol podcast.
Today, I have someone with me who I always admired, whenever he gave presentations or talks when he came by to Singapore, his name is Dave Thomas, he is also, the founder of eaeu Australia. And also the go to conference fellow. I always find your top very insightful, so, Looking forward to this conversation, Dave and I'm very pleased to have this chance to talk to you today. Henry, thanks very much for a great show, really enjoy listening to it and catching them online.
Yes, there are two, Dave Thomas has. Fortunately, he's a very good friend. He was doing Ruby and prior to that I was doing Small Talk, which you could sort of, think of as the first Ruby, if you want. So, Dave's now doing her lying in JavaScript, I'm dabbling in Becker. Functional programming is where I've been for the last little while, so great to be here. So maybe for people who may not know you yet, if you can introduce yourself spending a
few minutes. Still tell us your journey telling us more about your highlights or any turning points in your career. Oh, Henry, has to be careful asking a software fossil about their history. I could put the entire audience to sleep been really fortunate to work with a lot of amazing people. I think that's one of the advantages of being early in the field is there weren't very many books and the word that many
experts. So I think in many ways it was a lot easier to become an expert because you didn't actually have to know that much. So I was very fortunate to be there. I was able to work my way through college paying by programming helping these students in business do their religious assignments. So, they could go skiing, they would pay good money for that. So, I was fortunate to work in a number of areas, during work terms, and that was really great.
And then after graduation, I was lucky to get a job in the computer center, computer center, probably would not be the place of maybe some people would go look today but in the early days I mean that's where simula was invented was the Norwegian. Computer center was really the place if you wanted. C programming. Language is an operating systems. That was really the only place you can see it.
You could get in that big computer room with all that air conditioning and be there with the machine. So it was really quite exciting. So I ran the programming languages group there and work with both, the Honeywell in Xerox who were computer companies. In those days, we were able to through our relationships. Helping them end up getting some contracts, develop the Pascal, compiler and compiler tools and database refactoring. Oh jeez. So we developed quite a good
relationship and those. Fortunately, I got to see a lot of the US industry from the inside and how they manage software projects are didn't manage software projects as the case may be. So I was there for a good while and then I went back to grad school, did you graduate work and specialized in databases and programming languages? And just as I was finishing grad school, the dean of the School of Business came and he says, you've been teaching our
students for some time. We really have a terrible old fashioned die. The program, would you come and be a faculty member and redesigned the program? So I was a privilege to do that. I did a lot of teaching it's a
privilege to teach students. Keep you honest they asked those naive really hard questions which always great to have to think about I've started there and soon after that the Carleton University here in Ottawa Canada decided that they wanted to have a new school of computer science and so I was invited to participate in the founding of that school I ended up with a cross appointment between business and In computer
science. My undergrad is in electrical engineering, but that's the nice thing about Computing. You get to go to different disciplines work with people and biology and finance and so on. And that's where I was really interested in office automation. I came across this work called the system for business. Automation that took me down a very interesting path in two languages like scheme and particularly Carl. Hewitt's actors which is kind of the inspiration of things like Acca.
And so on the route, they're commercially that led me fairly quickly towards the Len called small talk and object orientation. So I was really interested in that. We actually built an implementation of small talk from the byte magazine in 1980 implemented in a very exotic language called APL. There'd be many cruel and unnatural acts on my journey.
I love exotic languages so friend of mine called me up who was in my engineering class and said look I'm building this hardware company but we don't know anything about software. You've got to come and work with me. So, I took my sabbatical working in a company that builds at 80. A and 68,000 microcomputers. We built a network operating system essentially like a network file Appliance to
attended. A first course by Brad Cox who was a GE. Then he had a language called oopsie which you would only know today as objective-c. So that was the beginning. It wasn't ready. So we both our own language and compiled it to fourth or there's a very interesting language. Many of the tricks we use their we actually use later in small talk and Jabba Building embedded systems, how to put things in ROM and Flash and deal with garbage collection in really complex systems.
So after I worked at this company die for I went back to UNI and I was really convinced that I've needed to work on the real thing. I needed really find out about objects. The only way to do that was really to study Small Talk. Fortunately we were able to get early small talks from Berkeley. Dave Unger's work on sore. Did you talk methods and from tektronix who at the time we're
building a, I work stations. We were fortunate to get our search funded by the DND in Canada who were looking for a way to build models of multiprocessor systems. So they funded us to build actra which is a multiprocessor, small talk system. They also funded every developer, which is the easiest way to describe it.
Sort of a get for small talk done Circa 1986 that allowed Small Talk programmers, who normally work in an image and you do not cooperate to actually share and do version management, fine-grained level and that was our first product. Then both tektronix Cindy and defunded us to build a production. Small talk, and the small talk we built for tektronix embedded. Small, Talk V was actually put into the tektronix oscilloscopes.
And those oscilloscope started shipping in 1988 before Java there were byte codes inside of embedded systems. Several of them, including later on the momenta pain computer and first version of the Sony Qualcomm mobile phone prototypes in the early 90s, so that was really exciting. Small Talk was a wonderful time in 1997 oti which was the company that did this work was purchased by IBM. Of course, before that had built IBM a small talk which was the basis for the IBM, visualized platform.
After we were purchased, we were given the mission to develop visual aids for Java. And the IBM jvms known as j9. Still to this day, we were headed the enjoyable and challenging opportunity to develop that really without access to the source code from sun because would be Needed. So a lot of the core libraries and so on were actually written from scratch whether j9 virtual machine and Ide.
At the time, we started with the eclipse project Eclipse had another part called the UVM Universal virtual machine which was a multi-language virtual machine. But unfortunately IBM decided that they were only going to go ahead with Jabba at that point Eclipse was off and running but it became only a Java IDE originally, it was designed to be a multi-language ID, that's the way the journey goes I left. IBM. About that time. At that point, everyone was getting quite excited about
something called XP and scrum. Fortunately, we had a protest at OT, I called Justin Time software, which was really very much in the spirit of XP. I joined up with a bunch of other enthusiasts to form, something called the agile Alliance which I sort of apologize because agile has been such a depressing thing way. It's been implemented. It seemed like such a good idea. How could something, so simple, go so wrong. Oh well my apologies. Objects. Do had their problems, dude.
They're really powerful, but they're very stateful and you can make things complicated, learn some lessons from these things. After that did a lot of training and transitioning to people to 0. And then I had to withdraw myself and go back to a place called Madera research Labs with my former partner from oti Bryan Berry focus on Research or research themes were collaborative, analytics. Accelerated, development and
embedded systems. We did one project and Bedded systems and then Canadian government agency. CSE came along and said we have this. Big problem with cyber analytics. We're using these really old tools. We can't keep up with the data volumes in the speed so they said, we'll punch you to try your next crazy thing. They'd already use small talk and Eclipse IDE. Done in the past will try, whatever you're doing this time.
Very fortunate to have these kinds of customers, so we built something we called IV which is essentially a visual workbench for collaborative analytics. We sold that to a company called First derivatives created KX Labs. I was a chief scientist there until a couple of years ago when the last 18 months, what I've been doing is fortunately through Zoom interacting with the bunch of interesting people around the world, which is, I think the good news about the
pandemic. I've started my own personal research Journey, now that I have time to go back and look at some of the things that I found, very interesting but didn't have time to polish really understand what was good or bad about them. I'm now able to do that to leisurely Pace. I'm sure it'll keep me busy for the remaining time than I'm able to use my technical brain. Thank you for sharing such a
comprehensive journey of yours. So every time I listen to your story, you did this in your talks as well, right? So I'm always fascinated. I didn't know many of those names that you've mentioned, maybe also because due to my age, but always excited to hear. Okay? What are these things that Dave is talking about, seems like very exotic very fascinating. And then your story also told a lot of pin lines across Grabbing languages object-oriented a gel
data. Today we are going to talk, maybe a personal project of yours as well as part of your personal research, which is called 42d. Maybe name sounds interesting as well. Quite exotic. Can you tell us a little bit more? What is this 42d project? Sure. 42d is really just a personal project, 42 of course. Everyone should know, is the answer to life and the meaning
of the universe. So, 42 D is just one small Galaxy and it's the Alex see where we're seeking to explore and find ways so that small groups of developers can develop high-value software quickly that's really been my interest. Every time start a new product, a new application, is there some way we can change the process, change the tooling change, how we think, such that we can be more productive and not end up with big ugly code Mountain that.
We always seem to end up with that's what 42d is about and it's really just taking a few things that I found to be really. Full overtime, trying to now think about them and see if I can bring them to more mature ideas. So for those of you who may not know about the meaning of life and all that, I think Dave, is referring to this Hitchhiker's Guide to the Galaxy. This term comes from there so you're talking about increasing
productivity. Is it still the case that developer is still not productive? I mean, technology has advanced rapidly, so many tools, so many advancements, a IML and all that. So maybe if you can elaborate a little bit more, why do you think think developers productivity is still a challenge these days? I think because they're just too much stuff vendors and Capi Field of Dreams. Every you name it the next Amazon or Google Cloud, they all introduce another 40 or 50 apis. They'll sort them
alphabetically. So they're easy to use, there's many cases, they do the same thing. So you can't even tell, which one should I choose? The problem is this, there's so much of this stuff. There's so many libraries. There's so many open source, tools, and so many. Tools is very hard and they're constantly changing. So if you look people or oh no I'm moving from this one to that one.
Or I'm upgrading from this version to another so people are not using them, they're learning the next one and so it's very complicated API design. And framework design is really language design. And language is on is very hard when you're in a rush and you're producing apis very quickly to be competitive. You often don't get the same thought. Imitation and examples.
So this means it poor developers have to perform experiments while a good news is lots of things to blog because now you have to find how to use react 14, and the plays version of go and rust. These languages are actually very nice Scotland's a much nicer simpler Jabba. But the surface area of these apis keeps growing and it varies from vendor to vendor. So this makes things very
complicated though, thing. Is it my colleagues call me that In an asynchronous world and then we have to have everything be fully asynchronous to scale and get performance. This is definitely true. The bad news is asynchronous is not something that most programmers are really good at. There is a mechanism due to Eric Marr called async/await, which is heavily used. But there's a bunch of very subtle State machines underneath that. You really want to understand what's going on.
You need to understand what these State machines are doing asynchronous. Computing is still Challenge versus, if you do something like Fred. George talks about very simple data flow before you knew about it, there was a thing called data flow diagrams that we're very easy to understand today. They were very easy to implement on micro service architecture, but when you start building, these asynchronous systems are much more complicated.
So complicated tools, complicated designs and very demanding requirements in terms of performance and scale. That's why programming is harder today. I can see some of these And I'm just as well, especially for me learning, new tools, learning new technologies. You just finish one or two years working on this technology and then suddenly, oh, there's a new one. Okay. Maybe we should give it a try. And the other Advantage is always, there's a new job for
these people. So you learn something new and then you can jump to another job. No, no, absolutely. I mean, it's great for resumes, right? You just can't put that new thing on the resume if you can run ahead and it's a serious investment. So if you really learn it, I mean everybody else has to learn all those apis. That's your 10,000 hours. You have to put in.
So you mentioned as a subtitle of this project for the 2D you mentioned about maximum value and maximum speed, maybe you can explain what do you mean by maximum value? Is it that the software that we build has the maximum value out of it and maximum speed? Do you mean by the performance of the software or is it that its speed of churning out that software the speed has to do with the speed of development?
If it's high value software and it has to be passed and it needs to be passed to. It's really the value of the In the sense that we want to write, as little software as possible, and we wanted to have as much value as possible. I think that's an obvious thing, but if you actually focus on that, then you think a lot more about, how can I build that how they can? I build that quickly? How can I have it maintainable when evolve? And how can I try and focus on the things that are maximum
value versus often? A project gets into all sorts of features and other stuff, which really doesn't matter. So, it means that you have to be close to your customer. I think this is obvious Yes, but if you talk to most Edge old developers and you ask them what the business value of the story is they say, I don't know, it's just more important than this
other one. And they're buried in little tiny stories because they don't really have the big picture that was really, when can't talk about the metaphor, he was really talking about. Having the big picture of the really big story in some sense because if you understand, the key story, then that's where the key value is. And that's what you want to try and focus on an Implement, not
get distracted. And to all of Details and you start with this problem, this challenge with many of the software development teams is that you mentioned the speed actually comes, if you form a team that is small enough, you also mention right as little code as possible, bring as much value as you can but the tendency these days is actually to build more and more microservices, build more teams, add more people there. So many developers this day the
demands, right? So maybe you can tell us a little bit more sometimes this is obvious, big is not better but the tendency for us in this software. Or will these days is just to crime and at more and more. Oh I think you can go back to mythical man month where Fred Brooks and also were bullet. This is the story of the building, the IBM 360 computer is still a great book. He points out that over and over again. We have this nice triangle about resources and time.
Despite the fact that everyone who's ever worked in software, says, yes, we need a smaller team because we can move quicker and we can focus. We can maintain quality management has this panic. Because of everything rushing along today and the fact that boober has 4000 developers and maybe, you know, be only has thirty five hundred selenium 5,000 so they can have more than doordash or whatever.
So there's just this desire to throw features out on this is particularly true because of the web culture. So, web basing applications, people love to pile features in them. The problem is that once you get this many developers, you've just got more and more people, basically sticking code onto. Code mountain and it just becomes a bigger and bigger mess. Even though you've got tooling for testing and things like that. In the end.
The only thing that matters is the code and went Code matters. Then you get complexity. That's when you get technical debt. Yeah. Agile developers in the beginning, everything is great. And then they start begging for technical debt cards, who created the technical deck them, because too many people running
too fast. The other thing is, if you have to use a lot of different languages, a lot of different tools, And you have to communicate between more teams than you've got, all this overheads. So you've got the Layton complexity plus The Accidental complexity, like the apis are not working yet because it's a
brand new API from company XYZ. You just have more and more people and just piles up. I'm not met anyone who has any experience, who thinks that hiring a lot more people is the answer for how to get better software but people do it. The tendency from the industry is like that. I'm looking at a start-up, so it's also So the same thing hiring is always a challenge. We want to hire more and more. We want to hire faster and we have a lot of competitors as
well. People also putting these kind of people so it seems like what you're saying is resonating with me as well. Many developers now are being demanded and there are more and more features and code are being written. Which brings us to the discussion that you mentioned. More lines of code is actually problematic. We have so many developers, maybe they build more and more lines of code.
But why do you think bigger lines of code is always a challenge, of course, maintain abilities one but Is the Tipping Point that we should say. Okay, this lines of code is actually more than enough. I think the first question is, why are we building this? You'd be surprised how many things where there's people working on this and having a big debate about the architecture or the technology or the features. If you stand back and say, why is this important what customer
cares about this often? There is no customer that cares about its just somebody in the organization thought. This would be an interesting idea, the easiest way to reduce the code is not to write. It is what we're batting really essential. Is there a way that we can simplify that into a mechanism, which is much more compact. So, essentially we can replace something that's hard coded with an interpreter, which is easier to change.
Clearly the number developers influences, this from my point of view, I think that if you have an IDE, it shouldn't allow you to scroll that will limit the size of a function or a method so it has to fit on the screen. Maybe you can get smaller font if you want larger methods, As soon as you get into a world where you have to scroll, or basically you have to use emacs to find where the functions are and so on, I think you just get lost in the complexity, the,
even the tooling, right? I mean, you get the latest release of Visual Studio or Eclipse, it really doesn't matter. There's more knobs and dials and ways to do things. So you just put more and more complexity on the people. And often a lot of the functionality is there, you don't need it's not, obviously layered is their stock. Off in some Corner someplace. There's a whole Library you want to use a framework but it turns out you only need two classes in the framework.
But as soon as you pull the framework, it injects all these dependencies into your program because you have to know what's inside the framework. So it's not really a component.
It now becomes part of your program Frameworks were the big mistake of. Oh, oh, the idea was you were to use a framework inside and then you were to have an external API which was just a value-based so you didn't actually Have to know what the classes were inside the framework and so on, as you didn't have the subclass them and so on, but when you use a framework, you get to intimate with the actual framework and now you just create another big dependency on.
So many people's dependencies actually aren't the ROM. They're dependent on. Oh, look at this great library that I saw. Look at npms, for example, I mean, like, you're talking about the modern Navy technology disease as well. So many libraries, so many open source tools, so many things that could be easily installed these This could be like a I'm install or whatever your categorizing this as modern tools becoming more and more
complex. It seems that the answer to a certain problem is to just build more stuff. So I'm quite fascinated by this idea because yeah, there are so many things being built these days. Even my if you look at JavaScript library, maybe every few days, they will be one being created out of Any Corner in the world. Good developers, trying to use
as few libraries as possible. That's basically the secret we do, we really have to use this framework of this library because the Is that those things have a high cost down the road? It looks like an easy path but often they may go dead. The project May Fork. Some definitely too much code is definitely the problem and in part contributed to that with the whole notion of Frameworks and inheritance.
And so on and stateful programming, one of the benefits of functional programming, is that you're much more limited in the sorts of things that you can do. And in general, that's what we really need. We need fewer ways of doing things. For instance, when Amazon came out with their first, First apis. They were very simple,
basically. You just had asked, two, buckets API was very limited, but the good news is, it was easy to use because the word many ways to do things now for everything you do on AWS or any other Cloud platform. There's at least five other ways to do it, but I mean, the counter-argument will be people create these tools with the intention of increasing productivity. Right? More Frameworks, more abstractions mode. Libraries is actually encapsulating all those unnecessary details.
Probably developers don't need to think about. So what about that angle? How do you counter this argument really building more and more this for example. Aw services. So that developers become more productive and they just do things with a simple API call and then we take care of the rest. I think it's a nice story but most of them are written way too quickly. They may be well designed but they're certainly not well named or documented so I don't buy
that story. I think the answer is if something is really good it'll make its way into a library. That's used and not into a big tool chain. You just look and see, look, okay. Now because we got event oriented programming, we don't have a stack anymore. So what you have to do is you have to turn on tracing and then you'd get some to get yourself a honeycomb or some other observatories you, so you can try and create a stack from this event.
Something's wrong here, right? It's just too complicated. Maybe I'm just old, and don't get it, but it just seems like it's just too much stuff. So, I had an episode yesterday. Much semen is referring to cognitive load program has brain these days is really super, super intense because they're just too many things. I could be the state's reading, the code could be the tools. Understanding the apis. The surface areas that you're talking about.
It could be also all these orchestration, observability tools. It seems like these days. If you want to be trendy developers, you really need to master. A few of these Technologies before you can be considered the top level of developers. In the software, will definitely the case. On the other hand, I think there's lots of Smart Companies They're looking at things like low code.
The code is not something that all lie, aspiring hot, developers want and that's good because you want them to go. Some other place where they can have that big mess at that place with all their tools. So I think for normal business has low code tools, are a good approach, they reduce the surface area of what you have to use. They constrain what you can do, which is a problem if you want to produce the most amazing, JavaScript web site or
microservice architecture. It allows people to get things done, fairly simply. So I think the economics for companies that are willing to go with a local approach are very promising. There's a lot of choices there decades ago, there were things called for gl's, which were the low code language is of the time and people were very productive in them. Now, people look down at them because real programmers don't program in low code.
When the end, if you're running a business and people are successfully knocking at applications that seems to me like a pretty good idea compared to Trying to figure out how you hire the bright guys who argue with each other over, which technology and microservice architecture. They're going to use. And so on, I think simpler is always better to one thing that probably does not get simpler is the concept of business logic, right?
Depending on the industry, of course, these days we need to build more and more highly sophisticated rules logic, and whatever. That is, you mentioned that the domain knowledge is actually still important. So this also goes back to the concept of domain driven design, and all that. So, tell us more Why you still think domain is still the key here?
I think the challenge here is how can we get more developers to care more about domains when you use to start a new company long time ago, you would actually had to work in different departments so you would actually find out what purchasing was like and what inventory was like and you'd meet some people, are those people will your links to The Domain but now developers stay like to only focus on coding. They don't want to know any of that domain stuff.
Look, give me the story, but what this does is, it burns out the product owners or the product managers because they have to take something that's very simple. Domain concept and break it down into almost a task level. So, the developer understands it and to me, if you're breaking things down to task level, you've missed the point of agile. Basically means you don't really
have communications anymore. You basically are forcing people to break down all the work into tiny things that developers can Implement by work for. Derivatives. And one of the interesting things they did is they hired graduates out of Science and business and they would teach them Capital markets, essentially, everything about stocks and options the domain, and they would teach them how to program in the queue functional programming language.
But to the employers, they were super attractive because they could go in to a company like the stock exchange in Singapore, for example, and they could be productive because the business people could communicate with them. They actually knew the difference with swap on. An option, what the rules were and so on things like them. So it really allows efficiency in the organization because now the business and the developers are speaking the same language.
So I think it's a very, very important thing to train developers in the domain because you cut down all this overhead. The other thing is that there are techniques like decision, tables, State, tables, spreadsheets, that work really well for business people and those can be automated into
code. Instead of writing a bunch of story cards then coating them into Java or go you can automate these, they're just data-driven so you can change and these are very old techniques but they work very well and they're very good for capturing business knowledge. Most people that business can put their rules in a table or they can put their calculations in a spreadsheet or they can put their workflow in some sort of State machine or state transition diagram. These are generic techniques,
they're very powerful yet. Many programmers aren't taught them in school. They're not familiar with them and so they end up hard-coding all these things. So the calculation JJ you should just be able to change your spreadsheet and deploy it and run it today. We can run spreadsheets at blazing speed over trillions of rows of data. We don't need to hard code that in Java per se. The other thing to talk to Eric Evans, I don't think it's enough emphasis on domain language.
If you actually captured the main language in the old days, we call it a data dictionary. If you has actually a well-known vocabulary. Definitions. And so on those names travel through the architecture in the code so that you can actually relate the words in the requirements and the words in the stories and in the code, in the architecture, you can get this overall flow so you can find out what happens versus. If you just go into a code base,
you find programmer names. They're either XYZ or some horrible elongated thing that you can hardly type and it takes up all the space on your screen. So what you want is to reflect the domain in the Code, so that it's easier to understand.
So companies that want to make it go fast, they invest in making sure the developers understand the domain it should be ever going to be in a business transitioning from a developer to someone in a start-up, you learn very quickly that speaking the language of the customers speaking, the language of the domain, it's absolutely critical to success. The customers don't come to you then, describe exactly what they
want. They expect you as a Founder to have this vision and to be able to articulate it. Them in their own vocabulary. I have two things that I want to ask you as well first. It's about working in startups, a lot of startups actually. Although some work in well-known domains like Financial technology Medical but maybe the founding members are not super business experts. So these knowledge actually is not there. What will be your suggestion for these people?
They have the passion to work in a start-up building products, but they don't necessarily have the business expense so they hire product managers which is a generic product managers and having to be And a specialized domain software. So, this is, I think, one of the key trends these days, why? Probably software product is not optimized. I definitely agree with you. I think the problem is generic programming, a generic product person, generics are really
never all that useful. In the sense that what you really want is someone that has some value, they have experience in building real-time Control Systems, that's why you're hiring them. You're hiring them for their expertise, the way in which we like to do is where you can is work with domain X. Bert's. So, if you're going to be working in that particular, application area, where you want to do is find those domain
experts. They're more important because what you need to do is get steeped in domain. So it's better to engage with two or three real domain, experts or someone that's retired, maybe or they've done very well and they're able to spare you the time but you can essentially learn from them and build your kind of domain model and your understanding before you get your start up going very far. The problem is once you start
coding, You're in trouble. Basically, then you're already committed, you've got to schedule, you've got to release plan. So it's all about investing in the right places before you start coding because the more you can Define described in words and in the architecture, the more you'll be able to add new people because they'll come in say, okay, I see this just play the movie, or the talk about how we got here, and where we're going.
And what's the domain about companies that were very good at this. For instance, Bob work started, originally you Successful consulting firm, I'm sure, you know them when they started, they had this unique idea of having really super business. Analyst people who really
understood given domains. And that was one of the things that was a real major contributor impressed me very much when I met Roy and his team many years ago, they had business analyst who had Decades of experience in a given
industry. So, when they went to work with a customer, the thought Works team had the benefit of this person that really understood the domain, had the whole Vocabulary could relate to the customer and I think that's something that you really want someone that has experience understands the customer. So if you can bring someone like that in your startup, whether it's someone that comes in as a resource in the evenings of the weekends and say, look what is
this? General ledger thing, right? I hear they have this in accounting. What is it? It really helps you that context is very important and people don't invest enough in understanding to me. Yeah, I think I agree with you. I mean, many people many Software development teams. Do not invest enough in understanding business domain because you mention about as soon as the code is written,
right? Not only that, as soon as the investment comes in, as soon as the turnover is starting, or as more and more people joining the company, then it's a total mess because there's no clear picture of what the software is doing. There's no same understanding about the domain. So, I think that is the current challenge of software industry. Yeah, I don't think you should take much money until you actually figured out what you're doing. That's not the tendency, but Most of business.
I know that have been successful. I've actually spent a good deal of time early on thinking about what they're doing understanding it and not taking money. Because as soon as you get VC money in your on the wheel you just have to run faster and get more done.
Get more customers and it just doesn't in the other thing that you mentioned that I was fascinated about because last time I used to work in insurance industry, I was working with actuary people building this point of sale system where you calculate the benefits and all that and they all use spreadsheets this dish. Shun tables calculators and all that. And we programmers have to convert the head, complex spreadsheet into code, which sometimes when you look at it you can't even tell.
Okay, this calculation is actually as simple as a spreadsheet calculation. So I think what you mentioned here, maybe we could just leverage your decision tables or spreadsheet, even to build programs, instead of having to write lines of code in general programming language. So, maybe can explore a little bit more here because I rarely
see people doing this. Take a look at things like are table and So on there's a whole lot of these sort of local code systems and you'll see that they're really about spreadsheets that mean in the IBM analytics environment we did a analytics in a spreadsheet. So even though you Computing over a trillion Rose, it was still managed in the spreadsheet. You can actually just run spreadsheets, there's no reason to give them to a programmer to get them wrong. It says very straightforward
algorithm. You just have to do a topological sort that puts all the things in the order and then put the code and you can Itís, simple interpreter. You can write one Jabba program and it'll run all the spreadsheets and back years ago. Kent Beck worked in a project was a small talk project at the time, but a big insurance company in Chicago. They were trying to replace COBOL programmers with small talk programmers, it went.
Okay, but didn't go nearly as well as the small talk people argued it would, this was the early days of XP, but then can't observe that the people who negotiated the contracts and the Curren policies. Actually did it all in spreadsheets. So they actually implemented a spreadsheet interpreter, and put it inside the Mainframe, talking to the COBOL programs. They didn't small talk. And they also wrote a rule Checker, because spreadsheets
are usually a mess. So before they deployed the spreadsheet, they first of all I had a rule check or so that the analysts would be able to do this. So here's a case of two species of special-purpose tooling and they were able to automate. If you're going to do concurrent State machines, So you can do this high-speed messaging asynchronous, microservices, you have to build a state tables and you have to be able to understand those clearly.
You can do the simple ones with step functions and AWS, but if you're building a complicated system, you'll have to build your own State machines and your own interpreters for those State machine. So this stuff still works. It's been around for decades. Yeah. Especially acting is still the most important tools this day because the interface is simple enough. Many people understand if you translate to code, you have to do testing, you have Wi you have to build so many things so it
becomes a challenge. So another thing which you mentioned, I know that you have been dealing with so many different programming language, including building. Some of those. You mentioned that programming languages actually met the these days they are. Plenty of programming languages. They are probably too many to learn. So there are small. Why do you think programming languages matter, and how we should choose it? Actually choosing as much harder than the other question in the end.
Certainly, there are people who disagree about this. Some people think that you just do the design in the programming language, doesn't matter. I know you've already all cups in his view that you just get the system design, right? But my experience the more code you have, the more problems you have, the more developers you need. So, an expressive programming language, really reduces the amount of code you have and increases the rate at which you
can make change. If you have a small code base, it's very easy to make changes so you can involve the code quickly. If the language is simple, then people don't have to debate. Date which library to use which API if there's only one way to initialize something it's simple. If there's five ways to initialize that you have to go, which one should I use?
And why should I use this? Most of the I will call them exotic programming languages things like Haskell or j or k or or Lang. For example, have very expressive ways for handling. The kinds of problems that they work on. No language is ideal for everything. So a language, that's it. With regard to syntax and semantics is going to be
naturally much more productive. The other thing is, it's likely to have a cleaner implementation because the number of cases that the implementers have to work with.
As much smaller, the advantage of languages, which don't have the library written in the language is, you don't get this interaction between the runtime and the library job of has all its libraries written in Java. The bad news is that this means that a change in the jvm may not Be reflected in the actual libraries when Lambda is were added. You have to change one thing at a time. So I'm not criticizing the job implementers here to be able to do handle things like mapreduce efficiently.
You can put a mechanism in the jvm but the library doesn't use it. So you have this codependency between the library and the runtime and you have to get both fixed to do it versus languages where the library is, essentially written in C or machine code, the Library can be varied tuned versus you. Look at python python is not my favorite language because I don't like white space, but the language actually looks like it's fairly vast.
That's because it's actually very good at using the same old library, some of which are even implemented unfortunate and is rely on proven libraries that are not given to you in the source code. So I think the advantage of the language, we're separate those concerns.
I don't think it's always a great idea to have the library for your language written in the Language because again, language design and Library design is hard, if you make it easy, people go, oh look I can change what object means or some nonsense like that or change hash or something like that. You don't want people making those sorts of changes. I think I'd be good at everyone. Got the source code to read for the libraries but they weren't allowed to change it.
Source, code is very important. It's just you don't want everybody changing all the source code, I think choosing a language, which is simple and expressive that is you can learn it quickly. It's Simple consistent set of rules. As a good implementation, you can run a benchmark to see. Is it fast enough? So if you're choosing a more exotic language, you need to address those concerns responsibly so that you really understand that this is going to work for what you expect.
And it probably means that if you use an exotic language for inserter liners, lots of code in the Erickson switches which is written in C, but that's perfectly good. There's small functions which do what see does the overall switch architecture which is serve the pie. An ultimate microservice architecture as well designed inner lining supports that, but for some of the critical code sections, they do the right thing.
They use another language, they program the critical code performance-wise in C. So, I think that's a good separation concerned. There's no point using Haskell to try and compete against CEO or rust people may do that. But if you want to express something, that's got some very serious system of types and algorithms. And so on Haskell's a beautiful language for doing that, you can always Use some other mechanism for the low-level pieces of
code. So out of curiosity for Dave, Thomas right, if you have to choose one popular or Enterprise language and one exotic language maybe if we can share with us. What will be your two choices? The choices? I think, probably for an Enterprise language today. I would choose kotlin. So simpler Java is also not this whipped, so you can get by for doing mobile for at least Android and so on. So I would say, I think Collins a nice piece of work. And one for exotic.
OK, I don't even know what that is. But okay, I'll check it out later. I'll send you the link. Yeah, another thing that you mention about working with Legacy, right? So, a lot of systems these days has been built for many years. They are legacies. They maybe have been written in Cobol, Java, whatever that is these days, we still have to interoperate with them. You mentioned something that is to me is quite insightful instead of doing all this
rewriting. Why don't we just integrate by Using a mod data Centric approach. So if you can tell us a little bit more, what do you mean by this? Sure, I think everyone went to the Michael feathers School of Legacy transformation. He and Michael Nygaard, many of the great iäôs speakers talk about strangling, your monolith. But strangling is very expensive and takes some very talented people.
It works, but it can take two or three years to take your monolith and strangle the pieces, and turn it into Services. The approach that I've advocated and many others as well. Is that changing? Code is hard. A lot of the times you don't even want to change it because it's working, fine. So the real issues you want to introduce new performance or functionality new capability in the system. Listen, natural place to do that. That's wherever the data is stored at rest or moving along.
So basically, this can be streaming data, it can be a persistent file or a database. It can be a place where communication happens between programs.
This is an easy place to have an intervention, it's an easy place to insert a new To the nice thing is you can essentially put it in there right into the existing system, then divert the flow so you can just take some subset of the transaction so you can test it. You could take like five percent verify that they're working in. So on you can select the high-volume transactions and say, okay we're going to process these differently because we have too many now.
Our system is too slow. So it's very easy. And the nice thing. It's easy place to insert new technology so it can use. For instance, one of my favorites is and A database. So essentially you can do things blazingly fast in terms of queries.
And so on, that's essentially what honeycomb provides for doing observability of their the amazing database that you can do queries over to essentially try and recover the stack and figure out what's going on. The nice thing is they're fairly easy to do and you can usually do them in three or four months so you can complete the whole project by putting this new technology in place, you can put new Hardware in place but Intel just announced a new chip but basically, you know, 4, Dollars.
You get a terabyte of ram, another two thousand dollars, you get 20, terabytes of nvme memory. It's got 64 cores. I think 48 thousand dollars with soap. You can get massive compute capability and you can take that and you can insert it in the appropriate place. You can use it for testing but these things are all fairly straightforward. They can be done by a small team by carefully.
Looking at the data flows, the data provides a natural place where you can check and verify so testing is much easier. As well. You can just think about decoupling the data stream and putting this inside. And then using it, it's a very powerful technique. I've used it for all sorts of things for instant, high speed data base refactoring, taking a database from one technology to another technology. Just by streaming it full speed from one representation to another very different approach
to how one typically does this. Just trying to get the data out using SQL is a nightmare. So this thing actually takes the pages right from the physical And transforms them to pages on another physical store in a representation, but the actual algorithm is very straightforward, but simple algorithms and the access to Modern Hardware, really lets. You make huge changes in an organizational system without disturbing very much since it doesn't disturb.
Very mother isn't a big issue about devops changing the data center, doing all that sort of stuff. You were just saying, look, we're going to take this and we're going to put it in a different format and I don't, Think which I learned many people think, especially in the micro Service Road data is actually an internal. So the service rep should not be shared or, you know, you should not even care about what columns, what data types and all that. What's your perspective about
this? If you mention about integrating using data Centric approach, we need to understand those internals of the data structure. So what would be your advice here? I'm definitely wrong on this so I'm happy to be wrong. I actually think that the future programming is query. The whole issue of having 140 In your faces. When in the end most of those
things are just queries. So if you look at graph, F Q, I would actually go further and said I think they should be a web SQL, where you can just write a query and you should never have to see you rest in the things like that, rest can be underneath. I understand the properties and so on, but I believe the data center city is still a very valuable approach. I understand why people do it,
but it's like the same thing. People don't even want to reuse any code, we don't reuse any code, we just write whatever we want. So, now, Now you've got 13 or 15 versions of the same function, all different because we're going to move fast. Well in the end you're going to have a lot more code and lot more codes in your fears. So I think you have to use your head. It depends on how often people do this for performance.
All right, solution, but in the end someone still has to understand where all the data is now. The theory, of course means it's all moving so you don't need to worry about it. I'm not yet convinced that when you look at the architecture, I am and you see that everything talks to everything. Does that really help you understand? If you see those wonderful microservice communication patterns? Is that a good thing? I don't think so.
Everything talks to everything, even sometimes you don't have the diagram. Yes, he kept us on locks over multiple Services. Well, that's why you have to have those tools so you can get the guy again. Look, it's always good to be able to isolate things and separate them. The problem is sometimes that can actually contribute more to the complexity it's sort of the same thing as Nosql nosql looks like a free lunch.
I'm a Ruby programmer. So I just stick it in a blob and I don't worry about it, makes it easy for you. But every person that wants to look at that data has to write a query to unpack that blob. So, what you did is you traded your convenience as the developer by sucking a nosql blob with the pain of everyone who has to actually use that data having to parse it and take it apart.
I think we need to pay a lot more attention to how to Queries. In fact, if you look at all the new tools, observability honey comments on, they're all taking
us back to look. If you want to understand what's going on, you're going to have to query all this data, all these traces, I think query is kind of the underrated tool, and I think it's partly because programmers hate SQL, and don't like databases, but the nice thing is there are databases which are functional technology and which are very powerful and I think as you see and use those things you go. Oh well, I didn't actually have To do all this other stuff.
All I had to do is write a query. You can even do points to analysis and compiler concert. Like, if you look at data log or was this a talk at Lambda gym, by Simon Marlowe from meta Facebook. They've just built a system for analyzing programs and essentially, it's all done in Haskell course. They basically I've built the data log engine so they can query properties about programs to try and understand what's happening in different programming.
Languages and interaction inside of Facebook. So I think query is the Course, for the future. Everyone is moving back to a sequel Ezra. So really looking forward to see the day, we don't need to learn so many different query languages. So David's been a pleasant of I always learn many new things, so it's insightful. Not only that, some are unintuitive for me. All right.
But those things actually make sense after you explained about it, unfortunately, due to time, we need to wrap up pretty soon. But I would like to ask you one. Last question that I normally ask for all my guests, which is about three technical leadership wisdom. So this is like an advice for you to all technical leaders here. What will be some of the lessons that you want to share with our
scary three questions? The first one is actually a quote, from a very famous gentleman, called Seymour. Cray who invented, cray, Computing, higher than young, they don't know. It can't be done if I've had any good fortune. It's been to hire many young people often, just in their second year of University where they're very Innocent, but enthusiastic and they do amazing things. If you hire them with a PhD, they can't do anything because they already know all the wrong
ways. The great thing about young people because they are not afraid. So, with discipline and guidance, obviously, they do amazing things, don't underestimate the young people that you have. Access to Singapore, has an amazing pool. So exciting place to hire. The next one is focus isn't just important. It's everything. The most important thing you can decide every day is what you're not doing. Everybody has A big list. So the real question is, what is
that you don't need to do today? What are you not going to do? Those are the big decisions, very simple. But are the last one is that every release should have less code in it than the previous release. If you're a really great software organization, you will figure out how to get more function in the release and reduce. The code, may only be 3% or 5%, but if you can add new function and delete code, you would probably on the way to having a maintainable code base.
Your code base keeps growing, then you have a big maintenance problem and lots of challenges ahead of you. I really think the last one may be difficult because as we build more beaches, normally more lines of code, it's being written. But thank you so much. And I love the focus question, right? Because every day we should think about what we should not do today. So I think it's always a good
question to ponder. So Dave, if people want to follow you or continue this conversation with you, is there a place where they can reach out? So they can go to my Twitter, the Indian. Thomas or they can just email me. David Bolero.com. Thanks very much Henry. It's been really great to talk to you. As always, thank you so much for your time. Really Pleasant conversation. Take care. Thank you for listening to this episode and for staying, right until the end if you highly enjoyed it.
I would appreciate if you share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you are new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It helps me a lot. In order to grow this podcast better.
You can also find the full show notes of this conversation on the episode page at technology Arnold death website, including the full transcript enter, Testing courts and links to the resources mention from the conversation. And lastly, make sure to subscribe to the show's mailing list on pack leader know that deaf to get notified for any future episodes. Stay tuned for the next technology, no episode. And until then goodbye.