Bash has a debugger

One of my biggest complaints with interpreted languages in general is that the debugging tools available are rather limited. When trying to find the root of a problem, having some sexy surgical tools available to cut into your program are nice. No, more than nice - sometimes they're necessary.

To my surprise, I discovered that Bash has a debugger! Bashdb, where have you been all my life? You can set breakpoints in your code, and step through the script line by line if desired. In terms of basic functionality, it's matches gdb fairly closely. Amazing!

I've used the PHP debugger XDebug before, but I found it to be a bit intrusive into the source code. You have to add PHP commands to the source to enable XDebug. I've never used Python or JS debuggers. Anyone know if good debuggers exist for those languages?

WiX: Windows Installer XML Toolset

While reading "The Build Master" this week, I was introduced to the tool that I find quite interesting: WiX. It's a MSFT produced and supported tool that has been open-sourced (gasp!). Open-source? Microsoft? Useful? My head hurts.

The WiX toolset allows you to create an MSI rather painlessly using an XML format that they've defined. It's actually quite intuitive and useful. The WISE and InstallShield guys have had the market on creating Windows Installers for the longest time. In addition, the horror stories I've heard from people who have the strength to use the WISE / InstallShield tools really caused me to do a double-take when I saw this tool.

In addition, there is no "setup" to speak of with this toolset. It's literally a set of binaries that you can execute from the command-line. There is no installation overhead, making these tools easy to store and version for build escrow purposes.

There is another open-source tool called Votive that ties in to Visual Studio and allows you to create and control the MSI build using WiX from within the GUI. As Borat would say, Niiice.

The Comfort Zone

Steve Yegge had a really interesting blog post last week about the average programmer. Take a looksey:

"But how do programmers compete? Generally, they just don't. Not in the way chess players or golfers compete, anyway. The reason? You can't compare programmers quantitatively, so you can't compute a score or a rank. Competitions and competitors have to be scored. Sure, you can set up scored programming competitions, but they're so tightly controlled that they don't resemble real-world software development anymore. Professional programmers basically just don't compete with each other.

Hence, you're probably not pushing yourself. Even if you're trying to improve your programming skills, you're probably just doing it in areas you're already comfortable in. And your improvements probably still aren't happening as fast as they would if you were competing to improve them."

Very true. He goes on to discuss how programmers are ranked relative to each other, since there is no quantitative method of ranking programmers, which in itself is completely subjective (and hence, his complaint). Programmers are ranked according to the context they are in.

His main complaint is about the comfort zone we all find ourselves in. He believes that since it is difficult to quantify the skill of a programmer, incentive is provided for pigeonholing yourself into an area you feel comfortable with.

I think this is true in most professions, not just programming, but I find this very true in testing as well. It is very easy to turn to the same tools and oracles to help with your problems and give advice.

"See, I always thought I was a perfectly competent programmer: as good as you can get, basically. I was building cool stuff, doing seemingly complicated things, and I felt I knew a tremendous amount of lore about the art of programming. I had won or placed in programming competitions, could program in Java for weeks on end without referring to the API docs, and pretty much felt on top of things.

Every few years, I would read some critical book, or have some weighty flash of insight, and realize that I'd been operating all this time in what could only be termed "clueless mode", and that I hadn't really known what I was doing after all. Amusingly, I was always relieved that now I could consider myself to be a good programmer, since I now knew whatever it was I'd been missing before.

Last year it finally dawned on me, after 16 or 17 years of this, that I just might possibly still be clueless about something important that I really ought to know, something that would make me a much better programmer."

Word. Hopefully I'll be that inspired and insightful after 16 or 17 years of working.

Test Personality Traits

I've begun to wonder what affect personality traits have in testing. The main question I pose to you is: are there specific personality traits that one should look for in good testers? This isn't to say that there aren't people who are excellent testers who have personality traits that aren't amiable to testing, but I'm looking for some generic pattern.

Take cynicism. Cynical people could be described as untrusting. I think it could be argued that this is a good trait to have in a tester. If by nature one does not trust the very inputs, outputs, data flows, and processes of a system system under test, it is possible that one could find more problems, assuming that there is proper motivation to do so.

On the opposite side of the spectrum, what about optimists? If you by nature are a very trusting person, would you unknowingly overlook problems due to your sunny outlook? Or is it possible to seperate your innate optimism from the technical job at hand?

You can probably already read my biases in the writing above, but I'm curious what the world at hand thinks. I'm not suggesting that hiring people should be based on personality traits, especially since I think it is impossible to get a good feel for someone's personality in 4-5 hours; but perhaps, just maybe, it should be taken into account.

The Brotherhood of Building and Testing

In the past few weeks, I've been embedded in the world of build engineering and configuration management. It has been an eye-opening experience, believe me. There are many splinters and specializations in the software industry, and the area of build engineering is one that I've never really paid attention to until recently. From what I've seen thus far, there are far more connections between building and testing than I've previously known.

There is a web of trust in the process of building any project that one takes a bit for granted, and indeed one must take it for granted. It's impossible to know every detail that every responsibility entails, so you must take for granted that the program manager is doing his job, and the product manager's requirements have been adequately reviewed and vetted out. The one area where the web of trust stops is between developer and testers. The testers are present to be cynical, and in general not trust the output of the developers. This ensures more quality in the software so that the users are not the ones consuming poor products.

I've recently started to think that the web of trust should be breaking down in another place: building. I would say that most engineers take the output of the build engineer a bit for granted. You assume that the build is an instrumented build because the build engineer says so. You assume that the build has the correct fixes in it because the build engineer says so. Well what happens if the build engineer is wrong? Having the correct build is the first step in the testing process, and depending on where you are in the life cycle, the main consumer of the build will be the testers.

I don't think it's too far-fetched to say that a new specialization should open up: build test engineer. The process of building can be complicated enough, depending on the size of your project, and can be a full-time job by itself. Adding value on top of that could be another full-time job. The value I'm referring to is build testing, build metrics, and build consumption.

Just as testers are considered a trusted third-party that can tell you with certainty (i.e., data) the risks and issues found in a product, a build test engineer would be a trusted third-party who could tell you with certainty that the build has or contains the attributes it says it does.

Nerdiest. Comic. Ever.

This is a bit off topic, but xkcd had quite possibly the nerdiest comic ever tonight, and I thought I should share with you all. It involves Lisp, God, and Perl.

http://xkcd.com/c224.html

Amazing.

The Desire to Build

My girlfriend and I had an interesting conversation last week about how so many test engineers feel the need to create and recreate tools upon more tools, even if a tool already exists that does what they need to do. This is a situation that has its own acronym: YATT (yet another test tool).

It brings up an interesting question: does this desire come from the very core of what it means to be an engineer, to build and create; or is this possibly something more? Is it possible that this desire stems from deeper feelings of inadequacies at not being a "developer", at least in title? When you need a test tool to perform an action, and there are twenty tools out there already that do this, why should one create another tool?

It's true that some stigma remains around the role of the tester. When people ask what I do, I feel the need to stress that I'm an engineer, but in the testing field. There are times at work when I feel I should be creating something in order to be taken seriously by my fellow engineers. I feel this is true, at least in part. Doing your job, and doing it well, is an exceptional way of getting respect, but there is nothing like showing off something cool to get instant cred. It's like we're in 8th grade again.

Which brings up an interesting conclusion that we came to in our coversation. The testing field needs to a mature a little before such problems will be alleviated. I think that when testing is taken as a serious discipline across the industry, testers will stop trying to be developers and start trying to be testers.