Unit tests have many uses. Primarily, they’re the canary in the coal mine of our code, and alert us when changes are about to go horribly wrong. When Niels’s team saw a recent change broke their unit test, they instantly knew how to fix it.
The submitter of the below code, who chooses to remain Anonymous, recently started a job at a social media company as a software engineer. Seeing that they had never had anyone dedicated to their iOS product before, apparently they were quite excited.
Arrays are one of the most basic data structures. They’re a primitive in nearly every language. In languages like C, they’re low level structures, which represent direct access to memory.
Let's say, hypothetically, that you need a bit of code to create a unique key in a database table that starts with an "N" and it MUST fit within the limits defined by a varchar(20) column.
It was supposed to be simple. The plan was that Alex would temporarily inherit support an old VB e-commerce website for a week while a colleague was out on vacation. With the web being out there for years and years, Alex assumed that most of the old bugs had been squashed leaving him with a nice and quiet week on his hands. As it turned out, Alex had assumed incorrectly.
"When I look at the way that my predecessor wrote his code," Benedikt B wrote, "I can't help but wonder if he understood pointers as well as Kramer understood write-offs."
"I had a pretty good idea of what I was getting into," Christian Riesen wrote, "the company I started at was very forthcoming about their codebase, and how it had grown organically over the past 12 years. I took the job because it would be a challenge to convert it from single files with tons of includes to a to a framework-based approach."
"Lucky me," Ryan wrote, "I got assigned to work on Legacy, an application whose name accurately describes itself. I'm pretty sure that this system manages to have a WTF/line ratio greater than 1.0, especially if we include the 'minor' ones, like the System.Environment.Exit calls peppered throughout library code that causes the app to inexplicably exit."
Simple Date Validation "I'm very fortunate that my new job is at a cool company working with cool coworkers on cool projects," writes Dave via the Submit to WTF Visual Studio Plug-in.
"There are so many things wrong with the project that I'm maintaining," writes Bruce.
"The project was done in C and it was clear the original contractor had no comprehension of function parameters," Aargle Zymurgy writes, "Imagine a source file with 20 functions in it, all modestly complex (between 10 and 40 lines) that only differed from each other by which global variable they operated on. Now repeat for dozens of other modules."
By day, Matthew is a highly-paid consultant that travels around globe helping companies develop and optimize application databases. By night, he's a un-paid consultant for a friend that supports a massive, vendor-provided system that cost well in the six figures. And like many enterprisey systems, the quality is inversely proportional to the price.
Matthew R recently took a team-lead position and was tasked with improving the quality of the company's application. He started with security, specifically the fact that user passwords were stored in plain-text. "But it's easier this way," the developer complained when Matthew suggested to change it, "plus, it's relatively easy to break modern encryption."
Over the years, Armid transitioned from being a full-time developer to a full-time pen tester (as in penetration testing, not pen testing) and he hasn't looked back since. "I did enjoy writing code," he commented, "but there's something really satisfying about demonstrating an XSRF attack to that smug developer who swore up-and-down that his code was perfect." And with things like PCI Compliance to worry about, there are plenty of projects to keep him busy.
We've got two different representative lines from two entirely different systems.
"Not long ago, I was poking around one of our production web servers and noticed the following curiosity in a shell script," writes Marshall G.
"I was hired on to take things over from a fellow named 'Trent', who was known for writing some stunningly awful code," Michael writes, "I was not only to be tasked with rewriting one of our two main software products into a modern language (compared to the VB6 in which it was currently built), but in the short term I was also tasked with maintaining the older versions. "
If there's one phrase that Salvatore could attribute to his predecessor, it'd be fundamental misunderstanding. He had a fundamental misunderstanding of the business requirements. He had a fundamental misunderstanding of how to transform business requirements into code. He had a fundamental misunderstanding of how to write maintainable code. He had a fundamental misunderstanding of tools like source control. He had a fundamental misunderstanding of maintaining a modicum of documentation... even the passwords needed to access the server where the codebase (and production application) resided.
"I was (once again) re-assigned to another old project for upkeep 'n such," Johnny D writes, "and as it so happened, there was a bug. "
"From the first minute of the first hour of the first day of my job," Aaron writes, "I knew I had an epic WTF on my hands."
"In late 2009, I started a new job at a large logistics corporation," Nikos writes, "it was on my first day that I learned that 'quality' and 'best practices' can mean vastly different things to different people. Within my first week, I learned that I should probably ask a lot more questions about the system I will be spending 8 hours a day maintaining. Within my first month, I started counting my days."
There are two development teams at Matt T's company: his group and the other group.
One of the great things about Boolean logic is its simplicity. At the most basic level, there's simply TRUE and FALSE with AND, OR, and NOT. It takes a lot of work to overcomplicate such a simple system, yet "certain" developers seem to find such over-complication second nature. Take E.H.'s colleague, for example.
To say that the codebase at Andy’s client is sub-optimal would be generous. It’s a kludge on top of a kludge that was cobbled together by countless developers over many years. And as with many large and unwieldy information systems, distilling this beast into an understandable form is a challenge superseded only by the actual maintenance of the code.
"At one end of the system," Steve A writes "we have a fairly simple HTML-form that displayed a handful of shipping-related fields. At that the other end, there's a database table that pretty much matches those fields one-to-one. But in the middle.... there's a lot more."
"My company sells access to a massive PHP application that was built a few years ago by The Originals," writes Magnus Bergmark. "The application has everything: slow interface, quirks-mode invalid HTML4, hidden POST forms for every link, you name it."
"Our Senior Architect likes the idea of keeping things simple," Stephen B, "no stored procedures, no parameterized queries... just simple, simple strings."
Several years ago, Dan D’ predecessor, Steve, came to the realization that many of us arrived at one point or another: writing data-access code can get boring and repetitive. To ease the tedium, Steve did what many developers in his position do. He wrote some code to generate a lot of code.
"Years ago," Mark wrote, "and long before I had started working there, the lead developer at my company tendered his resignation and starting up a firm of his own. It was a one-man consultancy built to service a single client: his former employer. They had little choice in retaining his services as, prior to leaving, he intentionally obfuscated all of the code.
Generally speaking, Andrew tries his best to avoid the DBA team. It's not just because database administrators tend to be a unique breed (his colleagues were certainly no exception), but because of the "things" that he'd heard about the team. The sort of "things" that keep developers up at night and make them regret not becoming an accountant.
Having just inherited a mammoth, ASP-based ecommerce application created in a developmestuction by a handful of different consultants over several years, Ryan Davis found himself asking one question, over and over: why?
Most of us web developers will never encounter an HTTP 414 Error. According to the W3C, 414 means:
"I'm as much a fan of Java Generics as the next guy," writes Jim Bethancourt, "why bother with writing all that type-specific code for common collections (or - gasp - losing type safety) when one can simply go HashMap<String, SomeObject>."
“Shortly after joining my new company,” writes Rajesh Subramanian, “they introduced me to The Monster: a massive, incomplete framework written in C++. Its documentation consisted of a few sparse, often contradictory comments. It was designed to be multithreaded, but always crashed with more than one thread. It was expected to run on different operating systems, but never quite made it past Windows 2000 SP3. And naturally, it’s filled with friendly variable names like s, t, pp1, pp2, and so on.”
A little more than a year ago, Nathan T's company decided to outsource a large portion of certain project to a certain country many thousands of miles away. "Even if the code quality isn't as good," one manager would often say, "we'll just pay them to rewrite it and rewrite it again. It'll still be less expensive."
A few years back, Randy A took a contract as a maintenance developer on a wretched abomination of an application. Like those who've stared into the heart of the Great Codethulhu, Randy's retinas are forever burned with code from the system. One line that continues to haunt his dreams is as clear as the day he first encountered it...
Not all of us are fortunate enough to work in "spacious, windowed private office" like the pampered developers over at Fogcreek. At my company (Inedo) for example, developers are constantly trying to figure out, do I get a chair today, or is it my turn to plug-in to the network? While I'm sure your work environments are equally less-than-ideal, not too many can compare with Baughn's experience.
A lot of “certain” developers just don’t like change. They’ll stick to their architecture no matter what, and certainly regardless of the requirements change. Doing any less would compromise the “purity” their design.
John Y recently had to deal with an XML-like dump from a "4D" database. This dump used a peculiar form of abbreviation in which letters were chosen seemingly at random from field names, in order to meet the well known XML limitation of only allowing 5 characters per tag name.
If you aren’t familiar with Serialization in Java, then today is your lucky day! Here’s a quick, crash course in Java Serialization:
Telly B. sent in a representative line that returns database connection information... from the database.
Dave works as a programmer in a small IT department within a large division of a gigantic company. Unlike his company’s Central IT, his division’s IT department doesn’t seem to hire regular programmers. Instead, they take people from within the division that have programming acclimations and stick them on the programming team. Combine this with the lack of a real development process, testing, or even user feedback, and a lot of interesting programs end up in production.
These days, Accessibility is all the rage. I wish I could say it was actually driven by §508 Requirements, W3C Standards, and an all-in-all good faith effort to allow “differently abled” people to access content. But it hasn’t. As long as we, the majority, can access content, that’s all that really matters.
I generally don't publish code from the videogames because I don't believe that code quality is as important in that industry. Short of the occasional patch, once the product is shipped, it's done; there's no ten-year lifespan to worry about.
For those of you stuck at work today, or in one of those 191 countries that don't celebrate Thanksgiving Day today, or -- *gasp* -- actually reading this from home while on holiday, here's a Representative Line that should get you in the holiday spirit. It's the subject of an email sent by the CFO to Mike and the rest of the company ...
Good news, everyone: it's time for a new series! Technically, this is not the first time that I've presented a Representative Line: a single line of code from a large application that somehow manages to provide an almost endless insight into the pain that its maintainers face each day. However, going back and renaming the old articles is a bit of a hassle, so I'll just pretend this is the first episode.