5/12/2010
In the previous post I’ve talked how a even in the most hostile environment one can do things that will help on the road for becoming a better programmer. fortunately however the scenario described in the previous post is quite rare and in most cases things are not as bad.
The following is probably a more reasonable scenario
A lone Developer in an indifferent organization
You discussed TDD with your boss and while he is not against it, he doesn’t see enough value in it . Most likely his reaction went along the lines of:
Yes, automated unit tests are great but …
On the other side, you generally get enough freedom as long as you get the job done. other team members also think TDD an interesting concept, but again no one has yet made any move.
Start Learning
If you find yourself in this situation (which I believe is quite common), there’s much you can do. As always you start out by learning. Books, blogs, lectures, videos,.. anything will do. There is even a slight chance you can persuade your company to spend some money and sent you to an actual TDD course.
Setting up a CI server
Next step is setting up of a Continuous Integration server. Yes, I’m serious. If you are going to practice TDD, you should have a full blown CI server at your disposal. Setting one up takes somewhere between 30 minutes to a few hours. The benefits are huge, and down the line it will definitely help you convince others (most managers just love the visibility given by a CI server)
BTW You don’t need a dedicated machine for this. If you can’t locate a spare machine (and any machine will do) just set it up on your own personal development station.
Picking out the toolset
Next step will be to pick up the actual toolset for TDD. the most important thing about it is not to let this slow you done. While there are several options out there for every technology, for the most part the differences between the tools will have no affect at this point. Later on you might want to change the tools but even if that happens the actual cost of switching is usually minimal, and you will have much better understanding then. Just pick the tools you feel will be the fastest to learn. Don’t let the tools get in the way.
Practice TDD.
Now comes the fun part. Just start doing TDD. Pick up you next programming task and allocate some time for doing it the TDD way. If possible try to pick a standalone piece of code if not never mind. Don’t worry about doing mistakes. Don’t worry if your tests doesn’t seem like unit tests at all, and don’t worry if your are not following the TDD rules by the letter. You are just learning. And remember, in most cases it can take a couple of hours, maybe even half a day to write the first test. Things will become easier as you gather more practice.
You are not alone
Starting out TDD is hard. Without help it’s even harder. The fact that you are alone in your organization doing TDD doesn’t mean you shouldn’t have any. Reach out to the mailing lists. Luckily The web is filled with very nice people which likes to help. It might take some time but you will get the answers you need. The real trick for succeeding in TDD is just to have patience. It take some time to master a new skill.
Share you accomplishment
Hopefully after a few weeks/months you will be able to demonstrate the real benefits of TDD. If you stick to doing it, you will overcome the initial issues and will prepare the ground for the team to follow. You will have real experience, and it will be much easier to convince others of the value in TDD.
But even if not, if you got to this point you already are a better programmer.
Posted in: 
Posts
0 comments:
Post a Comment