- Feature Articles
- Other Articles
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.
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.
Owen J picked up a ticket complaining that users were not seeing all of their work items. Now, these particular “work items” weren’t merely project tasks, but vital for regulatory compliance. We’re talking the kinds of regulations that have the words “criminal penalties” attached to them.
What made it even more odd was that only one user was complaining. The user knew it was odd, their ticket even said, “Other people in my department aren’t having this issue, so maybe it’s something with my account?” Owen quickly eliminated their account as a likely source of the problem, but Owen also couldn’t duplicate the bug in test.
These days, you aren’t just doing development. Your development has to be driven. Business driven. Domain driven. Test driven.
TDD is generally held up as a tool for improving developer efficiency and code quality. As it turns out, scholarly research doesn’t support that: there’s no indication that TDD has any impact at all.
Kevin did the freelance thing, developing websites for small businesses. Sometimes, they had their own IT teams that would own the site afterwards, and perform routine maintenance. In those cases, they often dictated their technical standards, like “use VB.Net with WebForms”.
Kevin took a job, delivered the site, and moved onto the next job. Years later, that company needed some new features added. They called him in to do the work. He saw some surprises in the way the code base had changed.
Moving to version control is hard. It's a necessary step as a company grows into developing more complex software, with more developers working on the various products, but that doesn't make it any easier. Like all change, it's often delayed far too long, half-assed, and generally resented until everyone's forgotten about the indignity and moved on to complaining about the next improvement.
At the end of the lecture session, students immediately started packing up their laptops to race across campus for their next class. Andrew’s professor droned on, anyway, describing their assignment. “I’ve provided parser code,” he said, “so you can just download the datafile and use it.”
He had more to say, but no one was paying attention. Perhaps he even had a correction to the assignment- because when Andrew went to download the data file for the assignment 404ed.
Brent, who had started at JavaChip in QA several years ago, was tapped for “real” work with the core development team. On the day of his transfer, he gathered his things from his desk in a cardboard box, told his teammates in QA that he’d continue to see them for D&D at lunch, and trekked down the hall to the larger office.
After finding his new desk, he went to find Karla, his team lead. As it turned out, Karla had called in sick, but she had sent Brent an email from home. Get settled in, she wrote. Our repo’s on the company git server. Make sure you have Maven and IntelliJ installed on your machine. Everything else is in the
Given the rise of the internet in the mid 1990's, various events and companies led up to Adobe releasing Flash. Not to be out done, in the mid noughts, Microsoft created their own version called Silverlight. Somewhere down the road, Facebook, Instagram and others put forth React. These can sit on top of a webservice, like, for example, WCF to make it easier for web-facing programs to call home to interact with back-end applications to do useful things like display videos of cats being, well, cats. Occasionally, folks even attempt to use these tools to provide access to business applications.
Some time back, Fred became a hired-gun/consultant/architect to a small financial company to help them replace a dying 150K LOC Silverlight UI with a React front-end, and the underlying WCF API (named Rest.Services for some reason). This allegedly trivial task was budgeted to take three months. Ten months down the road, Silverlight and the underlying code base were way ahead on points while the battle raged on. Eventually, management acquiesced and allowed the entire UI to be rewritten from scratch. The back-end, however...
Going through TDWTF inbox, I’ve built a sort of mental taxonomy of bad code. For example, there’s the kingdom of Tempus Malum: home-brew date manipulation functions, a rather profligate branch of bad code. Or the Order of Linguan Ignorans- bad code developed out of a complete ignorance of the available language features.
There’s another category that I always consider a treat. It’s related to Linguan Ignorans, but also borrows from Quaesto Ignorat (ignorant of the problem being solved): Filo Annexa, or “Knotted String”, also known as “String All the Things!”