James Carr

Sometimes life has a way of punching you in the gut when you least expect it, irreversibly changing your life forever. This morning I woke up and flipped open my laptop as usual for my morning RSS feed reeding to discover the screen was completely frozen, with the clock stopped at 3:20am… letting me know when the disaster had occurred. A reboot simply returned a cryptic “Grub Error 17″ and discontinued booting.

Anyhow, after running a few diagnostic tools from a boot disc utility my fears have been confirmed. My hard drive is dead. This is quite disappointing, as I didn’t quite expect it to happen on a laptop so new. Unfortunately, I have lost:

• Basically any code I have written since September, which includes a ton of AOP exercises, Scala examples, a funtime app I’ve been writing to run on Android, and quite a few other personal projects
• 10 Gigs worth of photos I hadn’t bothered uploading to flickr yet
• Notes and audio clips from Agile2007
• Documents and information on houses I’m currently looking at

I can kind of live with most of these being now lost, except for the code. Not only was some of it for personal development time projects in progress, but there were a lot of projects on my laptop that I was actively learning new things with. Arrggghh!!!

Anyhow, anyone have any idea where to find a new hard dive for a Sony Vaio PCG-6J1L?

Of course, my main resolution this year is to undo the 50 to 60 pounds I put on over the course of 2007 (it’s troubling when you increase your pants size by 8 sizes!), but in addition to that I have several goals for 2008 that I hope to accomplish. So, here they are, in no particular order:

• Learn Scala
• Become a complete expert at Struts 2
• Be a major advocate for adopting aspect oriented programming
• Facilitate the adoption of Spring
• Integrate at least one scripting language (Jython, JRuby, Groovy, Javascript) into an existing java system in a way that makes sense
• Be more active in the blogsphere
• Post more tutorials

Scala has just captured my interest a little. For those unfamiliar, here’s a quick snippet to whet your appetite:

/* Adding ! as a method on int's */
object extendBuiltins extends Application {
  def fact(n: Int): BigInt =
    if (n == 0) 1 else fact(n-1) * n
  class Factorizer(n: Int) {
    def ! = fact(n)
  }
  implicit def int2fact(n: Int) = new Factorizer(n)

  println("10! = " + (10!))
}

The last item on the list is a big goal to shoot for…. I have a ton of tutorials I’ve been asked to write, but for some reason I just haven’t gotten around to it. But I will this year, I promise.

Fear is quite obviously the worst emotion that any developer (agile or not) can succumb to… the fear to try new technologies, the fear to try something out, the fear to speak up, etcetera etcetera. The list goes on. In my honest opinion, fear is the one driving force that can break a development team and cost stakeholders time and money.

The fear to just “try it and see” would have to be the biggest one… and possibly the one I think is a root problem of any software development effort. We do “spikes” in XP for this very reason… so we can try something out and see how long it would take before giving our customer an estimate. Maybe it’s just easier than we thought it was, maybe not… either way, to just simply “try it and see” we are able to confidently tell our customers “X feature will probably be about 2 units of work” rather than muttering to ourselves “I have no idea how much work that could be, but it’s probably a lot!” and telling the customer that “X feature would probably be 12 units, just to be safe.” Argh… those large unit cards of uncertainty!

Some may take a different route… rather than trying something different, they’ll stick with what they know. This can be fine most of the time, except in the case where “stick with what you know” is shoehorned ad nauseam to the point of ridiculousness. How many times have you came across a nice 20 branch if-else if statement (okay, it’s rare, but it can be observed)? Or rather than investigating pre-made solutions to technical problems cross cutting a program, one might instead opt to “roll their own.” Sure, inventing your own custom made low level logging system is fun, but is it really giving the customer their most value? Of course, there DO exist cases where you may need a custom logging system, but just for the sake of the argument. In short, you should stick to what you know if it’s reasonable, but don’t be afraid to think out of the box and try something different. A programming problem could take a pair an hour that might take another full team days (or even weeks) depending how the problem is approached! If you find an alternative approach to solving a problem, just try it and see!

Finally, never ever ever be afraid to speak up. If your team is making a decision you disagree with, speak up! If they disagree with you, make sure you convey the information behind the “why” you disagree with them. Further, make sure you always participate with your customers… ask questions when they meet with you, be inquisitive, collaborate. If you ever have doubts or questions about a particular story or feature, never be afraid to get them on the line… I think in the end they’d rather you “bothered” them for a few minutes than build the wrong thing. Of course, if they consider your calls “bothering them”, you might have other issues.

I guess what I’m getting at in this long post is that every developer should champion courage as one of their traits… a successful developer is fearless… unafraid of change, unafraid of new technologies, unafraid to try something different out, and unafraid of any doubts in their mind.

Remember… do what you think is right, have courage, and above all, don’t let fear rule your development decisions.

This evening I was browsing some of the recent posts on the amsuing thedailywtf.com and was amused by a post that detailed a certain programmer’s predecessor’s trials and tribulations trying to fulfill the requirement to”programmatically send an email in .NET” and the source control log that details the programmer’s frustration of trying to send an email under windows 2003 by programmatically manipulating Microsoft Outlook.

Yes. Manipulating the UI of Microsoft Outlook to send an email. From .NET.

But it doesn’t end there, the programmer has a difficult time getting around Outlook’s “anti-hijacking feature” that prompts the user to click yes if they want to let the program send the email. So he goes back and forth to the drawing board, struggles with a custom coded attempt to trick Outlook, then finally reveals the solution:

2004-12-07 16:22 — Install, on the server, a newly purchased program called ClickYes that automatically clicks “Yes” to those dialogs.

After I stopped laughing, I did a little google seatch and discovered, yes, there IS a program called ClickYes! And it’s at version 2.2! I really couldn’t stop grinning, especially when I saw the hundred dollar server license fee and the fact that it also has an API hints that sadly a lot of people have used this as a “solution” to their “problem” of programmatically sending an email.

If only he had spent a second to use google.

Yesterday I was pretty amazed when I got to take a look at google’s newest web application, an online spreadsheet program. what really interested me though was when I was viewing some blogs I commonly read and I stumbled upon zohosheet, a very cool online spreadsheet program written completely in javascript on the client end and also allows users to upload and view excel files.

Pretty nifty. And without the silly invite only crud.