Justified Code Founder

Hi, I'm HH!

Welcome to Justified Code, where i help you rise above peers and reach the level of a Software Architect. Here's a quick rundown of who I am:

  • I became a Software Architect in 2010 and have made every mistake imaginable since then: choosing architecture to experiment, adding complexity without justification, working hard for companies instead of developing myself...

  • Unlike other architects, I stay involved in coding. This hands-on approach ensures that my designs are ready to implement.

  • My methods are informed by classic literature in the field, ensuring that foundational knowledge is passed on in its purest form.

In a field muddled by overcomplication, I am known for my straightforward approach to software architecture. Join me at Justified Code to build a solid foundation that stands the test of time.

An expert is a person who has made all the mistakes that can be made in a narrow field.

Trend Is Not Your Friend.

Experience is what you got when you didn't get what you wanted.

Good times teach only bad lessons: that building software is easy, and that you don’t need to worry about risk. The most valuable lessons are learned in tough times. In that sense, I’ve been “fortunate” to have lived through some hard ones.

.NET Web Forms

Before the web browser became the norm, Microsoft successfully provided us Windows Forms that we used to build desktop applications. Then they said: why not transfer the same behavior to the web. The game started. Everyone delivered web pages quickly. You need to load a grid or a dropdown list with data? It is a drag-and-drop thing that felt like magic.

Then came the first deployment. That's when we discovered how slow web pages were to load and we started tinkering with the ViewState. We found ourselves solving problems we had created by assuming the web could be treated like a Windows app.

Looking back, I learned the cost of following an antipattern which is the code-behind approach. MVC web architecture eventually won the race. Till today, you still hear people say “.NET is slow.” Now you know why.

Adobe Flex

The Adobe Flex wave, where companies went all in on rich browser apps. It felt like the web had finally caught up with strong interactivity, like building desktop applications inside the browser.

Then one decision changed everything. Steve Jobs refused to support Adobe Flash in Safari. Just like that. How could anyone anticipate Apple pulling the plug on Adobe Flash, when that was a core component to run Flex?

I was involved with a company that decided to move all its Windows app logic to Flex, only to hit that wall. The company had to shut down the whole team. You can imagine the amount of energy and money wasted.

As a funny note, we had the dean of our university back then asking every alumni he met, “do you know Flex?” If someone hesitated to say yes, he’d immediately tell them to catch up, as if not learning it meant you’d get hit hard in the job market 😄

NoSQL

The run toward NoSQL, where teams rushed to use MongoDB everywhere and ditched relational databases, only to hit a wall when the first serious report was asked.

I worked with an owner who asked us to build a prototype/MVP, then let his paying customers use it for a while. The day he had a meeting with them, he asked for a detailed report. Teams who stayed with traditional SQL/Oracle had no issue delivering. The ones who followed the hype struggled to produce the same report in time. They resolved the situation with different kind of hacks and explanations.

ERP

Installing ERP systems for users who needed only 5% of what those systems were built for, and watching the learning curve kill people morale.

We had a local Sony services agent who asked a company I had just joined to build a system for them. A “consultant” pushed for an open-source ERP instead. They started tweaking the code here and there and deployed it. What was supposed to be a focused solution turned into a giant system the client didn’t need.

The problem showed up quickly. Small changes started taking weeks, especially when developers modified the core instead of using the system’s pluggable approach. The client saw what was happening and took the company to court. All of it came from delivering something far bigger than what was actually needed.

ORM

ORM-heavy code that boosted developer productivity but struggled under real read load. My experience with Entity Framework wasn’t great. I now use Dapper for reads and NHibernate for writes.

People say modern ORMs are extremely performant if you know what you’re doing. Maybe. But no matter how far I pushed it, moving to Dapper was always the better solution. Just recently, I had a worker service consuming broker messages and writing to an Oracle flat table. Using Entity Framework, it was taking 4–5GB of memory and 6–8 cores. Moving to Dapper brought it back down to around 150–200MB and mcores.

Microservices

The microservices trend, where everything became a service, and we paid the distribution tax.

It’s wild how we consistently find more complex ways to solve problems that "boring" tech already handled perfectly fine.

Here is the full story in case you missed it: Microservices… what actually happened

SPA by default

The prevalence of teams choosing a single-page application (SPA) when they need a website continues. People aren't properly recognizing SPAs as an architectural style to begin with; instead they're immediately jumping into framework selection.

SPAs incur complexity that doesn't exist with traditional server-based websites: issues such as search engine optimization, browser history management, web analytics and first page load time.

Most software developers aren't aware of an alternative approach because they have spent their entire career in a framework like React. The reality is that many websites will benefit from the simplicity of server-side logic.

Nowadays, after several years of abandoning server side rendered pages to embrace Facebook's React, we rediscovered Server Side Rendering (SSR) as a "cool thing".

Looking back

One mistake I see often is people choosing architecture to enhance their resume, what’s known as resume driven development. I’m guilty of it too. I’ve chosen architectures just to experiment, not because the problem needed them.

One mental model that helped me later: Trend Is Not Your Friend.