The Big Picture

I discovered programming during high school, and I've been hooked ever since. When other kids were playing video games, I was writing my own. I've always enjoyed puzzles, but discovered that writing an algorithm to solve them could be even more interesting, as when I wrote code to solve my Rubik's tangle.

Programming gets a little more interesting when you enter the professional world. For fun pet projects (games especially), if something is too difficult, you can just change the rules (requirements) to make coding easier. When coding for a real-world client, however, this is often simply not an option. This forces a programmer to stretch a little, and results in much more valuable applications.

In college I learned a lot about the value of documentation and code readability, as tools to make code maintainable months or years after the original application is finished, and to make code re-usable for other projects. But sometime during grad school I learned that even the most well-documented, elegantly designed code is garbage if it doesn't meet the needs of the client. Re-usable code takes more time to develop than single-use code, and often the extra time spent is unnecessary or only marginally valuable. Good coding practices have to be driven by customer needs, and time spent on a project must be spent providing value to someone other than the programmer.

Lately, I've enjoyed learning about test-driven development (TDD), and I like it a lot. It lends itself to very elegant code, as efforts are streamlined to only the essential parts. It fulfills client needs, as tests are written based on client-specified requirements, and these requirements are very easily expressible in the language of testing (much more so than the language of implementation). And finally, TDD lends itself very well to maintainability and re-usability because major behind-the-scenes functional changes can be verified against your complete bank of tests, rather than relying on (ugh) manual testing. I'll highlight this with an anecdote.

In my early days of learning Ruby on Rails and using TDD, I had created a database table and the necessary web page to view and modify the data in it. Working further on the project I realized that the database table name wasn't descriptive enough, and needed to be changed. Wary of missing a key dependency that would cause my page to crash, I changed the table name in the database and re-ran my tests. The tests highlighted the 2-5 lines of code that actually needed to be changed to keep the old web pages working with the new table name in a matter of minutes. Manual testing to find and change these bits of code would have taken hours, and also would have resulted in several code changes that weren't even necessary. From what I've seen so far, the TDD programming paradigm is where it's at.