Forums
Good intentions are never enough. If they aren't coupled with the wisdom to follow through properly, they can result in a horrible mess. Today’s Anonymous submitter has learned this the hard way:
Old Peter’s company has a legend. It has been passed down through generations of programmers and staff through an oral tradition. Oh, from time to time, someone would be inspired to record the tale for posterity, but inevitably, the hard copy was recycled, the digital copy was lost.
It was 1982, and the German tech industry was booming. Old Peter’s company manufactured a line of 8-bit computers that were targeted towards businesses. Their targets were generally larger companies and government organizations- like Frequenzhof Busgesellschaft.
Paulo F was doing a little online banking with one of the largest banks in Brazil. He wanted to buy a pre-paid debit-card. He chose a value from the drop-down, for example R$50,00- fifty Reals. The site promised him a card loaded with R$200,00. It didn’t matter what he chose, the site offered him a completely different value.
Curious, he pulled up the element in the inspector.
"All the news that's fit to print, eh?" Jared S. writes.
Comments are rough. I always take the stance that code should always be clear enough to explain what it does, but you’ll may need a comment to explain why it does that. I recently attended a talk by Sean Griffin (maintainer of Rails) who argued that commit messages should accomplish that goal, since they can contain far more content than a code comment, and while code comments and code can drift apart and cease to be accurate, commit messages are always linked to the point-in-time when they were made. Donald Knuth, on the other hand, might argue that code should annotate comments instead of the opposite.
Regardless of the method we use, I think most of us would agree that code needs some documentation in the same way it needs tests: it should exist, but we don’t want to have to create it.
Let’s talk about maintainability.
Those of you that know me know that in my civillian identity, I work as a SQA professional. QA gets a bum rap sometimes; manual functional testing can be one of the most boring parts of software engineering, but while there’s plenty of button-pushers who will be happy to poke at an application for minimum wage, there’s a lot more to quality than simply functionality. One of the commonly overlooked aspects is maintainability: the ease with which changes can be made to the software system.
Let’s talk a little bit about front-end development. Even at its best, it’s terrible- decades of kruft mixed with standards and topped off with a pile of frameworks that do their best to turn this mess into a cohesive whole.
Jameson is suffering through this, and his suffering is the special level of front-end suffering known as “Angular”. Angular bolts Model-View-Controller semantics on top of HTML/JS/CSS, and its big selling point is that it makes two-way data-binding trivially easy.
"Look like Microsoft really, really wants me to celebrate Windows 10's birthday," wrote Andrew.
As web developers, we spend a fair amount of time protecting our valuable server resources from the grasping tentacles of Internet ruffians and malfeasants. Occasionally, we're tasked with exposing data endpoints to the public Internet. This is generally a carefully crafted solution of whitelists, authentication, authorization, escaping input, limiting access and other protective measures.
Let’s say you have a collection of objects which contain geographic points. You want to find a specific item in that collection, and then extract the lat/lon of that item. You might write code like:
Jul 16
.jpg)
var point = userGeoPositions.Where(x => x.userId = userId);
decimal lat = point.Latitude;
decimal lon = point.Longitude;If you get the rare luxury to start a new project from scratch, there's something deep down inside you that makes you want to do it right. You pick the right people, equipment and tools so that you have the best chance of success. Unfortunately, sometimes incorrect decisions are innocently made and a technical time bomb is placed in the code.
About 20 years ago at Big Money Inc., such a project was started and such a mistake was made. In this case, the mistake revolved around choosing a messaging platform that failed miserably when asked to pump more messages than was intended. The original developers knew not of this otherwise widely-known limitation.
I did a brief contract with Hershey, the candy manufacturer, once. The biggest thing I recall from the experience was that they had bowls full of candy all over the place. You could just grab them by the handful.
I bring this up, because Brenda worked for a pharmaceutical company, and I can only assume that there are bowls full of random drugs scattered around, and someone has been chowing down on them by the handful. That’s the most logical explanation for the following code:
Nick writes, "Well, it just goes to show you - don't under estimate the cultural significance of modal windows."
Imagine you’re a financial institution. You’ve built an application that processes financial transactions, and there are a number of flags that need to be set as constants to determine application behavior.
You might choose to write code like this:
It was Brian’s first day at AutoDetective, a website for comparing listed car prices vs. blue book values. His work inbox was overflowing with style guides, best practices, and notes from the dozen or so other developers he would be working with. His interviewer, Douglas, had mentioned that the site ran on a substantial chunk of legacy code, but Brian had experience with plenty of old code.
He spent most of the day digging through the source, getting a feel for the in-house development style. It didn’t take long before he noticed how … off the code was.
I took my first official programming class circa 1997, and that year was notable, only because it was the last years that class was taught using Turbo Pascal. In future years, it was taught in C++. For the teacher, this was quite the transition. To help her make the transition, at the end of the course, she spent a few days teaching us basic C++, so she’d be more ready for the following class, and we got a little bonus education.
As far as I know, future runs of the class went just fine. I bring this up, because Frank had some co-workers who needed to make the exact same transition, from Turbo Pascal to C++. They may have done it a bit less gracefully. When reviewing some of the C++ they wrote, Frank spotted lots of code like:
In this world, there are those with common sense, and there are managers. In the world of high finance, there are only those with power and those without it. Those who have power make decisions - regardless of their familiarity with the relevant subject matter, or their ability to prioritize things involved in the decision. Those who don't have power (aka: us) live with the aftermath.
James T. joined a major financial company. Because they have over $1B in revenue a year, he was under the impression that these folks knew what they were doing. They paid very lucrative salaries. They all seemed intelligent. They talked a good game about best practices and doing things right. They hit all the right buzzwords during the interview.
"I wonder how many packages end up in rural Alabama?" Andreas wrote.
Today, programmers, let us celebrate all the varied and wonderful facets of code commenting: an art that too few of our brethren bother with, and even fewer master. Those who do stand to leave their mark on untold generations to come!
In lieu of a traditional WTF, I want to use today’s post to talk about the real WTF, or at least the source of all the WTFs we get to write about: our readers.
We’ve got great writers here, and every time I hit “publish” on one of their articles, I’m happy with what’s about to go out to the world. They do a great job building funny, entertaining narratives that highlight some of the unique challenges of working in IT. We get great support from our sponsors, who fund the site and keep it running.
Modern object-oriented languages tend to support the concept of “reflection”. Reflection lets you inspect an object and find out its methods and invoke them dynamically. If you’re building extensible frameworks where you’re handling objects where their type might not be known until runtime, it can be very useful. On the other hand, if you’re using a strongly typed language and find yourself in this situation frequently… you’re probably doing something wrong.
For that reason, when Adam encounters calls to method.invoke() in Java programs, he gets suspicious. So, when he saw this:
SuperFast Performance Monitoring Systems was an ordinary, average production monitoring company, promising to keep an eye on web traffic and alert customers if they needed to scale up their cloud hardware to match incoming demand. Their core product was simple, straightforward, and solid, doing what it claimed to do without incident ... but it wasn't sexy. Enter Wile E. Coyote, Supergenius Programmer, hereafter called Will for short.
