Why Would They Make Something That Hurts You?

DZone 's Guide to

Why Would They Make Something That Hurts You?

A Zone Leader talks about the debate on vaccines and how similar views apply to Information Technology.

· Agile Zone ·
Free Resource

Sometimes it hurts, that doesn't mean it's bad!

Living in a country where the idea of "free speech" is a First Amendment Right allows opinions and views to be expressed on a wide array of topics. Sometimes these become hot issues that individuals are willing to become engaged in...at times a bit more extreme than one might expect.

One of those topics is the debate on vaccinations.  While I am not going to provide the details on each side of the opinion, there was one quote that I heard a doctor state when talking to a patient about not wanting to administer a vaccination. The doctor basically asked, "Why would they make something that hurts you?"

You may also like: How to Write Software: 5 Lessons Learned from Running Businesses

Upon hearing that question, I paused. Not because I thought she was 100% correct, but with the doctor's conclusion that nothing bad can ever happen with good intentions. This reminded me of a couple of real-life examples that I have encountered in my career.

SQL Query Gone Wrong

I can recall where a SQL command is executed by a database administrator against a database, which yields results that are not expected.

To validate the query logic, the database administrator ran the query in development and test environments without any issues. Then, when the same query is executed in production, different results are achieved.  

The worst case of this situation is when the unexpected results were not caught immediately. In fact, only after numerous transactions have been executed against the database, the problem is revealed.

At this point, the situation is cumbersome, because there is new data in the system alongside the failed update data to sort through.  

The end result led to downtime for the application.

Using the doctor's approach, this would be like end-users asking, "Why would the individual submit a change that would cause our system to crash?"

Updates That Broke Another Application

While working on a project that utilized seventeen feature teams, the biggest challenge we faced was cross-team communication.

So many items were attempted, including scrum of scrum sessions, but inevitably we ran into issues because one team's actions conflicted with another team's needs. Most of the time, these were small issues that simply caused minor updates, once revealed.

However, the biggest issue was when the feature team was working with the financial department to make changes to some monetary aspect of the application. For years, the design was not right and the team was finally taking steps to correct the situation. The resulting change led to a new data model that was going to be enforced by the team doing the work. All other teams would utilize their API to gain access to this data and perform updates.

Feature teams that were involved with the financial items being changed were in the loop on what was going on. Any integrations they had on their backlog were tabled until the new design was in place.

When the release date arrived, the changes were deployed without any issues with the code deployment. The new financial design was in place and the application was functioning as expected. That feature team had started their planning session for their next set of objects, when calls began to surface to the help center from external users accessing a mobile application.

The help center first seemed to think there was some form of attack being made against the company. This diverted the calls to the security team, who took time to scan all the necessary aspects of their software perimeter — only to not see anything out of the ordinary. This caused the team to dive deeper, because something just did not seem correct.

This continued until late in the afternoon, when a developer of the legacy mobile application finished tracing the older program code. Upon trying to access a table in the database, the developer realized that the table no longer existed. It turned out that the mobile application was directly accessing the table that was removed as part of the financial system redesign.

Like the last example, there was a mountain of new data that had flowed into the new design.  All along, the feature team, product owners and managers agreed that there would be no going back to the old design. Yet, everyone seemed to forget about the mobile application needing the same data.

If the doctor was a user of the application, I believe she would be the first to ask,"why would they intentionally break my application?"


The doctor's comment caused me to pause because the probability for someone to intentionally make something to cause harm to one or more individuals is very slim.  Regardless of one's point of view on that original topic of vaccinations, I think it is disappointing that the comment was made by the doctor - as if to guilt the patient into taking the doctor's viewpoint.

In the examples above, I gave an example of a database administrator who had completed the due diligence to make sure the query was correct.  Something unexpected happened to cause a different result in the final environment.

I also noted how a feature team was dedicated to getting a new design in place for their customer.  They took the necessary steps to inform everyone who was accessing the data through the legacy API before —which was not an easy task to complete.  They did not account for an older mobile application accessing the data directly — through a means that was very difficult to reveal.

People, projects and tasks can end up having a result which is not the true intention or the expectation.  This does not mean there was intentional harm.  Rather, there was simply an unfortunate result.

Have a really great day!

Further Reading

IT Lessons Aren't Just Learned at the Office

A Year of Continuous Deployment: Lessons Learned

Considering Offshoring? Consider These Lessons Learned

agile adoption ,lessons learned ,sql query ,failure ,agile

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}