Our next speaker is Adam Uren.
He's a developer with over 25 years of experience in IT.
So big round of applause for Adam.
Hi and welcome.
Welcome to Recycle Reused Rebuild.
And I'm here with you today to talk about some of the
tactics for turning your brownfields green.
So quick intro.
My name is Adam Juran.
I have my own company, Juranosaurus Tex.
It's because, like you said, I've been doing this for 25
years.
It makes me a bit of a dinosaur.
And I functionally am a fractional CTO at this
US startup called OK Capsule, which we'll figure later in
today's talk.
And before we jump in, you all know what brownfields and
greenfields mean?
No.
Great.
So a brownfield is like a legacy project.
It's maybe brown because you feel like it's a piece of
beep.
And but that's almost what all of us work on professionally.
And it's the greenfield projects, the ones with all
the latest libraries and the latest version of Tan Stack
Query or React Router or whatever your favorite
X state, I don't know, whatever it is, the ones we get
really excited about are weekend, our side projects.
And this talk is about some of the ways we can help make
our brownfields a little greener.
So here's a quick overview.
We're going to talk about the challenge of legacy systems,
how to unlock transformation, navigating the JavaScript or
solution evolution, how to empower development and
developers.
And then we're going to look at a quick case study, which I
think highlights a lot of these points.
And then a quick Q&A.
And I have to resume my timer.
There we go.
All right.
So this is what OK Capsule sells.
We sell these dispenser boxes rolled up of pouches of
vitamins, of supplements, so that we can reduce plastic.
And you don't have to.
If you're taking a lot of vitamins, you all look very
young, but for anyone who takes supplements on a
regular basis, it's kind of a nuisance to open up like three
different bottles or four different bottles.
And there's a lot of plastic that goes into that as well.
What's really interesting about working for OK Capsule, this
is the first time I have ever worked with a company that
produces a physical product and not just code.
Does anyone else work where the end product is anything
manufactured?
Cool.
Cool.
It's a US company, and it's supplements, so it falls
under the jurisdiction of the Food and Drug Administration.
By the way, as a Native American, not a Native American, but
an American Native speaker, I sometimes speak really, really
fast.
If I'm going too fast or I'm not speaking clearly enough, just
shout at me.
It's a slow, no, no, no.
The startup was started about four years ago, and just
because that's what the CTO knew, it became Salesforce
everything.
Now, Salesforce is a great tool for certain things, but as
a development platform, it's frustrating.
Especially for all the things we look for, for scalability,
for efficiency, et cetera.
But it had everything, not just the CRM, the client
relationship management, which is typically what it was
invented for, or ERP.
Oh gosh.
Enterprise, resource, planning, thank you.
Too many acronyms this early in the day, which is really
because we have inventory and we have lots, and we need a way
to manage that.
And Salesforce is a reasonable way to handle that.
But the API was written as into JavaScript using Apex, which
is Java, cool.
But there were other problems in that architecture, which I
won't get into now.
And various integrations, everything was Salesforce.
And they just started to move some things out to AWS, but
it was very, very, very early.
There's a Shopify app to make it easy for some clients,
because this is a white-labeled product.
You can have your brand.
It can be anything.
And there was just a lot of tech debt, even within the
Salesforce, MVPs, POCs, Band-Aids on top of that.
It was kind of a mind-blowingly broad landscape of bad
practices.
And yet it worked.
That's the thing.
There's value in the fact that it was already working.
Think about all the banking software in the world.
It's all COBOL, in from where you're going to go and blend
the reliability of what exists with the agility of maybe
some new technology.
And I'm getting a stamp.
I have to read.
Oh, no.
Does this work?
Yes, this is better.
I'm sorry.
This is, I have speaker notes.
You know how it is.
So what we're looking to navigate is what I call the
middle path.
And it's about finding that right balance, keeping the
system stable and reliable while at the same time making
them more efficient and ready for the future.
So we have to carefully choose which aspects to enhance and
how to integrate new technologies.
So we're doing more than updating.
We're, in a way, future-proofing the work.
Because as it is said, what got us here really can't take us
to the next level.
So there's this amazing temptation when you look at
someone else's code and you don't have the context and
you're like, oh my god, this developer was an idiot.
Like, who would write something like this?
And another side of it is someone's looked at our code
and thought the exact same thing.
So there is this temptation to throw it away and start over.
But it seems like this direct roots to efficiency.
But hitting the reset button comes with its own costs and
challenges.
Because not only you're losing what you've already built and
the opportunity cost, like the time and the money that was
spent developing the thing that mostly works in the first
place, but then there's knowledge gaps about why
decisions were made.
That's keeping track of whoever came before us, why they
chose what they did.
There must have been some, we hope, that there was some logic
in the choices that they made.
And almost inevitably, there's these tentacles of tightly
coupled systems that reach way deeper than we initially
imagined.
So we really need to consider a more thoughtful and layered
approach for a meaningful transformation.
So who here has burned it all down before and be like, the
hell with this?
I'm starting over.
OK.
Did it work?
Oh, and we lost my slide.
I'm unplugged.
Please go back to full, please.
I'm plugged in, I promise.
Yeah.
We're going to have to find it again or reset it or
something, you know?
This way?
It should be fine, but it's not there.
Yeah, hold on.
Window.
There we go.
And is it full?
It's full enough.
We're going to leave it like that.
I just don't want that feedback.
It's been driving me nuts.
Let's try putting it down again.
I'm going to take it like this.
OK.
So moving on.
So how do we find this strategic middle path?
So you have to start with an evaluation of
legacy systems.
You have to identify, see, stand back.
See what is already delivering business value?
Because, do you guys hear that?
Hmm?
It's when you get near to the things.
This thing?
Yeah.
Try to.
I'm standing over here in the corner.
Anyway, OK, good.
It's gone.
So we have to look for the places that deliver business
value.
And I know that's not always our first instinct as
developers.
We want to do the cool thing and have a good developer
experience.
But sometimes our managers, they have a point.
We can't.
The whole point is we're a business.
We're offering something of value and people give us
money for that.
So we have to look for what provides business value.
Because sometimes the cost of rewriting or replacing
doesn't justify the potential gains.
Like, it's not just about us having fun.
I mean, it is, but it isn't.
So this assessment helps us pinpoint where enhancements
can be made without disrupting the underlying value.
And then we can bring in new technology to enhance these
areas so that we can boost performance without starting
over.
So we want to mix the old's dependability, because it's
already there.
It's already working, mostly theoretically, hopefully,
with the new's efficiency and do gradual improvements.
So we're talking about evolving systems bit by bit,
ensuring that they may remain stable as we
integrate new features.
This is also why testing is really important.
Because no one sleeps well at night when you roll something
else, roll something new out.
And you're just like, well, I hope this works.
I don't like that anymore.
I did when I was young.
Also, 25 years ago, no one was dead.
No one was testing.
At least I wasn't testing.
OK, let's call it on yourself.
So by choosing a middle path, we can make sure that we meet
today's needs and also plan for the future.
All right, so how do we navigate finding the right
solutions?
So JavaScript, which is the bulk of my new platform, but
no to the back end and React on the front end, is a massively
evolving landscape.
I have trouble keeping track sometimes of all the new
frameworks and new libraries or changes.
And it's so easy to have FOMO, this fear of missing out on,
I'm not using React server components yet.
And it feels like everyone is.
You have to just be aware of that context.
But you do have to look at all the pieces out there.
There's a lot.
I mean, we think of the JavaScript ecosystem and all the
packages and the vast majority of it is open source.
And so you get to consider, like, do I want this library?
What's the best way to handle this?
Do I want state management?
Do I want two stunts?
Do I want recoil?
Recoil is old.
Redux is too big for my taste.
X-State is my favorite.
But there's like a million options.
And how do you choose?
So but even stepping back, you have to look at the whole
architecture of the system and think about how you can go
from tightly coupled towards loosely coupled.
Legacy systems often, not always, often tends to be
tightly coupled.
So we want to keep our move towards loosely coupled,
keeping the architecture scalable and flexible.
And then there's the aspect of repair or rebuild from scratch.
And it's not just about dealing with tech debt.
It's about, again, weighing the ongoing value of the system
as it is.
Is there something of value that you can salvage before you
decide to rewrite it altogether?
And as I mentioned, open source versus custom solutions for
OK Capsule, four years ago, Salesforce, the vendor solution
seemed like the logical choice.
It was known.
They didn't have the director of engineering.
And they just said, OK, well, let's start with this.
This seems like a reasonable choice.
And went.
And they got themselves in pretty deep before they
realized we're going to have to replace this, especially for
the order infrastructure, the way that our
clients can submit orders.
And finding this right balance, really between open source and
vendor solutions, can actually drive innovation if you plan it
and navigate it well.
So another poll for you all.
Rebuild, repair.
What do you all think?
What have you done before?
What do you prefer to do?
It depends.
Yeah, I know.
Good answer.
Good answer.
Have you heard my talk before?
So beyond the technical challenge, another aspect of
transforming these legacy systems is how do we empower our
teams?
Because odds are there's already some underlying
frustration in development teams working on legacy
applications.
We feel frustrated by the inability to move quickly very
often.
But there is sometimes this untapped potential there.
And we can find the path for innovation and efficiency.
So the activity is to engage with your teams and consider the
mud of a brownfield.
And decide whether when you're going to sow the seeds and
when you're going to let this field life fallow, you're going
to leave it alone.
And this is the strategic transformation, applying thoughtful
targeted strategies to cultivate sustainable tech
landscapes.
And when we all raise our hands having worked in legacy,
we're not alone in this.
We're all dealing with this.
And there's really a lot of value in the collective wisdom
whether you're reaching out through open source communities
or you're asking the models of chat GBT.
There's info or Stack Overflow too, back in the old days.
But there's a lot of information out there.
And you don't have to go this alone.
So now we're moving on to the case study.
And how am I doing on time?
18 minutes?
Yes, yes, we're in good shape.
All right.
So we're going to talk about the problem I faced, my team
faced, the opportunity, how we divided up, recycled,
rebuilt, reused, what the outcome was, and lessons learned
and takeaways.
So if you all remember back in the beginning,
I showed you that little dispenser box,
and we sell these little pouches.
What we also package with that is a pamphlet.
The pamphlet is a marketing material.
It also has descriptions of the supplement.
They show up to orders the next day.
The pamphlets are already ready.
They use a little scan to make sure the order matches
the pamphlet.
So conga, this is another product within Salesforce,
decided that we weren't paying enough.
We were one of the bigger clients, and they're like, hey,
we're raising your rates.
And it amounted to highway robbery.
They were blackmail, or extortion,
or one of these terrible words.
And my CTO is like, we're not doing that.
He's wanted to get rid of them for a long time.
And so he said, like the day before Christmas,
we're going to rebuild, and you have until mid-February.
We're going to do that.
So yeah, so vendor lock-in.
Who here has suffered from vendor lock-in?
And the problems?
I'm not alone.
So this is how we dealt with it.
We chose to basically reverse engineer.
We had some of the pieces in place.
Too close to this box.
We applied the principles of a cycle, rebuilt, reused,
and we completed the development under five weeks.
We're testing right now, and this will be going into
production within the next two weeks.
We're just basically testing the printing and alignment
and making sure, because again, it's a physical product.
And just because it comes out in the PDF doesn't mean it
comes out of the printer exactly how you want it.
And I'm really, really proud that every member of my team
played a role in making this.
We have a very small, like five-person team, and
everyone touched this in some way.
So what's really cool is here's a few of the open source
libraries.
And we already had this node app, which helps us produce
the nutrition fact panels, and we extended it to be able to
print pamphlets using pug templates, existing visual
assets, and an S3 bucket, no problem.
We had to manually copy the text and style data from the
Microsoft Word templates.
We put it into a JSON format, and we put that into a
database table.
What's really awesome is the new architecture allows us to
have now multiple blocks of dynamic code per page, or in
multiple pages of these pamphlets.
We're not doing that yet, but it's just another row in the
database and another cycle in the loop.
We added a new endpoint with actual schema
validation for Salesforce, because Salesforce has the
orders information at the moment, so it's going to call
out to our panel app on AWS to generate the PDF and then
send it back.
You'll see another diagram on the next page.
And with this also having this stored this way, it lays a
foundation for us to build a section in our portal to allow
clients to directly interact with their pamphlet designs
and handle themselves, because right now someone on my team
has to collect the data and put it into the database.
So ultimately, that's an efficiency that as soon as we
have time, we build this UI and then just charge the client
every time they want to update their pamphlet, and we stay
out of the mix.
So have you all ever had this innovation under pressure?
Kind of a thing before?
Few of us.
It's it was a fun challenge.
It wasn't just too much, but it was still a challenge over
the holidays too.
So here's the original.
Here's the before, if you recall, and this is a little
more complicated how this all works.
So Salesforce still triggers a cron job, hits its apex class,
which calls the panel app.
It then takes the image assets from S3, order data from the
database, and also the style data.
I didn't mention that aggregates it all through a pug
template, generates HTML, playwright, handily, just creates
a PDF of my HTML template, sends it back, attaches it, boom,
done.
So this just shows the comparison.
And there's a lot more independence available.
We've just taken out the blocker.
We don't need this anymore.
I can go bye-bye.
And you can also see tightly coupled where we're like, these
are all individual things.
So now more loosely coupled.
Cool.
So lessons learned.
What is that?
So the journey taught us several lessons.
The importance of reducing dependency, Fender Lock-In,
power of creative problem solving, the need for
strategic flexibility in our planning.
And these insights have shaped our new approaches, preparing
us not to face future challenges, but to anticipate them
and solve them proactively, like the UI.
And that's kind of it.
So I wanted to just open up a Q&A session.
Please share questions, insights, or experiences related to
Brownfield transformation.
And yeah, questions, please.
Questions?
Yes, sir.
It's very curious to me.
I'm in a position right now about the Starr-Grindfield
project with a client that it's asking between AWS and just
buying everything out of Salesforce.
So this is already helpful.
Thanks for that.
You're welcome.
But if you were in this situation, again, where you're
starting from scratch, what would be the set of tools
you would prefer?
So the question is, if I'm starting from scratch, what
would be the set of tools?
And to quote from someone else in the session, it depends.
It really depends.
I kind of like, for certain things, I like Redwood JS,
because it's kind of a full stack solution out of the box.
But it really depends on what you need to start with
and where you're going.
You really have to, because Redwood's good for a few
solutions.
We have a micro, our new API, which was built last year,
we outsourced it, was, is microservices, about 10 of them.
And so it just depends.
What are you building?
So I'm dealing with people who really want to keep using Excel.
So they just want to make sure I don't take the weight
on Excel files.
So is that the actual Excel or the experience of a spreadsheet?
So now they come from manufacturing, but also physical
products.
Uh-huh.
But yeah, they're clueless.
On the text, they don't have a CPO.
So it's really hand-holding them into the world of choosing
the best for their future when they have absolutely
no knowledge of tech.
Got it.
So the question is, he's dealing with a new client, and
they're in manufacturing, and they really like Excel
spreadsheets.
I, my gut would be, find a tool that emulates, like a data
table that emulates that and lets them get pretty close to
that so that it's not actually Excel.
Unless you want to use Excel as like a back-end, and I only
say that, and that sounds crazy, but you know this website,
levels.fyi, which they had all the aggregated information about
who got paid what and all the fang companies?
Their back-end for the first three years was Excel.
It was Google Sheets.
Actually, it was Google Sheets.
I'm sorry.
So, and that was their back-end.