Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Live PD and Living in IT

DZone's Guide to

Live PD and Living in IT

Zone Leader, John Vester, provides insight on how a live-action police television show can apply to the daily lives of an IT professional.

· Agile Zone ·
Free Resource

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.

Earlier this year while driving home from a client visit, I was tuned in to the (Jake) Query and (Derek) Schultz program on my local Fox Sports provider. A topic of the conversation during my drive home was how one of the two hosts had become hooked on a cable television program called Live PD.

Intrigued by what Derek Schultz had to say about the program, I decided to tune in to Live PD that next weekend. The show caught my attention and is something I have scheduled on the DVR when new episodes appear.

What Is Live PD?

According to Wikipedia, Live PD is a "non-fiction program that follows police officers in the course of their duties but is unique in the fact that the footage is being broadcast in real-time, nationally. The program features live video feeds from multiple (usually six) law enforcement agencies throughout the United States."

Basically, teams of law enforcement are performing their duties on Friday and Saturday evenings, from 9:00 pm to midnight (EST), accompanied by a film crew and remote producer. Their actions are recorded live (with minimal delays to sensor personal information, if needed), with the officers educating and updating viewers from time to time.

What Lessons Can We Learn From Live PD?

As I write this article, Live PD is celebrating their first full year of broadcasting the activities of law enforcement around the United States. While I haven't watched the program a great deal over the past year, there are some lessons that I observed during my viewings that can apply to life as an Information Technology (IT) professional.

More Lies Than Truth

Hands down, the most repetitive action I have observed is the inability for those being questioned to be open and honest about their current state. On the show, this can range from the suspect's current activity (what are they up to) to communicating if there are any illegal substances on them or in their vehicle, to being straight-forward about weapons being in the vicinity, to (believe it or not) providing their real identity.

This is really no different in IT.

Consider an example where a production support team has to diagnose an issue with an existing application. With staff attrition and use of external partners, there are times when the only source of truth is the underlying program code itself. Reading through thousands of lines of code can become a daunting task and one that can lead to incorrect results when method names do not reflect current functionality or comments in the code are simply not right (as I noted in one of my favorite articles "Code Commenting Patterns").

This is really no different than an officer trying to quickly ascertain what is valid and what is invalid. Many times, we have limited information and have to make quick decisions, while under the extreme pressure of trying to resolve an issue.

Trying to Cheat the System

When law enforcement responds to a situation, often times it is the result of someone trying to get away with something. Maybe the suspect is in the process of breaking and entering, transporting drugs across state lines, or squatting on a property which they do not own. In these cases, the result is a failed goal of trying to get something for nothing ... or to simply cheat the system.

This idea parallels the often-repeated solution to cut corners as part of the development lifecycle. In my view, the biggest occurrence has to be situations where a lack of unit tests exist for production program code.

The path to this situation is often the same. Planning work begins, with trying to establish a project plan (on Waterfall projects) or a Sprint planning sessions (for Agile projects) - having expectations that every line of code will have a corresponding unit test to validate the desired functionality. As the project begins, unexpected events happen - which can range in a change of direction or additional details being discovered once development is underway. Knowing there is a limited amount of time before the published delivery date, the decision is made to forego the creation of unit tests and focus on delivering as much functionality as possible on the expected due date.

Taking the unit tests out of the development lifecycle is basically trying to cheat the system. The leadership team is basically rolling the dice, hoping every developer kept every requirement and scenario in mind to avoid introducing unexpected results. Like the criminal trying to cheat the system, the resulting approach is a short-term hope with the potential for a long-term disaster.

When You're Caught, You're Caught

I've seen suspects lead teams of law enforcement on pursuits that span a large portion of the three-hour broadcast of Live PD. I have also seen suspects opt to flee the scene, pushing away from the officers and racing into the darkness. In every case, the teams (often employing some pretty amazing K-9 units) capture the suspect without issue. It is at that point that I find it interesting to watch the suspects actions from a psychological perspective. The suspect is caught and their demeanor changes to a calm and far-more subdued behavior.

Within IT, consider the example where a team member introduced logic which led to an unexpected issue. To avoid being associated with the issue, the team member may keep the details behind their actions to themselves, hoping to keep from being caught. While I try to tell my team members to be open and honest about mistakes, that can be a difficult barrier to overcome in the heat of the moment.

Just like the officers on Live PD, the root cause of the unexpected issue will be determined and the person behind the situation is recognized. Based on the severity of the issue, corrective actions can range from a one-on-one discussion to initiation of a disciplinary plan maintained by human resources.

In both interactions with law enforcement and your IT team, honesty is always the best policy and can be a huge time-saver when trying to get to the bottom of an issue.

Conclusion

I wasn't sure if I would enjoy Live PD when it was discussed by Query and Schultz on their Fox Sports talk show program. However, I have gained a better appreciation of the daily activities behind the scores of law enforcement professionals who make our country a safer place. Watching multiple episodes gives one a familiarity with the officers in each area of the country, providing the opportunity to know them on a more personal level.

From a sociological-perspective, Live PD is an interesting view into human behavior, that I believe a majority of viewers would have not otherwise had the opportunity to experience.

Most notably, the show allows me to draw similarities to our world of Information Technology, which is something I always enjoy doing.

Have a really great day!

Take Agile to the next level with DevOps. Learn practical tools and techniques in the three-day DevOps Implementation Boot Camp. Brought to you in partnership with Techtown.

Topics:
application development ,lessons learned ,agile ,agile teams ,company culture

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}