Faith Based Deployment
For most of us who have learned to program, there was a time when our
code more often than not did not run right the first time we wrote it
and we were faced with the daunting task of figuring out why. At that
point we were maybe struggling with writing a basic linked list or even
implementing a memory allocation utility. Whatever it was, you come to
the point where you are staring at the screen with no idea what went
wrong and you fall into the nasty trap of tweak and pray debugging. You
look around, find a piece of code that looks promising, change one
little part of it and run it again. If it works now, problem solved. If
not, try again. This method will perhaps eventually work out for you,
but in the end it is slow and you are prone to make the same errors
over and over again.
Why? Because by following this technique you are not gaining any
understanding of the problem at hand. In effect, you are thinking down
to the computer's level, resorting to a brute force trial and error
approach. This is not a profound point I'm making here. Breakpoints,
tests, code reviews, simulation, etc. are all approaches that have
developed to give the developer a set of tools that are much, much
better than tweak and pray. Programmers tend to be very protective of
their code, wanting it to not only work, but work beautifully, which of
course requires understanding it at a deeper level.
So, if you've made it this far, hopefully I've convinced that you are
already knew that coding systematically is preferable to coding by
coincidence. However, do you code systematically or are an adherent to
what I like to call faith-based deployment? For whatever reason, there
is a tendency among programmers to think that if code works on my
machine it should work on yours and on the production machine. If it
doesn't, something is wrong with the language or the platform.
Faith-based deployment is the result of this thought process.
Instead of systematically going about deployment, making it repeatable
and predictable, we get ourselves into trouble by treating it as if it
were a magical and unknown process. We assume our code will work in a
different place and if it doesn't we may have a guru or sage of
deployment around to fix our deployment issue with his or her arcane
knowledge.
Instead of assuming, we can try to prove that our code will work where
we want it to. Whatever our process is, we can make sure we always do
it the same way and if that way doesn't work, record what we did
different so we can do it the next time. We can write code to help us
automate this, use third party or open source tools or just use a plain
old spreadsheet. Whatever tool we use, we can turn the tables on
deployment and control it as much as we control our software quality.
There will always be glitches and bugs, but we can make an effort to
manage them. Just because worrying about deployment doesn't seem as
glamourous as writing perfect code and it is usually ignored in school
doesn't diminish its importance one bit. Do you write code and hope it
works or do you write code and prove it to work? If you're already
spending the time to prove it to work, it's worth it to make sure it
gets out into the world so other people can see how great your code
really is.