Technical Debt, App Performance, and Elon vs. a Developer

By Pete Czech

p>Every once in a while, something happens that's so timely and of such consequence that I rearranged my morning to write a post about it. This is one of those moments…!

By now, we've all heard the news: Elon Musk has acquired Twitter, and severe turbulence has ensued. I have so many thoughts about what's recently transpired… of course, we have the whole issue of free speech, social networks, and the complexity of running them. While that isn't the topic of this post, I think it's easy to say that running a social network is inherently more complex than starting a car or even a rocket company. The reason for that is that cars and rockets follow some universal laws of physics, as opposed to people who are, as if by design, irrational beings.

But I digress!

This post is more about a conversation I saw between Musk and one of his developers on Twitter this weekend. Last night, Musk tweeted that Twitter for Android was slow because of an overabundance of RPCs, or remote procedure calls. He's implying that the performance of the app is slow because the app is making too many calls back to the server for data. As a reminder, most mobile applications work because they gather data from servers via APIs. Whenever you load a mobile application, it communicates with various servers to collect information such as authentication, content, etc.

Elon's subsequent comment was that there were more than 1000 remote calls upon loading the Twitter application on Android. In response to this, one of the developers at Twitter responsible for the app called him out on it. Before I dig into their conversation, let me say that it's doubtful Elon is correct. 1000 remote calls to render the Twitter timeline would be outrageous, to say the least. If this were true, the app would be unusable, and Twitter would rely on more server infrastructure than it would need. Even a junior developer would know better. So, it's safe to say that Elon didn't know what he was talking about.

So, enter Eric Frohnhoefer, a developer at Twitter who replied to the comment. His reply to Elon was calling him out for the mistake. Of course, Elon being Elon, needs to respond with a snarky comment, asking what the developer has done to fix it. The reply from the developer is a series of tweets that should go down in history as one of the most professional responses to an executive claim that many of us will ever see in public.

To summarize, the developer indicates that to load the app, there are about 20 API calls, not 1000. But it gets more interesting from there as he discusses multiple reasons why the app is slow. And within these reasons are lessons for everyone that's building applications, whether for mobile devices or web-based use.

First, the developer rightly points out that the app is bloated with too many features that no one uses. This is typical for something that has developed over time, especially with large development teams and a turnover of product managers. As he suggests later in the thread, removing features that are not used should be considered.

Secondly, he makes mention of years of technical debt. This is a fascinating point, which he indicates is because the company was more interested in the quick iteration of new features and growth than in performance.

Finally, the developer does indicate that the app must wait for network responses. He's implying that the back-end systems are not functioning well, either. That would leave one to guess that if there's technical debt and future blow with the app, perhaps back-end systems are suffering from the same ailment.

As I've linked to the thread above, anyone can see all the comments others have contributed. The purpose of this post isn't to debate how these things happened and who made mistakes along the way but to point out one simple truth: these issues are not unique to Twitter, and they're not unique to your company if you suffer from it too. This thread should indicate that we may be in an era of bloatware and technical debt, a problem many organizations will have to take seriously in the near term.

During the onboarding process of new customers, I often talk to developers and other in-house technical members at client organizations. Almost all of them bring up these same issues. Maintaining clean and efficient software while iterating quickly is challenging. And as evidenced by this thread, even the largest, most sophisticated modern organizations have trouble addressing the challenge.

So, what can Twitter do?

In this case, the developer is recommending some significant rewrites. Essentially, he indicates that ten or more years of technical debt can't be addressed without rewriting or refactoring a substantial portion of the code. An analogy to this would be buying a house and rebuilding every room in it. This is frustrating if you just bought the house… or Twitter!

But more importantly, what can your organization do to avoid these issues in the future? After all, we don't have the massive development teams that companies such as Twitter have. 

Simply put, the best thing you can do is to understand that technical debt is a legitimate issue that needs to be addressed and formulate a commonsense approach to dealing with it. This starts with a cultural understanding of what it is, how it occurs, and putting it into steps as part of a development process procedures to handle it.

There are quite a few good posts about this floating around the Internet, so I recommend you search for it. To dig into all the different techniques in this post would be outside the scope of what I was trying to discuss.

Many of you are probably asking what happened to the developer that dared question their new overlord's opinion. Well, that poor guy got fired this morning.

I believe that he'll find new work quickly.

While we're on this topic, I would be remiss if I didn't mention the sheer toxicity that Musk has brought to Twitter and the organization since he took over. Issues like this being litigated in an open forum are not optimal. Granted, Twitter now belongs to him, and he can do what he wants. But there will be many issues and debates around significantly more critical issues that will come up while Twitter is in his custody. These problems could sometimes mean life and death, especially considering geopolitical factors.

Because of this, I note that owning a social network will be the biggest challenge of his career.

Furthermore, the more public his toxic takeover and tactics become, the more we need to question the operation of his other companies, such as Tesla and SpaceX. These companies are too big to ignore and factor into significant segments of the US and global economy. The recent rollout of the verified blue check mark on Twitter turned into a disaster. It was poorly conceived and horrifically executed, resulting in the future being embarrassingly removed. This is not the type of rollout we want to see with an automobile or a space vehicle.

I would hope that the day-to-day operations of Twitter are neither a distraction from these other enterprises nor some indication of problems happening not these other organizations.

Only time will tell. 

Get in Touch

In the past, we have addressed many of the important reasons to take website accessibility seriously.

Get In Touch