James Carr

Earlier today I found myself scavenging the PLOP site hoping to find some of the final drafts of the papers presented at PLOP 07 this year… no luck, but I did come across last years and, coincidentially, Martin, Noble & Biddle’s paper “Programmers are from Mars, Customers are from Venus: A practical guide for customers on XP Projects“, of which I happened to attend a session on at Agile 2007.

Geek Interpreter is one I find pretty valuable… although as developers we should strive to develop an ubiquitous language with our customer to describe domain details, sometimes we still let a little something leak through… and this is even more evident when dealing with legacy systems. Having a non technical person around to kind of help ground the conversation and keep everyone in line is beneficial. Just remember… a geek interpreter is NOT a substitute for programmer/customer communication, nor are they a buffer to “gather requirements from the customer and give them to the developers” either. They’re there to keep developers from saying at the beginning of the meeting…

“H3Y D00DZ, L3TZ C0D3 UP SUM ST0R1Z!!”

It’s well worth a read if, like me, you’re hoping to improve our working relationship with your customer.

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.

Jim Shore has written an excellent blog post (in rant mode) enumerating what he sees as the Five Ways to Misuse Fit.

And I couldn’t agree with him more.

Ever wanted to know what an agile software development environment looks like? Curious how teams are usually laid out, or just frankly interested in agile themed photos?

I’ve formed an “Agile Software Development” group on flickr… feel free to check it out and even submit any photos of your own.

On a side note, Friday we had a professional photographer onsite taking photos of us working… I’m going to try and see if I can snag a few for the group.

There’s something to be said about simplicity…

import org.springframework.orm.ibatis.support.SqlMapClientDaoSupport;

import roadrantz.model.Motorist;

public class IBatisRantDao extends SqlMapClientDaoSupport
							implements RantDao {
	public Motorist getMotoristById(long id) {
		return (Motorist) getSqlMapClientTemplate().
						queryForObject("getMotoristById", id);
	}

	public void saveMotorist(Motorist motorist) {
		getSqlMapClientTemplate().insert("saveMotorist", motorist);
	}

}

Since I’ve been pushing Spring quite a bit lately (what can I say… I like it!), a lot of people have continuously asked me, “why?” The most common question I keep getting is “What problems does it solve?” and when I mention all the features it has (dependency injection, wiring, bean management, event publishing/subscribing, etc) the response is always along the lines of “Why bother? Why not just handle the dependency injection yourself?” or “Any programmer worth their salt would be able to write a simple event handling mechanism.”

My thoughts on this is that Spring handles all the boring, mundane boilerplate work and allows developers to focus on what really matters in software… the domain. The domain is what drives business, and sadly while it is 90% of what makes the software important, it often goes ignored in favor of focusing on the mechanics of tying everything together in a system. And, to my dismay, I have on more than one occasion observed developers ignoring the domain all together (even at one of the DesignFest sessions I attended at OOPSLA, the developers tackled the problem by first designing the database tables and the ORM mapping to them).

So, long story short… I think that we as developers need to delegate non-domain work to frameworks as much as possible… why in this day in age we still let developers write custom O/R mapping solutions, dependency injection frameworks, and custom event dispatching systems on business projects is quite a mystery indeed… wouldn’t their talent and effort be better put to work by focusing on the business logic in their system instead?

This past weekend I had the joy to attend NFJS once again (thanks Paul!) and, for the 3rd time in a row, I’ve found it to be one of the best conferences I’ve ever attended… and that’s saying a lot when it has OOPSLA and Agile to showdown against. I think it’s the energy and effort that Jay Zimmerman puts into the whole thing.

The first thing different about this NFJS is that it was greatly smaller… it felt like there were only a handful of speakers and about half of the attendees from the last two Spring events I attended. However, it made up for quantity with quality… the sessions I attended were so fascinating that I actually skipped offers from my co-workers to go out drinking to tinker with the new things I learned (okay, I did take my laptop down to the hotel bar Saturday night to socialize and explore Spring AOP and JRuby).

The most eye opening concept that I took from the event was that I somehow had missed the boat on Spring and Aspect Oriented Programming… and I am very very angry at myself for letting these two pass under my radar undetected! I mean, I had even heard of Spring some 2 or 3 years ago when reading Fowler’s paper on Dependency Injection, but for some reason I never dabbled with it. FOr those unfamiliar, Spring is a pretty nifty application framework that brings all sorts of interesting things to the table, from Dependency Injection, Bean Management, ORM, nice extensions for plugging into 3 party frameworks like iBatis, AOP, and much much more. I went out on a limb and purchased 2 spring books… and I am halfway through Spring In Action.

Now to AOP… AOP is a solution to a problem that had always nagged me but I never really investigated the solutions I guess. What has always bugged me with things like logging and security logic is that alot of times the logic is built directly into my domain objects… weaving into it and dirtying up the purity of my domain model. Enter Aspect Oriented Programming… with aspects I can address my cross cutting concearns by isolating all of my logging and security code into aspects (or just Plain Old Java Objects using AspectJ and Spring) and writing the proper pointcuts to allow for interception of joinpoints of my application. Whew, that sounds like a lot for the uninitiated, but I’ll definately be posting a lot on AOP in the future, so bear with me.

I also attended some JSF sessions, as well as JRuby and Groovy sessions… which were also very top notch as well. As always, NFJS is a conference that cannot be missed.