This Type of Flutter Code WILL Ruin Productivity
My story about how I broke a codebase and couldn't fix it
Sometimes as we’re working in a Flutter codebase it just feels, “Ugly”. That’s the only way I can put it.
Almost like it’s been hacked together and the pieces do not belong with each other.
Today I want to address this issue and present to you some things you can try to fix this problem. Most teams leave it as-is since it doesn’t make a difference in the product performance or functionality.
But it does have other impacts.
Unstructured and hacky code can drain your team’s productivity.
Today I want to tell you a story about how ugly code negatively impacted a team I worked in.
Understanding the impact it has and how to avoid ending up there will allow you to be more productive from the beginning.
How I broke a project due to ugly code
“The CPU doesn’t care about how your code looks”
I heard this a lot when I commented on code that my two architect C++ teammates wrote in 2015.
They used variables named m_lvt
or _sf
. In fact, they wrote their own XML parser because the fastest parser (at the time) wasn’t fast enough, that’s the kind of developers they were.
We were building a cross-platform game scripting engine that uses XML.
I joined the team, with only 1-year experience, the other two team members were architects with 20+ years of experience. I needed to get up to speed, quickly.
I started by reading the XML to understand the structure, how it was set up, and what each node meant (they had no documentation, obviously). As I read the XML and gained understanding, I documented the nodes in detail. We were set to scale up to 14 people (3→14) so I wanted to avoid everyone wasting days like I was.
I committed the XML with comments and pushed my code. A few minutes later, Chris, the number 7 employee in the company of over 2k people, looks over the desk and says, “Hey, you broke everything”.
Why I couldn’t fix my mistake on my own
I opened the XML parser immediately and started frantically looking for the issue.
I was sitting there looking through the code, I couldn’t understand a single line of their code. The functions were large, not well named, and contained variables like _sf.
Some functions even had 2-letter names.
With code like this there’s no way I would be able to find the problem. Eventually, I get a debug breakpoint at the exact point it breaks and I show Chris. He says “Aha, I see you added comments. Our parser doesn’t support comments.“.
I would not have figured that out just by looking at the code.
The unreadable code made it difficult for me to understand what was happening, and even more difficult to contribute anything meaningful. This meant I now need additional help from the original developer who wrote it, whose hours were far more valuable than mine.
Together we probably spent 8 hours trying to find the issue. This means 8 hours his work was on hold, and mine wasn’t moving forward.
Unreadable, ugly code, is not there to increase CPU or GPU performance, it’s there to increase team performance.
There is a cost to code that looks and feels hacked together.
The real cost is hours of developer time flushed down the drain.
Instead of fixing issues you first have to battle to understand the code. After that battle, if you win, you can attempt to fix the issue. If you don’t win, you need another developer to come help fix it.
You lose a significant amount of time which affects the entire team. A lot of this can be avoided through better variable names, better function names, splitting responsibilities, and creating good facades.
If you want to dive deeper into separating responsibilities in Flutter code and writing excellent code. Read my full guide.
Let’s work together
Book a 1-on-1 call with me to take the next steps for your Flutter project.