- 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.