As developers, we often find ourselves working in stupid ways because the folks who were hired above/before us think that what they set up is ideal. While this happens in numerous industries, finance, especially at huge conglomerates, takes IT/Software-WTF to a whole new level. As contractors, we often get the we need your help in an emergency even though everything is unicorns and rainbows speech that precedes some meltdown for which they want you to take the blame.

EXPENSES

After taking a contract position at a large financial company, Bryan T. expected to see some amazing things. On the interview, they talked a big game and had even bigger budgets. It didn't take long to see some amazing things; but not the kind of amazing you'd think.

To begin with, the managers and developers were still trying to roll their own time zones and caching. They didn't understand any of these terms: object graph, business intelligence services, concurrency, message pump, domain model, and well-defined. Bryan even needed to explain to them why JavaScript on random web pages doesn't have natural mechanisms to attach to .NET event handlers in other applications.

Their head DBA explained that the difference between a uniqueness constraint and a primary key was semantics, and that audit records and current records should always be stored in the same table so as to keep related data together. They even used a simple text column to store City, State and Country, which led to obvious issues like three different values for the US ("US", "USA", "US_TOTAL").

We all need to conform to some semblance of coding practices. These folks decided to use anti-coding-practices. For example, IEntity was a class but the "I" prefix was used because it was returned from an API.

Shared common libraries were not allowed; if you needed to re-use a chunk of code, copy and paste it to where you need it; that's why they implemented cut-n-paste across applications!

This also explains why SLOC is their primary productivity metric.

There were no planned releases or scheduled iterations; whenever someone barked, a snapshot was manually copied from local builds.

Perhaps most interesting of all, they had an awesome approach to branching. Instead of actually branching, they copied the whole code base into a new repository and ran that forward. Of course, this left a trail of repository droppings that you had to navigate.

It took Bryan quite a while to acclimate to all of this. Then the team received a massive product request. Unfortunately, nobody understood the concept of scalability, let alone why it had to be considered. Instead, they decided that Cowboy Coding would be the M.O. of the project.

At this point, Bryan decided he didn't want the job all that much. That very day, he had to work with another developer with whom he'd not yet had the pleasure. Their task was to return some JSON from a web service call. After more than a month of work, the other developer proudly showed Bryan what he had come up with to return specific data from the web service:

    [
      ["Morning Workflow Status", 
          "http://initrodestatus:1234/dashboards/WTFProject/Morning%20Workflow%20Status"], 
      ["Scrape Status", 
          "http://initrodestatus:1234/dashboards/WTFProject/Scrape%20Status"],
      ["UK Nominations Storage", 
          "http://initrodestorage:1234/dashboards/WTFProject/UK%20Nominations%20Storage"]
    ]

For Bryan, it was the last straw.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!