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.