"I was recently assigned to work on a team that maintains a fairly large product," writes Aaron, "at first, I was a bit overwhelmed by the complexity of the architecture. There were countless layers of abstraction, thousands and thousands of classes, and design patterns galore. Since it was such a large project – and my first large project – I figured that the architectural complexity was simply par for the course."
“Then I started looking at the code a little more closely. If I had two words to describe it, they’d be ‘unnecessary complexity.’ And if I had one snippet to describe it, it would be this.”
"Do you think it's wise to have consultants running our IT department?" Holger asked. It was an honest question, worded as diplomatically as possible. Holger's company had more consultants on hand than actual IT staff.
"Holger, these folks are experts," his manager replied. "It isn't cost effective to hire-on this level of expertise full time. We may pay a little more up front, but when we don't need the consultants anymore, we can hand it off to our internal people."
Think of all those old applications you’ve had to maintain. You know the type: the ones written by long-forgotten developers in long-lost languages. The ones that, after spending days searching for that one line of code that needs to be changed, you frustratingly decree “this f%*#@ thing needs to be rewritten.” And, naturally, the ones that never are, nor never will be rewritten.
Call it luck or persistence, but after dozens and dozens of maintenance requests over the years, Israel Brewster finally was given the opportunity to rewrite an application. From scratch. And the right way, this time. No shoddy VB6 front-end; no horribly-designed SQL Server 2000 (only) database; and certainly no Microsoft Access-based administration tool.
When Greg was shopping for jobs at his college’s career fair, there was a whole lot of business as usual.
The larger banks were on-hand looking to swoon the upcoming Financial grads. Several representatives from a few big name manufacturing corporations were there to interview the Chemistry majors and a few IT firms were on the lookout for the soon-to-be CS grads, like Greg, to add to their ranks. However, amid the ocean of pamphlets and suits there was one aerospace corporation with one particular position that caught Greg’s attention. The position that he applied and was ultimately hired for could be summed up in one sentence:
"While digging through some inherited code," writes Joe "M2tM" Smith, "I encountered a conditional masquerading as a loop."
"Thankfully, the fellow responsible is 'no longer with us', and I suppose this type of code stands as silent testament to why. This interesting loop is only created so the break keyword can be used as an elaborate GOTO."
The words "Enterprise Integration" strike fear into the most stalwart of developers. When coupled with "in-house developed" and "B2B", one is almost guaranteed to find complex code, arcane requirements, and a thicket of poorly understood file formats. Dan was made of sterner stuff. When the contract was explained to him, he didn't flinch. There were between 40 and 80 partners that used a web app to extract data about multimedia assets? Gigantic recordsets of them? In formats ranging from Excel to iTunes-compatible databases? No problem.
Steve, the project manager, explained: "Our original lead developer was one of those rockstar types. Real cutting edge, pushing the envelope type guy. He's since moved on to bigger and better things, so we've just muddled on the best we could. We really need you to step up and take on that rockstar role for us, because there are a few problems we'd like you to fix. And we need a real quick turn-around on this."
Paul was having a good morning. It was a beautiful day outside, he managed to shave 15 minutes off his commute, and even the local coffee shop had his favorite donut in stock. All of that changed when he got his first support call of the day. It was from a client running "the beast" product. "The beast", as Paul and his coworkers nicknamed it, was a legacy version of their application developed somewhere overseas years before Paul was hired, by hundreds of poorly trained, and probably poorly paid, developers. The company's sales team actively encouraged clients to upgrade from the legacy application, but a select few had resisted.
"The beast" had a reputation for containing some of the worst code Paul had ever seen and every time he had to support it, he felt like he needed a shower afterwards. It was during his fourth hour of debugging that Paul came across a previously unvisited function shown below.
Bob was in the process of shutting down a software company that he had built over the past seven years. He had found a buyer for all of the software that he'd developed, collected his "eff you money" and was now retiring.
In fact, things were at the point where Bob had already closed the building and redirected the phones to his home phone with a distinctive ring so that he could tie up loose ends while the building was up for sale.
