February 23, 2022 • 50 mins
In this episode, we have a discussion with Mike Fitzmaurice, Low-code evangelist, and our CEO, Tiago Neves about the interesting world of Low-Code. Have a listen as they debate the importance this trend and how it impacts the industry!
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Mario Cunha (00:22):
Hello, and welcome to a new interview of the high
tech low code podcast. Thisepisode, we'll be discussing low
code with Mike Fitzmorris. AndKevin Nash. Mike is a local
evangelist, and He's the VP ofNorth America. Welcome. Mike,
thank you very much for joiningus on the podcast. How are you
doing?
Mike Fitzmaurice (00:39):
Great. Thank you for having me. This is going
to be fun, I
Mario Cunha (00:42):
think. Hope so hope so. Could you give us a bit of
an introduction so that theaudience could get to know you a
little bit better?
Mike Fitzmaurice (00:50):
I've been involved in low code
development, declarativedevelopment, rapid application
of it, call it what you will,for close to 30 years, both by
professionals and by citizendevelopers. I've done it as a
consultant, I've done it as anIT director. I've also done it
(01:11):
while working for multiplecompanies involved in low code,
including Microsoft. I was partof a team that created
SharePoint and brought it to themarket and I was responsible for
developer relations for aboutthe first 10 years of its life.
Since then, I've worked for acouple of different workflow
(01:33):
centric business process centriclocal companies. For the last
three years, that's been anoutfit called webcon. They're
really good, clever people basedout of Europe. And I spend a
whole lot of time not so muchselling product, but absolutely
selling ideas. And lettingpeople make their own decisions.
(01:59):
DSI seller about low code andhow to do it. Well.
Mario Cunha (02:04):
All right, that sounds interesting. I think
we're gonna have a really goodconversation today. Then
Jericho, also welcome back. Howare you doing? I'd have you been
up to.
Tiago Neves (02:17):
Hey, nice to be here again. And looking forward
also for for this one, I sharedthe same opinion as us. So
looking, very interested to hearfrom from Mike and his
background, which I think willbe amazing for for all of us
hearing. So looking forward forfor this one. And I'll just let
(02:37):
you drive Mario, but I'llcertainly probably have a
question or two, as I'mcertainly passionate about this
topic as
Mario Cunha (02:46):
well. All right, please do do quick, ask away.
Before anything, I would reallylike to say thank you to both of
you for joining us. Now I knowwe have spoken about local in
the past. But they we do havethe privilege of having the
opportunity to desert the topicwith a spokesperson slash
evangelist. So not wanting towaste this chance. I would like
(03:07):
to kick off our conversationwith the following question. Who
do you think benefits the mostfrom low code? citizen
developers? Professionals? Oh,gosh,
Mike Fitzmaurice (03:17):
that that's a harder question to answer than
you might think. Because itdepends on what you mean by
Benefit. Alright, so I couldsee. Like, I probably need to
preface this by saying low codeand citizen developer, or
citizen development are not thesame thing. Most citizen
(03:38):
development efforts I've seeninvolve low code, with some
exceptions, scripting tools.
I've seen a lot of people doPowerShell work, for example, in
the world of Microsoft, as anexample. But they would call it
scripting. In fact, they wouldgo out of their way to avoid
calling it code. I wouldn't.
(03:58):
It's code if you in fact, if youcan make a spelling error and it
breaks, then that's code. Butit's just a question of how much
is involved. But yeah, generallyspeaking, citizen developers
live for low code. Now, itdepends on who benefits if
(04:18):
you're talking, given theprofessionals have the option to
code, you could argue thatcitizen developers wouldn't
exist or would barely exist.
Without low code, that'sprobably fine. But I care a
whole lot more about outcomesthan I do about supply side
issues. And when it comes to whoreaps business benefit, or who
(04:41):
reaps the best results from lowcode, that's professionals.
Mario Cunha (04:50):
I see. Okay.
Mike Fitzmaurice (04:51):
There's a lot more activity in low code on the
part of citizen developers but alot of it breaks a lot of it's
fragile. A lot of it requiresfor professionals to evolve it.
Sometimes he'll it's but I don'twant to be mean or pejorative
because a lot of citizendevelopment work is actually
pretty good and prettyinteresting. But a lot of it
(05:15):
tends to focus on what you know,I hate business buzzwords, but
the long tail is not a horribleone in this case. In other
words, we've got on one end ofthe spectrum, very high impact,
very high budget high timeconsuming development efforts
for creating big missioncritical projects. On the other
(05:37):
end, you've got an evershrinking tail of small
applications that affect just afew people at a time. And if you
add up all of the productivityto be gained from implementing
all of those littleapplications, it does add up to
quite a bit of value, or atleast it has the potential to,
(06:00):
and a lot of citizen developmentefforts have lived in that area.
And if what was built worked,would work rather nicely.
Sometimes it does, sometimes itdoesn't. So when you're looking
at biggest benefit to theorganisation, this is
(06:21):
counterintuitive, and probablynot not going against the grain
for compared to what a lot ofthought leaders would like to
say on this. But know a lot ofthe time that people are best
able to deal with low codedevelopment, our developers,
because it's still development.
And even if you don't have tocode like a developer, you've
(06:42):
got to think like one. And ifyou don't think like a
developer, you will createthings that are not that are
going to leave out assumptions.
Or they're going to leave outexceptions, they're going to
make assumptions that don'talways hold true. Have you ever
(07:07):
implemented, say, a simpleautomation or workflow scenario?
For example, I don't care if itinvolves code or low code, and
the client, the customer, thebusiness stakeholder, whatever,
the person who's not going to dothe work for the person that
wants you to do it tells youwhat's supposed to happen. And
what they told you was only thebest case scenario, the so
(07:34):
called happy path. Yes, exactly.
the happy path, they give youthe happy path, they don't think
about well, what if thishappens? Or what if that
happens? Or what if the otherthing happens? should I handle
it this way or that way? Inother words, your natural
reaction, I'm willing to bet isto come back at them with a
whole bunch of questions. Thatif they aren't answered, we'll
(07:56):
create a horrible application.
And asking them these questions,results in them being annoyed,
maybe dependence, some, somewill actually thank you for
having thought this through. Andthey might even say, Oh, you
actually get it? Well, what youreally get is logic, not
necessarily the process theyhave in mind. But that happens
(08:21):
all the time. citizen developersdon't necessarily ask themselves
these questions, unless theyreally are developers at heart.
The thing I will say about thatis if you really are a developer
at heart, and you just never didit professionally, and you start
doing this, the odds are reallygood that within a year or two,
(08:43):
you're going to change jobs andbecome a developer instead of
somebody that does it on theside. And thanks, come on, join
us we have cake. It'll be fun.
But um, yeah, look, developmentis still development. And look,
you and I could both grab a hunkof clay. But if you've got
(09:06):
artistic talent, and I don't, mysculpture is not going to be as
good as yours. And yours will bethe only one that that is
exhibited in a gallery. So evenif there are 50 of me and one of
you, you're the one that createsthe most benefit to the world of
Mario Cunha (09:27):
art. Goodwin, I like the comparison. Yeah, an
Mike Fitzmaurice (09:31):
end of rant, or at
Mario Cunha (09:32):
least No, no rant.
Jaggu anything you would like tohave.
Tiago Neves (09:40):
So I'm someone that does certainly see what Mike is
picturing for us. But becauseI'm somewhere in between. I I
come from a business background,but I I've been in IoT projects
(10:01):
ever since I started myprofessional life. And, and so
that was 20 years ago and evermade that transition really. So
I've been a developer myself,and certainly see how I believe
I I fit into that citizendeveloper that actually has a
(10:24):
developer minds. And I think Idid that transition somewhere. I
don't know when it through mycareer. And I think certainly,
this is what I would see myselfdoing what you mentioned, Mike,
which is how would come up withall these questions, I won't be
(10:44):
happy with what is just a usecase. And all different
questions will come up. And andI would wonder, but what happens
if so the user just inserts thewrong type of data here? So
what's the next question? Andwhat happens then and this and
that. And so that was always mymy way of looking at this. And I
(11:08):
think certainly, this issomething that if you don't have
that developer mindset of soquestioning all these different
paths, that that can happen, andyou have low code is certainly
going to help you put thebusiness logic in there. But if
(11:29):
you don't have that developer,mindset, you will certainly be
facing with issues of bugs, usecases that you haven't thought
about. And so all of that, thatwe know, happens, and that's why
we have requirements, we havetesting and and so it's
(11:50):
development that goes a longway. And it's not just a
question of having a form thatthat works with one particular
case.
Mike Fitzmaurice (11:59):
Yeah, I found?
Well, yeah, there are a couplemore things we could do along
the slide. I don't really wantto spend too much time talking
about things that citizendevelopers who don't have a
developer mindset failed to do.
Topics been done the deaf, and Idon't think we've, I don't think
we're gonna argue with eachother very much about that. But,
(12:19):
you know, it's things likesecurity, like, do you? How do
you handle accessing data sothat SQL injection errors or
attacks don't take place? Or,you know, any of a number of
things that are securityrelated, there's still hope
there aren't so many holes inWord macros and Excel macros and
(12:43):
so on that there used to be, butthere are still options or
things to fail to think about,even if How about this, a lot of
projects with a lot of Lokotools, assume by default that
you're developing in production,and that everybody has
permissions to do everything.
And it's the job of the citizendeveloper to think through or
(13:07):
the local developer, I shouldsay, to think through how to
take away privileges peopleshouldn't have. But it's a
subtractive approach, as opposedto an additive one, which means
if you do nothing, anyone can doanything. That thinking through
security carefully, not matters.
(13:29):
And that actually has nothing todo with code. That's we come
back to the developer mindsetfor that, in fact, one of our
clients last year, what did hesay about this? Oh, development
is only 10% of delivery. Thatother 90% involves change
(13:50):
management, deployment, usereducation, it education, for
maintenance purposes, security,auditing, to prove things
happen. Metrics and monitoring,not the same thing, because
that's like application healthsystem health, performance
(14:11):
against metrics, and so on andso forth. It's not it's not
auditing. It's somethingdifferent, but it's related and
involves keeping track of whattook place and presenting it the
right way. There's a long listof things that have to be done.
And again, somebody with eithera developer mindset and a lot
(14:32):
and some experience they gainedalong the way or someone who's
been professionally trained,knows these things. A casual
dabbler does not. So I circledback to the original question.
(14:52):
The world is benefited more,more from low code when it's
been used by people who knowwhat they're doing As opposed to
people that are experiment everyonce in a while those
experiments however producereally interesting results. I
don't want to devalue that. Andby the way, if you write an
insecure you know barelyaudited, happy path only
(15:20):
automation scenario butscratches a very necessary itch
only you and maybe yourimmediate colleagues feel fine
who am I to tell you youshouldn't do that. But the
moment you start sharing thatwith other people, wackiness
ensues,
Mario Cunha (15:38):
nice.
Mike Fitzmaurice (15:39):
Scope it right. minimise the risk and can
all have a good time.
Mario Cunha (15:47):
Okay, changing gears now. Is locode entirely
completely on its online? Or canit learn things from the world
of traditional coding high code?
And if so, what can they learn?
Mike Fitzmaurice (16:01):
Okay, has to learn things from the world pi
code? If it doesn't, it's notgoing to be very effective. So
we come back to two things here,something I said which was low
code development is stilldevelopment. And the second
thing would be that developmentsonly 10% of delivery. Things
(16:25):
like agile, not agile, like thereligion some people make it out
to be, but agile, like theprinciple of team of people
contributing specific strengthsto an efforts, very short
release cycles, constantiteration, continuous
improvement, that that kind ofconcept. That can and probably
(16:51):
should be applied to locode.
Mike, you know, webcon isdevoted to that that concept.
We're not the only one. But butI'd like to think we're pretty
good about it. But, again, it'sthe idea that matters here. If
you're going to releasesomething, just because it's low
code doesn't mean that it's aone and done. In fact, I know of
(17:12):
a low code company that has inthe past, they've since been
acquired, but they used to do abrisk business, but they
actually had a marketingcampaign devoted around
disposable applications,disposable applications,
disposable applications. Yeah.
And I would argue that if anapplication is disposable, that
(17:35):
means barely usable. If anyapplication that's worth
something is probably going tohave an extended life of some
sort.
Mario Cunha (17:45):
Oh, yeah. I mean, just the time you spend
developing it.
Mike Fitzmaurice (17:50):
Yeah. And part of that mindset was okay, well,
we realise the application nolonger does what we need,
because our our requirementshave changed, the world has
moved on our business conditionsare the same, we'll just replace
it with a whole new application.
That seems incredibly wasteful,and possibly something that
would result in a loss ofhistorical excuse me historical
(18:11):
data. I don't want to see that.
So yeah, there are all kinds ofthings going on in the world of
professional development thatLoko development really, really
needs to keep track of changemanagement matters to stage
(18:31):
deployment from a developmentenvironment to a test
environment to a productionenvironment. These are things
developers take for granted,it's second nature, you're
you're not in the club, if youdon't follow these things,
because they're not evencontroversial anymore. It is
scary. The degree to which Iwould I would argue that the
(18:54):
majority of citizen developmentefforts never consider those
kinds of things, they kind ofthink of one and done and they
think of developing anddeploying directly into
production. And again, if thisis like you and me working
together in a in a small team,and we're building a happy path
(19:15):
thing, you know, and it's justfor us, fine. We start sharing
it with someone else. Not sofine.
Mario Cunha (19:25):
Problems are sure to appear,
Mike Fitzmaurice (19:27):
and patterns, like thinking through, you know,
try to explain a loop or a statemachine or certain just parallel
processing and making surethings think sync up so that you
know when it's safe to moveforward from all the parallel
paths, some kind of signallinggoing on. These are ideas,
(19:53):
they're not code. But if youdon't do this, it really really
limits what someone's allowed todo to basically a simple set of
linear sequence events, maybepassing data from step to step.
And again, it's it limits what'spossible, maybe not in a bad
way. But for the love of God, wecan't bet the business on one of
(20:15):
those things.
Mario Cunha (20:16):
That's actually a good point. And what about you?
What do you think?
Tiago Neves (20:22):
I was just thinking about how I see, maybe it's next
next question, but how localvendors and so that the low code
concept in itself, so comes fromthat application development
beginning, but at the same time,so I think what we see nowadays
(20:47):
is exactly what Mike is, isreferring to, which is the
concept of low code is movingaway from just being then the
development, and is now beingtaken to other parts of in this
case, the delivery, as well aseven other technologies. But the
(21:07):
question is still there that weare just abstracting complexity,
and that yet at still, at thisstage, I don't see how someone
just without that developermindset, or at least some basic
technical background, is capableto still deliver a robust, so
(21:32):
scalable application. And so allof those concepts that we know
are behind a corporate deliveryof either then something that
can be small, like you'resaying, if it's just to be
shared between family andfriends, it's not going to be
anything critical for anybusiness, probably, it's fine.
(21:53):
But when we're talking aboutthen critical business
applications, it's all of theseneeds, certainly to be taken
care of. And, and I think that'swhere local with citizen citizen
developers can go only thus far.
And, and so you cannot have acomplete delivery, just with
citizen developers. And I thinkthere was a bit of more hype
(22:16):
around citizen developers two,three years ago, or so. I think
that there's been at least somerealisation that it's good, I
think that we have low codebeing a facilitator of the
collaboration between businessand IT. But that doesn't mean so
just business can take over and,and do their own delivery. So
(22:40):
take over it at that. I don'tsee that happening anytime soon,
at least.
Mike Fitzmaurice (22:48):
Yeah, in fact, you know, I, let's be very clear
here. I'm not anti citizendevelopment, I'm pro citizen
development with a fence aroundit. And what I am anti is people
thinking low code equals citizendevelopment. Low code is bigger
(23:09):
than that. I love low code. Infact, I want professionals to
use low code as much aspossible, as long as they choose
their low code tools carefully,because low code cannot be a
wash, down, or a watered downversion of real development. My
(23:32):
whole goal in life, my company'ssole goal in life, is for load
code to be real, professionaldevelopment, that just takes
less time and produces morereliable, predictable results
and gets more done in less timewith better results. That's the
(23:53):
goal of of professional, lowcode, low code for adults, if
you would. I think that mattersa lot. And so, you know, if
you've got a low code systemthat only focuses on the
development part building thing,you're probably looking at
something that is watered down.
If you're if you've got low codethat only thinks in terms of
(24:16):
data, in other words, itsdevelopment model is based
around Oh, I'm going to I have acanvas that will manifest as a
webpage or a mobile app. I'mgoing to draw some controls,
drop it onto the form. I'm goingto bind that to some data. And
then I'll add some reactivelogic when somebody you know
(24:38):
clicks on something that's avery limiting or limited
application pattern, if it'sappropriate some of the time but
usually if you're editing data,you're doing it for a reason. So
I really want to see thebusiness process show up in the
application model somehow. Notjust reactive activity. But, you
(25:00):
know, there are plenty of lowcode platforms out there that
think beyond, you know, buildingsomething. And the thing that
you're building in the firstplace is nothing more than a
table editor. So yeah, dependson the tools. But you know,
actually, that's true of evenhigh code or classic code
(25:24):
environments, there are some IDsthat are great, and some that
are terrible. So yeah, chooseyour tools carefully. And low
code is 100%. Professional. Andagain, you won't have all the
freedom of full code. But you'llhave a lot more productivity,
meaning, more output fasteroutput for the same amount of
(25:48):
work or same output with a wholelot less work. If you turned low
code, and include that, as partof professional development
shops repertoire,
Mario Cunha (26:02):
we kind of touched on the next question. So I'm
going to jump over to the nextone. Oh, okay. Because you just
answered it. And I was like,Okay, this is perfect. And so
pick it up as a segue to thenext one. And are the local
platforms, the silver bullet formany of the IT problems, or is
(26:26):
just generating more entropy?
Mike Fitzmaurice (26:29):
Oh, yeah, it depends a lot on the tool. But
it has the potential to solvesome many IT problems now. Never
all of them come out. Let'slet's not kid ourselves. But
there are there are reallywhat's citizen development is a
useful reference right here,because two of the reasons why
(26:55):
we tend to find citizendevelopment attractive, by the
way, both and both of them arecompletely legitimate, they
really need to be a time to doReason number one is the
application back blog, thetalent gap, the fact that there
are, you know, on my side of theAtlantic and yours, you're in
(27:16):
Europe, right? Yes, yes. IPortugal, right.
Mario Cunha (27:21):
No, and it's always in the UK. I'm in Berlin.
Mike Fitzmaurice (27:25):
Oh, okay.
Great. Sorry, my mistake. I sawTiago and immediately thought,
Portuguese name, but
Tiago Neves (27:34):
we name yes.
Absolutely. Yeah.
Mike Fitzmaurice (27:38):
Okay. I mean, added up. So basically, we're
covering a lot of places. And inon both sides of the Atlantic,
there's a gap of about 600,000IT jobs, they're not going to
get filled their people to fillthem. We have a talent gap, we
(28:00):
have a supply gap, therefore wehave an application gap. And
because of this, we need to finda way to get more stuff built
with the resources we have. Oneoption was citizen development.
In other words, increase thenumber of people that can build
applications by asking less ofthose applications possibly, or
(28:23):
using magic tools. That meantthat you didn't need as much
skill in order to create thosethings. Now, that was that was
sort of a desperate hope. Thatpays off from time to time, but
as much more modest results, butit's not without help. But I
want to focus on the reasonhere, we need to get more done.
(28:46):
We need to get more stuff builtlocode can absolutely in the
hands of professionals canabsolutely help with that.
Almost everybody's lead codeplatform in the hands of a
professional can help them getmore done in less time than if
they were coding unless whatthey've been asked to code is
really, really weird, andhopefully weird and wonderful.
(29:09):
But usually low code tools, takeaway some freedom and give you
back productivity in exchangefor it. And if it's not, they
didn't take away too much andyou still get to produce the
kind of results you need to veryhappy trade off. It's the second
reason for citizen developmentthat's much much harder. I not
(29:32):
it's rare, but low code can helpwith this but not non existent.
And that problem is the factthat mine melts only exist in
Star Trek. There's no mindreading going on. That's just in
the movies and sci fi shows andbooks and so on. It's very hard
(29:56):
for those of us that are trainedto be technical software to
Developers low code or high codeor what have you, to be able to
read the mind of a businessperson that has a problem that
needs to be solved. It's alsovery, very hard for that person
to describe what they need, orwhat they want, or even the
problem they have, in a way thatyou and I can act on to help
(30:22):
them. Which means when we getinvolved in a project, it's not
an explanation. It's anegotiation. And if all parties
have a lot of goodwill, itdoesn't get nasty, but sometimes
it turns into an argument. Andthat's just crazy. But that the
(30:44):
appeal of citizen development isif I'm a business person, and I
can build something for myself,I don't need to explain what I'm
doing to anyone. That's a veryattractive idea. Of course, the
issue is in explaining it tosomeone, even another business
person, we might realise thingswe hadn't thought of until we
(31:05):
set it out loud, or until afresh pair of ears, you know,
thought about it and asked acouple of questions that help to
refine things nicely. It's goodto have people communicate a
little bit, you've producedbetter results in some cases. So
I think that logo can even helpwith that. But the low code has
(31:29):
to focus on more than justconstruction. If it's again, I'd
say 80 to 90% of low codeplatforms out there are focused
solely on construction 10 to 20%of them think beyond that. Those
are the ones you want to take alook at, because they might even
help you communicate with usersand business stakeholders and
(31:54):
come up with a common set ofdesign specifications, common
set of plans, even a commonreview process where people get
together, look at what's beingbuilt, figure out how to improve
it for the next iteration and soon. There's a communication
issue, low code can help withthat low CO construction tools
(32:16):
won't help with that. But lowcode platforms might. We're
certainly trying to do that.
Other people are trying to dothat, too. It's
that will solve the otherproblem, it has to stick at
least in terms of buildingthings. I mean, will it help
with solving their integrationissues? Probably not integration
(32:40):
is as much about politics as itis about protocols, and
priorities, and so on. So it isgoing to have plenty of problems
to deal with. But we can getpast just the application
backlog and the communicationgap with the right kinds of low
code of purchase. I don't thinkcode integration works nearly as
(33:05):
well as some people claim it is.
But yeah, those first fewthings. I think we can do that.
I think we can do that.
Mario Cunha (33:12):
All right. It's pretty good. Um, actually, I was
just thinking of what you justsaid, about the integrations and
how hard they convenient andthat they are more politics than
anything else. It's so true.
Mike Fitzmaurice (33:29):
You know, I, here's, here's a red flag for me
when I look at a local platform,it's not, if they say we've got
hundreds of ready to useconnectors, you can treat them
like Lego bricks, snap themtogether and magical habit. It's
not that the having a lot ofconnectors is a bad thing. It's
(33:50):
a good thing. It's a usefulthing. But thinking if that's
one of the first things out ofyour mouth, it makes me think
that you probably started in thewrong place, and you prioritise
the wrong stuff. Because if Iwant to create, again, a
(34:11):
personal application to scratchat personal itch, a connector
that talks to my contacts inOutlook Connector that talks to
my accounts in Salesforce, anaccount connector that accounts
or connects to a sharedcalendar, or if I'm glueing,
(34:34):
together three or four datasources that I work with on a
regular basis. Great, yeah, youcan do that with canned
connectors coming fromsomebody's library. But here's
the key here. You have 100%authority to touch that data.
It's your data. The only thingyou have to care about is your
(34:57):
stuff. Now if I curate our ERPsystem. And you curate our
marketing automation platform,email campaigns, digital
marketing, and you want to logactivity or outcomes or
something like that into myenvironment, could even be lower
(35:19):
stakes than ERP, it could be CRMor something like that. But
still,
Unknown (35:24):
I don't know you.
Mike Fitzmaurice (35:26):
Maybe company picnics or meetings here and
there, you seem like a nice guy.
But I don't know that you knowhow to work with Salesforce, I
definitely know that you don'tknow how we in my team use
Salesforce, we got to teach youa lot if we're going to let you
open up our file cabinets and gothrough them, you know, with a
(35:47):
flashlight in your mouth andsome gloves. I don't like that.
I like that idea very much atall. And again, it's not a
question of bad faith. It's aquestion of, there's more to
this than somebody snappingtogether to Lego bricks, their
(36:08):
policies, their procedures,there are permissions, there
might be compliance concerns,there might be an audit trail
that needs to be followed.
Integration at the corporatelevel is hard. And it's not hard
because people are jerks. It'shard because the world is more
complicated than we often thinkabout. So it actually does
(36:31):
require us to do somenegotiation. In fact, that might
be we might be better off if Iwrite a small automation script
or business process, and makethat available to you, as you
write an application that needsto talk to my CRM data. So you
have a leak, you want to pump itdirectly into Salesforce, I love
(36:51):
that. So I'm going to give yousomething that you can call as
one rest method. And it'll usewhat whatever scripting facility
I want to use within myenvironment or third party
facility that I want to usewithin my environment that puts
the right things in the rightplaces under the right
conditions, you just call itmagic black box. That works out
(37:14):
really, really well. No one'sgot that in their toolbox of 500
connectors. That's something youand I, and we as an
organisation, curate, we createit, we evolve it, we look out
for it. It's part of what makesour organisation special. So I
think and we negotiated it andcreated it together. And that is
(37:38):
what integration at theenterprise level is like, if an
application if a low codeplatform thinks that integration
at the enterprise level is snapthis to this and you're done.
You're probably thinking of thewrong tools.
Mario Cunha (37:57):
Or getting ready for a big headache ahead of him.
Mike Fitzmaurice (38:00):
Yeah, yeah.
But again, that's that that isaimed at one person scratching
one inch. And, again, if that'sall your application has to do,
yeah, use that tool for that.
For the love of God, don't useit for more than that. I'm
saying
Mario Cunha (38:17):
he has a purpose has a purpose, are about to what
do you think?
Tiago Neves (38:23):
I was just thinking about? So basically a question
for for Mike. But, Mike, how doyou think that the business
might might perceive them lowcodes, in the sense of, it's not
a silver bullet. So all thesechallenges that you're raising,
(38:44):
that they are still there? Canit be that business just might
then give it too much valuethinking that it's gonna solve
everything,
Mike Fitzmaurice (38:55):
under help with a lot of things if it's
done well. So at the very, veryleast, it and I'm using it as an
umbrella term now to mean allthe technical people employed by
the organisation as opposed toall the business people, I don't
necessarily mean that people whomaintain the infrastructure or
evolve the infrastructure. I'malso including developers, it if
(39:16):
we're talking to technicalaudiences, there are people that
build solutions, buildapplications, there may be a
business process team, theydon't think of themselves
society. For our littlediscussion right here right now
for the next minute or two.
There it. Alright. So yes, lowcode is going to help it be more
responsive to business because,again, a lot of the stuff that
(39:40):
slows them down. They don't haveto deal with that. That's a good
thing. Or they don't have todeal with it. It's done for them
automatically in a systematisedway, so everybody has to agree
that it's okay for it to happenin that systematised way But
yeah, it's gonna help them buildmore in less time and do a lot
(40:02):
for them. So they don't have todo everything by hand. It's like
using power tools or laboursaving devices in the kitchen.
It's going to help them get morestuff done in less time with
more predictable, sufficientresults. You're not going to
create grand art with code,which can happen sometimes, but
(40:26):
everything else. Yeah, it'sgoing to help. It's not going to
solve, but it's going to help.
And that might be enough. Here'sthe key. No, we're not going to
win hearts and minds and thelove the business community as
technical people if that's allwe focus on, if we use the right
(40:49):
kinds of logo tools to improveour communication, our project
management and our transparency,our collaboration with business.
Yeah, there's still a lot we cando with low code to improve the
organisation the totalthroughput of the organisation.
And the right kind of low codetools save us an incredible
(41:13):
amount of time. I'll give you aperfect example. What if we are
able to create a businessprocess diagram that is
understandable by businesspeople, but the understandable
business process diagram is theflowchart. With a lot of
(41:35):
environments, you've got onediagram you're going to create
to explain what it is you'regoing to do and a different
diagram you have to create toactually build the workflow
logic. The latter one you can doautomatically. In other words, I
could sketch it out insomebodies workflow ma modeller,
(41:56):
and then it will generate theapplication that we need. But
the diagram that explains whatwe're doing that happens by
hand, there might not be arelationship between the two
diagrams at all. What if theywere one diagram? What if it
were actionable? Andunderstandable? At the same
time, we can get a lot more donethat way. What if you and I can
(42:20):
sit down together, and we cancreate the look. And in broad
strokes, the behaviour of theapplication you want me to build
for you, in order to build anexample of what you want. So I
can see if I can try something,you can tell me where I'm wrong.
And within about an hour's time,we can agree that this is what
(42:43):
it should look like this is whatshould happen when you click
this button, and so on wecreate, this could be a
wireframe or something thatlooks a lot nicer than that. But
yeah, if we look at low codestuff that is not just about
construction, but it's alsoabout collaboration, and
cooperation and communication.
Yeah, that's going to solve alot of IT problems that haven't
(43:06):
been touched in the past.
Because it is not known forbeing good at communication or
or good at providingcommunication or understanding
communication. That's theorganization's fault as a whole.
It's not just it, but but at thesame time, you know, we use the
(43:29):
right Lopo platforms, platforms,not just tools. We address more
than just construction, weaddressed collaboration, long
winded way of saying you use theright tools than the answer,
yes.
Mario Cunha (43:45):
Okay, could Luke code continuous focus on
automation? Bring any sort ofunwanted consequences? Could it
be become too focused?
Mike Fitzmaurice (43:57):
I actually am very, very wary about
automation. Because it is fartoo easy to beautifully automate
a terrible process.
Mario Cunha (44:11):
It's a good one.
Yeah.
Mike Fitzmaurice (44:16):
And the problem is, unless you live this
stuff, it doesn't occur to youthat automation and process and
workflow are three differentthings. And again, I don't
expect somebody that doesn'tlive this all the time to care
about the difference betweenprocesses and automation. But,
(44:37):
you know, there are a number ofwonderful tools out there from
RPA vendors, robotic processautomation vendors, you know,
the UiPath, blue prismautomation anywhere. There are
others, but those those are thethree rock solid dudes. They,
they do good work, but they'dactually be the first to tell
(44:59):
you that They're not in thebusiness process modelling and
automation business. But they'rereally automating our processes.
They're automating activitytasks, there should be our TA or
RA or something like that, asopposed to RPA. But they have
(45:20):
the name that you really shouldcombine that sort of thing. with
something that looks at thebusiness process, what are the
assets, we need to get thisdone? What are the goals we
have? What are the How will wemeasure whether we accomplish
it, what should be done, andthen we defer to rpa, or
(45:42):
scripting, or automation tools,or any of a number of different
things that or even code toactually execute the things that
the process tells us? It's timeto do? Yeah, it's, if all we
focus on is automation, one oftwo things happen, we will
(46:06):
slavish li try harder and harderto automate what might be bad
processes, or what we'll have isworking very hard to automate
implicit processes. Maybethey're not bad, but they're in
our heads. In other words, whatto do gets automated, why we're
(46:28):
doing it gets lost if somebodyleaves the organisation, or it's
manual and has to be read inorder for you to understand
which automation to kick off andwhat to do with the results when
it's done. I yeah, I have aproblem with that. I think that
looking at automation, and onlyautomation is a very incomplete
(46:52):
picture. So you have to think ofthe process and think of the
data assets as well. But yeah,there's subject matter expertise
that matters a lot in the worldof process management, it's
thinking about the processfirst, and then determining
which assets you need, and whichautomated bursts of activity
(47:12):
should be created to support theprocess. Doing it backwards,
involves a lot of risk. The samekind of thing happens in the
world of business intelligence,I can't tell you how often
people have just said, Okay,I've got this data, let's see
what I can find from it. Bydoing ad hoc analysis, after ad
(47:35):
hoc analysis without reallyunderstanding the data that
they're analysing in the firstplace. They might draw crazy,
they might occasionally come upwith something no one had
thought of, but more often thannot, they'll draw crazy
conclusions because they aregrounded in the subject matter.
It's really easy to focus oncool tools, without thinking
(47:59):
through, why you're using themin the first place.
Mario Cunha (48:03):
That is quite an interesting, I did like the the
example of the businessintelligence kind of makes you
think we have a set of data,let's look for patterns. Okay.
Some patterns just happenbecause they happen. They don't
have any meaning behind it. Orif
Mike Fitzmaurice (48:19):
Yeah, okay.
Well, it's it's still it's 2020.
It's the beginning of 2022. Ifsomeone's listening to this next
year, hopefully the wholepandemic thing will be over.
Yes. But yeah, this happenedmore in 2020 and 21. But there
were countless armchairepidemiologists who had it, who
(48:44):
were business intelligence,people that just love to be able
to get at crunch numbers andsay, actually, what's happening
is this without understandinghow viruses work, or how, you
know, without knowing thingsthat doctors know, it's not just
(49:05):
about data, there is a certainsense of subject matter
expertise that matters. DataAnalysis contributes a lot to
human knowledge, but not withoutsome knowledge to know what to
do with the data in the firstplace. So sometimes wonderful
things happen. But a lot ofpeople, basically because
(49:29):
particularly in the first yearof a pandemic, when there were
no vaccines, there were lots oflock downs. You know, what am I
going to do? Well, this data ispublicly available. Let's see
what I can figure out a lot ofcrazy inferences happened that
that that was more 2020 thanlast year and certainly more
than this year, but you know,it's a big obvious example. You
(49:55):
got to got to know what you'redoing in order to handle the
mechanic Parts of it well,
Mario Cunha (50:01):
make sense makes total sense. Jaggu anything you
would like the head?
Tiago Neves (50:07):
Don't just just love that example, Mike. That's
all.
Mario Cunha (50:13):
Okay guys, on that last note then we end today's
podcast. Thank you very muchMike Integra for joining us. I
bid love your company likeamazing. I would also like to
send a big thank you to everyonewho is listening and hope you
can join us on our next episodeof high tech local podcast where
we will always talk about moretopics about the tech universe.
(50:34):
See you soon. Bye, everyone.
Unknown (50:36):
Outstanding. What a pleasure. She is. Bye bye
Hello, and welcome to a new interview of the high
tech low code podcast. Thisepisode, we'll be discussing low
code with Mike Fitzmorris. AndKevin Nash. Mike is a local
evangelist, and He's the VP ofNorth America. Welcome. Mike,
thank you very much for joiningus on the podcast. How are you
doing?
Mike Fitzmaurice (00:39):
Great. Thank you for having me. This is going
to be fun, I
Mario Cunha (00:42):
think. Hope so hope so. Could you give us a bit of
an introduction so that theaudience could get to know you a
little bit better?
Mike Fitzmaurice (00:50):
I've been involved in low code
development, declarativedevelopment, rapid application
of it, call it what you will,for close to 30 years, both by
professionals and by citizendevelopers. I've done it as a
consultant, I've done it as anIT director. I've also done it
(01:11):
while working for multiplecompanies involved in low code,
including Microsoft. I was partof a team that created
SharePoint and brought it to themarket and I was responsible for
developer relations for aboutthe first 10 years of its life.
Since then, I've worked for acouple of different workflow
(01:33):
centric business process centriclocal companies. For the last
three years, that's been anoutfit called webcon. They're
really good, clever people basedout of Europe. And I spend a
whole lot of time not so muchselling product, but absolutely
selling ideas. And lettingpeople make their own decisions.
(01:59):
DSI seller about low code andhow to do it. Well.
Mario Cunha (02:04):
All right, that sounds interesting. I think
we're gonna have a really goodconversation today. Then
Jericho, also welcome back. Howare you doing? I'd have you been
up to.
Tiago Neves (02:17):
Hey, nice to be here again. And looking forward
also for for this one, I sharedthe same opinion as us. So
looking, very interested to hearfrom from Mike and his
background, which I think willbe amazing for for all of us
hearing. So looking forward forfor this one. And I'll just let
(02:37):
you drive Mario, but I'llcertainly probably have a
question or two, as I'mcertainly passionate about this
topic as
Mario Cunha (02:46):
well. All right, please do do quick, ask away.
Before anything, I would reallylike to say thank you to both of
you for joining us. Now I knowwe have spoken about local in
the past. But they we do havethe privilege of having the
opportunity to desert the topicwith a spokesperson slash
evangelist. So not wanting towaste this chance. I would like
(03:07):
to kick off our conversationwith the following question. Who
do you think benefits the mostfrom low code? citizen
developers? Professionals? Oh,gosh,
Mike Fitzmaurice (03:17):
that that's a harder question to answer than
you might think. Because itdepends on what you mean by
Benefit. Alright, so I couldsee. Like, I probably need to
preface this by saying low codeand citizen developer, or
citizen development are not thesame thing. Most citizen
(03:38):
development efforts I've seeninvolve low code, with some
exceptions, scripting tools.
I've seen a lot of people doPowerShell work, for example, in
the world of Microsoft, as anexample. But they would call it
scripting. In fact, they wouldgo out of their way to avoid
calling it code. I wouldn't.
(03:58):
It's code if you in fact, if youcan make a spelling error and it
breaks, then that's code. Butit's just a question of how much
is involved. But yeah, generallyspeaking, citizen developers
live for low code. Now, itdepends on who benefits if
(04:18):
you're talking, given theprofessionals have the option to
code, you could argue thatcitizen developers wouldn't
exist or would barely exist.
Without low code, that'sprobably fine. But I care a
whole lot more about outcomesthan I do about supply side
issues. And when it comes to whoreaps business benefit, or who
(04:41):
reaps the best results from lowcode, that's professionals.
Mario Cunha (04:50):
I see. Okay.
Mike Fitzmaurice (04:51):
There's a lot more activity in low code on the
part of citizen developers but alot of it breaks a lot of it's
fragile. A lot of it requiresfor professionals to evolve it.
Sometimes he'll it's but I don'twant to be mean or pejorative
because a lot of citizendevelopment work is actually
pretty good and prettyinteresting. But a lot of it
(05:15):
tends to focus on what you know,I hate business buzzwords, but
the long tail is not a horribleone in this case. In other
words, we've got on one end ofthe spectrum, very high impact,
very high budget high timeconsuming development efforts
for creating big missioncritical projects. On the other
(05:37):
end, you've got an evershrinking tail of small
applications that affect just afew people at a time. And if you
add up all of the productivityto be gained from implementing
all of those littleapplications, it does add up to
quite a bit of value, or atleast it has the potential to,
(06:00):
and a lot of citizen developmentefforts have lived in that area.
And if what was built worked,would work rather nicely.
Sometimes it does, sometimes itdoesn't. So when you're looking
at biggest benefit to theorganisation, this is
(06:21):
counterintuitive, and probablynot not going against the grain
for compared to what a lot ofthought leaders would like to
say on this. But know a lot ofthe time that people are best
able to deal with low codedevelopment, our developers,
because it's still development.
And even if you don't have tocode like a developer, you've
(06:42):
got to think like one. And ifyou don't think like a
developer, you will createthings that are not that are
going to leave out assumptions.
Or they're going to leave outexceptions, they're going to
make assumptions that don'talways hold true. Have you ever
(07:07):
implemented, say, a simpleautomation or workflow scenario?
For example, I don't care if itinvolves code or low code, and
the client, the customer, thebusiness stakeholder, whatever,
the person who's not going to dothe work for the person that
wants you to do it tells youwhat's supposed to happen. And
what they told you was only thebest case scenario, the so
(07:34):
called happy path. Yes, exactly.
the happy path, they give youthe happy path, they don't think
about well, what if thishappens? Or what if that
happens? Or what if the otherthing happens? should I handle
it this way or that way? Inother words, your natural
reaction, I'm willing to bet isto come back at them with a
whole bunch of questions. Thatif they aren't answered, we'll
(07:56):
create a horrible application.
And asking them these questions,results in them being annoyed,
maybe dependence, some, somewill actually thank you for
having thought this through. Andthey might even say, Oh, you
actually get it? Well, what youreally get is logic, not
necessarily the process theyhave in mind. But that happens
(08:21):
all the time. citizen developersdon't necessarily ask themselves
these questions, unless theyreally are developers at heart.
The thing I will say about thatis if you really are a developer
at heart, and you just never didit professionally, and you start
doing this, the odds are reallygood that within a year or two,
(08:43):
you're going to change jobs andbecome a developer instead of
somebody that does it on theside. And thanks, come on, join
us we have cake. It'll be fun.
But um, yeah, look, developmentis still development. And look,
you and I could both grab a hunkof clay. But if you've got
(09:06):
artistic talent, and I don't, mysculpture is not going to be as
good as yours. And yours will bethe only one that that is
exhibited in a gallery. So evenif there are 50 of me and one of
you, you're the one that createsthe most benefit to the world of
Mario Cunha (09:27):
art. Goodwin, I like the comparison. Yeah, an
Mike Fitzmaurice (09:31):
end of rant, or at
Mario Cunha (09:32):
least No, no rant.
Jaggu anything you would like tohave.
Tiago Neves (09:40):
So I'm someone that does certainly see what Mike is
picturing for us. But becauseI'm somewhere in between. I I
come from a business background,but I I've been in IoT projects
(10:01):
ever since I started myprofessional life. And, and so
that was 20 years ago and evermade that transition really. So
I've been a developer myself,and certainly see how I believe
I I fit into that citizendeveloper that actually has a
(10:24):
developer minds. And I think Idid that transition somewhere. I
don't know when it through mycareer. And I think certainly,
this is what I would see myselfdoing what you mentioned, Mike,
which is how would come up withall these questions, I won't be
(10:44):
happy with what is just a usecase. And all different
questions will come up. And andI would wonder, but what happens
if so the user just inserts thewrong type of data here? So
what's the next question? Andwhat happens then and this and
that. And so that was always mymy way of looking at this. And I
(11:08):
think certainly, this issomething that if you don't have
that developer mindset of soquestioning all these different
paths, that that can happen, andyou have low code is certainly
going to help you put thebusiness logic in there. But if
(11:29):
you don't have that developer,mindset, you will certainly be
facing with issues of bugs, usecases that you haven't thought
about. And so all of that, thatwe know, happens, and that's why
we have requirements, we havetesting and and so it's
(11:50):
development that goes a longway. And it's not just a
question of having a form thatthat works with one particular
case.
Mike Fitzmaurice (11:59):
Yeah, I found?
Well, yeah, there are a couplemore things we could do along
the slide. I don't really wantto spend too much time talking
about things that citizendevelopers who don't have a
developer mindset failed to do.
Topics been done the deaf, and Idon't think we've, I don't think
we're gonna argue with eachother very much about that. But,
(12:19):
you know, it's things likesecurity, like, do you? How do
you handle accessing data sothat SQL injection errors or
attacks don't take place? Or,you know, any of a number of
things that are securityrelated, there's still hope
there aren't so many holes inWord macros and Excel macros and
(12:43):
so on that there used to be, butthere are still options or
things to fail to think about,even if How about this, a lot of
projects with a lot of Lokotools, assume by default that
you're developing in production,and that everybody has
permissions to do everything.
And it's the job of the citizendeveloper to think through or
(13:07):
the local developer, I shouldsay, to think through how to
take away privileges peopleshouldn't have. But it's a
subtractive approach, as opposedto an additive one, which means
if you do nothing, anyone can doanything. That thinking through
security carefully, not matters.
(13:29):
And that actually has nothing todo with code. That's we come
back to the developer mindsetfor that, in fact, one of our
clients last year, what did hesay about this? Oh, development
is only 10% of delivery. Thatother 90% involves change
(13:50):
management, deployment, usereducation, it education, for
maintenance purposes, security,auditing, to prove things
happen. Metrics and monitoring,not the same thing, because
that's like application healthsystem health, performance
(14:11):
against metrics, and so on andso forth. It's not it's not
auditing. It's somethingdifferent, but it's related and
involves keeping track of whattook place and presenting it the
right way. There's a long listof things that have to be done.
And again, somebody with eithera developer mindset and a lot
(14:32):
and some experience they gainedalong the way or someone who's
been professionally trained,knows these things. A casual
dabbler does not. So I circledback to the original question.
(14:52):
The world is benefited more,more from low code when it's
been used by people who knowwhat they're doing As opposed to
people that are experiment everyonce in a while those
experiments however producereally interesting results. I
don't want to devalue that. Andby the way, if you write an
insecure you know barelyaudited, happy path only
(15:20):
automation scenario butscratches a very necessary itch
only you and maybe yourimmediate colleagues feel fine
who am I to tell you youshouldn't do that. But the
moment you start sharing thatwith other people, wackiness
ensues,
Mario Cunha (15:38):
nice.
Mike Fitzmaurice (15:39):
Scope it right. minimise the risk and can
all have a good time.
Mario Cunha (15:47):
Okay, changing gears now. Is locode entirely
completely on its online? Or canit learn things from the world
of traditional coding high code?
And if so, what can they learn?
Mike Fitzmaurice (16:01):
Okay, has to learn things from the world pi
code? If it doesn't, it's notgoing to be very effective. So
we come back to two things here,something I said which was low
code development is stilldevelopment. And the second
thing would be that developmentsonly 10% of delivery. Things
(16:25):
like agile, not agile, like thereligion some people make it out
to be, but agile, like theprinciple of team of people
contributing specific strengthsto an efforts, very short
release cycles, constantiteration, continuous
improvement, that that kind ofconcept. That can and probably
(16:51):
should be applied to locode.
Mike, you know, webcon isdevoted to that that concept.
We're not the only one. But butI'd like to think we're pretty
good about it. But, again, it'sthe idea that matters here. If
you're going to releasesomething, just because it's low
code doesn't mean that it's aone and done. In fact, I know of
(17:12):
a low code company that has inthe past, they've since been
acquired, but they used to do abrisk business, but they
actually had a marketingcampaign devoted around
disposable applications,disposable applications,
disposable applications. Yeah.
And I would argue that if anapplication is disposable, that
(17:35):
means barely usable. If anyapplication that's worth
something is probably going tohave an extended life of some
sort.
Mario Cunha (17:45):
Oh, yeah. I mean, just the time you spend
developing it.
Mike Fitzmaurice (17:50):
Yeah. And part of that mindset was okay, well,
we realise the application nolonger does what we need,
because our our requirementshave changed, the world has
moved on our business conditionsare the same, we'll just replace
it with a whole new application.
That seems incredibly wasteful,and possibly something that
would result in a loss ofhistorical excuse me historical
(18:11):
data. I don't want to see that.
So yeah, there are all kinds ofthings going on in the world of
professional development thatLoko development really, really
needs to keep track of changemanagement matters to stage
(18:31):
deployment from a developmentenvironment to a test
environment to a productionenvironment. These are things
developers take for granted,it's second nature, you're
you're not in the club, if youdon't follow these things,
because they're not evencontroversial anymore. It is
scary. The degree to which Iwould I would argue that the
(18:54):
majority of citizen developmentefforts never consider those
kinds of things, they kind ofthink of one and done and they
think of developing anddeploying directly into
production. And again, if thisis like you and me working
together in a in a small team,and we're building a happy path
(19:15):
thing, you know, and it's justfor us, fine. We start sharing
it with someone else. Not sofine.
Mario Cunha (19:25):
Problems are sure to appear,
Mike Fitzmaurice (19:27):
and patterns, like thinking through, you know,
try to explain a loop or a statemachine or certain just parallel
processing and making surethings think sync up so that you
know when it's safe to moveforward from all the parallel
paths, some kind of signallinggoing on. These are ideas,
(19:53):
they're not code. But if youdon't do this, it really really
limits what someone's allowed todo to basically a simple set of
linear sequence events, maybepassing data from step to step.
And again, it's it limits what'spossible, maybe not in a bad
way. But for the love of God, wecan't bet the business on one of
(20:15):
those things.
Mario Cunha (20:16):
That's actually a good point. And what about you?
What do you think?
Tiago Neves (20:22):
I was just thinking about how I see, maybe it's next
next question, but how localvendors and so that the low code
concept in itself, so comes fromthat application development
beginning, but at the same time,so I think what we see nowadays
(20:47):
is exactly what Mike is, isreferring to, which is the
concept of low code is movingaway from just being then the
development, and is now beingtaken to other parts of in this
case, the delivery, as well aseven other technologies. But the
(21:07):
question is still there that weare just abstracting complexity,
and that yet at still, at thisstage, I don't see how someone
just without that developermindset, or at least some basic
technical background, is capableto still deliver a robust, so
(21:32):
scalable application. And so allof those concepts that we know
are behind a corporate deliveryof either then something that
can be small, like you'resaying, if it's just to be
shared between family andfriends, it's not going to be
anything critical for anybusiness, probably, it's fine.
(21:53):
But when we're talking aboutthen critical business
applications, it's all of theseneeds, certainly to be taken
care of. And, and I think that'swhere local with citizen citizen
developers can go only thus far.
And, and so you cannot have acomplete delivery, just with
citizen developers. And I thinkthere was a bit of more hype
(22:16):
around citizen developers two,three years ago, or so. I think
that there's been at least somerealisation that it's good, I
think that we have low codebeing a facilitator of the
collaboration between businessand IT. But that doesn't mean so
just business can take over and,and do their own delivery. So
(22:40):
take over it at that. I don'tsee that happening anytime soon,
at least.
Mike Fitzmaurice (22:48):
Yeah, in fact, you know, I, let's be very clear
here. I'm not anti citizendevelopment, I'm pro citizen
development with a fence aroundit. And what I am anti is people
thinking low code equals citizendevelopment. Low code is bigger
(23:09):
than that. I love low code. Infact, I want professionals to
use low code as much aspossible, as long as they choose
their low code tools carefully,because low code cannot be a
wash, down, or a watered downversion of real development. My
(23:32):
whole goal in life, my company'ssole goal in life, is for load
code to be real, professionaldevelopment, that just takes
less time and produces morereliable, predictable results
and gets more done in less timewith better results. That's the
(23:53):
goal of of professional, lowcode, low code for adults, if
you would. I think that mattersa lot. And so, you know, if
you've got a low code systemthat only focuses on the
development part building thing,you're probably looking at
something that is watered down.
If you're if you've got low codethat only thinks in terms of
(24:16):
data, in other words, itsdevelopment model is based
around Oh, I'm going to I have acanvas that will manifest as a
webpage or a mobile app. I'mgoing to draw some controls,
drop it onto the form. I'm goingto bind that to some data. And
then I'll add some reactivelogic when somebody you know
(24:38):
clicks on something that's avery limiting or limited
application pattern, if it'sappropriate some of the time but
usually if you're editing data,you're doing it for a reason. So
I really want to see thebusiness process show up in the
application model somehow. Notjust reactive activity. But, you
(25:00):
know, there are plenty of lowcode platforms out there that
think beyond, you know, buildingsomething. And the thing that
you're building in the firstplace is nothing more than a
table editor. So yeah, dependson the tools. But you know,
actually, that's true of evenhigh code or classic code
(25:24):
environments, there are some IDsthat are great, and some that
are terrible. So yeah, chooseyour tools carefully. And low
code is 100%. Professional. Andagain, you won't have all the
freedom of full code. But you'llhave a lot more productivity,
meaning, more output fasteroutput for the same amount of
(25:48):
work or same output with a wholelot less work. If you turned low
code, and include that, as partof professional development
shops repertoire,
Mario Cunha (26:02):
we kind of touched on the next question. So I'm
going to jump over to the nextone. Oh, okay. Because you just
answered it. And I was like,Okay, this is perfect. And so
pick it up as a segue to thenext one. And are the local
platforms, the silver bullet formany of the IT problems, or is
(26:26):
just generating more entropy?
Mike Fitzmaurice (26:29):
Oh, yeah, it depends a lot on the tool. But
it has the potential to solvesome many IT problems now. Never
all of them come out. Let'slet's not kid ourselves. But
there are there are reallywhat's citizen development is a
useful reference right here,because two of the reasons why
(26:55):
we tend to find citizendevelopment attractive, by the
way, both and both of them arecompletely legitimate, they
really need to be a time to doReason number one is the
application back blog, thetalent gap, the fact that there
are, you know, on my side of theAtlantic and yours, you're in
(27:16):
Europe, right? Yes, yes. IPortugal, right.
Mario Cunha (27:21):
No, and it's always in the UK. I'm in Berlin.
Mike Fitzmaurice (27:25):
Oh, okay.
Great. Sorry, my mistake. I sawTiago and immediately thought,
Portuguese name, but
Tiago Neves (27:34):
we name yes.
Absolutely. Yeah.
Mike Fitzmaurice (27:38):
Okay. I mean, added up. So basically, we're
covering a lot of places. And inon both sides of the Atlantic,
there's a gap of about 600,000IT jobs, they're not going to
get filled their people to fillthem. We have a talent gap, we
(28:00):
have a supply gap, therefore wehave an application gap. And
because of this, we need to finda way to get more stuff built
with the resources we have. Oneoption was citizen development.
In other words, increase thenumber of people that can build
applications by asking less ofthose applications possibly, or
(28:23):
using magic tools. That meantthat you didn't need as much
skill in order to create thosethings. Now, that was that was
sort of a desperate hope. Thatpays off from time to time, but
as much more modest results, butit's not without help. But I
want to focus on the reasonhere, we need to get more done.
(28:46):
We need to get more stuff builtlocode can absolutely in the
hands of professionals canabsolutely help with that.
Almost everybody's lead codeplatform in the hands of a
professional can help them getmore done in less time than if
they were coding unless whatthey've been asked to code is
really, really weird, andhopefully weird and wonderful.
(29:09):
But usually low code tools, takeaway some freedom and give you
back productivity in exchangefor it. And if it's not, they
didn't take away too much andyou still get to produce the
kind of results you need to veryhappy trade off. It's the second
reason for citizen developmentthat's much much harder. I not
(29:32):
it's rare, but low code can helpwith this but not non existent.
And that problem is the factthat mine melts only exist in
Star Trek. There's no mindreading going on. That's just in
the movies and sci fi shows andbooks and so on. It's very hard
(29:56):
for those of us that are trainedto be technical software to
Developers low code or high codeor what have you, to be able to
read the mind of a businessperson that has a problem that
needs to be solved. It's alsovery, very hard for that person
to describe what they need, orwhat they want, or even the
problem they have, in a way thatyou and I can act on to help
(30:22):
them. Which means when we getinvolved in a project, it's not
an explanation. It's anegotiation. And if all parties
have a lot of goodwill, itdoesn't get nasty, but sometimes
it turns into an argument. Andthat's just crazy. But that the
(30:44):
appeal of citizen development isif I'm a business person, and I
can build something for myself,I don't need to explain what I'm
doing to anyone. That's a veryattractive idea. Of course, the
issue is in explaining it tosomeone, even another business
person, we might realise thingswe hadn't thought of until we
(31:05):
set it out loud, or until afresh pair of ears, you know,
thought about it and asked acouple of questions that help to
refine things nicely. It's goodto have people communicate a
little bit, you've producedbetter results in some cases. So
I think that logo can even helpwith that. But the low code has
(31:29):
to focus on more than justconstruction. If it's again, I'd
say 80 to 90% of low codeplatforms out there are focused
solely on construction 10 to 20%of them think beyond that. Those
are the ones you want to take alook at, because they might even
help you communicate with usersand business stakeholders and
(31:54):
come up with a common set ofdesign specifications, common
set of plans, even a commonreview process where people get
together, look at what's beingbuilt, figure out how to improve
it for the next iteration and soon. There's a communication
issue, low code can help withthat low CO construction tools
(32:16):
won't help with that. But lowcode platforms might. We're
certainly trying to do that.
Other people are trying to dothat, too. It's
that will solve the otherproblem, it has to stick at
least in terms of buildingthings. I mean, will it help
with solving their integrationissues? Probably not integration
(32:40):
is as much about politics as itis about protocols, and
priorities, and so on. So it isgoing to have plenty of problems
to deal with. But we can getpast just the application
backlog and the communicationgap with the right kinds of low
code of purchase. I don't thinkcode integration works nearly as
(33:05):
well as some people claim it is.
But yeah, those first fewthings. I think we can do that.
I think we can do that.
Mario Cunha (33:12):
All right. It's pretty good. Um, actually, I was
just thinking of what you justsaid, about the integrations and
how hard they convenient andthat they are more politics than
anything else. It's so true.
Mike Fitzmaurice (33:29):
You know, I, here's, here's a red flag for me
when I look at a local platform,it's not, if they say we've got
hundreds of ready to useconnectors, you can treat them
like Lego bricks, snap themtogether and magical habit. It's
not that the having a lot ofconnectors is a bad thing. It's
(33:50):
a good thing. It's a usefulthing. But thinking if that's
one of the first things out ofyour mouth, it makes me think
that you probably started in thewrong place, and you prioritise
the wrong stuff. Because if Iwant to create, again, a
(34:11):
personal application to scratchat personal itch, a connector
that talks to my contacts inOutlook Connector that talks to
my accounts in Salesforce, anaccount connector that accounts
or connects to a sharedcalendar, or if I'm glueing,
(34:34):
together three or four datasources that I work with on a
regular basis. Great, yeah, youcan do that with canned
connectors coming fromsomebody's library. But here's
the key here. You have 100%authority to touch that data.
It's your data. The only thingyou have to care about is your
(34:57):
stuff. Now if I curate our ERPsystem. And you curate our
marketing automation platform,email campaigns, digital
marketing, and you want to logactivity or outcomes or
something like that into myenvironment, could even be lower
(35:19):
stakes than ERP, it could be CRMor something like that. But
still,
Unknown (35:24):
I don't know you.
Mike Fitzmaurice (35:26):
Maybe company picnics or meetings here and
there, you seem like a nice guy.
But I don't know that you knowhow to work with Salesforce, I
definitely know that you don'tknow how we in my team use
Salesforce, we got to teach youa lot if we're going to let you
open up our file cabinets and gothrough them, you know, with a
(35:47):
flashlight in your mouth andsome gloves. I don't like that.
I like that idea very much atall. And again, it's not a
question of bad faith. It's aquestion of, there's more to
this than somebody snappingtogether to Lego bricks, their
(36:08):
policies, their procedures,there are permissions, there
might be compliance concerns,there might be an audit trail
that needs to be followed.
Integration at the corporatelevel is hard. And it's not hard
because people are jerks. It'shard because the world is more
complicated than we often thinkabout. So it actually does
(36:31):
require us to do somenegotiation. In fact, that might
be we might be better off if Iwrite a small automation script
or business process, and makethat available to you, as you
write an application that needsto talk to my CRM data. So you
have a leak, you want to pump itdirectly into Salesforce, I love
(36:51):
that. So I'm going to give yousomething that you can call as
one rest method. And it'll usewhat whatever scripting facility
I want to use within myenvironment or third party
facility that I want to usewithin my environment that puts
the right things in the rightplaces under the right
conditions, you just call itmagic black box. That works out
(37:14):
really, really well. No one'sgot that in their toolbox of 500
connectors. That's something youand I, and we as an
organisation, curate, we createit, we evolve it, we look out
for it. It's part of what makesour organisation special. So I
think and we negotiated it andcreated it together. And that is
(37:38):
what integration at theenterprise level is like, if an
application if a low codeplatform thinks that integration
at the enterprise level is snapthis to this and you're done.
You're probably thinking of thewrong tools.
Mario Cunha (37:57):
Or getting ready for a big headache ahead of him.
Mike Fitzmaurice (38:00):
Yeah, yeah.
But again, that's that that isaimed at one person scratching
one inch. And, again, if that'sall your application has to do,
yeah, use that tool for that.
For the love of God, don't useit for more than that. I'm
saying
Mario Cunha (38:17):
he has a purpose has a purpose, are about to what
do you think?
Tiago Neves (38:23):
I was just thinking about? So basically a question
for for Mike. But, Mike, how doyou think that the business
might might perceive them lowcodes, in the sense of, it's not
a silver bullet. So all thesechallenges that you're raising,
(38:44):
that they are still there? Canit be that business just might
then give it too much valuethinking that it's gonna solve
everything,
Mike Fitzmaurice (38:55):
under help with a lot of things if it's
done well. So at the very, veryleast, it and I'm using it as an
umbrella term now to mean allthe technical people employed by
the organisation as opposed toall the business people, I don't
necessarily mean that people whomaintain the infrastructure or
evolve the infrastructure. I'malso including developers, it if
(39:16):
we're talking to technicalaudiences, there are people that
build solutions, buildapplications, there may be a
business process team, theydon't think of themselves
society. For our littlediscussion right here right now
for the next minute or two.
There it. Alright. So yes, lowcode is going to help it be more
responsive to business because,again, a lot of the stuff that
(39:40):
slows them down. They don't haveto deal with that. That's a good
thing. Or they don't have todeal with it. It's done for them
automatically in a systematisedway, so everybody has to agree
that it's okay for it to happenin that systematised way But
yeah, it's gonna help them buildmore in less time and do a lot
(40:02):
for them. So they don't have todo everything by hand. It's like
using power tools or laboursaving devices in the kitchen.
It's going to help them get morestuff done in less time with
more predictable, sufficientresults. You're not going to
create grand art with code,which can happen sometimes, but
(40:26):
everything else. Yeah, it'sgoing to help. It's not going to
solve, but it's going to help.
And that might be enough. Here'sthe key. No, we're not going to
win hearts and minds and thelove the business community as
technical people if that's allwe focus on, if we use the right
(40:49):
kinds of logo tools to improveour communication, our project
management and our transparency,our collaboration with business.
Yeah, there's still a lot we cando with low code to improve the
organisation the totalthroughput of the organisation.
And the right kind of low codetools save us an incredible
(41:13):
amount of time. I'll give you aperfect example. What if we are
able to create a businessprocess diagram that is
understandable by businesspeople, but the understandable
business process diagram is theflowchart. With a lot of
(41:35):
environments, you've got onediagram you're going to create
to explain what it is you'regoing to do and a different
diagram you have to create toactually build the workflow
logic. The latter one you can doautomatically. In other words, I
could sketch it out insomebodies workflow ma modeller,
(41:56):
and then it will generate theapplication that we need. But
the diagram that explains whatwe're doing that happens by
hand, there might not be arelationship between the two
diagrams at all. What if theywere one diagram? What if it
were actionable? Andunderstandable? At the same
time, we can get a lot more donethat way. What if you and I can
(42:20):
sit down together, and we cancreate the look. And in broad
strokes, the behaviour of theapplication you want me to build
for you, in order to build anexample of what you want. So I
can see if I can try something,you can tell me where I'm wrong.
And within about an hour's time,we can agree that this is what
(42:43):
it should look like this is whatshould happen when you click
this button, and so on wecreate, this could be a
wireframe or something thatlooks a lot nicer than that. But
yeah, if we look at low codestuff that is not just about
construction, but it's alsoabout collaboration, and
cooperation and communication.
Yeah, that's going to solve alot of IT problems that haven't
(43:06):
been touched in the past.
Because it is not known forbeing good at communication or
or good at providingcommunication or understanding
communication. That's theorganization's fault as a whole.
It's not just it, but but at thesame time, you know, we use the
(43:29):
right Lopo platforms, platforms,not just tools. We address more
than just construction, weaddressed collaboration, long
winded way of saying you use theright tools than the answer,
yes.
Mario Cunha (43:45):
Okay, could Luke code continuous focus on
automation? Bring any sort ofunwanted consequences? Could it
be become too focused?
Mike Fitzmaurice (43:57):
I actually am very, very wary about
automation. Because it is fartoo easy to beautifully automate
a terrible process.
Mario Cunha (44:11):
It's a good one.
Yeah.
Mike Fitzmaurice (44:16):
And the problem is, unless you live this
stuff, it doesn't occur to youthat automation and process and
workflow are three differentthings. And again, I don't
expect somebody that doesn'tlive this all the time to care
about the difference betweenprocesses and automation. But,
(44:37):
you know, there are a number ofwonderful tools out there from
RPA vendors, robotic processautomation vendors, you know,
the UiPath, blue prismautomation anywhere. There are
others, but those those are thethree rock solid dudes. They,
they do good work, but they'dactually be the first to tell
(44:59):
you that They're not in thebusiness process modelling and
automation business. But they'rereally automating our processes.
They're automating activitytasks, there should be our TA or
RA or something like that, asopposed to RPA. But they have
(45:20):
the name that you really shouldcombine that sort of thing. with
something that looks at thebusiness process, what are the
assets, we need to get thisdone? What are the goals we
have? What are the How will wemeasure whether we accomplish
it, what should be done, andthen we defer to rpa, or
(45:42):
scripting, or automation tools,or any of a number of different
things that or even code toactually execute the things that
the process tells us? It's timeto do? Yeah, it's, if all we
focus on is automation, one oftwo things happen, we will
(46:06):
slavish li try harder and harderto automate what might be bad
processes, or what we'll have isworking very hard to automate
implicit processes. Maybethey're not bad, but they're in
our heads. In other words, whatto do gets automated, why we're
(46:28):
doing it gets lost if somebodyleaves the organisation, or it's
manual and has to be read inorder for you to understand
which automation to kick off andwhat to do with the results when
it's done. I yeah, I have aproblem with that. I think that
looking at automation, and onlyautomation is a very incomplete
(46:52):
picture. So you have to think ofthe process and think of the
data assets as well. But yeah,there's subject matter expertise
that matters a lot in the worldof process management, it's
thinking about the processfirst, and then determining
which assets you need, and whichautomated bursts of activity
(47:12):
should be created to support theprocess. Doing it backwards,
involves a lot of risk. The samekind of thing happens in the
world of business intelligence,I can't tell you how often
people have just said, Okay,I've got this data, let's see
what I can find from it. Bydoing ad hoc analysis, after ad
(47:35):
hoc analysis without reallyunderstanding the data that
they're analysing in the firstplace. They might draw crazy,
they might occasionally come upwith something no one had
thought of, but more often thannot, they'll draw crazy
conclusions because they aregrounded in the subject matter.
It's really easy to focus oncool tools, without thinking
(47:59):
through, why you're using themin the first place.
Mario Cunha (48:03):
That is quite an interesting, I did like the the
example of the businessintelligence kind of makes you
think we have a set of data,let's look for patterns. Okay.
Some patterns just happenbecause they happen. They don't
have any meaning behind it. Orif
Mike Fitzmaurice (48:19):
Yeah, okay.
Well, it's it's still it's 2020.
It's the beginning of 2022. Ifsomeone's listening to this next
year, hopefully the wholepandemic thing will be over.
Yes. But yeah, this happenedmore in 2020 and 21. But there
were countless armchairepidemiologists who had it, who
(48:44):
were business intelligence,people that just love to be able
to get at crunch numbers andsay, actually, what's happening
is this without understandinghow viruses work, or how, you
know, without knowing thingsthat doctors know, it's not just
(49:05):
about data, there is a certainsense of subject matter
expertise that matters. DataAnalysis contributes a lot to
human knowledge, but not withoutsome knowledge to know what to
do with the data in the firstplace. So sometimes wonderful
things happen. But a lot ofpeople, basically because
(49:29):
particularly in the first yearof a pandemic, when there were
no vaccines, there were lots oflock downs. You know, what am I
going to do? Well, this data ispublicly available. Let's see
what I can figure out a lot ofcrazy inferences happened that
that that was more 2020 thanlast year and certainly more
than this year, but you know,it's a big obvious example. You
(49:55):
got to got to know what you'redoing in order to handle the
mechanic Parts of it well,
Mario Cunha (50:01):
make sense makes total sense. Jaggu anything you
would like the head?
Tiago Neves (50:07):
Don't just just love that example, Mike. That's
all.
Mario Cunha (50:13):
Okay guys, on that last note then we end today's
podcast. Thank you very muchMike Integra for joining us. I
bid love your company likeamazing. I would also like to
send a big thank you to everyonewho is listening and hope you
can join us on our next episodeof high tech local podcast where
we will always talk about moretopics about the tech universe.
(50:34):
See you soon. Bye, everyone.
Unknown (50:36):
Outstanding. What a pleasure. She is. Bye bye
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
The Breakfast Club
The World's Most Dangerous Morning Show, The Breakfast Club, With DJ Envy And Charlamagne Tha God!
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.