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.