There are two kinds of “magic” that I come across in my daily work with technology. Like at Hogwarts there is good magic and bad magic. Unfortunately, sometimes you can’t tell them apart until it is too late.
I am actually a big fan of magic in software. The addition of __call(), __get(), __set() in PHP5 opened up all kinds of doors. If Ruby is anything it is a magicians toolkit. Good magic is common in good software. Things like Object Relational Mappers, templating tools, even object inheritance use good magic. Good magic is visible to the developer as long as the look. Most good magic in software development has to do with following conventions more than anything else. As long as you follow the defined general rules and practices, good magic can save you a lot of time.
Bad magic can save you a lot of time too, at first. Bad magic causes things to happen that are often unexplainable except by the developer(s) who created the software. While Ruby allows for lots of good magic, it allows plenty of bad magic too. The ability to overwrite classes at runtime is one of the most powerful and dangerous tools I have ever seen. With proper conventions it can be great; without you might as well be using witchcraft.
Recently I have been dealing with magic that is not just bad but is straight up EVIL. What is this Voldemort that I speak of? ODBC connections. They are handed out to database amateurs as a quick and easy way to let them access data. Of course, people want to share the Excel Spreadsheets and reports that they have created. That is when the ease of setup reveals itself as a wormhole straight to hell.
ODBC portability sucks. However, unlike other ways to connect to databases like JDBC and OCI, ODBC provides horrible error messages (if it provides any). The reliance on User or System data sources and the often cryptic requirements for what needs to be named the same from system to system makes working with ODBC miserable. It feels like a black art whose oral tradition has been jumbled over the years.
