The Tech Blog of Ken

Antipattern: Something Stupid and Rapid Development

Every experienced developer knows this scenario - you're coding all day, churning out all kinds of code, feeling really productive, and then WHAM!

You run into a problem that grinds all that productivity to a halt.  Sometimes for the next day or two, or worse. 

I call this Something Stupid, as in "I've been stuck for the last three days on Something Stupid".

by Dizzy Girl

Something Stupid is characterized by some innocuous coding error that creates a severe problem - could be a missing semi-colon, a stray tab character, or a missing XML tag. Something Stupid is usually accompanied by bizarre and misleading error messages and strange behavior. Unfortunately, you don't usually realize it's Something Stupid until you waste a few days diagnosing the problem.

Usually when I'm stuck in the midst of Something Stupid, it seems like some kind of hard problem. Sometimes, I have the hubris to think that there's a subtle bug in some library that I'm using. I remember once in college I was totally convinced that gcc had a bug when it was something in my own code. In Java, 9 out of 10 times it has something to do with something wrong with the classpath.  (Always remember this, java developers.) If the code is dealing with J2EE, it might be 95 out of 100.

Be careful to recognize the signs of Something Stupid and deal with it as such. Use the principle of Occam's Razor to look for low-level problems instead of complex ones. In the worst case, restore your code to the last known working state and redo your changes.

Wasting a lot of time dealing Something Stupid with is often a sign of something wrong with your development process. Maybe you need to use better source control practices, or to create some build/deployment scripts, or should take advantage of unit testing more effectively. Avoid things that generally cause strange problems, like using spaces in file and directory names.

The new breed of frameworks are not immune to this phenomenon. Ruby on Rails has been touted as a framework that offers at least 10X the productivity of other web frameworks. It's been sold as being free from the configuration hassles associated with frameworks like J2EE. It is indeed very fast to develop in Rails, but don't be fooled into complacency - Ruby/Rails is just as prone to Something Stupid. Perhaps even more so. Because of the dynamic nature of ruby and the heavy use of conventions in Rails, Something Stupid can be even harder to hunt down than in other environments.

get <oXygen/> and breathe a sigh of relief!

I've been doing some frustrating maintenance work on some XML/XSLT code. Working with XSLT is awkward enough as it is, but trying to debug XSLT problems without an interactive debugger is just maddening - it's like randomly poking in a black box.

A coworker was complaining about XML Spy, so I thought I'd take a look at the <oXygen/> XML editor. The interactive XSLT debugger is great! You can step through the XSL file, set breakpoints, look at the stack, and even use different XSL processors (choose from Xalan and a few versions of Saxon). I think I've regained my sanity now.

It's a little sluggish on my G4 PB15, but still very usable. The fact that it's java-based and therefore cross-platform is a big plus. My coworker is totally sold on it too - he loves the Outline view, real-time validation, and built-in spell-checker. Cheap, too at less than 50 bucks for a personal license.

super cheap SSL cert

I just picked up a RapidSSL (a subsidiary of GeoTrust) SSL certificate from a reseller called ServerTastic for the unbelievably low price of $26 for two years. Compare to Thawte, which is $150 for only a year. Works great.

It took a few hours for them to process the order, but after that it was smooth sailing. The reseller only handles the order - they use a payment gateway for handling the credit card and the RapidSSL site handles provisioning the cert, so it's pretty low-risk.

They only use Domain Control Validation to validate your identity, meaning that they call you on the phone (automated) and also send an email to the email address listed in your domain's WHOIS record. But you get an actual 128 bit certificate from RapidSSL, and it's not one of those junky chained certificates, either.

AOP in JavaScript?

Yes. AOP in JavaScript. Be afraid. Be very afraid.

Interview with Wil Shipley of Delicious Monster

DrunkenBlog (one of my favorite Mac-oriented blogs) has a fantastic interview with Wil Shipley of Delicious Monster where they discuss independent software development, Cocoa, and the history of Delicious Library. For those non-Mac users out there, Delicious Library is a really cool media manager (books, music, and games) for OS X. Worth a read if you harbor any fantasies about one day running a small software company.

Interviewing tip: look at the hardware

I was thinking today about trends during my career as a professional software developer, and it occurred to me that the overall quality of the work experience at various companies correlates roughly with the level of the hardware developers had for their workstations.

At what I would consider as my worst gig, all the developers had relatively slow laptops with small screens. Fine for other desk jobs, bad for developers. Everything related to development there was pure chaos. For example, once I started working there I learned that everyone had to share a single remote instance of Weblogic for developing EJBs, no local developer Weblogic installs allowed. Worst. Gig. Ever.

At my best gig, I was given a workstation that had pretty fast specs, lots of RAM, a nice big flat-panel monitor, and the workstation was upgraded every nine months or so. That gig was not without it's problems, but we managed to roll out a rather large scale enterprise app without being too late or having to work crazy overtime.

I'm not saying that developers can't be productive without the latest and greatest hardware, but rather that the developer hardware can reflect on the organization's attitudes towards software development. If a business doesn't care about a basic developer need like having a decent workstation, they probably don't place too high a value on developer productivity. There's a good chance that it won't be too keen on higher-level development activities like version control, defect tracking, and software process improvement, either. Of course, these things can be pretty obvious, but sometimes it's hard to find out during a short interview.

So next time you're interviewing as a developer, it wouldn't hurt to casually ask one of your potential future peers what kind of hardware (s)he's got under that desk. You might learn something.