Sony Experia XZs in the US with fingerprint reader

Got a Sony Xperia XZs about a couple of months ago to replace my iPhone.
Main reason was with our move to Montevideo I wanted a dual SIM phone and I didn't want a Samsung.

The Samsung deal is a long story, but in short, Samsung tech support in the US was the only people ever that mistreated when trying to get camcorder repaired, after literally stealing a device we shipped to their repair facility and claiming they shipped it back to us and we were trying to rip them off. Anyway, we just don't buy anything Samsung at our household, period.

I digressed, going back to the Xperia. Great phone! But I badly missed the fingerprint reader, until I found out that in the US they are simply disabled by firmware.

After I learned that, the thought about figuring out how to change the firmware stuck with me. I decided to try the procedure when my son eventually discovered my unlock key simply by watching me do to unlocking pattern a couple of times.

I will not reproduce here the whole process, you can do Google search and you will find plenty of pages that explain it.

In summary this is what I did:

Downloaded xperifirm tool. With that tool I found the right Indian firmware for my phone and downloaded it.

Got the flashtool for Sony devices. Built a firmware file from the downloaded and unpacked files.

A note here is to delete a fwinfo.xml file on the root download folder. According to one page I found if that file is included in the firmware file it gets corrupted.

With the firmware file built I went into "flashing mode". When you initiate the flashing process you are prompted with a dialog to exclude certain items and wipe others. I simply used the default settings and that works well to replace the firmware without loosing any data or config.

A note on the flashing process. Relatively early in the process, the console showing the files being upload to the phone suddenly stopped showing any activity. After a couple of minutes of inactivity I thought I finally bricked the phone, but armed myself with patience and waited. Eventually the flashtool picked up and kept going reporting on files being uploaded to the phone until it was done.

I unplugged the phone and turn it back on. Got another scare when the Xperia logo color animation took forever... Again I thought maybe I bricked the thing and all I got was a fancy screen showing an animation. But no, eventually the phone booted, reported an upgrade in process and was usable right from the start.

I went to the security settings and to my surprise I found the fingerprint manager, fully functional!

For this phone this feature is a game changer. If you own one of this great phones, you have to do this flashing and get the fingerprint reader working. You won't regret.

Yet another way to look at technical debt to help with prioritization efforts

There have been many authors proposing different approaches to categorize Technical Debt.
You have Martin Fowler with his TechnicalDebtQuadrant.
Then you have Uncle Bob making a strong distinction between Technical Debt and "a mess", which I happen to disagree with, a mess is also debt.
Then if you read Uncle Bob's article, I like the comment by Mark H where he suggests perfectly good code can "bankrupt" and become debt. I definitively love that concept.


At the end of the day, let's go back to the root of the word debt.
Using the same theme of dissecting a word definition I used on other articles, let's start by using a definition of the word debt straight from Google:

debt

something, typically money, that is owed or due.

So, in short, a debt is something we owe. Legacy code, messy, can be become a debt? O yeah... it can. Is it always "debt"? Absolutely not!

Go back again to Mark H comment on Uncle Bob's post. The key thing to take into account is when legacy code becomes bankrupt. What's the event that triggers its bankruptcy?

So, putting that digression aside, let's risk a definition for Technical Debt:

Technical Debt appears when we ought to do something about a piece of code in order to keep it viable.

Let's look a the three pieces I underlined:

1. Technical Debt appears: The point of this is that not always we do "create" tech debt from the start, nor in a deliberate or inadvertently way (in contrast to Martin's quadrant). Perfectly fine code, as written some time ago, can become a debt after passing thorough a "legacy" stage. When this happens? when we...
2. ought to do something (about the code): If we have code that is perfectly fine as-is. We are good, there's no debt. If we have a piece of code that it's a mess, and it was born as a mess, we got ourselves into credit card debt, unsecured debt (there's not even an asset to back it up). If debt was incurred in a deliberate fashion to accelerate a deliverable, maybe we are talking of a home mortgage or a line of credit. Or, for existing code that became a liability at some point, maybe we are talking a depreciating asset that it's costing us more to maintain that the intrinsic value it provides. Either way, as soon as we have a piece of code that we are forced to plan to take action upon it in order to...
3. keep it viable: we are talking about technical debt. It may happen we have pieces of code that are not "ideal", perfect, algorithms that are not necessarily the best performing for a problem but they are definitively "good enough" in our market or as required by our clients. Are those debt? I would argue they are not debt. A piece of code becomes debt when its viability is in question. A perfectly nicely written piece of code can become debt if suddenly a change in its running platform makes it obsolete or unsupported. The code is great, nicely written, but its viability is in question.

Now that we cleared what is debt (to a degree) from what is NOT debt, let me propose a simple two-way to look at technical debt that should help prioritize paying down.

As with any debt, I like to think it in terms of two types:

1. Neutral
2. Debilitating

Neutral Debt

Why the word "Neutral"? Well, I wanted to use a word that doesn't denote good or bad. Something in the middle. This is in purpose, because personally I believe having no debt will be the ideal we should strive for, yet sometimes we will have to incur on it but definitively I don't want to portray that as a net positive. Therefore the choice of "Neutral" as a word to define it.

What is Neutral Debt?

Neutral Technical Debt is debt that doesn't endanger the product operation nor poses increasing monetary costs to keep the code viable on the short to mid-term.

In another words, we know we have to do something about it, we know it will break down at some point, but at this point in time and for the mid-term (pick your length of time that best fits you) the code will work and it won't be a resource drain to maintain. The code is still an asset, it's doing it's job, yet we know we will have to do something about it "at some point".

Debilitating Debt

Easy. Pretty much negate Neutral Debt and you got Debilitating Debt.
You got a piece of code you find yourself investing time again and again to keep it working. You fix a place, and break five places inadvertently. Each new feature you add the code smells multiple like well fed rabbits. Your backlog is filled with "refactorings" in order to add new features. And all of this is happening right now, and getting worst everyday to the point you can't even think about the long term.

Well, I could keep going on the narrative above. You get the point. Look at the word I used: "Debilitating". With this type of debt, you become weaker every day, you can do less of what really matters because you find yourself on this never ending cycle of fire fighting broken and unwieldy code.

Prioritization

So, when need to do your next technical debt prioritization meeting, try separating it first into Neutral vs. Debilitating debt and only focus on discussing Debilitating Technical Debt to further decide what to do.
Upon the right time there will be pieces of Neutral Technical Debt that get "demoted" (or if you prefer "promoted") to Debilitating Technical Debt. Maybe that's how you start the meeting, quickly go thorough existing Neutral Technical Debt and assess if any entry should be changed to Debilitating.

If you want to get fancy, you can rank them from #1 to #5, with priority #1 being the worst ones, those that get your company hooked in those strong painkillers (being your team the painkillers).

Hope this helps your tackle your technical debt problem.