February 2006 - Posts
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.
Recently I've been using a tool called
Programmers Notepad
as I learn Ruby and even at work as I edit various documents.
Programmers Notepad (PN) is a replacement for windows Notepad that
includes a bunch of nice to have features like syntax highlighting and
a tabbed interface. However, the part about it that I've liked the most
so far is its "Tools" capability. With "Tools", PN lets me automate
common tasks associated with certain document types. For example, I can
set up a Tool for SQL files that will open up SQL Query Analyzer with
the script I am working on already set up to be run. Or I can setup a
Tool to run the script and capture the output to a file, which I can
then review after every modification to the file I'm working on.
So that may not sound very exciting to you; especially since you can do
a lot of similar things by fooling with your file extension
associations in XP. What's nice about this is that you can be
manipulating a bunch of text items within one environment and have that
environment setup to allow you to easily execute common tasks with
these items. So if I'm working on something in Ruby, I may have a bunch
of Ruby source files open, a SQL script for a database and an HTML file
for the front end. If I setup PN right, I can setup keyboard shortcuts
to run tools that do whatever is appropriate for those file types. So,
in essence, PN lets you build up your own IDE.
So why not just use a prepackaged IDE? Well for .NET development, it is
hard to argue against Visual Studio .NET for nothing else than its
ubiquity. For all the slowdowns, annoying crashes, and inexplicable
behaviors, it is still the defacto standard for a .NET project and
gives me IntelliSense, integrated help, easy compiling, etc. So VS .NET
certainly does a lot to speed up my day. However, what I've noticed
while learning Ruby is that for Windows at least, there is not an IDE
anywhere close to as polished as VS.NET. This forced me to fend for my
self and figure out how to make my development in Ruby go easier, and
hence PN.
Getting back to PN and rounding into some kind of point to this post...
I discovered there was actually a large value to me in having to build
up my own IDE and automate the common tasks I wanted to accomplish.
There was a cost in time, but there was also a value in really having
to figure out what was going on to feel confident in automating it. If
automation is given to you out of the box, you never have to dig into
it and figure out what's going on; it just works. Sometimes that's
fine, sometimes we only care that it just works. However, that often
ends up coming back to haunt us later. When we deploy an application
and can't figure out why it doesn't work in the new environment when it
works on our desk or when we try to setup up a project on somebody
else's machine and realize we don't really know why it works on ours,
this is when we incur the cost of automation we haven't earned or don't
understand. So that's why automation can be a tricky friend: we'd be
foolish to not save time and take advantage of it, but if we accept it
with no understaning, we are fooled into thinking we know more than we
do.
After a brief hiatus, I am diving back into the world of Ruby, helped out by the
Pragmatic Programmer's canonical book:
Programming Ruby,
aka the PickAxe. This book is considered the required book to learn
Ruby and for good reason. As I've mentioned previously, programming
skill has no direct relationship to writing skill. Thankfully, in the
case of these authors the two match up perfectly and the result is a book that is
eminently readable with good depth. It was good enough for me to buy in
both the physical and PDF versions.
So beyond a book recommendation I hope to share some little programs
that I write along the way as I try to grok different parts of Ruby. In
the meantime, while I'm in a recommending mood, I would highly
recommend Kathy Sierra's blog,
Creating Passionate Users.
She is one of the principals behind the Head First series, and has a
lot to say about usability, design and the rest of the softer side of
our profession. So check her blog out and learn your one new thing for
the day.