Happy Friday!

I couldn't sleep last night. That gave me some time to think about what I'd write in this little newsletter. I thought I'd write about a topic I can go endlessly about, but it's hard for me to describe.

It's just that our industry sucks at writing software.

When I think back to all of my previous clients and jobs, and if they coded themselves into a corner or created some part of a system that was too scary to touch, every single job and client had that. Some of these instances were new projects just a few months old that were built by very clever people.

But, our industry sucks at writing software.

There are many reasons for this, but one catalyst for poorly written software comes from how we use frameworks, and that's what I want to focus on today.

Frameworks like Angular, React, Spring, Express, and even things like AWS Lambda all have a common set of characteristics that make our code garbage.

You see, the authors of these frameworks know that they built something that works and is useful. They try to make it so that their framework is easy to adopt and implement. And we happily do. We go about coupling all of our code to their code from the very beginning.

We wind up with code that only needs to add two numbers but now requires that we load all of React as a dependency. We just need to test that we are getting the correct mock data from a database, but we loaded all of Spring, Hibernate, and its security model to do it.

Our code is now so tied up to the framework that we don't know where our code stops and theirs begins.

Thanks to how we use frameworks, we build balls of mud so much faster!

The cure is keeping our business code outside and away from those frameworks. That code we needed to write that adds two numbers never import React. The display code that is React imports our addition code.

By keeping our code completely isolated from the frameworks, we keep it easy to test, easy to change, and easy to upgrade. Aggressive isolation is the name of the game.

One of my ways to get started with this is to look at the code people create in services or controllers. Those typically make very easy candidates for refactoring and extracting our logic into separate and isolated classes. Controller and service methods that were 300 lines long become 5, and I can prove our logic is perfect without worrying about if I've set up the framework. If something isn't working, I know it is a configuration, not a code issue.

So, that's my advice here for you this Friday morning. Rip your business logic out of your frameworks. Those frameworks do a lot, including making your job harder.

Here're the fresh articles from my site you might enjoy...

🗒️ Book Review - The Checklist Manifesto

I was talking with some friends the other day about the state of our industry, as we often do, and someone mentioned various problematic metaphors that people use.

In particular, the metaphor that software teams should work like a surgical team led by a surgeon.

That led to a book recommendation for The Checklist Manifesto.

I picked it up, read through it, and thought I’d share my major takeaways.

Click here to read more

🗒️ Make One Small Adjustment to Your Roadmaps

I’m not a fan of most roadmaps or their usage, but so what?

They are a near-universal tool in many companies that awkwardly try to communicate what is going on and their timelines.

Despite them turning into vague work-breakdown schedules, there is something we can do to improve them.

Click here to read more

🗒️ Tales of Efficiency

The alarm goes off in the morning, and as usual, I begin my day by putting on my clothes.

Now, I’ve been putting on my clothes for a long time, and I like to do things efficiently, so I put my clothes on in the following order:

Click here to read more

Enjoy,

Ryan Latta