Are we ready to go Groovy?

So in my last blog post, Contemplating Learning, I discussed what would cause you to start looking for new technologies.

Well let me lay out a scenario for you of where I'm at right now in this decision process. We have Project A that uses an old home grown persistence framework. And Project B that uses our new framework that is JPA based. Now the problem is that our old and new frameworks are highly incompatible, to the point that we do not want them both on the classpath at the same time. Now the problem is that Project A & B need to share a very large peice of pretty complicated code. The inputs to the shared code our large domain objects. And the output is many changed values on those input domain objects. The plan is that Project C will now house the shared code.

Project A's domain objects are classes that extend a goofy base class that does the dao work. Project B's domain objects are POJOs with the addition of JPA annotations. Since we are purely a Java shop Project C now needs to house a thrid domain object that is really a DTO. All 3 of these domain objects will always need to stay in sync. And the real bummer will be the transition code, Project A/B has a domain object then converts it to a DTO for Project C, then after C returns it the DTO needs to be converted back into Project A/B's domain object. Which leads to 4 more places that we need to maintain all of the getters and setters for each of these domain objects.

Enter Duck Typing. For those unfamiliar with duck typing the idea is: if walks like a duck and quacks like a duck then it is a duck. So in the case of our domain objects as long as Project A's & Project B's domain objects have the same set of getters and setters ( which is actually enforced because of the fact that they need to map the same table just in two different frameworks ) then we can just call all the getters and not worry about what kind of framework we are using, or for that matter what type of class we have. This will allow us the flexibility to move to some other future framework as well, and as long as we still have getters & setters the code will work just fine.

So Groovy solves the problem. Are there other ways, probably. In fact Ruby, Python, Perl, etc. would all solve the problem is a similar way. So why groovy? The biggest reason is that this isn't a decision about me using a new language, but rather the team using a new language. The big advantage of Groovy is that it is sooo close to Java that the other developers on our team, who pretty much know Java and that's it, can hopefully pick this up pretty well.

Now I know I could use a whole bunch more features of Groovy to make Project C even better, but if there is one thing that I've learned from the great minds that I pick everyday at work its baby steps. So by writing the Groovy to be as close to Java as possible we can take that first little baby step towards freedom from our insistence that Java is the only language that code can ever be written in. Although I do see many places in our code base that Java makes the most sense, this isn't one of them.

Time to pitch my idea to the powers that be and see what we come up with.

Contemplating Learning

Over time we must continue to add new tools to our tool box. This is one of the most important things that every developer and every development team must do. If we, as developers, continue to do nothing to improve our knowledge then we will quickly become obsolete and be doing nothing but maintenance work on legacy code in languages like COBOL. If we, as development teams, don't continue to progress and attempt to use new technologies, tools, and/or languages our code will quickly become out dated. There is a reason that teams do not ( or least not normal teams ) choose COBOL for green field development. That said the flip side is true as well. We need to be cautious to not practice RDD ( Resume Driven Design ). Choosing to write some code in Groovy just because Groovy happens to be your new flavor of the day language doesn't make for a good business model, just like forcing all code to be written in Java just because that's what we've always done, doesn't make a good business model.

So the first question to answer is how do you know when its time to look at a new tool/technology/language. I think the starting point is pretty obvious...does your current set up prevent you from accomplishing something. Now it doesn't have to be a total block, maybe it just makes something really really hard. Or maybe it forces you to write some horrible hackish code that you just know is going to be next to impossible to maintain.

The tough part is the next decision... Should I/we use said new technology. If it is an "I" question then the answer is probably yes. If this is for some home project or something along those lines then there is much much less convincing to do. As the pragmatic programmers have taught us, you should be teaching yourself a new language every year. Same thing if it is an "I" for a new tool that you are personally going to use that could make you more productive without impacting anybody else on your team. Well then go for it. What's the worst that could happen, it doesn't work out and you have to go back to doing things the way you used to.

If it is a "we" question well then it gets a whole lot tougher. You have to consider things like: what benefit does this bring beyond just my one task at hand? How difficult is it going to be to maintain this code for a developer that has never used this before? What's wrong with finding a way to do it the way we always have? What risk is involved? Is there a step learning curve? If the project turns into an epic fail can we recover by switching back to some other solution? If we can then why are we not using that other solution in the first place?

I think one of the biggest problems we get ourselves into is exactly first question...maybe the technology doesn't provide any benefit beyond the current task at hand, but if it solves that problem shouldn't we say its good enough for that task?

Over the next couple of blog post's I'll use Groovy as an example of going through this process of choosing whether or not its time to introduce a new language.