Sonic 2006

Enterprise Resource Planning software, or ERP for short, is crucial to the operation of many large businesses. Several popular ERP systems have plugin-friendly architecture, the better to sell upgrades their customers will never want or use. This software is primarily aimed at businesses with too many complex process flows to manage by hand—making it the perfect domain for a small, lean startup with 3 developers and 1 customer.

Ethan and Roland were brand-new developers, fresh out of college and ready to take on the world. Patrick, a consultant, was more experienced, though still fairly early in his career. They worked in C# with the Visual Studio ecosystem, and their boss had bestowed just one instruction as to how their culture should be formed:

"Picture a scale from 1 to 10, with 1 being fast and 10 being scalability and code quality and all that crap. I want you to aim for a 2."

Visual Studio is a great tool for beginning developers who need to work fast. It makes scaffolding the code simple and efficient, and allows for a drag-and-drop visual design that lets you rapidly prototype your screens. Couple that with great intellisense, and the team was confident they could deliver their addon as promised.

That said, Visual Studio is also a complex piece of software, with many of its best features hidden inside a labyrinthine menu system and/or optional settings deep in a configuration file. It works better if you have time to learn how to use it. Unfortunately, our ERP team did not have that kind of time, and they missed a few key features. For example, out of the box, Visual Studio won't step into a catch block while debugging. You can debug catch blocks, but you have to explicitly set a breakpoint in them or they will be skipped entirely. There's an option to turn this behavior off, but it's hidden deep in the menus.

Ethan and Roland developed a workaround for this behavior that let them continue working: they would comment out catch blocks surrounding code they were actively debugging, then restore the commented-out code afterward. But this took time and effort, and often multiple cuss-filled executions as they realized the exception was handled at a higher or lower level than they'd originally anticipated and they had to comment out more code. Finally, Patrick came up with a more creative solution: pre-emptively comment out all try-catch blocks in the entire solution, and stop adding more.

"There's no time for exception handling," he scoffed. "We have to move fast or we won't hit our street date."

Ethan was concerned by this solution. He'd already caught himself forgetting to un-comment catch blocks using their old strategy. Wasn't this infinitely more risky? And how would they know their catch blocks were written correctly? What about testing the error messages they were meant to display to the users? Still, he was brand new, and Patrick had industry experience, so he was overruled.

The weeks wore on, and development moved at blazing speed. The developers did their own unit tests, and from time to time, their BA would perform manual tests of the addon installed in the ERP system. It mostly crashed, but it was early yet. There was time to figure it out. Still, blazing isn't quite lightspeed, and the BA kept finding more and more crucial functionality that would be required if anyone was going to be interested in purchasing the thing. The general feeling of the project team matched the immortal words of Sonic the Hedgehog: "We're not going to make it. Let's speed up!"

The team took on more developers in an effort to increase overall velocity. One of these was Alex, a contractor with 30 years of experience handling IT projects. Alex rapidly emerged as the clear leader of the entire team; his age and experience dethroned even Patrick. He spent increasing amounts of time sequestered with the boss, talking through everything from planned features to plugin architecture to the speed of development, which the boss felt was responsible for their missed milestones. Not because the code quality was crappy and therefore more time was spent fixing bugs, but because developers "weren't coding fast enough."

The codebase had grown from a few hundred lines to several thousand. Ethan had found the magic toggle for Visual Studio that made it step into catch blocks, much to his relief. He reported this to the boss, and the ban on exception handling was (begrudgingly) lifted. Ethan adjusted rapidly, but many of the other developers still blamed exception handling for the slowness of coding. Often the addon would crash due to an incorrect cast or bad index. However, handling exceptions was seen as wasted time, so many developers refused to do it.

Upon overhearing the boss and Alex discussing the matter, Ethan threw in his two cents. "We're nearing release. We should really start adding exception handling to all new code. Then we should do a final round of testing to make sure nothing breaks."

This didn't go over well with the boss. The solution was simple to him. "Just don't use any exception handling. Remove all of it. Then we won't have to test anything extra, and we might even make our deadline."

Ethan, after retrieving his jaw from the floor, protested violently. "Who's gonna pay for a system that crashes the moment you look at it wrong? What about data integrity? If bad data is persisted to the database, it'll fill up with garbage—and then the application will throw even more exceptions!"

"I know it's not ideal," said the boss, "but there's no time. Remember the scale: we need to be at a 2, and you're at like a 6 right now. This is industry standard stuff. Trust me on this, okay?"

Time marched on. The company doubled in size, adding more developers who were forbidden from using exception handling. They moved even faster now, approaching the final ship date—well, the new final ship date, anyway.

One day, while debugging, Ethan noticed that the addon didn't crash anymore, but did log an error to the console. "Wait, what? Where was that handled?"

Concerned, he dug through the code. Most of his exception handling had been removed or commented out; he couldn't find a single catch block in the whole module he was working on. Finally, he found it: at the very top level, someone had put a try-catch block around the entry point to swallow any exceptions that were thrown.

Ethan asked Alex about it the next time he caught him in the hallway.

"Yeah, we can't have the addon crashing all the time, you know?" Alex shrugged.

Another junior developer poked his head out of a nearby cubicle. "It turns out, in C#, if you have an exception, the entire application crashes! Crazy, right? I found that out last week, and I told Alex about it, so we decided to implement exception handling."

Ethan had no words at first. He just cradled his forehead in the palm of his hand. Finally, he tried one last time to explain. "Look. Exception handling is a good idea. But this is going to swallow all the errors, so debugging will be impossible. At the very least, let's put a catch block around each module so we know which one failed. And stop removing my catch blocks!"

Alex shook his head. "You just have to do it right. All of you," he added, raising his voice so the others could hear. "If you just code it right from the start, there won't be exceptions, and handling them won't be necessary!"

Ethan learned a valuable lesson that day: why exactly it was that startup developers tended to congregate in bars and debate the merits of various fine liquors online. It wasn't that people who liked alcohol were drawn to software development. Working at places like this drove developers to drink.

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