A DZone Zone Leader takes some inspiration from the latest Call of Duty game to reflect on seemingly obvious performance issues software teams often miss.
Over the weekend, I watched my son (Eric) play the latest version of the Call of Duty series, called Call of Duty WWII on the PlayStation 4 console. He’s owned the game for several weeks now but waited to start the single-player campaign at a time when I could watch him navigate through the storyline. This last weekend was our first opportunity — now that his state-championship winning football season has come to a close.
Before he was old enough to play first-person shooter (FPS) games, I spent some time playing these types of games on the PC. The Call of Duty series was definitely my favorite because so many of the missions were based on real World War II storylines. I wasn’t the best listener while attending history classes in high school, so a great deal of what was presented in the storylines was new to me. When Eric told me that the single-player story begins at the beaches of Normandy, I could not wait to watch.
The gameplay on the PS4 version is amazing, with the graphics showing details that were not imaginable when I played Call of Duty 2 on the PC in 2005. However, there was one cheesy aspect that has remained in this series (among others) that cracks me up. Those bright red fuel containers, always in plain view.
As Eric was working through his mission, he arrived at a point where he had to take out some anti-aircraft (AA) guns, that were hampering the USA’s efforts to control the zone. With a sniper rifle in hand, he zoomed across the landscape to locate the guns. His scope focused on the image below:
I made him take a screenshot and he had to pause the game because he wondered why I was laughing. Did he do something wrong?
It was not him, it was the game.
Next to each of the AA guns were a few bright red containers filled with some explosive liquid. We know this because a) the canisters are bright red, and b) as soon as he launched one sniper bullet into one of the cans, the ensuing explosion eliminated the immediate area.
I was laughing because I don’t get the logic behind this situation.
Imagine you are in the middle of a war. You are trying to defend your turf and know there is an onslaught of troops heading your way. As you set up your heavy artillery, I would think you would do everything to make your area as impenetrable as possible. To me, that would include not leaving the bright red fuel containers in plain view — right next to your very important AA guns.
But in the Call of Duty series, the single-player modes often leave these canisters in clear view — making for an awesome explosion and for an easy way to complete the task at hand. While it doesn’t seem to make sense that war-trained soldiers would make such a simple mistake, I started to wonder if there are any “bright red fuel containers” sitting around in a typical application development endeavor.
When developing a new application, the team performing the development often has the convenience of a local instance of everything they need to make development fast and productive. Sometimes this even includes the database. While this is great, a false sense of comfort can exist from working in isolation. One common example in the past was related to database pool size. Basically, the application would perform well during development, unit testing, and even non-production testing because the load on the application was not large enough to reveal any issues.
However, once the application was deployed into production and began to see peak usage levels, the bright red fuel containers became evident… when the application began to crash — or explode (to maintain the same metaphor).
Open Source frameworks are great, as they allow development teams to avoid having to create common operations and allow them to focus on writing business logic to meet their current needs and requirements.
However, these same frameworks can contain an unexpected vulnerability that can cripple or destroy a business. Need an example? How about the Equifax situation that rose to Internet fame earlier this year, all based upon an unpatched vulnerability with the Struts framework? In this case, the bright red fuel container was inherited unexpectedly by a team that had viewed Apache’s open-source framework as bug-free.
The last bright red fuel container can be as simple as a missed requirement. As odd as that may sound, it is possible that a missed requirement can lead to an explosive impact on your application. All it takes is for the developer and tester to not realize that the requirement was not completely understood and the business user to avoid fully validating the scenario.
Perhaps, this is a gap in the process to complete a task — like marking an aspect of the application as inactive. For the developer and tester, they understood the requirement as removing the record from the application, while the actual need was to set a flag to mark the record as inactive. While testing, the need is being met. Since there is not a way to mark the aspect as active, the issue would not arise until down the road, when a request is created for an Inactive Report. At this point, the developer and tester would return to the application owner confused, wondering how they can write a report based on deleted data.
I believe I will always smile when I see those bright red fuel containers in an FPS game, as they make me wonder why someone would carelessly avoid hiding the devastating explosives from plain view. Still, the explosive effect is always impressive.
However, after thinking things through, I am sure the development team for the FPS missions could say the same about the code I have written or experienced, based upon things like application configuration issues, vulnerabilities, and missed requirements. Here, the explosive effect is not-so-impressive.
Have a really great day!
