Equifax ... Seriously?
First, there was the breach, then issues were revealed related to a large volume of technical debt. Then, Equifax tried to gain respect only to fall flat.
Join the DZone community and get the full member experience.Join For Free
First, there was the breach that impacted 143 million US citizens. Then issues were revealed related to a large volume of technical debt. Now, Equifax attempts to gain respect in the industry only to fall flat when users attempted to register and use their latest application.
Last September, I wrote about the original security breach with Equifax in an article titled "Equifax Attack: Only a Matter of Time." That event exposed confidential information for 143 million individuals living in the United States. The event led to a swing in stock price from nearly $143 per share before the event all the way down to $93 - a 35% loss in value over a seven-day losing period.
In October, I continued talking about Equifax the "Equifax Issues Continue - Technical Debt at the Core" article - which revealed the cause of the breach was basically due to technical debt not being maintained. What really amazed me was the fact that the Apache Struts framework was still being utilized - something I have long since removed as a primary skill on both my resume and in my LinkedIn profile.
Now imagine being a member of the team at Equifax. You are in the middle of a public relations nightmare and have become the example in the security world of what not to do. You have reached rock-bottom and are in the need to make up ground to prove to the public that your brand is still a valid and trustworthy source. You need a home run, a last-second score, a win in the eyes of the consumer - especially the 40% who had their information exposed not even six months earlier.
I am not sure if the decision was from the marketing team, technology team or executive team - but in early February the idea was posed to create the "Lock & Alert" application that will allow customers to lock their credit reports and was able at no cost. Consumers using the application could keep their credit locked and only unlock it when they are in the process of applying for credit.
To Equifax, this could be a positive image boost to tell their customers, "we are sorry about what happened, but here is a free application and process that will provide some added protection with your personal credit." Even if the application would not make consumers jump for joy or figure them for the avoidable security breach - it certainly should not make things worse.
Well ... not true.
When the Lock & Alert application was released, Sean Gallagher (Ars Technica), opted to download and (attempt to) use the application as part of a follow-up article over the Equifax situation. It turns out the Lock & Alert application was a disaster, here are some highlights:
After filling out the necessary (sensitive) information, the registration process errored out, asking Sean to contact customer support.
Sometime later, on a support call, the technician indicated the account was set up and a new password request would be sent via email ... which never arrived.
Trying to reset the password from the app, caused an "invalid address" message from the application - access to the application was denied.
He re-tried the entire process again ... yielding the same result.
I certainly recommend reading Sean's article, as it will likely cause your jaw to drop from his experience.
Software Delivery 101
In the grand scheme of things, the methodology that a development team utilizes doesn't really matter, as long as quality products are being produced and delivered. I don't have insight into the approach that was used by Equifax for the development of the Lock & Alert application, but I can certainly conclude that the end result which produced the Lock & Alert application was not ideal.
It seems that the most basic task, gathering information from the consumer for the purposes of registering the application for use, was not fully tested. For a long time, this most common flow would be referred to as the happy path. New user registration seems that like a candidate for a happy path flow - especially since every user of the application needs to follow this path in order to use the application.
If the assumption is made that the application was not the problem and that some back-end service (perhaps the database) was the cause for all of these issues, another area of concern springs to the forefront: production support challenges. If the database cannot handle the needs of the application, this is another potential gap in the development process - where the team failed to simulate a realistic load on the application. The fact that Sean Gallagher spent 15 minutes with customer support trying to resolve his issue points out the support team's inability to resolve an issue with a flow common for each and every user.
Regardless of the source of the challenges with the Lock & Alert application, the primary goal for Equifax's latest customer-facing application is far from being met. In fact, the end result of deploying an application which doesn't seem to work correctly further tarnishes their image and reputation with the consumer.
I have had the fortune of working on teams where everyone shares the common goal of delivering a solid solution. At the same time, I have participated in projects where differing goals are trying to be met or teams which are far from being fully engaged. As one might expect, the end results always favor the teams which are dedicated, focused and driven. What confuses me is how the leadership team at Equifax would venture down this road to introduce an application geared at rebuilding their reputation, only to deliver a subpar product - which was obviously not tested and validated prior to releasing to the general public.
Have a really great day!
Opinions expressed by DZone contributors are their own.