The Daily WTF

The Daily WTF is a programming-oriented humor blog created by Alex Papadimoulis based on stories about software development and the world of technology. It mainly focuses on anecdotes based on project issues, code examples, and funny stories related to IT. The site contains a vast collection of these real-world experiences by many developers who share their strange and funny encounters at work, both technical or personal, but always connected to related tech.

Thread Of Notes

CdXz5zHNQW_LC8T1Da23x.jpeg
While discussions of bad video game code are rare, they often focus on specialized performance optimizations rather than maintainability issues. A released game, despite being a professional product from a small team, contains a notable config file related to its multiplayer functionality. This config file allows for extensive adjustments to networking parameters.One setting, net_socks_buffer_size, comes with a warning not to change it. Others, like net_max_message_size and net_max_download_frames, require game restarts if modified and must be powers of two. The net_udp_packet_size is set to a large value, with notes on recommended fragment cutoffs and IPv6 requirements. Further settings control UDP packet buffer sizes, including a warning about discarding packets when the receive buffer is full.There's also an option to override operating system recommendations for UDP packet sizes, which could potentially disable networking or crash the game. The decision to disable UDP checksums is presented as an optional, likely unnecessary, feature. Critically, the ability for players to configure these settings implies the potential to launch denial-of-service attacks against other players' network stacks.The config file humorously warns users not to be "a dick" about changing certain parameters. Beyond the networking, a truly alarming setting is sys_ignore_variable_constraints, explicitly labeled as "DANGEROUS AS F*." The author humorously advocates for this dangerous flag to be added to all games and even their own robot software for potentially destructive purposes.
The narrator, a tech support professional, faces a new challenge: a printer in HR that's "printing gibberish." He learns from Tony, the ticket-holder, that the issue is severe enough to warrant an in-person visit. On his way, he briefly reconnects with Aggie, a former mentor who has since been promoted, scheduling a coffee meeting with her. His destination is HR, a department he normally dreads, but he also thinks of Leila, an executive who previously helped him with a difficult case.Upon arrival, he discovers an older man, Tony's boss, attempting to fix the printer with a hairdryer, risking damage to the machine. The narrator intervenes, unplugging the hairdryer and politely but firmly informing the "Hothead" of the potential harm to the printer. He then instructs Hothead to use another printer and promises to resolve the issue himself, while also planning to inform Leila about the incident.After Hothead leaves, the narrator inspects the printer, finding it surprisingly undamaged and fully functional after a series of test prints. He then meets Tony, who confirms Hothead is his boss and expresses gratitude for the narrator's willingness to report the incident to the new head of HR. Tony clarifies that the printer, though old, is "new over here" to their department.Later, during a smoke break, the narrator recounts the morning's events to his colleagues Megan and Reynaldo, showing them the "gibberish" printouts. These pages contain various anonymous HR complaints, such as "I don't feel safe working with Cheryl" and "John keeps staring at me." Megan suggests it might be a network issue, a theory supported by the fact that test prints work fine.Reynaldo, a network admin, recognizes the nature of the printouts, recalling an old, supposedly decommissioned intranet system for anonymous HR complaints. Realizing that the complaints are being unintentionally printed, Reynaldo decides to trace the IP addresses to investigate the source of the issue. The narrator is ready to assist in solving this unusual tech problem.
A legacy finance application contains a C# method, ValueAGPFund, which is criticized for its numerous side effects. This method modifies its input parameters and internal class members, performing multiple distinct operations. It also interacts with a method called CheckPreviousValuationIfRequired. This latter method is designed to retrieve and process previous valuation data based on specific parameters.A significant issue arises from a circular dependency where ValueAGPFund calls CheckPreviousValuationIfRequired, which in turn calls ValueAGPFund. Furthermore, the return statement in CheckPreviousValuationIfRequired is flawed, leading to a NullReferenceException when it attempts to access a null value. This error likely masks the intended logic, which was presumably to recursively call ValueAGPFund only when prior valuation data existed. The current implementation means this function either returns null or throws an exception.Despite these apparent flaws, the application reportedly functions correctly. The submitter suspects that the problematic code, CheckPreviousValuationIfRequired and its interaction with ValueAGPFund, might be redundant. However, they are hesitant to remove it without confirming if it has any unforeseen side effects or if other parts of the system rely on the thrown NullReferenceException. The submitter sarcastically notes that unit tests would typically mitigate such risks, implying their absence or inadequacy. The core problem lies in the complex and potentially broken logic of these interdependent methods.