Probably my favorite thing about Perl is the general philosophy of “There’s more than one way to do it” (often seen/read as TMTOWTDI).
I think developers should really take that to heart though and extend it to more than just the language they work on.
For any given problem, there is most certainly more than one way to do it. More than one way around the problem.
For example, at Bowker we’ve got a handful of features on a yet-to-be-released project I’m trying to push through to production.
However, some of these new features require some new tables to be built. And that means the production replication scripts will need to be updated. Then that means that the replication process needs to be re-tested, and etc. etc. etc.
Add to that, the primary person who does this for Bowker (I don’t even have access or permissions to the systems to do it myself if I wanted to) is out for two weeks on vacation!
So do I just sit back and say we can’t release until he gets back and does the updates/testing we need? Meanwhile having the business units (and other areas involved in getting this project out) yell to get this thing in production…
No. Remember there’s always another way.
If I can’t have access to the database for these features right now…I’ll just cut the database out of the picture for these parts!
So I just wrote some stuff to go with a physical file store and simple lookup procedure…nothing too fancy or full featured, but it will easily get us through the initial few weeks until the database stuff can get worked out and implemented (at which point I’ll just have to ensure I backload from the physical files as well as update the code to cut out the physical file stores).
Sure it adds a bit more work on my part, but really not that much…and best of all, it’s invisible work to the clients and end-users (as long as I do it right)…because remember in the end, they don’t really care how or why it works…they just care that it DOES work.
Sometimes having to put in temporary back doors, ugly scaffolding, or duct taping things together is just the quickest way to getting a happy and productive client or allowing yourself the freedom to move on to the next, bigger, issue…just remember that it’s not a ‘set it and forget it’ type of thing.
You eventually have to go back and finish the job the right way. But then again, if it’s a project of any real worth, there’s a solid chance you were going to be re-factoring bits and pieces of the code here and there anyway.
This post has received 40 loves.
Kevin has a day job as CTO of Veritonic and is spending nights & weekends hacking on Share Game Tape. You can also check out some of his open source code on GitHub or connect with him on Twitter @falicon or via email at kevin at falicon.com.
If you have comments, thoughts, or want to respond to something you see here I would encourage you to respond via a post on your own blog (and then let me know about the link via one of the routes mentioned above).