Best Practices Are Best, Except When They're Not

A code-review of sorts where we go over some of the real-world situations when things just don't go the way the Stack Overflow Gods say they should. We'll look at the pros and cons of solutions in these situations and the lessons hopefully learned along the way. This is a talk on anti-patterns, and what to do when we're forced to use them in the real world.

Description of target audience: Developers that write apps in the real world, that have deadlines, and have to solve real problems that don't always fit nicely in a box.

Assumed knowledge for the topic: Intermediate level of ColdFusion (or a similar language) and some experience with OOP (but by no means will you need to be an fact, if you call yourself an 'expert' you'll probably think this talk is beneath you...and if that's the case, I'd encourage you to attend even moreso. ;)

Objective of the topic: We all see lots of "well I would never do it THAT way" comments on blog posts, mailing lists, and the all-mighty Stack Overflow. But what about when you HAVE to do it that way? Let's look at some of these situations and talk about different solutions that might not be the most elegant, but solved the problem, and helped us learn something for making the next version of our app better.

Main takeaways:

  • When is it BETTER to have errors emailed to the team instead of stored in a logging tool (Yes, there is a time for this).
  • Can you do things like add Bootstrap to an old table-based web app? (Yes, there are still some of these out in the wild.) And what happens when you do so?
  • An explanation of technical debt and why it's important.
  • Some real code situations where incurring a little technical debt was necessary.
  • Some lessons learned when these situations have presented themselves, so we can improve things in the future.

[Slide Deck]