In the bowels of a business unit, a director got a great deal on a third party software package. He bought it, without talking to corporate IT, and then was upset when it couldnt gracefully integrate with any of the corporate IT assets. Eager to throw good money after bad, the director hired his nephews consultancy to build an integration tool to make his new toy work.

A few months later, the users complained about performance, and somehow, fixing this thing became Jeffs problem. The process was simple enough: slurp enterprise data out of a text file, and pass the data on to the third-party tool. It didnt take Jeff long to figure out why it performed poorly:

Private Sub ProcessFile()

    ' prepare to do stuff

    Do Until blnLastTime = True
        
        Set fileReader = fso.OpenTextFile(strFileName)
        
         If fileReader.AtEndOfStream = True Then
            blnLastTime = True
         Else
            strTextLine = fileReader.ReadLine
         End If

        ' actually do stuff
         
        fileReader.Close
        Delete_Line (strFileName)
    Loop
    fileReader.Close

End Sub



Private Sub Delete_Line(strFile)

    Set fileReader = fso.OpenTextFile(strFile)
    
    If fso.FileExists(strFile & "2") Then
        fso.DeleteFile (strFile & "2")
    End If
    
    Set fileWriter = fso.CreateTextFile(strFile & 2)
    
    If fileReader.AtEndOfStream = False Then
        fileReader.ReadLine
    End If
    
    If fileReader.AtEndOfStream = False Then
            strLine = fileReader.ReadAll
            fileWriter.Write (strLine)
    End If
    
    
    fileReader.Close
    fileWriter.Close

    fso.DeleteFile strFile, True
    fso.CopyFile strFile & "2", strFile, True
    fso.DeleteFile strFile & 2, True
    
End Sub

Start by opening a file foo.txt. Read a single line from the file. Send it to the third party app. Close the file. Open foo.txt again. Open another file, called foo.txt2. Read the first line from foo.txt, again. Throw that away. Read the remainder of foo.txt, and write it to foo.txt2. Copy foo.txt2 back over foo.txt. Now, go back to the top of the loop and read a single line from foo.txt again.

So, for a 10,000 line file, this would perform 30,000 file open operations, write nearly 50 million lines, delete 20,000 files, and perform 10,000 copy operations. It didnt take Jeff very long to rewrite this to simply read the file, one line at a time. The runtime dropped from a few hours to less than a minute.

http://thedailywtf.com/Articles/Line-by-Line.aspx

Back in early 2000, Clint interviewed for a position as a software developer for a mid-sized engineering company of about 200-plus people somewhere in the deserts of Kerblekistan, located in very close proximity to the Elbonian mud fields. Everyone there, especially the women, was used to living in harsh conditions, and had grown extremely rugged as a result. The Kerblekistanis and Elbonians had been enjoying an uneasy peace, but kept a wary eye out for less-than-peaceful activities...

During the interview, the development team was ready to hire him when one of the bosses burst into the room and interrupted the interview to introduce himself. When he discovered that Clint had an IT background, he became very excited. They temporarily needed a network administrator until they could hire someone permanently, so for the first three months, Clint was assigned to be a network admin.

To further complicate things, the team was moving to a new office. Two new network administrators were hired, one of which Clint had worked with elsewhere. Since both had extensive experience in managing office moves, they were given the task of continuing to coordinate that, while Clint maintained the day to day network tasks. Since the new guys would ultimately be running the network, he gave them the luxury of modifying some of the plans to suit themselves.

A few weeks before the move when it was time to get the communications set up, there arose a heated debate between the two admins about where to set up the servers.

The new office had two floors. On the lower floor, a receptionist who was built like a tank and could have single handedly replaced the Pittsburgh Steel Curtain, sat directly in front of the main entrance. She was the secretary, receptionist and security. Right behind her was a large air conditioned area where power and communications came into the building. Directly above this room was a small office without any special A/C, power or communications set-ups, which was to be the administrators' office. Before the two admins were hired, Clint had placed several server racks in the big room downstairs.

Both new admins had installed the racks, but new admin B was not happy; he wanted the server racks to be installed in the small room on the second floor (the new IT office). Admin A wanted them left downstairs where they were already located because the small office upstairs was barely big enough for two people, let alone several racks of noisy servers, plus A/C that would have to be added.

  Admin-B: We can't have these racks downstairs; what if the Elbonians attack 
           through the front door?
  Admin-A: The receptionist is in front of the door, and nobody gets 
           past her without a pass!
  Admin-B: These racks need to be upstairs; this way if the server room is 
           destroyed, they'll be safe - with us
  Admin-A: If the room downstairs blows up, what makes you think we will survive 
           directly above it? Besides, how much damage can a wad of mud really do?
  Admin-B: But they've been ramping up their weapons and supplies; we need to be ready!
  ...

The debate was still raging when Clint arrived at the new office with two owners of the company (one Elbonian, one Kerblekistani) in tow, to check on things. Neither admin noticed Clint or the owners walk in.

  Admin A: There is no security issue. These doors are solid and they lock!
           The servers are not going to be any more secure on the second floor.
  Admin B: (sounding like a belligerent child)
           Yes, but those doors are not bazooka-proof. The owners are Elbonian 
           and Kerblekistani - you never know what might happen!

Rather than take offence, both owners decided to have some fun with the situation...

  Owner E: Our mud-bombs could certainly penetrate this door!
  Owner K: Perhaps, but you'll never get them past my secretary - 
           Nothing gets past her - NOTHING!
  Admin A: Um, what the f...?!
  Admin B: Now do you see why we need to keep these servers upstairs?
  Owner E: I am positive our new Mud-a-Pult™ has both the range and 
           power to penetrate the upstairs office
  Owner K: Then I suppose I'll have to call up the reserves from the office pool
           to back up my secretary
  Admin B: (sounding significantly less belligerent)
           W..W..Wait - are you serious?

As the owners wandered away while pretending to still argue, Clint brokered a compromise where only the rack with the more important mission-critical servers was to be located in the upstairs office, safe from the mud-people. The other servers would stay in the server room, protected by the locked door, and the receptionist, who thankfully would never know that she was the first line of defense.

Foter / CC BY

http://thedailywtf.com/articles/Bazooka-Proof

Back in early 2000, Clint interviewed for a position as a software developer for a mid-sized engineering company of about 200-plus people somewhere in the deserts of Kerblekistan, located in very close proximity to the Elbonian mud fields. Everyone there, especially the women, was used to living in harsh conditions, and had grown extremely rugged as a result. The Kerblekistanis and Elbonians had been enjoying an uneasy peace, but kept a wary eye out for less-than-peaceful activities...

During the interview, the development team was ready to hire him when one of the bosses burst into the room and interrupted the interview to introduce himself. When he discovered that Clint had an IT background, he became very excited. They temporarily needed a network administrator until they could hire someone permanently, so for the first three months, Clint was assigned to be a network admin.

To further complicate things, the team was moving to a new office. Two new network administrators were hired, one of which Clint had worked with elsewhere. Since both had extensive experience in managing office moves, they were given the task of continuing to coordinate that, while Clint maintained the day to day network tasks. Since the new guys would ultimately be running the network, he gave them the luxury of modifying some of the plans to suit themselves.

A few weeks before the move when it was time to get the communications set up, there arose a heated debate between the two admins about where to set up the servers.

The new office had two floors. On the lower floor, a receptionist who was built like a tank and could have single handedly replaced the Pittsburgh Steel Curtain, sat directly in front of the main entrance. She was the secretary, receptionist and security. Right behind her was a large air conditioned area where power and communications came into the building. Directly above this room was a small office without any special A/C, power or communications set-ups, which was to be the administrators' office. Before the two admins were hired, Clint had placed several server racks in the big room downstairs.

Both new admins had installed the racks, but new admin B was not happy; he wanted the server racks to be installed in the small room on the second floor (the new IT office). Admin A wanted them left downstairs where they were already located because the small office upstairs was barely big enough for two people, let alone several racks of noisy servers, plus A/C that would have to be added.

  Admin-B: We can't have these racks downstairs; what if the Elbonians attack 
           through the front door?
  Admin-A: The receptionist is in front of the door, and nobody gets 
           past her without a pass!
  Admin-B: These racks need to be upstairs; this way if the server room is 
           destroyed, they'll be safe - with us
  Admin-A: If the room downstairs blows up, what makes you think we will survive 
           directly above it? Besides, how much damage can a wad of mud really do?
  Admin-B: But they've been ramping up their weapons and supplies; we need to be ready!
  ...

The debate was still raging when Clint arrived at the new office with two owners of the company (one Elbonian, one Kerblekistani) in tow, to check on things. Neither admin noticed Clint or the owners walk in.

  Admin A: There is no security issue. These doors are solid and they lock!
           The servers are not going to be any more secure on the second floor.
  Admin B: (sounding like a belligerent child)
           Yes, but those doors are not bazooka-proof. The owners are Elbonian 
           and Kerblekistani - you never know what might happen!

Rather than take offence, both owners decided to have some fun with the situation...

  Owner E: Our mud-bombs could certainly penetrate this door!
  Owner K: Perhaps, but you'll never get them past my secretary - 
           Nothing gets past her - NOTHING!
  Admin A: Um, what the f...?!
  Admin B: Now do you see why we need to keep these servers upstairs?
  Owner E: I am positive our new Mud-a-Pult™ has both the range and 
           power to penetrate the upstairs office
  Owner K: Then I suppose I'll have to call up the reserves from the office pool
           to back up my secretary
  Admin B: (sounding significantly less belligerent)
           W..W..Wait - are you serious?

As the owners wandered away while pretending to still argue, Clint brokered a compromise where only the rack with the more important mission-critical servers was to be located in the upstairs office, safe from the mud-people. The other servers would stay in the server room, protected by the locked door, and the receptionist, who thankfully would never know that she was the first line of defense.

Foter / CC BY

[Advertisement] Have you seen BuildMaster 4.3 yet? Lots of new features to make continuous delivery even easier; deploy builds from TeamCity (and other CI) to your own servers, the cloud, and more.

http://thedailywtf.com/Articles/Bazooka-Proof.aspx

We've all seen it before. I dare say we've all been a party to it.

First, we look at a block of code that needs to be modified. Then we determine which criteria needs to be added to address the case that we've been tasked to implement. Next, we add the condition and walk away before the waft from the code smell reaches our nostrils. Over time, a monstrosity like the following arises from the depths. Not something that couldn't be greatly improved by some fava beans and a nice refactor. I'm sure the unit tests that cover your production code base will ensure that your refactoring was successful. Right? Right??

Photo credit: Foter / CC BY-SA

http://thedailywtf.com/articles/We-Dont-Need-no-Stinking-Elses

We've all seen it before. I dare say we've all been a party to it.

First, we look at a block of code that needs to be modified. Then we determine which criteria needs to be added to address the case that we've been tasked to implement. Next, we add the condition and walk away before the waft from the code smell reaches our nostrils. Over time, a monstrosity like the following arises from the depths. Not something that couldn't be greatly improved by some fava beans and a nice refactor. I'm sure the unit tests that cover your production code base will ensure that your refactoring was successful. Right? Right??

Photo credit: Foter / CC BY-SA

http://thedailywtf.com/Articles/We-Dont-Need-no-Stinking-Elses.aspx

"These car shades I found at Walmart were made especially for the American market," Bryan W. writes, "I mean just look - they work much better in Fahrenheit than in Celsius."

"Hmmm...I wonder if Github might be trying to tell me something here," writes Stefan.

Brick wrote, "In a way, I guess that the United States isn't technically in the US."

"I hadn't run the app in a long time, but it looks like I under estimated just how long that had been. I wasn't aware this app was created by the Ardipithecus," writes Paul F.

"Now you're playing with power...The power to prevent cavities and gingivitis!," wrote Ryan P.

Thomas writes, "When I got up this morning, I didn't think that a 'checking hard disk for errors' screen would be the thing getting between me and fueling up my car."

"Looks like a hard-drive crash in a London Underground station," wrote Tom, "Maybe the BIOS is simply accessing the...wait for it... wrong track."

And, rounding out a trio of error screens, it looks like Dmitriy has a sale on Windows error codes today.

http://thedailywtf.com/articles/Do-the-Math

"These car shades I found at Walmart were made especially for the American market," Bryan W. writes, "I mean just look - they work much better in Fahrenheit than in Celsius."

"Hmmm...I wonder if Github might be trying to tell me something here," writes Stefan.

Brick wrote, "In a way, I guess that the United States isn't technically in the US."

"I hadn't run the app in a long time, but it looks like I under estimated just how long that had been. I wasn't aware this app was created by the Ardipithecus," writes Paul F.

"Now you're playing with power...The power to prevent cavities and gingivitis!," wrote Ryan P.

Thomas writes, "When I got up this morning, I didn't think that a 'checking hard disk for errors' screen would be the thing getting between me and fueling up my car."

"Looks like a hard-drive crash in a London Underground station," wrote Tom, "Maybe the BIOS is simply accessing the...wait for it... wrong track."

And, rounding out a trio of error screens, it looks like Dmitriy has a sale on Windows error codes today.

http://thedailywtf.com/Articles/Do-the-Math.aspx

While trying to assign an address from his framed /29 route to the internal side of his Linksys AM300 router, Phillip S. received an unexpected "Local IP Address is not valid" error.

Being a web script error, Phillip correctly figured that he could dig into what condition would make the address come up as invalid. Turns out, his problem was that the router considers any IP address starting with 115 to be invalid, but Phillip found that there were a few other instances of hard coding and magic number abuse. On a positive note, at least it's not device-side code.

/* IANA Reserved IP */
if (((sub_addr[0] >= 0) && (sub_addr[0] <= 2)) || sub_addr[0] == 5 || sub_addr[0] == 7 ||
  sub_addr[0] == 23 || sub_addr[0] == 27 || sub_addr[0] == 31 || sub_addr[0] == 36 ||
  sub_addr[0] == 37 || sub_addr[0] == 39 || sub_addr[0] == 42 ||
  ((sub_addr[0] >=92) && (sub_addr[0] <= 120)) || sub_addr[0] == 127 ||
  ((sub_addr[0] >= 173) && (sub_addr[0] <= 187)) || sub_addr[0] == 197 || sub_addr[0] >= 223)
    return false;

if(sub_addr[0] < 128) /* A class */
{
  if(sub_addr[0] == 0 || sub_addr[0] == 127)
    return false;
  host_id = sub_addr[1] * 0x10000 + sub_addr[2] * 0x100 + sub_addr[3] * 0x1;
  if(host_id == 0 || host_id == 0xffffff)
    return false;
}
else if(sub_addr[0] < 192) /* B class */
{
  host_id = sub_addr[2] * 0x100 + sub_addr[3] * 0x1;
  if(host_id == 0 || host_id == 0xffff)
    return false;
}
else if(sub_addr[0] < 224) /* C class */
{
  host_id = sub_addr[3] * 0x1;
  if(host_id == 0 || host_id == 0xff)
    return false;
}
else /* Limit broadcast, Multicast net */
{
  return false;
}

http://thedailywtf.com/articles/IP-Address-Denial

Our long-time friend, GRG, is back again, this time with tales of anti security...

A very long time ago, he worked at a University Computer Center. At the time, the school was the proud owner of two huge, hulking mainframes. (The faster of the two was big, gray, probably designed by a guy named Seymour, and was the fastest computer in the world for several years!) Unfortunately, the operating system was rather bare-bones. Thus, although you couldn't do much, you could do it without fear of the OS getting in your way. For example, you could store files (one directory per user), compile FORTRAN or COBOL or Pascal programs, or run SPSS, and that was about it. Unless you were willing to creatively think outside the box...

Also, another side effect of the bare-bones nature of the system, the security was a bit...weak. All the usernames, passwords, and permissions were kept in one unencrypted binary file. If you could get hold of that file, you had all the keys to the kingdom.

The system helpfully provided an ordinarily very useful feature where by if a program aborted, the system would keep the program's current files attached to the job. An interactive session was one long "job", so if you interrupted, say, the password change program, you would find the password file still attached to your job and you could read it at your leisure. Even more helpful, the dump program printed out 8 words per line which was the exact binary record length of each validation record. Thus, you could get a nice printout of the validation file with almost no effort at all.

After a while, the admins patched up this hole, sort of, by having the password program turn off terminal interrupts. That worked for about three days, until someone figured out that they hadn't turned off the "CPU time limit exceeded" abort. If you set your CPU time limit to 1 second, then ran a program that used up something like 0.990 seconds, and then chained to the password change program, the time limit would expire inside the password changer and you'd have the password file again. This state of affairs lasted about a month, but sadly, it too got patched.

Then somebody noticed that the operating system tried to be efficient, and if you had some FORTRAN "blank common" area, neither the OS nor the loader would initialize that area, so you'd see all kinds of garbage in your blank common. Sometimes you'd see data from other programs, editor buffers, and such. Hmmm, so you could peek at abandoned memory... Sure enough, if you ran the password changer and then dumped blank common, you could see the the I/O buffer that the password program used. It was conveniently 1024 words long so you'd have a peek at the 128 usernames and passwords around your username at a time. Handy.

Not to be outdone, someone else thought Hmmm, I wonder how they keep the password files synchronized between the two mainframes? This was before Ethernet, but both mainframes had access to a big box of extended memory... perhaps they passed the password file back and forth through that? It turns out the system came with a useful utility program named "DUMPECS" (Extended Core Storage). All you had to do was change your password and quickly type "DUMPECS" and you'd see the whole validation file printed out. They didn't clear ECS after each use. And conveniently the password file transfer happened at the same address in ECS that you'd get from DUMPECS. *Joy*

That went on for a few more months before ECS started returning all zeros on the first read. Darn. Then someone noticed that the regular usernames did not work during "system time", after midnight. Hmmm, how did they do that? The system wasn't very flexible, so they probably had to copy the real validation file to somewhere else and copy in a special validation file with just staff usernames. If you were lucky and they were a little bit tired at 6AM, they might copy the full file back but forget to delete it. Or they might forget to make it a private file. Or they might forget to password protect it. Anything can happen at 6AM. Sure enough, one morning there was a file called VALIJUN in the system directory, but it was password protected. Very clever. However the first password someone tried ("NUJILAV") worked!

There were other ways too. If the system got slow it was often due to disk backups to tape being run, and that left open the opportunity to watch for the tape operation finishing. With a little luck you could request the backup tape and the operator might be too lazy to check whether it was actually the backup application re-requesting the tape. Of course, the disk backups were unencrypted, and the first stuff on the tape was the system directories.

They never went to encrypted passwords. They couldn't because the account validation code ran in some small peripheral processors with 4K of memory. Not a lot of room for encryption code there.

Not a problem, though, because only trusted personnel could access the system.

http://thedailywtf.com/articles/Oh-So-Secret-Passwords

Jonathon recently got a new co-worker who is an enterprise systems developer, with an emphasis on enterprise. For an enterprise-level WTF, todays code is short, but it packs itself up with everything it could do wrong.

using System;

namespace Business.Common.Services
{
    /// 

    /// Guid service.
    /// 
    public class GuidService : IGuidService
    {
        /// 

        /// Initializes a new instance of the System.Guid structure.
        /// 
        /// A new GUID object.
        public Guid NewGuid()
        {
            return Guid.NewGuid();
        }
    }
}

You might say, wheres the WTF? To which I reply, everywhere! The number of things this developer did to annoy me, in such a tiny space, is amazing.

Lets start with the comments. Look at those comments. They provide no information. Why should they? The class provides no functionality, either! Itd be one thing if this service was an attempt to patch the fact that JavaScript has no native GUID functionality, but this code isnt called by JavaScript- its consumed by other services in Business.Common .

Speaking of: Business.Common. Business.Common. For some reason, enterprise developers think this is an acceptable naming convention for their enterprise code. I suppose once youve adopted an n-tier architecture, it doesnt really matter whats in those tiers any more.

Theres a psychological effect where, if you say the same word over and over again, your brain stops thinking about it as a word and it just becomes a meaningless jumble of noise. Try saying this aloud: The GuidService implements the IGuidService contract, and contains a method NewGuid which returns a Guid generated by the static NewGuid method on the Guid class.

---

For the Pittsburgh readers, Remy's "Technical Storytelling" workshop is less than two weeks away, and seats are filling up fast. He's teamed up with master storyteller Kevin Allison. Learn how storytelling, combined with a technical perspective, can make you better at your job and advance your career. For a taste of what we'll discuss, check out these essays: Characters and Personification, Failing Upwards, Driving Change, and Detail Oriented.

http://thedailywtf.com/articles/Enterprise-GUID

Organizing a small development team is an art. Organizing a large team is a challenge. Organizing a global team, scattered across eight countries and four continents is a job for Sisyphus.

Scalis company was in exactly that situation. Their self-appointed Sisyphus was actually named Steven. Stevens slot on the org-chart was Chief Application Architect for the Australian Region, or CAAAR for short.

Aguja Hilo 1 by Jorge Barrios

After a few successful projects, Steven started chatting with upper management. He made promises- if he ran all software development in the world, every project would go perfectly smooth. Theyd deliver more, on tighter timelines. He just needed to be given a little bit more power.

Steven got a little more power. He decreed that everyone in the world would use an Agile methodology. Contrary to Agile principles, this would be imposed from above, teams would all be forced to adhere to standard policies and forbidden from self-organizing. Since all of the existing policies couldnt be re-written, every team would also have to follow the Waterfall process while being Agile.

The transition didnt go well, but Steven pointed out that he simply hadnt been given enough power to do the job correctly. If they let him set a few more policies…

His next decree was to throw away their existing VCS and move everyone over to Git. The distributed nature would better support being Agile. Of course, they also had to comply with old policies, so one central repository was configured. With an associated build and integration server, code could only be released through that repository. It lived in Australia, of course.

Steven was a generous dictator. He provided a set of Ruby programs and build instructions that allowed each local office to set up their own build/integration server. There was no budget for new hardware, so most offices had to make do with whatever desktop machine was sitting in an unused cubicle at the time. Scali was no exception here, but his build server immediately started showing problems.

While the box wasnt beefy, any time Scali tried to test their core product on it, the entire server fell face down in the dirt and started thrashing like a child being told it was bath time. Scali asked Steven to take a look.

Well, it works on our server, Steven said. You must have broken something during the install process. Wipe the machine and do it again.

Scali wanted to argue the point, but knew he couldnt possibly win. Steven was the CAAAR after all. Scali redid the install, documented the entire process to prove he followed the instructions exactly. The problems remained, and Steven continued to blame Scali.

Scali ran the same tests against the canonical server in Australia, and while it didnt fall over and scream, it took far too long to run the tests- before switching to Stevens scripts, the process only took about 30 minutes. It was almost like the scripts were the problem…

Scali didnt have commit permissions on that code, but he branched a copy and took a look. He didnt really know Ruby, but with basic programming knowledge and some searching, he could get a feel for what it did. It didnt take long for him to spot the problem.

For each unit test in the project, the script spawned a new thread to execute it, then handed that pile of threads off to a test runner that spawned a few of its own threads to do the job. With their gigantic, enterprise-ready code-base, this could mean thousands of threads. It was, in essence, a fork-bomb that could cripple any machine given enough time. The only reason it worked in Australia was that their machine simply had more resources to bring to bear.

With a few more searches and some careful programming, Scali made the script smarter. Instead of blindly spawning threads, it managed a pool. The size of the pool was controlled by an environment variable called MAX_UNIT_TEST_THREADS, and the active pool landed in a variable called unitTestProcesses. The changes were simple, well documented, and well tested by the time Scali was done. And the tests! Even his crappy build server could complete the tests in 35 minutes. With some help from an Australian peer, the whole thing only took 15 minutes on the canonical server.

Scali showed his work to Steven. I appreciate what youre trying to do, but we cant deploy this. Its not up to our coding standards. Look here, just at naming conventions. MAX_UNIT_TEST_THREADS sounds like the total number of possible threads, when its really the total number of simultaneous threads. And unitTestProcesses is a list that contains threads, not processes. This is far too confusing and youve made my script unsupportable. But dont worry- I do recognize that there are some performance issues, and Im going to be releasing a script that performs better in the next few weeks.

Scali did his best to appeal the decision, but Steven was the CAAAR and had momentum on his side. Within a few days, Steven released his fixed script. In what was probably a coincidence, it was almost exactly like the script Scali had shown him. Almost. After all, Scalis script didnt depend on a variable named MAX_SIMULTANEOUS_UNIT_TEST_THREADS, nor did it have a variable called executingUnitTestThreads.

http://thedailywtf.com/articles/Threadbare-Down-Under

Mark H. wrote, "Despite being a company that specializes in shipping orders, I guess Tiger Direct has no idea which zip codes are in which cities."

"So...did it miss the last flight?" asks Mike D.

"Not sure what's going on with Hearthstone here," wrote Petrea M., "Maybe everyone at Blizzard got distracted?"

"If you run out of RAM and you're using Safari, it turns out that Apple has a special crash error for that," Andrew F. writes.

"While searching IBM Knowledge Center I found what seems like many line breaks - but where's the error?" Oliver wondered.

"Unfortunately it didn't cross my mind to try and add it to the cart until afterwards," writes Tim.

Marc writes, "Really, Yahoo? I know you're only trying to help protect my account but this is ridiculous!"

Kendall wrote, "This consistently appeared for times over 1 day."

http://thedailywtf.com/articles/The-Post-Office-is-Wrong

Back in July, I wrote about my disdain for ternary operators citing a monster representative line as being a great example of an attempt at cleverness gone too far.

Well, an anonymous submitter sent our way another ternary operator disaster but with a twist - nested within the call to "payRecordsList.Add", almost every parameter passed has its own ternary operator added.

payRecordsList.Add(payRecord.DateLeft == null ? includePayrollIDinResult == false ? string.Format("{0:dd/MM/yyyy} to Present : {1} ({2})", payRecord.DateStarted, payRecord.Department.PayrollCompany.CompanyName, payRecord.PayFrequency) : string.Format("{0:dd/MM/yyyy} to Present : {1} ({2})", payRecord.DateStarted, payRecord.Department.PayrollCompany.CompanyName, payRecord.PayFrequency) + "|" + payRecord.Department.PayrollCompanyID : includePayrollIDinResult == false ? string.Format("{0:dd/MM/yyyy} to {1:dd/MM/yyyy} : {2} ({3})", payRecord.DateStarted, payRecord.DateLeft, payRecord.Department.PayrollCompany.CompanyName, payRecord.PayFrequency) : string.Format("{0:dd/MM/yyyy} to {1:dd/MM/yyyy} : {2} ({3})", payRecord.DateStarted, payRecord.DateLeft, payRecord.Department.PayrollCompany.CompanyName, payRecord.PayFrequency) + "|" + payRecord.Department.PayrollCompanyID, payRecord.ID);

You know, I have to hand it to the developer responsible - this is quite a feat of complex software engineering. However, if you figure that this representative line is only one of many similar function calls in the application, then well, let's just say I hope that the code never breaks. Or needs updated. Forever.

http://thedailywtf.com/articles/Ternary-Operator-Nesting-Syndrome

Trying to advance yourself in your career is really tough. Usually, if you want things to go your way, either you have to work really hard at it or pray that you know someone who might be willing to assist on your behalf.

Well, if the email that Dhruv received is any indication, you can forget about all that stuff. Yep, here's proof that, sometimes, opportunities just fall out of the sky.

---

I am a serial entrepreneur who has made millions, on paper and in the real world.  I'm abt to give your skills a real life chance to make a difference and just maybe help create one of the great Internet legacy companies of all time..

It's not often you get a chance to change the world, to be a part of something that will resonate with (potentially) hundreds of millions of people all over the world.  This is that opportunity...right here and now.

Candidly, we need engineering help to build something extraordinary, futuristic in vision, massive, disruptive, even game changing.....It's been described as "Iron Man" Like, very cool, amazing.

Below info from the article abt Tablets in WSJ--Thursday, July 24, 2014 When the late Steve Jobs introduced the first Ipad in 2010, he acknowledged that many people already had a smartphone and a laptop computer.  "Is there room for a third category of device in the middle?", he asked.

We all know the answer given by both Apple and the universe of customers enjoying the product, but we would have to ask the question again slanted toward Quantum (temp name only).  Is there room for a fourth category of device positioned not really in the middle, more like to the sides?

WE see this as opportunity for the 4th category.  Our product will position itself as a next generation communication device designed to provide ultra value married to ultra convenience and be futuristic and cool.  In fact, the best words that describe what we have are VALUE, CONVENIENCE, and COOL.

We are looking for an outstanding tech team to help build this....engineers with the right acumen who can think outside the box to revolutionize an industry.
C++
electrical
mechanical
hardware
nanotechnologist
systems

that's why we are writing you.  You know people; you yourself could participate or simply direct us to sources who could engage.  
We would ask you to consider joining us and in the process, help create countless jobs and untold fortunes for many.  Our compensation will be most generous and the opportunity is beyond the pale if we have what we think we have.

AS a point of credibility, bc I realize I'm just an amourphous email at this point, I am sending you my trophy home I built for $8MM (land was 6MM) and was worth at one point 29MM.  

I started my RE empire (in Aspen) with only $10,000.  $10,000...that's it!  THe Company achieved a value at its height of $150MM with 350 employees.  Not so bad for a guy who knew nothing at all abt RE from an educated or pedigreed basis.

Yes, I got crushed in the meltdown and lost everything; that is true. But one of my gifts is seeing things ahead of the curve...a most valuable gift indeed.

Today, I see enormous value here, in this technology company.  I may be wrong, of course, but if I am right, if my compass is "on", then the upside is 100 homes like this one, maybe even a 1000.

AS a sidebar note relative to my vision skills, I tried to buy Marvel, as in Marvel comics...for $100MM...would have been worth $26Bn today, ---By the way, no one on Wall Stret saw the value at the time..as in "no one."----and then there was a roll up of disparate insurance companies...another billion dollar plus play.

Moreover, I brought in Food Billionaire Loida Lewis (Beatrice Foods) and tried to buy Whole Foods with a bankrupt Wild Oats in 2000 to actually "own" the organic food marketplace in the US.  (The reverse actually happened).

I understand you're in academia but there is more of a crossover to technology companies than ever before.  If you're up to it, and if you wish to test your bandwdith and belong to something potentially life changing and legacy building...call me and lets discuss our company and where your talents could apply.

The guy who painted the mural for FB made $500MM for a $65,000 mural...$500MM.....the upside here is so staggering as to defy all description if we can get Product to market first and capture market share. 

Once again, quite candidly, we need a "Mark Zuckerberg" and the team that effectuates vision into reality...
my very best

*name removed*

http://thedailywtf.com/articles/Best-of-Email--Greatest-Pitch-EVER!