Joel Helbling's Blog

Some Thoughts About TDD and TAD

Wed, 28 Sep 2011 09:19:22 GMT

An essay I wrote back in late ’09, titled TDD is Dead; Long Live TDD has picked up some comments after all this time. Commenter “Shmoo” made an interesting point, essentially that all my arguments in favor of TDD were really just arguments in favor of unit tests, and could just as validly build the case for a test-after style of unit testing. Shmoo writes:

All good points, Joel, except that they have little to do with TDD, and more to do with unit testing (before or after the fact).

“TDD As Kind Teacher” – except for the first line, where you mention, “Test-first,” all the rest applies to test-after development (TAD).

“TDD As Dopamine Drip” – the green bar rush you get here is the same in TAD.

“TDD As Brain Girdle” – everything here applies to TAD (indeed the, " … tests make it easier for me to re-orient myself to my old code …" has even less to do with TDD).

“TDD as Scrooge” – as you say yourself, “When I code without tests, I might end up rowing upstream in a gold-plated dinghy …” This clearly applies to TAD.

“TDD As SmellOVision” – As you say, “… you find that you’re having a really hard time writing one particular test. 9 out of 10 Pragmatic Press authors agree this is a strong indication that your code could use some rethinking.” That applies precisely to TAD as it does to TDD.

None of your advantages is specifically related to writing the tests before the code.

All you’ve done is praise testing.

Didn’t Naresh pick you up on this?

/ Shmoo_

You make some interesting points, Shmoo. I hadn’t really considered the Test-After approach as a desirable alternative to TDD. The reason for my “blinkered” focus on TDD is due to my early experience with TAD.

I began learning unit testing and TDD in the middle of a project, and so for new code I was doing TDD. But I really wanted coverage of all the code I had written before learning anything about unit tests, and so I also undertook to write unit tests for all the old stuff.

Those two exercises, done in parallel (TDD & TAD) really sold me on TDD. The two experiences were dramatically different. I do not think I exaggerate to say that the TAD work was an order of magnitude more difficult and time-consuming than the TDD work. And of course my TDD’d code emerged with a better, more testable design.

That last sentence may be the crux of the difference between the two. I find that TDD leads to better code than TAD, and I also find that TDD is a better teacher of good code design than TAD. The TDD workflow seems (for me) to unfold good design as I go along, whereas, writing tests after just jabs me in the ribs to tell me that I already got it wrong.

Furthermore, TAD, to be really effective, requires a kind of attention and discipline which, frankly, I don’t have in spades. It is to easy to write code for 30 minutes, an hour, or half a day, before that nagging feeling that I need some more tests finally overcomes my conding-engrossed brain, and I shift gears and try to put some tests around the bridge to nowhere that I have been building. TDD ensures the testing is built-in, and once the habit is formed, I don’t have to remember to test; the testing and the coding quite naturally come up together. For me, that’s way, easier.

This isn’t to say that an already mature, well disciplined developer mightn’t do quite well with a test-after workflow. But I find that TDD is a fine ladder which is helpful in elevating the skills of developers through a wide range of skill levels. I have been practicing it for a few years now, and I still find it helpful. And the number of TDD-practicing developers whose skill far exceeds my own encourages me not to lightly abandon the practice.

Google+ Will Win Because I'm Already Tired of It

Fri, 22 Jul 2011 17:24:21 GMT

Ok, so this is not a really scientific barometer for the viability of Google+ (we always need more barometers), but try this one on for size: I’ve been using Google+ for three weeks now, and I’m feeling a bit burned out.

To me this doesn’t mean that Google+ is deficient, it means it’s so good that it’s grabbing a larger chunk of my attention than I can really sustain. And I think that means it’s a success.

I remember when, years ago now, I discovered that I could use Twitter to troll for other folks with similar interests. That was the day that Twitter became worthwhile to me, and I immediately spent several exhausting days building myself a micro-community around those interests. And then suddenly I was completely fed up with it and had to take a break. After that I pursued a more low-level, casual, occasional relationship with Twitter until a year or two after that, when I began more work on my personal brand.

Onboarding Google+ has been easier. Much, much easier. It has been more exciting too. But I am looking forward to things settling down a bit. I am hoping I won’t have to cross-post between Google+ and Twitter much longer, or at least I hope cross-posting gets easier (#g+).

These exciting times remind me that I am not really part of the young wired generation. I do not have the thumbs for constant texting, and my mind cannot endure the constant interruption stream which has become the norm for the Facebook generation. I like to think I am hip, I strive to be current, but at the end of the day I see clearly that I need quiet.

Eventually I came to a point where I ignored Twitter for days at a time, and then just jumped in for an hour or so. And when I do pay attention, I use lists to provide some vague, gooey context to the stream. You miss massive amounts of fascinating information that way. But you stay sane.

I will be playing around with notification settings in the next few days. I’m definitely planning to stay connected with Google+. But I’ll need to tailor the Google+ experience to be sustainable for me in order to do that. From what I see so far, Google is already further ahead in that regard than either Facebook or Twitter. And that is why Google+ is going to win.

What's So Wrong With Quick and Dirty Code?

Fri, 10 Dec 2010 14:24:31 GMT

The twittersphere and blogosphere have been burning up (at least in my corner of the social graph) with the topic of clean code vs expediency. In essence, the question seems to be, “couldn’t we deliver software faster by not worrying too much about clean code?”

I think not. Consider these trivial examples from domains with which we are (mostly) all familiar:

Could we not save a minute or so by not tying our shoes in the morning?
Isn’t the kitchen more efficient if we never bother washing the dishes?
Who has time for car maintenance? Isn’t it faster if we just proceed to work riding on bare rims, with black smoke belching forth from under the hood?

These questions suggest obvious misperceptions, ones which functioning adults in the modern age easily recognize as dangerous. But each of us had to learn avoid them at some point. And there are human beings (called children) for which the attendant dangers may not be so apparent.

The basic value proposition in QuickAndDirtyCode™ that I’m hearing is that it’s faster. But it’s important to recognize that the risk in each of these mis-perceptions isn’t merely of the moderate, inverse-linear kind. If I’m an idiot and think I don’t need to tie my shoes when I go out, the danger to me is not merely that it will actually take longer than if I had tied them. The danger is far worse: I could stumble on the stairs, injure myself, and impair my ability to go out for a long time.

The risk in using unwashed dishes and utensils in the kitchen isn’t simply that it actually takes longer to cook with them. In point of fact it might be faster in some situations. But there exists the very real risk of laying the entire family low with food poisoning, which is a major slowdown to many people, not just one.

And if you drive your car on the rims, you’ll be walking soon, if you’re lucky. In the meantime, you’ll lose time, equipment and maybe worse.

The idea that quick, dirty and “expedient” coding edges past clean code in the short term is a terrifically naive one. Software projects (and their several parts) tend to grow when they are successful. That’s just what they do. As the codebase grows, the risk in not writing clean code isn’t merely that it ultimately may take a bit longer; dirty code can sink a project. Dirty code eventually dooms projects to one of two outcomes: a complete re-write, or total failure in the form of abandonment of the project’s goals. Clean code helps us steer clear of these two outcomes by offering us the chance to build better software on top of what we’ve built in the past.

So what do you do if you’re new to software development, and clean code doesn’t come naturally? It seems clear to me that until we know enough to take the time to tie our shoes, we are not ready for the Big Time. If we won’t wash the dishes, we shan’t do much cooking. If we won’t get the car fixed, we won’t drive very far. And if we don’t learn to write clean code, we won’t be delivering much working software. For the less experienced developer, there really is no viable alternative: learn to write cleaner code.

Abstraction Wrangling

Thu, 09 Dec 2010 09:28:42 GMT

Corey Haines blogged today about the difference between Taking it too far vs Taking too much time. He’s talking about refactoring, and the differences between beginners and more experienced programmers when refactoring (or choosing not to refactor).

One of his observations is that refactoring often involves introducing (or improving) abstractions. He says one differentiator between experienced programmers and beginners is that the more experience programmers have become more adept at “abstraction wrangling.” I think this observation is very apt; it tracks with what I’ve observed in teaching Java to inmates at Marion Correctional Institute. I think part of the reason for this must simply be the relative noise-to-signal ratio imposed by unfamiliarity with tools, conventions, TDD and the language being used. Less attention is available for thinking about abstractions when navigating the tools requires more conscious thought.

But another thing that makes abstractions relatively more difficult for beginners is simply understanding what they mean (or could mean) in the context of a computer program. Clearly, an object “joel” of type Person isn’t actually a real, live person. The implication is that the object “joel” has certain characteristics which model a real person. But in what sense is it true that “joel” is like Joel? In order to understand the computer program’s abstraction, it’s necessary to understand the intent or purpose of the program. Is it a phone book? Expect “joel” to have a phone number, just like Joel does. Is it an org chart? Maybe “joel” has a Boss, or TeamMates or an ArmyOfMinions. (Real Joel does not have an army of minions.)

In short I think the abstraction differentiator comes down to better familiarity with various application types and problem domains. This knowledge helps to inform a programmer as to all the ways in which “joel” could be like Joel, and more importantly, the ways in which “joel” is likely to be like Joel. Knowing the intent of the metaphor makes it possible to narrow our expectations and thereby avoid taking the metaphor too far. If the program is a phone book, we don’t expect “joel” to have an instance of MedicalRecords or a collection of ChildhoodExperiences.

TDD is Kanban For Code

Mon, 15 Nov 2010 14:24:16 GMT

Kent Beck had an interesting blog post the other day in which he proposes that TDD is like Kanban for code. It’s an interesting mental model, and I find I like it. Kanban speaks to the idea of a consistent, uninterrupted value stream, and the removal of waste from that process. This concept maps to test driven development quite nicely; in step one, value enters the flow in the form of a failing test; next the value is built in the form of making the test pass, and finally, we refactor.

It’s Kent’s notion of the last part, —the refactoring— that I disagree with. He said, “From the kanban perspective, though, post-success refactoring is over-production, the worst of the seven wastes of the Toyota Production System.” Here I have to disagree. I believe that the refactoring doesn’t constitute waste at all, but is an essential part of the TDD/Kanban-ish value stream.

Once a Camry rolls off the assembly line at the Toyota plant, the Kanban value stream is still far from ended. To simply let the finished cars pile up at the factory would certainly be a huge waste. Without delivery of finished vehicles to the marketplace, all efficiency gains throughout the rest of the factory are pretty much moot.

I see refactoring as being similar to delivering finished cars to the dealer: I think it helps if you think not of delivering simply source code, but of delivering business value. Toyota knows that their job is not merely to build cars, but sell them. To continue coding without continuously refactoring is akin to piling up finished cars at the factory. In both cases the value stream becomes clogged, resulting in slowdowns, undelivered value, and even breakage of existing finished work.

Refactoring isn’t overproduction, it’s simply the tail end of the TDD value stream. Like every other part of the value stream, it needs to run smoothly and consistently so as not to become a bottleneck.

PrizCon 2010: First Reflections

Sat, 13 Nov 2010 23:36:19 GMT

There is no research more fascinating and more satisfying than the research you do on a rabbit trail topic which runs tangentially away from the topic of a presentation you are supposed to be giving this weekend. Somehow the procrastination just sweetens the reading, and those wikipedia disambiguation links just glimmer like liquid sunshine. That’s what I learned last week as I tried to pull together my talk for PrizCon 2010.

My Talk

My talk was entitled “Agile Means Community and Community Means Success” (slides). I give all my attendees mad kudos for bearing up under my delusional ramblings; after all the time spent on those tangential rabbit trails, it seemed a pity to waste all that research. So it seems plausible that my talk covered too much ground. On the plus side, I am a fast talker, and I hit my last slide in 30 minutes flat, and opened things up for questions, comments and discussion. Easily this was the best part of the whole arrangement.

I was pleased as punch that our keynote speaker Jeff Langr sat in on my talk! Even better he jumped into the discussion afterwards, so my attendees got to discuss my talk with the guy who wrote the book they are using to learn Agile and Java! By the way, Jeff, I snagged the kindle edition last week, so if your ranking jumped from 600,000 to 30,000 among kindle books…that was me.

The Keynote

Speaking of Jeff Langr, great talk. It was huge that he agreed to fly in and keynote. I hadn’t met Jeff before, but we have Paul Nelson as a mutual friend. It was great to meet and talk shop with you, Jeff.

Things You Didn’t Know About Dan

Dan Wiebe gave an awesome slide-free talk about the Java-in-prison story, and also about how he came to be a TDD-card-carrying, pair-programming, agile software developer. I was floored; I had no idea that he initially resisted “all this new agile nonsense,” but now that he’s told the story, I can kinda visualize it. For those of you who don’t know what Dan looks like, he is a tall, bushy-bearded agile fanatic with clever, gleaming, beady eyes. I am just glad he’s on our side. If he fixed those eyes on you right after you rolled some code without writing a test first…{shudder}. But seriously, he gave a terrific talk.

More Talks

Matt Van Vleet jumped in to fill the time slot vacated by Bob Myers. He said he threw his slides together during the keynote. Not bad. I gotta acknowledge his improvisational skills, and sheer chutzpah: he slaps together slides and jumps up to give his boss’ talk on short notice with zero prep time…in prison. Good talk, too. Very entertaining, and I think he had some very helpful direction and ideas for the inmates who, after release, will be looking for work in the tech sector.

The other talk I heard was Eric Wilson’s very well attended story of how he changed careers, going from a guy who “couldn’t code ‘hello world’ in any language” to being a TDD-practicing, gainfully employed software craftsman in the span of 18 months. In his prior career, Eric was a professor of mathematics; so clearly he is no mental slouch. But still it speaks volumes that he was able to shift gears and pick up the trade of software development to the point that he was providing for his family in such a short time. As a matter of fact, if I remember the story correctly, he was paying the bills with working software after only about 9 months. During those nine months he was still at the old job, and would wake up early so that he could spend an hour and a half learning and practicing code in the morning before heading to the office. Some of the key points he made were 1) you’ve got to be really diligent, 2) you’ve got to take responsibility for your own education, and 3) he says, quite frankly, he asked God to help him. It’s a great story, and I think it had us all thinking about what it means to sack up in the face of learning challenges in order to reach our goals.

Even More Talks

In addition to all that, there were six other talks which I did not get to hear, including some that were given by inmates. One of those was about creating 3d animations using Blender and other technologies. Another was a talk about how computers are changing the music industry. Those guys actually had a digital recording application called Cubase up and running, and they had some musical instruments there and were literally recording music during the talk. Wish I could have seen the whole thing.

To hear more about the other talks, read Dan Wiebe’s blog and stay tuned to #prizcon on twitter.

Update:

SDTConf 2010: First Reflections

Sun, 31 Oct 2010 23:43:22 GMT

TDD Without Frameworks? Really?

Sometimes all it takes is for someone to suggest you do something that you’ve never tried before, and suddenly you’re doing something you didn’t know you could do. That’s what happened today in @chzy’s “Make it Sing” hands-on openspace session at SDTConf today. His suggestion that we TDD sans-framework provoked @joshwalsh and me to create a TDD framework called Really? which we developed by TDD’ing itself. What cracks me up is how easy this was to do.

true.really?

This, of course, will fail with a method missing error. Fix the error, and you’re on your way to

false.really?

You can get the source code for really? at github.

Practice, Practice, Practice

I really enjoyed the strong emphasis on coding practice at this year’s SDTConf. Two of the tracks had overhead projectors, and they were usually being used for looking at, refactoring, or writing code: whether it was the hands-on refactoring little shop of horrors that @auditty unveiled (this session was a blast, btw), or the strange, alien world of J and APL which @kaleidic demonstrated for us, or the Game of Life in Javascript being diagnosed/optimized by @zspencer and @DocOnDev.

The Icebreaker

In addition to sessions where code and coding were being demonstrated, there were also many sessions where everybody opened their laptops to practice coding. The first of these was @kbaribeau’s “Coding Icebreaker.” In that session, we took turns pair programming the bowling score kata. The catch, however, is that sessions were only 10 minutes long. At the end of the session, one person remained at the same workstation, and the other moved down. This means that you get to spend up to 20 minutes with each codebase, and that you get to see 3-4 codebases. There were three implementations in Java, and one in Ruby. I worked with all three Java implementations, but never got in front of the Ruby one.

Each approach was very different, and the “many-cooks-in-the-kitchen” aspect to this exercise made it very challenging to do more than 1) read/grok the code, 2) write a test and 3) make it pass. Some folks commented that leaving the code with a failing test was actually a nice thing to do, since fixing a failing test is often an easier task than writing the next failing test. I’ve always found this to be true.

Tick Tack Toe Driven Development

I also had fun in the “TDD Like You Mean It” session, doing the Tick Tack Toe Kata. I was pair programming with @angelaharms who was fairly new to Ruby although not new to development or TDD. Her newfound enthusiasm for Ruby completely tracks with the way I felt when I first began learning that language, and it was fun walking through the “Like You Mean It” process using Rspec.

We caught some critiques from @chzy and @nashjain because of the fact that we created a Board class. And I could see their point of view. Others argued why not make the Board class if you know you’re going to need it anyway.

I personally am not bothered by the fact that we created a Board class because we were nevertheless focused on small, TDD-invoked steps. We started our rspec file with:

describe Board do

end

And then, of course, the first thing rspec told us is that constant “Board” wasn’t initialized. Feed the test. Away we went.

I later redid the exercise without creating a Board class. I’ll have to show it to @chzy and see if it’s closer to what he was looking for.

Next year we may be hosting SDTConf on the Leandog boat in Cleveland. That would be hugely fun. We shall see.

Scanning The Topics

I have scanned in the open space topic cards from SDTConf 2010. If you were there, please feel free to tweet/comment/blog/download the card images.

A Couple of Thoughts About "Standard Agile"

Thu, 08 Jul 2010 13:56:09 GMT

Lately I’ve been hearing a lot about standardization of Agile methodologies, and while some of the discussion may be well-intended, I feel the trend isn’t a healthy direction for the Agile movement. My concern is that it reveals a reverence for manufacturing which doesn’t help teams and managers when implementing Agile practices. Nick Oostvogel recently wrote,

“Do we dare pretend to be better than the factory folks, which have multiple times the industry experience than we have in software development?”

As a matter of fact, we do (or we ought) to dare to be different from the “factory folks.” The concept of an hypothetical list of standards may be fine, depending on how they are applied within an organization. But a loose set of process guidelines is miles apart from the process management that goes on in manufacturing, which is as it should be.

Manufacturing processes classically emphasize dense, in-depth decision streams before the assembly line is set in motion. In agile software development the building and the designing happen simultaneously: thus the decision stream is constant and concurrent with the process. In fact, in software engineering you might even say that the decision stream is the process. To improve software development is to improve the process in which good decisions are made.

In the classic manufacturing model, decision making is confined to a relatively small number of process engineers —those who will actually carry out the processes have little involvement in making the decisions they execute. In software development there is no factory floor. If there were a way to map that part of the metaphor, it should be the applications and systems being developed, not the process of building those apps and systems. Consequently your rank-in-file developer has more in common with a manufacturing process engineer than he does with the factory worker on the line. To blindly apply the manufacturing model to software engineering is to embrace a solution in search of a problem.

If we point back to manufacturing as a general model for software development we promote heavy, up-front design, rather than encouraging an agile mindset which values lightweight and easily modifiable processes over wasteful standardization across an organization. We in software engineering need to think more about the human decision makers involved. These are considerations which have no particularly helpful ancillaries in the world of historical and mainstream manufacturing. I’m not knocking Lean or Toyota —quite the opposite. The concepts we draw from Lean are helpful precisely because they are revolutionary when compared to the manufacturing industry as a whole.

Apprenticeship Patterns: The White Belt

Fri, 04 Jun 2010 10:18:28 GMT

I love this pattern. More than simply a good approach to software craftsmanship, I believe wearing The White Belt is an essential life skill, with applications literally everywhere. Without approaching life with the beginner’s mind, we risk losing a virtually endless stream of opportunities for learning.

Get On Your Brain and Ride

One important trait of a person wearing the white belt is that he does not know what is important to learn. Earlier in my apprenticeship, I did not grasp this. I generally tried to hoard my attention, acting as if it were a very limited resource. And thus it was.

Nevertheless, there were, despite my “best” intentions, those days where I completely lost myself in learning something new. I would become so absorbed in learning, that I would frequently “come to” at the end of an unbelievably short day, and suddenly realize that I was hungry, thirsty, and that I needed to pee like a race horse. The world, including my own physical needs, had quite literally faded away. I always felt it was a guilty pleasure; however, without realizing it, I was stumbling onto the power of what scientists refer to as neuroplasticity. Studies have shown that people who believe their minds can continue to absorb new information —pretty much without limitation— are many times more effective at learning than those who believe, for instance, that in order to learn something new, we must lose something we learned earlier. The truth is that we haven’t even come close to tapping the human brain’s potential.

All too often, however, “common sense” would get the upper hand in my learning process, and it would shut things down. I’d fret that the things which were “distracting” me weren’t of any real value. I had, to some extent, swallowed some conventional wisdom that went along the lines of: find out which programming language is the most lucrative, find out which technology stacks are going to help you earn the most money, and study those to mastery. Blech. I had convinced myself that I had enough expertise to determine what was important to learn, and what wasn’t. But I really didn’t, and you don’t either, because that’s not the way it works. We learn what is important to learn…by learning. And that means we must start to learning before we’ve learned what’s important to learn. We have to stop worrying about wasteful learning and just start learning. Follow your curiosity.

Go To The Dagobah System

The simplest way to don the white belt is to ask questions. That’s what I did when I was making the transition from veteran Perl hacker to novice Java programmer. I found a mentor who tolerated my questions; an grouchy programmer named Bob who coached me through my introduction to Java unit tests and TDD. Our employer took a dim view on pair programming, but Bob and I pair programmed frequently. My boss quite literally told me to stop writing unit tests, but I kept at it anyway (my boss eventually came around). And anytime I had a question about design, or had gotten stuck on a problem, I’d put on my white belt and go talk to Bob.

This Ain’t No Beauty Contest

Humility is an essential requirement for wearing the white belt. When you wear the white belt, you set aside your expertise. You cannot simultaneously ask a mentor for help while reminding her that in some areas you have more experience than she does. It just doesn’t work. You have to be willing to be the dumb one. Sometimes, in the midst of hearing a few things you need to know, you’ll also get an earful of stuff you already know. Repeatedly butting in with “I know that” only ends the lesson too quickly. Rather than explaining how much you already know, try rephrasing what your “sensai” is saying, or better yet, apply it to a particular context. In this way you can demonstrate that you’re apprehending what your hearing.

Keep Your Pants Up

A few years ago my son was taking Tai Kwan Do lessons. He began with a white belt. Soon, however, he progressed to the point that he was able to pass his teacher’s requirements for a yellow belt. He paid the price in practice, and I paid the price by writing a check for each new belt my son earned. Consequently, as my son progressed, he began to accumulate a series of colored belts. Eventually he had a thick bundle of them. He hung them on the wall in his bedroom. And despite all the other belts he earned, he always remained the owner of a white belt.

That’s the way it is with any of us who have gained some experience. Whatever color your latest belt may be, you remain the owner of a white belt. The black belt programmer is simultaneously a white belt programmer, because there never comes a point at which it is appropriate to stop learning from others. To predetermine who can teach you something and who cannot is as shortsighted as I was when I was a beginner, when I tried to determine the most important programming language for me to learn. Stay humble, maintain your curiosity, and learn from absolutely anyone.

Apprenticeship Patterns: My First Language

Fri, 28 May 2010 16:01:15 GMT

The first language I ever learned well enough to really command was Perl. Before that I coded the occasional short recipe in Basic. I even did a smattering of Visual Basic. I fiddled with Delphi. I made several attempts at Java, but to no avail. At one point I even downloaded and printed a huge stack of Eiffel documentation (read the first couple pages). Back in college I coded in Pascal, and got good grades, but never felt like I was really fluent. I even coded in FORTRAN for a numerical methods math class. It was a blast, but I didn’t own a copy of FORTRAN, and didn’t understand its execution environment. But somehow, when I delved into a Teach Yourself Perl in 21 Days book, it just clicked. Perl was the first programming language that I ever really loved. Whenever possible, I read that book while sitting at a computer. This was so that as soon as I encountered a code snippet, I could immediately type it in and then start tweaking it.

Making Perl My Batch

One reason I loved Perl was that, for me, its operating environment was very easy to understand. You have this executable program, perl.exe. You write scripts in plain text. You run the executable, passing the filename as a parameter. Perl.exe reads the script and does what you intended it to do. Easy. No make files. No linking. No memory management. It let me go straight past all that chip-head junk and just do stuff that I’d actually want to do.

I also think that Perl scratched the itch I had developed through rather extensive writing of DOS batch files (my day job). Perl was simple enough for me to learn quickly, and provided so many of the features I had come to really wish for in DOS batch. I remember how excited I was to be working with real live flow control structures.

Peace Love And Understanding

Furthermore, Perl —or more accurately, the Perl community— was also very non-judgemental. They liked to say “there is more than one way to skin a cat.” Larry Wall, the creator of Perl, said that the language was purposefully designed to be apprehended in different ways and at different levels by the novice, the intermediate and master programmer. I liked that. Rather than worry that my code might not be completely proper, I felt free to just launch in. And as my organic piles of code began to collapse beneath their own weight, I had the opportunity to learn first-hand the basic tenets of clean code cultivation. Eventually I came to be a rather opinionated Perl programmer. But at the beginning, I appreciated working in a language touted as accessible to horrible coders. So what if my code took 15 lines to do what a Perl master could do in one? I still accomplished what I wanted to do. And writing 14 extra lines of code is not the end of the world. Eventually I came to value readable Perl code over hopelessly cool and dense obfuscation, and I’d settle for the five line version. When you have coded cleanly in Perl, you have under-promised and over-delivered.

After reading several chapters of the Teach Yourself book (but before getting to the chapters on Object Oriented Perl), I started working on a real-live application of my own. Back in the days before wikis, I wrote a wiki. Well, kinda. I called it a Document Management System. You logged in, and found yourself on a kind of home/default/landing page. There was a list of titles down the right-hand side. Click one of them, and you could view it. You could also create or edit any of the documents, using plain HTML to nicely format the page. Then I began reading about Object Oriented Perl, and suddenly the DMS just wasn’t good enough anymore. Now I wanted it to be object oriented.

Hacker For Hire

Soon I got a gig, coding CGI scripts for a local web designer. That was fun. It was also harrowing. Welcome to legacy spaghetti in Perl. I learned to gather requirements very carefully, guarding against scope creep and hidden complexity. I also began to learn why some codebases are fun and easy to maintain, while others are positively a nightmare. And I experienced the refactoring pain which ultimately prepared me to embrace TDD. Nonetheless, the first gig was fun, and I started thinking, “you know, my next job is going to be a Perl programming job.”

And so it was. I got a job working for a dot-com, with a small, distributed team of Perl programmers. Up to that point I didn’t actually know any other Perl programmers personally. I learned from books, from the Internet, and by experimenting. In hindsight I think that failing to connect with some other Perl programmers in the early days was a real mistake. So working at the dot-com gave me a chance to learn from some excellent programmers. And I learned to respect and strengthen our team’s coding conventions. Some of the conventions I liked and internalized. Others I didn’t agree with, but I observed them nonetheless. Perl is so permissive that Perl programmers soon learn that if they want to work as a team, they must lay down a few team ground rules for code they maintain together, or soon they will drive each other crazy.

After I left the dot-com (they ran low on money) I went to work as a database developer. Predominantly I wrote SQL queries and stored procedures using TSQL and PL/SQL. But once in a while someone would come to me and say, “Joel, I need to know something about the data which is spread across these 25 files. Can you help me?” And I would write a 12 line Perl program to give them the information they needed. And I began to really love Perl for its power in creating use-once, throw-away programs. Sometimes, when someone came back to me with the same or a similar problem, I’d be able to find the script I wrote before and re-use it. Often I couldn’t find what I was looking for, so I’d just code it all over again. Well-designed, reusable code is best, but fast and dirty throwaway code ain’t bad eiter. Today, as I learn to talk like the cool kids, I tend to call such code a “spike.”

That’s No Perl, That’s A Death Star

Throughout the years that I used Perl, I really learned to savor the culture of the Perl community. They are brilliant folks, and often they seem to have a quirky outlook which I appreciate very much (no wonder my first Ruby book was Why’s Poignant Guide!). The leading masters in the Perl community were miles ahead of me, both in coding skill and in their understanding of elusive, abstract concepts. All the reading and hacking that I did throughout those years helped to stretch my mind, and to remind me that I had a long ways to go.

This experience taught me the value of turning to powerful programming languages to solve problems, mine data for answers and automate tedious tasks. What I feel Perl did not give me was a really solid understanding of Object Oriented design. For that I would finally return to Java, and then soon after, to Ruby. But those are other stories for other days.